ผู้ช่วยที่ขับเคลื่อนด้วย AI ช่วยดูแลเวร on-call ของผมเป็นเวลาเจ็ดวัน โดยจัดการการแจ้งเตือน 11 ครั้ง และช่วยลดเวลาเฉลี่ยในการแก้ไขปัญหาจาก 45 นาที เหลือเพียง 20 นาที การทดลองนี้มีความสำคัญเพราะโมเดลภาษาที่มีขอบเขตไม่ใหญ่มากสามารถช่วยลดเวลาในการตอบสนองต่ออุบัติการณ์ได้ถึงครึ่งชั่วโมง โดยที่ยังคงต้องมีการควบคุมดูแลอย่างใกล้ชิดจากมนุษย์
ทำไมผมถึงให้ AI มาเข้าเวร on-call
ทีม Cloud ใช้เวลาส่วนใหญ่ในกะการทำงานไปกับการไล่ดู logs, ตรวจสอบการ deployment ล่าสุด และยืนยันว่าการขอ scaling นั้นปลอดภัย งานที่ "น่าเบื่อ" เหล่านี้เป็นงานที่ทำซ้ำได้, มีข้อมูลจำนวนมาก และเสี่ยงต่อความเหนื่อยล้าของมนุษย์ ความก้าวหน้าล่าสุดของ Large Language Models (LLMs) สัญญาว่าจะช่วยเปลี่ยนงานการจับคู่รูปแบบ (pattern-matching) เหล่านี้ให้เป็นอัตโนมัติ แต่การสาธิตส่วนใหญ่ที่เปิดเผยต่อสาธารณะมักจะรันในสภาพแวดล้อมแบบ sandbox ผมจึงอยากเห็นว่าความตื่นเต้นนี้จะยังคงอยู่หรือไม่เมื่อนำมาใช้ในคลัสเตอร์ระดับ production ที่ให้บริการลูกค้าที่จ่ายเงินจริง
การตั้งค่าการทดสอบ
- การเข้าถึง (Access) – เอเจนต์สามารถอ่านเมทริกซ์ (metric), log และนิยามการ deployment ได้ทุกอย่าง แต่มันสามารถเขียนได้เฉพาะในรายการ whitelist ที่กำหนดไว้เท่านั้น เช่น การ restart pod, การเพิ่มจำนวน replica หรือการ scale deployment หากเป็นอย่างอื่นนอกเหนือจากนี้จะต้องได้รับการอนุมัติจากผมโดยตรง
- บทบาท (Role) – ผมปฏิบัติกับโมเดลเหมือนเป็นวิศวกรระดับ junior ที่กำลังเข้าเวร on-call ครั้งแรก มันจะได้รับแจ้งเตือน, ทำการวิเคราะห์ และโพสต์คำแนะนำลงในช่อง incident
- ตาข่ายนิรภัย (Safety nets) – การดำเนินการเขียน (write actions) ทั้งหมดจะถูกกั้นไว้ด้วยคำสั่ง "yes/no" แบบแมนนวล นอกจากนี้ผมยังจำกัดการใช้งาน token ของโมเดลเพื่อควบคุมค่าใช้จ่ายให้คาดการณ์ได้
จุดที่ AI ทำได้อย่างยอดเยี่ยม
ความเร็วของเอเจนต์คือสิ่งที่เห็นได้ชัดที่สุด ทันทีที่มีการแจ้งเตือนเกิดขึ้น มันจะดึง logs ที่เกี่ยวข้อง, พล็อตกราฟเมทริกซ์ล่าสุด และแสดงรายการการ deployment สามรายการล่าสุด กว่าที่ผมจะเปิดแล็ปท็อป งานสืบสวนเบื้องต้นก็เสร็จสิ้นไปแล้ว จากการแจ้งเตือน 11 ครั้ง:
- 8 ครั้ง เป็นปัญหาทั่วไป (memory spikes, container restarts, การตั้งค่าผิดพลาดเล็กน้อย) AI สามารถระบุสาเหตุที่แท้จริง (root cause) ได้ถูกต้องทุกครั้ง
- มันตรวจพบการเพิ่มขึ้นของหน่วยความจำ (memory) อย่างค่อยเป็นค่อยไปใน microservice ก่อนที่ปัญหาจะลุกลามจนกลายเป็นระบบล่ม (outage) ในช่วงตี 2 ทำให้ทีมมีโอกาสเข้าแก้ไขได้ทันท่วงที
- การใช้ token ตลอดทั้งสัปดาห์อยู่ที่ประมาณ $30 ซึ่งอยู่ในงบประมาณสำหรับการเข้าเวรปกติเมื่อมีการจำกัดไว้
ผลลัพธ์เหล่านี้เปลี่ยนเป็นการลดค่าเฉลี่ยเวลาในการแก้ไขปัญหา (MTTR) จาก 45 นาที เหลือ 20 นาที ช่วยให้วิศวกรมีเวลาไปโฟกัสกับงานที่มีผลกระทบสูงกว่า
จุดที่ AI พลาด
ความมั่นใจไม่ได้เท่ากับความถูกต้อง AI ตอบผิดอย่างมั่นใจถึง 3 ครั้ง จากการแจ้งเตือน 11 ครั้ง:
- มันโทษการ deployment โค้ดล่าสุดว่าเป็นสาเหตุของความล้มเหลวในการเชื่อมต่อฐานข้อมูล แต่คำอธิบายนั้นไม่ถูกต้อง
- เมื่อต้องเผชิญกับความผิดปกติของเครือข่าย (networking anomaly) ที่ไม่คุ้นเคย มันกลับเสนอวิธีแก้ไขแบบทั่วไปที่ไม่สามารถแก้ปัญหาที่ต้นเหตุได้
- ระหว่างการแจ้งเตือนที่เกี่ยวข้องกับโหลด (load) มันแนะนำให้ scale service จาก 3 เป็น 30 replicas ทั้งที่ปัญหาไม่ได้อยู่ที่โหลด แต่อยู่ที่การตั้งค่า (config) ที่ผิดพลาด
เนื่องจากมาตรการป้องกัน (guardrails) ของผมกำหนดให้ต้องมีการอนุมัติแบบแมนนวลสำหรับการดำเนินการเขียนใดๆ ความผิดพลาดของโมเดลจึงถูกตรวจพบก่อนที่จะสร้างความเสียหาย อย่างไรก็ตาม เหตุการณ์นี้ได้ชี้ให้เห็นถึงความเสี่ยงหลัก: โมเดลสามารถสร้างคำแนะนำที่ฟังดูสมเหตุสมผลแต่ไม่ถูกต้อง โดยเฉพาะอย่างยิ่งกับปัญหาใหม่ๆ ที่ไม่เคยเจอ
การจัดการต้นทุนและความเสี่ยง
บิลค่า token จำนวน $30 แสดงให้เห็นว่าการรัน LLM ในลูปการทำงานจริง (production loop) สามารถทำได้ในราคาถูกหากมีการตรวจสอบการใช้งาน อย่างไรก็ตาม ต้นทุนที่แท้จริงคือความเสี่ยงในการดำเนินงาน (operational risk) การ scale deployment ผิดพลาดอาจนำไปสู่ค่าใช้จ่ายคลาวด์ที่พุ่งสูงเกินควบคุม และการ rollback การปล่อยเวอร์ชันที่ดีออกไปอาจทำลายความเชื่อมั่นของลูกค้า การทดลองนี้ช่วยย้ำเตือนถึงมาตรการป้องกันสองประการ:
- การกั้นการดำเนินการ (Action gating) – อนุญาตให้โมเดลทำได้เพียงแค่ "เสนอแนะ" เท่านั้น ห้าม "ดำเนินการ" การเปลี่ยนแปลงที่มีผลกระทบสูงโดยไม่มีการคลิกยืนยันจากมนุษย์
- การจำกัดงบประมาณ (Budget caps) – กำหนดขีดจำกัดที่ชัดเจนสำหรับการใช้ token และแจ้งเตือนทีมเมื่อโมเดลใช้งานใกล้ถึงเพดานที่ตั้งไว้
สิ่งที่ควรจับตามองต่อไป
จนกว่าจะถึงตอนนั้น ทีมควร:
- ติดตามสัดส่วนของคำแนะนำที่สร้างโดย AI ที่ต้องมีการแก้ไขด้วยมือ (manual override)
- วัดผลกระทบต่อ MTTR ในหมวดหมู่ของอุบัติการณ์ที่แตกต่างกัน (ปัญหาทั่วไป vs ปัญหาใหม่)
- ทดสอบโมเดลในสภาพแวดล้อม staging ด้วยการแจ้งเตือนแบบสังเคราะห์ (synthetic alerts) ก่อนที่จะมอบสิทธิ์ในการเขียนข้อมูลใน production
บทเรียนสำหรับทีม Ops
- ทำให้งานที่น่าเบื่อ 80% เป็นอัตโนมัติ – ใช้ AI สำหรับการรวบรวม logs, การหาความสัมพันธ์ของเมทริกซ์ (metric correlation) และการสร้างสมมติฐานเบื้องต้น
- เก็บงานที่เสี่ยง 20% ไว้ให้มนุษย์ – การ scale ที่เกินขีดจำกัดที่เหมาะสม, การ rollback และการลบข้อมูล ควรต้องผ่านขั้นตอนการอนุมัติแบบแมนนวล
- ปฏิบัติกับโมเดลในฐานะคู่หู ไม่ใช่ตัวแทน – วิศวกรที่รู้จักระบบดีจะสามารถตรวจสอบผลลัพธ์ของ AI ได้เร็วกว่าคนใหม่ ซึ่งจะเปลี่ยนผู้ช่วยนี้ให้กลายเป็นตัวช่วยเพิ่มประสิทธิภาพ (force multiplier)
เอเจนต์ AI ยังไม่สามารถบริหารจัดการการดำเนินงานบนคลาวด์ได้เพียงลำพัง แต่ในฐานะคู่หูในการคัดกรองปัญหา (triage partner) มันสามารถช่วยเพิ่มความเร็วในการทำงานได้อย่างเห็นผลชัดเจนแล้ว หัวใจสำคัญคือการควบคุมความเชื่อมั่นให้เหมาะสม กำหนดขอบเขตการทำงาน (guardrails) ที่เข้มงวด และปล่อยให้โมเดลจัดการกับงานรูทีนที่ต้องทำซ้ำๆ ในขณะที่ใช้ความเชี่ยวชาญของมนุษย์ในการตัดสินใจในเรื่องที่สำคัญ