การจัดการ Incident ด้วย AI จะล้มเหลวหากขาดบันทึกข้อมูลที่ใช้ร่วมกัน

AI agent กำลังก้าวเข้าสู่พื้นที่ของการตอบสนองต่อ Incident (incident response)

บริษัทอย่าง LangChain, PagerDuty และ New Relic กำลังสร้าง SRE agent เครื่องมือเหล่านี้สามารถอ่าน traces, ดึง logs และร่างข้อมูลอัปเดตได้ พวกมันทำงานเร็ว และให้บริบท (context) ที่ยอดเยี่ยม

แต่มีกับดักหนึ่งอยู่

หลายทีมปฏิบัติกับบริบทของ AI เหมือนเป็นสมุดจดบันทึกส่วนตัว พวกเขาใช้ AI สำหรับงานบรรเทาปัญหา (mitigation) เช่น การค้นหาสาเหตุที่แท้จริง (root cause) แต่พวกเขาลืมเรื่องงานด้านการประสานงาน (coordination)

การจัดการ Incident ไม่ใช่แค่เรื่องของการหาสาเหตุ แต่มันคือเรื่องของการประสานงาน มันคือการทำให้ทุกคนเห็นพ้องตรงกันในเรื่อง:

  • เกิดอะไรขึ้น
  • อะไรที่เปลี่ยนแปลงไป
  • อะไรที่คุณตัดออกไปแล้ว (สิ่งที่ไม่ใช่สาเหตุ)
  • ใครเป็นผู้รับผิดชอบขั้นตอนต่อไป
  • สิ่งที่ทางธุรกิจจำเป็นต้องทราบ

หากข้อมูลเหล่านี้ยังคงอยู่ในแชทส่วนตัวหรือบันทึกของ agent กระบวนการทั้งหมดก็จะล้มเหลว

บันทึก Incident ของ AI ที่มีประโยชน์ไม่ใช่แค่ log การแชท แต่มันคือวัตถุเชิงปฏิบัติการที่มีโครงสร้าง (structured operational object) ซึ่งต้องประกอบด้วย:

  • ตัวกระตุ้น (alert, service, severity)
  • หลักฐาน (traces, logs, metrics, การ deploy ล่าสุด)
  • สมมติฐาน (สิ่งที่คุณคิดว่ากำลังเกิดขึ้นและเพราะเหตุใด)
  • ทฤษฎีที่ถูกปฏิเสธ (สิ่งที่คุณพิสูจน์แล้วว่าไม่ใช่สาเหตุ)
  • การตัดสินใจและการอนุมัติ (ทำไมคุณถึงเลือกที่จะ roll back หรือรอ)

โครงสร้างนี้จะช่วยป้องกันความล้มเหลวที่พบบ่อยของ AI โดย agent อาจกลายเป็นเหมือน "หลุมดำทางความคิด" (gravity well) มันจะค้นหาสาเหตุที่ดูสมเหตุสมผลเพียงอย่างเดียวแล้วยึดติดกับมัน จากนั้นมันจะตีความข้อมูลใหม่ทั้งหมดเพื่อสนับสนุนทฤษฎีนั้นเพียงอย่างเดียว

บันทึกที่มีโครงสร้างและใช้ร่วมกันจะบังคับให้ทีมต้องพิจารณาหลักฐานที่ขัดแย้งด้วย ซึ่งจะช่วยควบคุมอคติ (bias) ของ agent ไว้ได้

ผู้ตอบสนอง (Responders) ไม่ต้องการข้อมูลที่วุ่นวาย (noise) มากขึ้น แต่พวกเขาต้องการ "สถานะที่ใช้ร่วมกัน" (shared state) เมื่อมีคนใหม่เข้ามาช่วยจัดการ Incident พวกเขาไม่ควรต้องเสียเวลาห้านาทีในการไล่หาข้อมูลใน Slack แต่ควรจะเห็นสมมติฐานปัจจุบัน หลักฐาน และสิ่งที่ต้องดำเนินการต่อไปได้ในทันที

เป้าหมายไม่ใช่การมีผู้ตอบสนองอัตโนมัติที่มีเดโมสวยหรู แต่เป้าหมายคือเครื่องมือที่ทิ้ง "ความรู้ในองค์กร" (institutional knowledge) เอาไว้

เลิกมองหาโมเดลที่ฉลาดที่สุด แต่เริ่มสร้างบันทึกที่มีโครงสร้างกันเถอะ

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

เครื่องมือ AI ที่ดีที่สุดคือเครื่องมือที่ทำให้ทีมมนุษย์ทำงานสอดประสานกันเป็นหนึ่งเดียว

Source: https://dev.to/focused_dot_io/ai-incident-management-breaks-without-a-shared-record-focused-labs-1og5

Optional learning community: https://t.me/GyaanSetuAi