เคล็ดลับการออกแบบซอร์ฟแวร์เพื่อความยืดหยุ่น (Resiliency Design)

บทความนี้จะสำรวจและอธิบายเรื่องการออกแบบซอฟต์แวร์เพื่อความยืดหยุ่นหรือที่เรียกว่า Resiliency Design ซึ่งเป็นแนวคิดที่สำคัญอย่างมากสำหรับการออกแบบระบบสำคัญๆ โดยเฉพาะอย่างยิ่งสำหรับบริษัท Enterprise ที่ต้องการระบบที่สามารถที่เสถียรและพร้อมรับมือกับสถานการณ์ที่อาจเปลี่ยนแปลงหรือไม่แน่นอนที่อาจจะส่งผลกับระบบได้ในอนาคต

ในบทความนี้ผมได้อ้างอิงเนื้อหาบางส่วนจาก Resiliency white-paper ของบริษัท Microsoft นะครับ

Software Resiliency คืออะไร

“Resiliency" เป็นภาษาไทยแบบตรงตัวคือ "ความยืดหยุ่น" ซึ่งในที่นี้หมายถึงความสามารถในการรับมือกับสถานการณ์ที่ไม่ปกติที่อาจเกิดขึ้นกับซอฟต์แวร์ในอนาคต อย่างเช่นการเกิดข้อผิดพลาดของฮาร์ดแวร์ การทำผิดพลาดของมนุษย์ในการจัดการระบบ (human error) การเกิดภัยภิบัติ เป็นต้น ซึ่งความยืดหยุ่นนี้จะช่วยให้ระบบสามารถฟื้นตัวและทำงานต่อไปได้โดยไม่ต้องติดขัดหรือสูญเสียประสิทธิภาพ หรือทำให้ผู้ใช้งานสัมพันธ์กับซอฟต์แวร์ได้อย่างต่อเนื่อง ซึ่งเป็นสิ่งสำคัญในการออกแบบระบบซอฟต์แวร์ที่มีความเสถียรและมีประสิทธิภาพในระยะยาว

ก่อนที่เราจะออกแบบซอฟต์แวร์ มีหลักสำคัญที่เราควรคำนึงถึง 3 ประการดังนี้:

1. การป้องกันหรือลดปริมาณข้อผิดพลาดของซอร์แวร์ (Avoid the failure)
2. การเฝ้าระวังและตรวจจับข้อผิดพลาด (Monitor and detect the failure)
3. การตอบสนองต่อความผิดพลาดที่เกิดขึ้นแล้ว (Response to the failure)

กำหนดความยืนหยุ่นที่ระบบต้องการ (Resiliency requirements)

ก่อนที่เราจะเริ่มออกแบบซอฟต์แวร์ เราต้องเข้าใจและกำหนด Resiliency requirements (ความต้องการทางความยืดหยุ่น) ที่จะช่วยให้เรากำหนดค่าใช้จ่ายและทรัพยากรที่เกี่ยวข้องได้อย่างถูกต้อง

ซอฟต์แวร์แต่ละประเภทมีความต้องการความยืดหยุ่นแตกต่างกันไป ตัวอย่างเช่น ระบบการเรียนการสอนอาจต้องการความเสถียรในเวลาทำการและสามารถปิดตัวได้หลังจากเลิกใช้งาน ในทางกลับกัน ระบบการเงินอาจต้องการความเสถียรตลอด 24 ชั่วโมง เพื่อรองรับการทำธุรกรรมและการบริการให้กับลูกค้าตลอดเวลา การเข้าใจความต้องการทางความยืดหยุ่นเหล่านี้เป็นสิ่งสำคัญในการออกแบบซอฟต์แวร์เพื่อรองรับความยืดหยุ่นที่เหมาะสมซึ่งจะช่วยให้เรากำหนดค่าใช้จ่ายและทรัพยากรที่เกี่ยวข้องได้อย่างถูกต้อง

โดยทั่วไป ความต้องการความยืดหยุ่น (resiliency requirements) มักมีแนวคิดหลักที่มาจากสองประการหลัก คือ Availability (ความพร้อมใช้งาน) และ Metrics (ตัวชี้วัด)

ความพร้อมใช้งาน (Availability requirements)

Availability คือความสามารถของระบบซอฟต์แวร์ที่ต้องการทำงานได้ตลอดเวลาหรือในระยะเวลาที่กำหนด ความพร้อมใช้งานสูงสุดเพื่อให้ผู้ใช้สามารถเข้าถึงและใช้งานระบบได้ตลอดเวลาโดยไม่มีการขัดข้องหรือต้องรอเวลานาน หลักแนวคิดในการกำหนดความพร้อมในการใช้งานแบ่งออกได้ดังนี้

1. การแจกแจงการทำงานของระบบ (Decompose workload): การแยกแยะระบบเป็นส่วนๆ จะช่วยให้เราสามารถกำหนดความต้องการความยืดหยุ่น (resiliency requirements) ได้อย่างง่ายดายมากขึ้น ตัวอย่างเช่นในระบบการทำงานของธนาคาร อาจแบ่งออกเป็นระบบฝากเงิน ระบบถอนเงิน และระบบการโอนเงิน เป็นต้น แต่ละระบบนี้อาจมีความต้องการใช้งานที่แตกต่างกัน แม้ว่าจะอยู่ในซอฟต์แวร์เดียวกัน
2. การกำหนดข้อตกลงระดับการให้บริการ (Service Level Agreement - SLA): ตัวชี้วัด SLA จะกำหนดเป็นเปอร์เซ็นต์ อาทิเช่น SLA 99.99% หมายความว่าระบบจะไม่มีข้อผิดพลาดอย่างน้อย 99.95% ของเวลาที่กำหนด หรือกล่าวอีกนัยหนึ่งคือบริการจะไม่สามารถใช้งานได้ไม่เกิน 0.05% ของเวลาที่กำหนด ตัวอย่างเช่น ในหนึ่งปีมี 8,760 ชั่วโมง นั่นหมายความว่าระบบจะอณุญาตระบบให้มีข้อผิดพลาดได้ 8,760 x 0.05 = 4.38 ชั่วโมงต่อปี

ตัวชี้วัด (Metrics requirements)

Metrics เป็นตัวชี้วัดที่ใช้ในการประเมินและติดตามความสามารถของระบบซอฟต์แวร์ในเรื่องของความยืดหยุ่น ตัวชี้วัดจะกำหนดโดยระบบหรือองค์กร เช่น ระยะเวลาการกู้คืนหากเกิดข้อผิดพลาด, ระยะเวลาในการซ่อมแซมหรือปรับปรุงระบบ, หรือระดับการตอบสนองต่อความผิดปกติ ซึ่งตัวชี้วัดของ resiliency แบ่งออกได้เป็นดังนี้

• ระยะเวลาในการกู้คืนระบบ (RTO - Recovery Time Objective): ตัวชี้วัดนี้จะกำหนดระยะเวลา ที่มากที่สุดที่จะใช้ในการกู้คืนระบบเมื่อมีปัญหาเกิดขึ้น ระยะเวลาในที่นี้รวมไปถึงการดำเนินงานร่วมกันของผู้ดูแลระบบ (มนุษย์) และระยะเวลาที่ตัวระบบเองใช้ในการกู้คืนคนเองกลับสถานะปกติ เช่นการ reboot server, การกู้คืนข้อมูลจาก backup โดยทั่วไปแล้วระยะเวลากู้คืนจะอยู่ที่การดำเนินงานของผู้ดูแลระบบ (มนุษย์) ดังนั้นเราควรออกแบบระบบให้มีกระบวนการกู้คืนโดยอัติโนมัติให้มากที่สุด
• ปริมาณข้อมูลที่สามารถกู้คืนได้ (RPO - Recovery Point Objective): มาตรวัดนี้จะเป็นการกำหนดปริมาณข้อมูลที่มากที่สุดที่จะสามารถยอมให้สูญเสียได้ ตัวอย่างเช่น ถ้าเรามีระบบการสำรองข้อมูล (backup) ที่จะรันทุกๆหนึ่งชั่วโมง ค่า RTO ของเราคือ 1 ชั่วโมงเนื่องจากในขณะที่เกิดปัญหา ข้อมูลที่สำรองไว้อาจจะเป็นของหนึ่งขั่วโมงที่แล้ว
• ค่าเฉลี่ยที่ใช้ในการกู้คือระบบ (MTTR - Mean Time To Recover): คือค่าเวลาเฉลี่ยที่ใช้ในการกู้คืนระบบโดยรวม ตัวอย่างเช่น หากในหนึ่งปีมีการล่มของระบบจำนวน 10 ครั้งโดยคิดเป็นค่าการกู้คืนรวมทั้งหมด 4 ชั่วโมง (240 นาที) ค่าเฉลี่ยที่ใช้ในการกู้คืนระบบคือ 240/10 ซึ่งก็คือ 24 นาทีนั่นเอง
• ค่าเฉลี่ยระหว่างการล่มของระบบ (MTBF - Mean Time Between Failure): ค่านี้จะเป็นการชี้วัดว่าระบบมีความน่าเชื่อถือมากน้อยแค่ไหน ยิ่งตัวเลขมากยิ่งแสดงถึงความน่าเชื่อถือได้มาก ตัวอย่างเช่นหากภายในหนึ่งวันมีการล่มของระบบ 2 ครั้งโดยนับเวลาที่ระบบใช้การไม่ได้เป็น 4 ชั่วโมง นั่นแสดงว่าระยะเวลาที่ระบบใช้ได้ในวันนั้นมีจำนวน 20 ชั่วโมง MTBF ของระบบจึงเป็น 20/10 = 10 ชั่วโมง

กลยุทธ์การพัฒนาซอร์ฟแวร์เพื่อรองรับตามลักษณะของข้อผิดพลาด (Failure types)

หลังจากที่ได้ทำความเข้าใจการกำหนด requirements ของระบบไปแล้ว ขั้นตอนนี้จะเป็นการพัฒนาระบบเพื่อที่จะรับมือกับความผิดพลาดชนิดต่างๆที่อาจเกิดขึ้นได้ โดยเราสามารถแจกแจงความผิดพลาดของระบบได้เป็นข้อย่อยๆดังนี้

Hardware failure - ความผิดพลาดที่เกิดจากฮาร์ดแวร์

ความผิดพลาดชนิดนี้เกิดจากความเสียหายของอุปกรณ์ย่อยๆในระบบ ตัวอย่างเช่น ฮาร์ดดิสเสียหาย สายเชื่อมต่อสัญญาณขาดหาย

วิธีป้องกัน: ความผิดพลาดของฮาร์ดแวร์สามารถป้องกันได้ด้วยการสร้างระบบซ้ำซ้อน (redundancy) ของฮาร์ดแวร์ที่อยู่ต่างสถานที่กัน ตัวอย่างเช่นใช้ฮาร์ดิสสองตัวที่อยู่คนละเซิร์ฟเวอร์ หรือเพิ่มจำนวนทางเข้าออกของระบบเน็ตเวิร์ค

Data center failure - ความผิดพลาดที่เกิดจากศูนย์ข้อมูล

ความผิดพลาดชนิดนี้เกิดจากการศูนย์ข้อมูลล่ม ตัวอย่างเช่น เกิดไฟฟ้าดับ หรือเกิดอุบัติเหตุกับศูนย์ข้อมูลนั้นๆ

วิธีป้องกัน ความผิดพลาดชนิดนี้ป้องกันได้ด้วยการสร้างระบบซ้ำซ้อนระหว่างศูนย์ข้อมูลหรือในทาง cloud computing จะเรียกว่า available zone นั้นเอง ตัวอย่างเช่นหากเราแบ่งโซนเป็นภาคกลาง ศูนย์ข้อมูลอาจจะกระจายอยู่ในจังหวัดที่ห่างไกลกันเช่น กรุงเทพ สมุทรปราการ นนทบุรี

Regional failure - ความผิดพลาดที่เกิดขึ้นระดับภูมิภาค

ความผิดพลาดชนิดนี้เป็นความผิดพลาดที่เกิดในวงกว้างที่สุดเป็นระดับภูมิภาค ความผิดพลาดชนิดนี้อาจเกิดจากภัยพิบัติหรือสงครามที่ทำให้ศูนย์ข้อมูลที่อยู่ในบริเวณนั้นเสียหายได้ทั้งหมด

วิธีป้องกัน ความผิดพลาดชนิดนี้ป้องกันด้วยการสร้างระบบซ้ำซ้อนระหว่างภูมิภาค เช่นการ deploy ระบบของเราไปในประเทศที่อยู่ห่างกัน

Transmission failure - ความผิดพลาดที่เกิดจากการส่งข้อมูล

ความผิดพลาดชนิดนี้เกิดได้จากการที่ระบบเน็ตเวิร์คส่งข้อมูลได้ไม่เสถียร การส่งข้อมูลอาจมีการทำได้ไม่ต่อเนื่อง เนื่องจากมีการติดดับเป็นระยะ

วิธีป้องกัน เราสามารถป้องกันข้อผิดพลาดชนิดนี้ด้วยการออกแบบระบบให้มีการส่งซ้ำ (retry logic) ตัวอย่างเช่นฝั่ง client ควรจะมีการตรวจสอบว่าการส่งข้อมูลสำเร็จหรือไม่ หากส่งไม่สำเร็จจะต้องมีการทำซ้ำในระยะเวลาที่กำหนด

Dependency failure - ความผิดพลาดที่เกิดจากระบบภายนอก

ความผิดพลาดชนิดนี้เกิดจากระบบภายนอกที่ซอร์ฟแวร์ทำงานด้วยซึ่งอยู่เหนือการควบคุมของเรา ตัวอย่างเช่น ซอร์ฟแวร์ของเราต้องทำการติดต่อกับ Google map เพื่อนำข้อมูลมาแสดงให้ user ทราบ Google map คือระบบภายนอกที่จะส่งผลกับซอร์ฟแวร์เราหากเกิดการล่มหรือพังขึ้นมา

วิธีแก้ไข ความผิดพลาดชนิดนี้เป็นความผิดพลาดที่อยู่นอกเหนือการควบคุมทำให้เราอาจจะวางแผนในการป้องกันได้ยาก อย่างไรก็ตามเราสามารถวางแผนในการแก้ไขได้ด้วยการสำรองข้อมูล หรือออกแบบระบบให้สามารถทำการหยุดสื่อสารกับระบบภายนอกเป็นการชั่วคราวได้ ตัวอย่างเช่น เราอาจจะเก็บข้อมูลที่ต้องทำการติดต่อกับระบบภายนอกไว้ในฐานข้อมูลและนำมาดำเนินการใหม่เหมือนระบบภายนอกกลับเข้าสู่สภาวะปกติ

อีกกลยุทธ์ที่ใช้เพื่อรับมือกับความผิดพลาดของระบบภายนอกคือการออกแบบให้ยอมรับความผิดพลาดนั้นๆ (Degrade gracefully) ตัวอย่างเช่นแทนที่จะส่งข้อมูลเปล่าๆกลับไปให้ user ให้ส่งข้อมูลกลับไปบอกว่าระบบมีปัญหาและกำลังทำการแก้ไขแทน

Heavy load failure - ความผิดพลาดที่เกิดจากปริมาณข้อมูลที่มหาศาล

ความผิดพลาดชนิดนี้เกิดจากการที่ระบบต้องรองรับข้อมูลมหาศาลในเวลาพร้อมกัน ทำให้เกิดอาการ over load และทำให้ระบบพังลงได้

วิธีป้องกัน heavy load แก้ไขได้ด้วยการกระจายโหลดไปยังระบบย่อยๆให้ช่วยกันทำงานโดยใช้ load balancer เขามาช่วยกระจาย load เหล่านี้ การใช้ auto-scaling ในระบบ cloud หรือระบบ container ก็เป็นอีกวิธีที่มีประสิทธิภาพในการรับมือกับข้อผิดพลาดเช่นนี้

Accidental deletion - ความผิดพลาดที่เกิดจากการทำลายข้อมูลโดยไม่ได้ตั้งใจ

ความผิดพลาดชนิดนี้เกิดขึ้นได้จากข้อผิดพลาดของมนุษย์ (human error) หรือการผิดพลาดของการจัดเก็บข้อมูลของระบบที่ทำให้ข้อมูลเสียหาย (data corruption)

วิธีป้องกัน วิธีป้องกันข้อผิดพลาดเช่นนี้ทำได้โดยการสำรองข้อมูลอย่างสม่ำเสมอ

Deployment failure - ความผิดพลาดที่เกิดจากขั้นตอนการติดตั้งซอร์ฟแวร์

ข้อผิดพลาดชนิดนี้เกิดขึ้นในขั้นตอนการติดตั้งหรืออัปเดทซอร์ฟแวร์ (Deployment process) ซึ่งในหลายๆครั้งอาจก่อให้เกิดเหตุการณ์ที่ไม่คาดคิดได้

การป้องกันข้อผิดพลาดในขั้นตอนนี้ทำได้หลายวิธีดังนี้

• วางแผนการย้อนกลับ (rollback plan): วิธีนี้เป็นการวางแผนในการดำเนินการให้ซอร์ฟแวร์ย้อนกลับไปยังเวอร์ชั่นเดิมที่ไม่มีปัญหา
• การติดตั้งแบบ ฟ้า-เขียว (blue-green deployment): วิธีการนี้จะเป็นการติดตั้งระบบใหม่เข้าไปก่อนและทำการยืนยันว่าระบบติดตั้งเสร็จสมบูรณ์ หลังจากนั้นจึงค่อยเปลี่ยน traffic ไปยังระบบใหม่และลบระบบเก่าทิ้ง
• การติดตั้งแบบคานารี่ (canary deployment): วิธีการนี้จะคล้ายๆกับแบบ blue-green โดยจะค่อยปล่อย traffic ให้ไหลเข้าไปในระบบใหม่และค่อยๆตรวจสอบเพิ่มปริมาณ traffic เข้าไปในระบบใหม่จนเสร็จสมบูรณ์
• ใช้การเขียนโค้ดในการติดตั้ง (IaC - Infrastructure as a code): วิธีการนี้จะเป็นการลดปริมาณการทำมือ (manual) และทำให้การติดตั้งหรือเปลี่ยนแปลงโครงสร้างของระบบเกิดข้อผิดพลาดน้อยที่สุด การใช้ IaC ยังทำให้การ rollback ระบบง่ายขึ้นอีกด้วย ตัวอย่างเครื่องมือ IaC ที่นิยมใช้ในปัจจุบันคือ Terraform, Ansible playbook
• ใช้ระบบ CICD (Continuous deployment continuous integration): CICD เป็นระบบที่ช่วยลดขั้นตอนการทำซ้ำในการติดตั้งซอร์ฟแวร์ เครื่องมือจะตรวจสอบการเปลี่ยนแปลงและดำเนินขั้นตอนการ deploy โดยอัติโนมัติ เช่น การรันเทส ดาวโหลดทรัพยากรณ์ และ build binary และทำการ deploy
• ไม่ใช้การเปลี่ยนแปลงโครงสร้างในการติดตั้ง (Immutable infrastructure): การติดตั้งชนิดนี้เป็นการติดตั้งของใหม่เข้าไปแทนที่ของเก่าเลย ไม่ใช่เป็นการไปแก้ไขของเก่า ตัวอย่างเช่นการ deploy application เข้าไปใน container ลูกใหม่แทนที่จะเข้าไปแก้ไขของเก่าที่รันอยู่แล้ว เนื่องจากการแก้ไขของเก่าอาจสร้างความผิดพลาดได้ง่ายกว่า

การวิเคราะห์โหมดการล้มเหลว (Failure Mode Analysis - FMA)

เทคนิคนี้เป็นกระบวนการที่ใช้วิเคราะห์ศึกษาโครงสร้างและกระบวนการทำงานของระบบเพื่อระบุและวิเคราะห์ความเป็นไปได้ของสิ่งที่จะก่อให้เกิดความล้มเหลวต่อระบบ รวมถึงความเสียหายและผลกระทบที่จะเกิดขึ้น

ในการวิเคราะห์โหมดการล้มเหลวของระบบ เราควรจะตอบคำถามสำคัญดังนี้ได้

• ระบบจะสามารถตรวจจับความล้มเหลวชนิดนั้นๆได้อย่างไร
• ระบบจะตอบสนองกับความล้มเหลวอย่างไร
• ระบบจะทำการบันทึกและเฝ้าระวังความล้มเหลวชนิดนั้นได้อย่างไร

ขั้นตอนในการทำ FMA

1. แยกส่วนประกอบระบบของออกเป็นส่วนสำคัญๆต่าง ทั้งส่วนที่เป็นของภายในระบบและภายนอกระบบ
2. เมื่อแยกระบบออกมาเป็นส่วนต่างๆได้แล้ว ให้กำหนดโหมดของข้อผิดพลาดที่สามารถเกิดขึ้นได้ในส่วนนั้นๆ เช่น โหมดการอ่านข้อมูล โหมดการเขียนข้อมูล
3. เมื่อได้แยกระบบและโหมดต่างๆแล้ว ให้ประเมิณความเสี่ยง (risk) ที่ต่อโหมดนั้นๆ
   1. ความน่าจะเป็นที่จะเกิดข้อผิดพลาดนั้น (ใช้วิธีประมาณเอาได้)
   2. ความเสียหายที่น่าจะเกิดขึ้น เช่น ความเสียหายต่อข้อมูล ค่าใช้จ่าย ความเสียหายต่อธุรกิจ
4. ในแต่ละโหมดวางแผนและกำหนดว่า เราจะสามารถ “ตรวจจับ” “ตอบสนอง” และ “กู้คืน” ระบบกลับมาได้อย่างไร

การทดสอบสถานการณ์ความผิดพลาด (Fault Injection Testing)

เราควรจะทดสอบสถานการณ์ข้อผิดพลาดก่อนที่จะเกิดขึ้นจริงเนื่องจากจะทำให้เรามั่นใจได้ว่าแผนที่เราวางไว้ เป็นไปตามแผน ซึ่งการทดสอบความผิดพลาดทำได้ 2 วิธีดังนี้

1. กระตุ้นสถานการณ์ข้อผิดพลาด (Fault Triggering): เราสามารถกระตุ้นเหตุการณ์ที่เป็นข้อผิดพลาดเพื่อทดสอบระบบในการตรวจจับและการกู้คืน ตัวอย่างเช่นการปิดเซิร์ฟเวอร์ การทำให้ใบรับรองหมดอายุ หรือการตัดการเชื่อมต่อเครือข่าย
2. จำลองสถานการณ์ (Simulation): เราสามารถทำการจำลองสถานการณ์ต่างๆ เพื่อทดสอบระบบ เช่น การทดสอบโหลดหน่วยประมวลผล (Load testing) หรือการจำลองสถานการณ์การเกิดภัยพิบัติ (Disaster recovery drill)

การเฝ้าระวังและตรวจจับข้อผิดพลาด (Monitor and detection)

ในขั้นตอนนี้เราต้องมาทำการวางกลยุทธ์ว่าเราจะสามารถตรวจจับข้อผิดพลาดของระบบให้ทันท่วงทีได้อย่างไรซึ่งขั้นตอนการเก็บข้อมูลเพื่อทำการเฝ้าระวังจะเกิดเป็นลำดับดังนี้

1. การกำหนดแหล่งข้อมูล (Instrumentation): เราต้องกำหนดแหล่งที่มาของข้อมูลที่เราต้องการเฝ้าระวัง เช่น บันทึกแอปพลิเคชัน (application logs), ข้อมูลเกี่ยวกับประสิทธิภาพของระบบปฏิบัติการ (OS), ทรัพยากรการตรวจสอบ Azure, สถานะและการสมัครสมาชิกของ Azure, และข้อมูลเชิงพื้นที่ Azure เป็นต้น
2. ขั้นตอนการจัดเก็บข้อมูลและบันทึก (Collection and Storage): เนื่องจากข้อมูลที่เราได้มาจากแหล่งต่าง ๆ อาจมีรูปแบบที่แตกต่างกัน เราจึงต้องทำการแปลงรูปแบบข้อมูลและจัดเก็บข้อมูลให้เรียบร้อยในระบบฐานข้อมูล
3. ขั้นตอนการวิเคราะห์และหาข้อผิดพลาด (Analysis and Diagnosis): ในขั้นตอนนี้ เราใช้คิวรีเพื่อค้นหาและวิเคราะห์ข้อมูลที่เราต้องการ เช่นการตรวจสอบเงื่อนไขหรือการวิเคราะห์ข้อมูลเพื่อค้นหาความผิดปกติ
4. ขั้นตอนการจัดแสดงและการแจ้งเตือน (Visualization and Alert): ในขั้นตอนสุดท้าย เราสร้างรายงานและสร้างระบบแจ้งเตือนเพื่อแสดงผลข้อมูลและแจ้งเตือนผู้ใช้เมื่อเกิดเหตุการณ์ที่สำคัญ การจัดแสดงข้อมูลเหล่านี้ช่วยให้เราเข้าใจข้อมูลและตอบสนองต่อข้อผิดพลาดหรือความผิดปกติในระบบอย่างมีประสิทธิภาพ

สรุป

ลองจินตนาการว่าวิศวกรโครงทำการออกแบบสะพานที่ไม่สามารถรับมือกับน้ำท่วม ลมพัด หรือแผ่นดินไหวได้เลย ผลงานของวิศวกรคนนั้นก็จะก่อให้เกิดอันตรายแก่ผู้ใช้และไม่สามารถเรียกคนผู้นั้นว่าเป็นวิศวกรที่ดีได้

Software Engineer ก็เช่นกัน หน้าที่ของ Software Engineer ไม่ได้มีแค่การสร้าง application หรือ software ให้เสร็จไปเท่านั้น แต่การคิดและการมี mindset ในการออกแบบเพื่อความยืดหยุ่นหรือ resiliency design นี้เป็นคุณสมบัติที่สำคัญเป็นอย่างมาก ในยุคที่เทคโนโลยีเข้าสู่ทุกส่วนของชีวิตเรา การออกแบบซอฟต์แวร์ที่ยั่งยืนและปลอดภัยเป็นสิ่งสำคัญที่ทำให้ผู้ใช้เกิดความมั่นใจและความสบายในการใช้งาน

สอบถาม ติชม เสนอแนะ ได้ที่ช่อง comment ด้านล่างเลยครับ