การแก้ไขและการกำกับดูแล
คู่มือองค์กรสำหรับการแก้ไขด้วย AI ที่มีการกำกับดูแล
Close the reliability loop with governed remediation that reproduces, diagnoses, proposes, and verifies, always under human authorization.
Zof AI Reliability Practice
คู่มือระดับองค์กร · ระบบอัตโนมัติที่มีการกำกับดูแล
ระบบอัตโนมัติที่มีการกำกับดูแลเป็นค่าเริ่มต้น: การอนุญาตจากมนุษย์สำหรับการแก้ไขที่ส่งผลต่อการใช้งานจริง หลักฐานการตรวจสอบ และตัวเลือกการติดตั้งใช้งานตั้งแต่ SaaS ไปจนถึง secure enclave
ทำไมการแก้ไขจึงต้องมีการกำกับดูแล
การแก้ไขอัตโนมัติโดยไม่มีการกำกับดูแลเป็นสิ่งที่ยอมรับไม่ได้ในซอฟต์แวร์ระดับองค์กร เพราะละเมิดการควบคุมการเปลี่ยนแปลง ทำให้การตรวจสอบเป็นโมฆะ และขยายรัศมีความเสียหาย การแก้ไขที่มีการกำกับดูแลแลกความเร็วกับความรับผิดชอบ
เอเจนต์ช่วยเร่งการตรวจสอบ ส่วนมนุษย์เป็นผู้อนุญาตทุกสิ่งที่เปลี่ยนแปลงโปรดักชันหรือเส้นทางข้อมูลภายใต้กฎระเบียบ
เอเจนต์การแก้ไขทำอะไร
เอเจนต์การแก้ไขจะทำซ้ำความล้มเหลวในสภาพแวดล้อมที่ควบคุมได้ วิเคราะห์เทเลเมทรีและบริบทของกราฟ และร่างแนวทางแก้ไข ทั้งโค้ด การตั้งค่า หรือการอัปเดตเทสต์ พร้อมสรุปผลกระทบ
เอเจนต์เหล่านี้จะไม่แพตช์โปรดักชันอย่างเงียบ ๆ แต่จะเตรียมชุดการเปลี่ยนแปลงที่ตรวจทานได้
ตรวจจับ → วิเคราะห์ → แนะนำ → อนุมัติ → แก้ไข → ตรวจยืนยัน → ตรวจสอบ
The workflow is linear and logged: detection from verification runs or monitors, analysis with evidence links, recommendations as typed diffs, approval via RBAC, application in staging or via PR, verification reruns, audit export.
การข้ามการตรวจยืนยันถือเป็นการละเมิดนโยบาย ไม่ใช่ทางลัด
การอนุญาตโดยมนุษย์
ผู้อนุมัติที่ระบุชื่อ การแบ่งแยกหน้าที่ และบทบาท break-glass สำหรับกรณีฉุกเฉินสามารถกำหนดค่าได้ การอนุมัติจะบันทึกว่าใคร เมื่อใด และนโยบายเวอร์ชันใดที่ถูกนำมาใช้
การผสานรวมกับเครื่องมือ ITSM เป็นเรื่องปกติสำหรับการรีลีสที่สอดคล้องกับ CAB
RBAC และการแบ่งแยกหน้าที่
บทบาทจะแยกสิทธิ์การเสนอ การอนุมัติ และการดีพลอยออกจากกัน QA อาจอนุมัติการเปลี่ยนแปลงเทสต์ ส่วนหัวหน้าทีมแพลตฟอร์มอนุมัติการเปลี่ยนแปลงโครงสร้างพื้นฐาน เอเจนต์จะสืบทอดสิทธิ์น้อยที่สุดตามบทบาท
การตรวจทานสิทธิ์การเข้าถึงเป็นระยะควรรวมบัญชีบริการของเอเจนต์และตัวตนของตัวรันด้วย
การแก้ไขโดยเริ่มจากสเตจจิงก่อน
เส้นทางการแก้ไขทั้งหมดจะกำหนดค่าเริ่มต้นไปยังสเตจจิงหรือสภาพแวดล้อมชั่วคราวที่สะท้อนข้อจำกัดของโปรดักชัน การเลื่อนสู่โปรดักชันต้องมีการอนุมัติการเลื่อนระดับอย่างชัดเจน
การเริ่มจากสเตจจิงก่อนช่วยลดการทำงานซ้ำและให้ขอบเขตที่ชัดเจนแก่ผู้ตรวจสอบ
การแก้ไขแบบใช้ PR
เอเจนต์จะเปิด pull request พร้อมหลักฐาน แผนการทดสอบ และขั้นตอนการย้อนกลับที่เชื่อมโยงกัน ผู้ตรวจทานจะแสดงความเห็นในเครื่องมือที่คุ้นเคย เมื่อมีการ merge จะทริกเกอร์ชุดการตรวจยืนยันโดยอัตโนมัติ
ฟลว์ที่ใช้ PR ช่วยรักษาวัฒนธรรมการรีวิวโค้ดไว้ในขณะที่ลดเวลาในการร่าง
การย้อนกลับและการตรวจยืนยัน
ทุกข้อเสนอจะรวมคำแนะนำการย้อนกลับและขอบเขตการตรวจยืนยันหลัง merge การตรวจยืนยันที่ล้มเหลวจะบล็อกการเลื่อนระดับและเปิดการวิเคราะห์ใหม่
ควรซ้อมการย้อนกลับในช่วง PoC ไม่ใช่ตอนเกิดเหตุการณ์ครั้งแรก
หลักฐานสำหรับการตรวจสอบ
ชุดหลักฐานสำหรับการตรวจสอบประกอบด้วยรหัสการรัน อาร์ติแฟกต์ ตัวตนของผู้อนุมัติ แฮชของดิฟฟ์ และผลการตรวจยืนยัน ซึ่งส่งออกได้สำหรับการตรวจทาน SOC, ISO หรือความเสี่ยงภายใน
การเก็บรักษาสอดคล้องกับกำหนดการปฏิบัติตามข้อกำหนดของคุณ ไม่ใช่แค่ค่าเริ่มต้นของผู้จำหน่ายเพียงอย่างเดียว
เช็กลิสต์การตรวจทานความปลอดภัย
ใช้เช็กลิสต์การแก้ไขที่มีการกำกับดูแล สำหรับการแมปมาตรการควบคุม พูดคุยเรื่องการแก้ไขที่มีการกำกับดูแล กับทีมของเราเมื่อกำหนดขอบเขตการนำร่องในสเตจจิง
Governed remediation implements this workflow in Zof AI.
คู่มือที่เกี่ยวข้อง
Governed Remediation
ลูปการแก้ไขที่ได้รับอนุญาตจากมนุษย์ ซึ่งปิดช่องว่างด้านความน่าเชื่อถือโดยไม่มีการเปลี่ยนแปลงในระบบจริงแบบไร้การควบคุม
โครงสร้างพื้นฐานความเชื่อถือได้แบบอัตโนมัติ
The pillar guide to governed ARI: System Graph, continuous verification, governed remediation, secure deployment, and buying criteria.
Software Reliability Control Plane
เหตุใดองค์กรจึงต้องการ control plane ไม่ใช่ point tool อีกตัวหนึ่ง สำหรับความน่าเชื่อถือแบบอัตโนมัติ
