Failure management

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

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

คำถามต่อไปนี้จะเน้นที่การพิจารณาด้านความน่าเชื่อถือ:

REL 9: คุณสำรองข้อมูลอย่างไร? สำรองข้อมูล แอปพลิเคชัน และการตั้งค่าเพื่อให้เป็นไปตามข้อกำหนดด้านระยะเวลาที่ใช้ในการกู้คืน (RTO) และจุดเวลาที่ใช้ในการกู้คืน (RPO)
REL 10: คุณใช้การแยกส่วนความผิดพลาด (Fault Isolation) เพื่อปกป้องเวิร์กโหลดอย่างไร? การแยกส่วนความผิดพลาดจะจำกัดผลกระทบของส่วนประกอบหรือความล้มเหลวของระบบให้อยู่ภายในขอบเขตที่กำหนด หากมีการแยกส่วนที่เหมาะสม ส่วนประกอบที่อยู่นอกขอบเขตจะไม่ได้รับผลกระทบจากความล้มเหลวนั้น การรันเวิร์กโหลดข้ามขอบเขตการแยกส่วนความผิดพลาดหลายแห่งจะช่วยให้ระบบทนทานต่อความล้มเหลวได้มากขึ้น
REL 11: คุณออกแบบเวิร์กโหลดอย่างไรให้ทนทานต่อความล้มเหลวของส่วนประกอบ? เวิร์กโหลดที่มีความต้องการความพร้อมใช้งานสูง (High Availability) และค่าเฉลี่ยเวลาที่ใช้ในการกู้คืนต่ำ (MTTR) จะต้องได้รับการออกแบบสถาปัตยกรรมเพื่อความยืดหยุ่นทนทาน (Resiliency)
REL 12: คุณทดสอบความน่าเชื่อถืออย่างไร? หลังจากที่คุณออกแบบเวิร์กโหลดให้ทนทานต่อแรงกดดันในสภาวะการใช้งานจริงแล้ว การทดสอบเป็นวิธีเดียวที่จะยืนยันได้ว่าระบบจะทำงานตามที่ออกแบบไว้และมอบคุณสมบัติทนทานตามที่คุณคาดหวัง
REL 13: คุณวางแผนการกู้คืนความเสียหาย (Disaster Recovery - DR) อย่างไร? การมีระบบสำรองข้อมูลและส่วนประกอบเวิร์กโหลดที่ซ้ำซ้อนเป็นจุดเริ่มต้นของกลยุทธ์ DR โดยมี RTO และ RPO เป็นเป้าหมายในการกู้คืนเวิร์กโหลดของคุณ ควรตั้งค่าเป้าหมายเหล่านี้ตามความต้องการทางธุรกิจ และใช้กลยุทธ์เพื่อให้บรรลุเป้าหมายโดยคำนึงถึงสถานที่ตั้ง หน้าที่ของทรัพยากร และข้อมูล นอกจากนี้ โอกาสที่จะเกิดการหยุดชะงักและต้นทุนการกู้คืนยังเป็นปัจจัยสำคัญที่ช่วยประเมินคุณค่าทางธุรกิจในการจัดเตรียมระบบกู้คืนความเสียหายสำหรับเวิร์กโหลด

ควรสำรองข้อมูลเป็นประจำและทดสอบไฟล์สำรองเพื่อยืนยันว่าคุณสามารถกู้คืนจากข้อผิดพลาดทั้งทางตรรกะ (Logical) และทางกายภาพ (Physical) หัวใจสำคัญในการจัดการความล้มเหลวคือการทดสอบเวิร์กโหลดด้วยระบบอัตโนมัติบ่อยๆ เพื่อให้เกิดความล้มเหลวแล้วสังเกตว่าระบบกู้คืนอย่างไร ควรทำสิ่งนี้ตามตารางเวลาที่สม่ำเสมอและตรวจสอบว่ามีการทดสอบดังกล่าวหลังจากการเปลี่ยนแปลงที่สำคัญของเวิร์กโหลดด้วย ติดตาม KPI รวมถึง RTO และ RPO อย่างจริงจังเพื่อประเมินความยืดหยุ่นของเวิร์กโหลด (โดยเฉพาะภายใต้สถานการณ์การทดสอบความล้มเหลว) การติดตาม KPI จะช่วยให้คุณระบุและบรรเทาจุดล้มเหลวเพียงจุดเดียว (Single point of failure) วัตถุประสงค์คือเพื่อทดสอบกระบวนการกู้คืนเวิร์กโหลดของคุณอย่างละเอียด เพื่อให้มั่นใจว่าคุณสามารถกู้คืนข้อมูลทั้งหมดและให้บริการลูกค้าต่อไปได้ แม้จะเผชิญกับปัญหาที่ต่อเนื่องยาวนาน กระบวนการกู้คืนของคุณควรได้รับการฝึกฝนให้เชี่ยวชาญพอๆ กับกระบวนการทำงานปกติในสภาพแวดล้อมจริง