ระบบแจ้งเตือนตอนตีสอง มีคนหาสาเหตุให้แล้ว

agent ที่เฝ้าการแจ้งเตือนจากระบบ monitoring ใน Slack หาทีมที่ดูแลโค้ดนั้น สืบหาสาเหตุจาก ticket ประวัติ build และ log แล้วเสนอ pull request ให้วิศวกรตรวจ ตามที่ Carvana ใช้งานกับ Claude Tag

ปัญหา

ทีมซอฟต์แวร์เล็กๆ หรือเอเจนซีที่ดูแลระบบให้ลูกค้าได้รับแจ้งเตือนจากระบบ monitoring ทุกชั่วโมงของวัน และทุกครั้งเริ่มเหมือนกัน มีคนต้องเปิด log หา deploy ล่าสุด แล้วไล่ว่าใครดูแลโค้ดส่วนนั้น สามสิบนาทีแรกของทุก incident คืองานสืบสวนที่ไม่มีใครอยากทำตอนตีสอง

agent ทำงานอย่างไร

1. เริ่มต้น

   agent เฝ้าช่องแจ้งเตือนใน Slack เมื่อมีการแจ้งเตือนเข้ามา มันระบุทีมที่ดูแลโค้ดส่วนที่ได้รับผลกระทบแล้วแท็กทีมนั้น จากนั้นสืบสวนเองโดยใช้สิทธิ์อ่าน ticket ประวัติ build โค้ด และ data warehouse ผ่าน identity ที่จำกัดขอบเขตของแต่ละทีม

2. agent ทำงาน

   สำหรับการปล่อยเวอร์ชันใหม่ มันเทียบจำนวน error, warning และปริมาณ log กับค่า baseline จากหนึ่งชั่วโมงก่อนปล่อย ซึ่งเป็น skill ที่เก็บไว้ใน repo ของทีม คู่กับ runbook และบันทึกการแจ้งเตือน แล้วโพสต์การวิเคราะห์สาเหตุใน thread ตามรูปแบบที่ทีมกำหนด ใน thread เดียวกันวิศวกรสั่งให้มันเปิด pull request จากผลวิเคราะห์ได้

3. ผลลัพธ์

   วิศวกรเป็นคนตรวจ pull request ก่อนขึ้น production และบางครั้งทางออกที่ถูกคือเปิด ticket ไว้หรือไม่แก้เลย บางทีมยังตั้งเวลาให้มันตรวจ pipeline และ feature flag ทุกชั่วโมง

ตัวอย่างการใช้งานจริง

case study ของ Anthropic เรื่อง Carvana อธิบาย Claude Tag ซึ่งเข้ามาแทน Slackbot ที่สร้างเองสองตัว ทีม wholesale platform ทดลองใช้สองสัปดาห์ในช่องรับงานและช่องแจ้งเตือน รวมห้าเคส โดยให้สิทธิ์อ่านอย่างเดียวกับ ticket ประวัติ build และโค้ด และรายงานว่าเวลาที่ใช้จนได้คำตอบลดลง 65% ส่วนช่องของทีม retail science ปริมาณการแจ้งเตือนลดลง 56% หลังจาก Claude Tag เริ่มแก้ที่ต้นเหตุ มีเคสหนึ่งช่วงสุดสัปดาห์ที่มันเปิด pull request เพื่อเพิ่ม logging เพราะ log ที่มีอธิบาย deployment นั้นไม่ได้ case study ระบุว่า Claude Tag ใช้ Opus 5 เป็นค่าเริ่มต้น Carvana เป็นบริษัทใหญ่ แต่รูปแบบนี้ต้องการแค่ช่อง Slack หนึ่งช่อง repo หนึ่งตัว และสิทธิ์อ่านที่จำกัดขอบเขต

แหล่งอ้างอิง

• https://claude.com/customers/carvana