ทำให้วงจรครบด้วยการปรับปรุงที่ตรวจสอบแล้ว

กำหนดวงจรที่ต้องการทำให้ครบ

ซอฟต์แวร์สร้างหลักฐานระหว่างใช้งาน ได้แก่ error ความล่าช้า คำขอ support, incident ข้อค้นพบด้านการบำรุงรักษา และงานที่ต้องทำด้วยมือซ้ำ Lifecycle ที่ครบถ้วนนำหลักฐานนั้นกลับไปสู่การตัดสินใจทางวิศวกรรม

ซอฟต์แวร์ที่ปรับปรุงตัวเองอาจหมายถึงการใช้ automation ช่วยระบุ เสนอ ลงมือทำ และตรวจสอบการเปลี่ยนแปลง ไม่จำเป็นต้องหมายถึงโมเดลฝึกตัวเอง ระบุว่าส่วนใดเปลี่ยน: โค้ดแอปพลิเคชัน การกำหนดค่า test คำสั่ง workflow หรือพารามิเตอร์โมเดล

Self-healing คืนสภาพการทำงานที่รู้จัก Self-improvement เปลี่ยนระบบเพื่อให้ผลดีขึ้นในอนาคต ข้ออ้างอย่างหลังต้องมีการเปรียบเทียบและป้องกัน regression

ติดตามข้อสังเกตหนึ่งอย่างตลอด lifecycle

ลำดับด้านล่างเป็นวิธีทางวิศวกรรมที่เสนอ ไม่ใช่ข้ออ้างว่าผลิตภัณฑ์ใดทำทุกขั้นตอนได้เองทั้งหมด

เก็บลิงก์ระหว่างผลเหล่านี้ งานจาก postmortem ที่บอกว่า “ปรับปรุง monitoring” ตรวจสอบได้ยาก สัญญาณ ผู้รับผิดชอบ threshold และการตอบสนองที่ทดสอบแล้วซึ่งระบุชัด ทำให้สังเกตได้ว่างานเสร็จ

ให้การประเมินเป็นอิสระจากข้อเสนอ

Agent สร้าง patch และเสนอ test ได้ แต่ทีมยังต้องตรวจว่า test ตรวจพบปัญหาเดิมหรือไม่ เก็บชุดประเมินที่มีเวอร์ชัน ซึ่งการเปลี่ยนแปลงลดความเข้มงวดโดยเงียบ ๆ ไม่ได้

สำหรับ memory leak สมมติ ให้เปรียบเทียบ workload และเวอร์ชันที่เทียบเท่ากัน รวมการส่งออกขนาดใหญ่ การยกเลิก การลองใหม่ และกรณีปฏิเสธสิทธิ์ ใช้ข้อมูลสังเคราะห์ที่แทนโครงสร้างข้อมูลที่เกี่ยวข้องโดยไม่เปิดเผยระเบียนลูกค้า

ปฏิเสธการส่งออกที่เร็วขึ้นหากทำระเบียนหาย ข้าม authorization หรือเกินต้นทุนที่อนุญาต กำหนดข้อจำกัดก่อนเพิ่มประสิทธิภาพ มิฉะนั้นระบบอาจทำให้ตัวชี้วัดที่เลือกดีขึ้นแต่บริการแย่ลง

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

ออก release และวัดผล

Canary release เปิดเวอร์ชันที่เสนอให้กลุ่มจำกัดใช้ เปรียบเทียบสัญญาณจากเวอร์ชันที่เสนอกับกลุ่มควบคุม และกำหนดว่าจะขยายหรือหยุดเมื่อใด Traffic น้อยหรือ workload ต่างกันอาจทำให้เปรียบเทียบแล้วยังสรุปไม่ได้ แนวทาง canary

ทีมในสถานการณ์สมมติบันทึก baseline จาก workload สังเคราะห์ที่คงที่ ทดสอบการแก้ ออก release ภายในขอบเขตอนุมัติ และตรวจช่วง production ที่เปรียบเทียบได้ หากหลักฐานยังไม่พอ ให้บันทึกความไม่แน่ชัดแทนการประกาศว่าดีขึ้น

วัดงานที่ทำด้วยมือซ้ำด้วย Automation ลดงานซ้ำที่กินแรงได้ แต่ก็ต้องบำรุงรักษาและจัดการความขัดข้อง รวมต้นทุนเหล่านี้ในการตัดสินผล แนวทางลด toil

ทำให้บันทึกผลย้อนกลับใช้งานได้

ใช้รายการเหล่านี้ในแบบฝึก: ข้อสังเกตและเวอร์ชัน baseline สาเหตุที่เสนอ เกณฑ์การยอมรับ regression check การเปลี่ยนแปลงและการตรวจทาน ขอบเขต release ผลที่วัด ผู้รับผิดชอบและการทบทวนถัดไป

Taiga Maintaining เชื่อมข้อค้นพบใน repository กับงานแก้ไข Initiatives เชื่อมการเปลี่ยนแปลงที่ตั้งใจกับการวางแผนและการส่งมอบ สิ่งเหล่านี้เป็นส่วนหนึ่งของสายหลักฐาน ผู้รับผิดชอบบริการยังต้องตรวจสอบ deployment และผลการดำเนินงาน Maintaining, Initiatives

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