คู่มือองค์กรสำหรับการแก้ไขด้วย AI ที่มีการกำกับดูแล

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

เอเจนต์ช่วยเร่งการตรวจสอบ ส่วนมนุษย์เป็นผู้อนุญาตทุกสิ่งที่เปลี่ยนแปลงโปรดักชันหรือเส้นทางข้อมูลภายใต้กฎระเบียบ

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

เอเจนต์เหล่านี้จะไม่แพตช์โปรดักชันอย่างเงียบ ๆ แต่จะเตรียมชุดการเปลี่ยนแปลงที่ตรวจทานได้

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

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

ผู้อนุมัติที่ระบุชื่อ การแบ่งแยกหน้าที่ และบทบาท break-glass สำหรับกรณีฉุกเฉินสามารถกำหนดค่าได้ การอนุมัติจะบันทึกว่าใคร เมื่อใด และนโยบายเวอร์ชันใดที่ถูกนำมาใช้

การผสานรวมกับเครื่องมือ ITSM เป็นเรื่องปกติสำหรับการรีลีสที่สอดคล้องกับ CAB

บทบาทจะแยกสิทธิ์การเสนอ การอนุมัติ และการดีพลอยออกจากกัน QA อาจอนุมัติการเปลี่ยนแปลงเทสต์ ส่วนหัวหน้าทีมแพลตฟอร์มอนุมัติการเปลี่ยนแปลงโครงสร้างพื้นฐาน เอเจนต์จะสืบทอดสิทธิ์น้อยที่สุดตามบทบาท

การตรวจทานสิทธิ์การเข้าถึงเป็นระยะควรรวมบัญชีบริการของเอเจนต์และตัวตนของตัวรันด้วย

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

การเริ่มจากสเตจจิงก่อนช่วยลดการทำงานซ้ำและให้ขอบเขตที่ชัดเจนแก่ผู้ตรวจสอบ

เอเจนต์จะเปิด pull request พร้อมหลักฐาน แผนการทดสอบ และขั้นตอนการย้อนกลับที่เชื่อมโยงกัน ผู้ตรวจทานจะแสดงความเห็นในเครื่องมือที่คุ้นเคย เมื่อมีการ merge จะทริกเกอร์ชุดการตรวจยืนยันโดยอัตโนมัติ

ฟลว์ที่ใช้ PR ช่วยรักษาวัฒนธรรมการรีวิวโค้ดไว้ในขณะที่ลดเวลาในการร่าง

ทุกข้อเสนอจะรวมคำแนะนำการย้อนกลับและขอบเขตการตรวจยืนยันหลัง merge การตรวจยืนยันที่ล้มเหลวจะบล็อกการเลื่อนระดับและเปิดการวิเคราะห์ใหม่

ควรซ้อมการย้อนกลับในช่วง PoC ไม่ใช่ตอนเกิดเหตุการณ์ครั้งแรก

ชุดหลักฐานสำหรับการตรวจสอบประกอบด้วยรหัสการรัน อาร์ติแฟกต์ ตัวตนของผู้อนุมัติ แฮชของดิฟฟ์ และผลการตรวจยืนยัน ซึ่งส่งออกได้สำหรับการตรวจทาน SOC, ISO หรือความเสี่ยงภายใน

การเก็บรักษาสอดคล้องกับกำหนดการปฏิบัติตามข้อกำหนดของคุณ ไม่ใช่แค่ค่าเริ่มต้นของผู้จำหน่ายเพียงอย่างเดียว

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

ฟลีตการแก้ไข นำเวิร์กโฟลว์นี้ไปใช้งานใน Zof AI