กำหนดขอบเขตที่ปลอดภัยสำหรับ self-healing

กู้คืนจากเงื่อนไขที่รู้จัก

Self-healing ตรวจพบความขัดข้องที่กำหนดโดยอัตโนมัติ และพยายามกู้คืนด้วยการกระทำที่ได้รับอนุญาต ตัวอย่างคือเริ่ม process ที่ล้มเหลวใหม่หรือแทนที่ instance ที่ผิดปกติ การกระทำต้องเหมาะกับความขัดข้องและโมเดลสถานะของบริการ

Kubernetes แทนที่ instance ของ workload ที่ล้มเหลวและปรับให้ตรงกับสถานะที่ประกาศไว้ได้ แต่ไม่ได้แก้ตรรกะแอปพลิเคชันที่ผิดหรือความขัดข้องของ storage ทุกแบบ การกู้คืนโครงสร้างพื้นฐานกับความถูกต้องของซอฟต์แวร์ต้องใช้การตรวจสอบต่างกัน Kubernetes self-healing

กำหนดเป้าหมายก่อนกลไก การกู้คืนการส่งออกหมายถึงงานที่เข้าเกณฑ์เสร็จอย่างถูกต้อง Container ที่ทำงานอยู่เป็นเพียงเงื่อนไขก่อนหน้าข้อหนึ่ง

แยกการเปลี่ยนแปลงสามประเภท

Agent อาจเสนอการแก้หลังการกู้คืน ข้อเสนอนั้นเป็นการเปลี่ยนซอฟต์แวร์ใหม่ ต้องไม่ได้รับอำนาจไม่จำกัดต่อมาจาก controller กู้คืน

Controller ต้องไม่แก้เกณฑ์ความสำเร็จของตัวเองเมื่อการตรวจไม่ผ่าน มิฉะนั้นระบบอาจรายงานว่าดีขึ้นโดยไม่ได้ทำให้บริการดีขึ้น

เขียนนโยบายกู้คืนก่อนเปิดใช้

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

ใช้ตัวตนที่มีสิทธิ์เท่าที่จำเป็น บันทึกเวอร์ชันนโยบาย หลักฐานที่ทำให้เริ่ม การกระทำ ทรัพยากร และผล จัดให้มีวิธีปิด controller ที่เป็นอิสระ กำหนดคนที่รับผิดชอบรับเรื่องยกระดับ

ทดสอบเส้นทางความขัดข้องควบคู่กับการกู้คืนสำเร็จ

การลองใหม่อาจทำผลข้างเคียงซ้ำ Worker อาจเก็บไฟล์แล้วหยุดก่อนยืนยันงาน ตรวจสอบ idempotency ก่อนอนุญาตให้ทำอีกครั้ง ดูตัวอย่างความขัดข้องแบบ cloud native

การลองใหม่อาจซ้ำเติม dependency ที่โหลดเกินด้วย จำกัดจำนวนครั้ง ใช้ timeout และ backoff ที่เหมาะสม หลีกเลี่ยงการลองใหม่พร้อมกันทุก instance AWS อธิบายว่า backoff และ jitter ช่วยลดการซ้ำเติมนี้อย่างไร แนวทางการลองใหม่

ทดสอบนโยบายสมมติกับสามกรณี Worker ที่หยุดหนึ่งตัวควรกู้คืนได้ ฐานข้อมูลล่มควรทำให้ไม่แทนที่ซ้ำ ความผิดปกติด้านความถูกต้องครบถ้วนที่ยังไม่แน่ชัดควรหยุด automation และขอการตัดสินใจตอบสนอง

ตรวจกรณี telemetry ขาดด้วย Heartbeat ที่หายอาจหมายถึง worker ขัดข้องหรือเส้นทางเก็บข้อมูลขัดข้อง Controller ต้องมีหลักฐานเพียงพอสำหรับการกระทำ ไม่ใช่ความมั่นใจในคำอธิบายจาก AI

วัดว่านโยบายช่วยหรือไม่

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

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