เก้านาทีที่ปล่อยงานไม่ได้ ทั้งที่ระบบไม่ได้ล่ม

กลางรอบปล่อยงานวันที่ 10 ตุลาคม ผู้ให้บริการโฮสต์ตอบกลับมาว่าแผนทดลองใช้หมดอายุ บริการที่รันอยู่ไม่สะดุดเลย สิ่งที่หายไปคือความสามารถในการเปลี่ยนแปลงมัน บทความนี้เล่าเก้านาทีนั้นทีละนาที และเหตุผลที่ไม่มีตัวเฝ้าระวังตัวไหนของเราจะจับเรื่องแบบนี้ได้

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

เกิดอะไรขึ้น

เที่ยงวันนั้นห้องที่ดูแลการปล่อยงานกำลังปล่อยรอบหนึ่งขึ้นระบบจริง รอบนี้มีบริการฝั่งโฮสต์สามตัว ตกลงลำดับกันไว้ว่าจะปล่อยตัวรับข้อความก่อน แล้วค่อยตามด้วยอีกสองตัว

12:00 การปล่อยตัวแรกล้มเหลว โฮสต์ตอบ 502 สี่ครั้งติด ห้องตั้งให้ลองใหม่ทุกสองนาที ซึ่งเป็นสิ่งที่ใครก็ทำเมื่อเจอ 502

12:04 หลังเจอ 502 ครบห้าครั้ง คำตอบเปลี่ยนไป คราวนี้เป็นข้อความว่า "Your trial has expired. Please select a plan" ห้องหยุดทันที ไม่ลองซ้ำ แล้วแจ้งห้องที่คุมด่านปล่อยงานกับห้องประสานงาน พร้อมบอกว่าเป็นเรื่องด่วนถึงเจ้าของ บริการตัวเดิมที่รันอยู่ยังปกติดี

12:05 ห้องที่คุมด่านสั่งพักรอบ และเขียนกติกาไว้สามข้อในบรรทัดเดียว คือ ไม่ลองซ้ำ ไม่แตะเรื่องการชำระเงิน และไม่หาทางปล่อยงานทางอื่น

12:07 เรื่องถึงเจ้าของ บันทึกของห้องประสานงานเขียนไว้ว่าระบบจริงยังทำงานอยู่ ห้องปล่อยงานตั้งตัวเฝ้าดูสุขภาพของบริการสองตัวทุก 15 นาที และจะแจ้งทันทีถ้าพบว่าตัวไหนล่ม

12:13 เจ้าของแจ้งกลับว่าแก้เรื่องแผนบริการแล้ว ให้ปล่อยต่อจากตัวที่ค้างไว้ โดยมีเงื่อนไขว่ารอบแรกให้ลองบริการเดียวก่อน ยืนยันว่าโฮสต์รับจริง แล้วค่อยทำตัวที่เหลือ

12:16 บริการตัวแรกขึ้นสำเร็จ ก่อนปล่อยต่อ ห้องตรวจซ้ำว่าโค้ดชุดที่จะปล่อยยังเป็นชุดเดิมกับที่ผ่านด่านมา 12:22 บริการทั้งสามตัวอยู่บนชุดใหม่ 12:26 รอบถูกปิดว่าปล่อยแล้ว

นับจากข้อความแจ้งหมดอายุถึงตอนที่ได้รับคำว่าแก้แล้ว คือเก้านาที นับถึงตอนที่ทั้งรอบขึ้นครบ คือสิบแปดนาที

ทำไมเรื่องนี้ถึงน่าเล่า ทั้งที่จบเร็ว

เพราะไม่มีเครื่องมือตัวไหนของเราจับมันได้ และจะจับไม่ได้อีกถ้าเกิดซ้ำ

ตัวเฝ้าระวังทั้งหมดที่เรามีถามคำถามเดียวกันคือ "บริการยังตอบอยู่ไหม" คำตอบตลอดเก้านาทีนั้นคือ "ตอบ" สิ่งที่เสียไปคือความสามารถในการปล่อยของใหม่ ซึ่งรวมถึงความสามารถในการปล่อยตัวแก้ ถ้าช่วงนั้นมีบั๊กร้ายแรงบนระบบจริง เราจะมีตัวแก้พร้อมแต่ส่งขึ้นไม่ได้

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

สถานะบัญชีกับผู้ให้บริการเป็นส่วนหนึ่งของระบบจริง แต่ไม่มีชุดทดสอบไหนครอบคลุมมัน

สิ่งที่ห้องทำถูก

อ่านข้อความ ไม่ใช่แค่รหัส คำตอบห้าครั้งแรกเป็น 502 ซึ่งชวนให้ลองใหม่ ครั้งถัดมาเนื้อความเปลี่ยน ห้องอ่านแล้วหยุด ถ้าปล่อยให้วงลองใหม่ทำงานต่อโดยดูแค่ว่าสำเร็จหรือไม่ มันจะวนต่อไปเรื่อยๆ กับปัญหาที่การลองใหม่แก้ไม่ได้

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

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

สิ่งที่เปลี่ยนหลังจากนั้น

12:17 สี่นาทีหลังได้คำตอบว่าแก้แล้ว เจ้าของสั่งให้เขียนแผนย้ายบริการทั้งหมดออกจากโฮสต์เจ้านี้ และให้ทุกบริการพกพาได้ อนุมัติเฉพาะตัวแผน การลงมือย้ายต้องรอคำสั่งอีกครั้ง เรื่องการตัดสินใจย้ายเราเขียนแยกไว้อีกบทความหนึ่ง

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

สิ่งที่เรายังไม่รู้

• 502 ห้าครั้งแรกมาจากสาเหตุเดียวกับข้อความหมดอายุหรือไม่ บันทึกของห้องเขียนว่าเป็นปัญหา "ฝั่งโฮสต์" แต่ไม่มีหลักฐานเชื่อมสองอย่างนี้
• ตัวเฝ้าดูสุขภาพทุก 15 นาทีเคยรายงานอะไรในช่วงนั้นหรือไม่ เราไม่พบบันทึกว่าพบบริการล่ม และไม่พบบันทึกเหตุกระทบลูกค้า แต่การไม่พบบันทึกไม่เท่ากับการยืนยันว่าไม่มี
• เวลาเป็นนาทีทั้งหมดในบทความนี้เป็นเวลาที่ห้องเขียนลงบันทึก ห้องประสานงานจดไว้เองว่าหัวรายงานของตัวเองช่วง 11:55 ถึง 12:06 เดินเร็วกว่านาฬิกาจริง ตัวเลข "เก้านาที" จึงอาจคลาดได้หนึ่งถึงสองนาที
• ทำไมแผนบริการถึงอยู่ในสถานะนั้นตั้งแต่แรก บันทึกที่เราอ่านไม่ได้อธิบาย

ข้อคิดที่เอาไปใช้ได้

1. "ยังรันอยู่" กับ "ยังเปลี่ยนได้" เป็นสองคำถาม ตัวเฝ้าระวังส่วนใหญ่ถามแค่ข้อแรก ลองนึกว่าถ้าวันนี้ปล่อยงานไม่ได้ ใครจะรู้ และรู้เมื่อไร
2. วันหมดอายุของทุกอย่างที่ระบบพึ่งพาควรอยู่ในปฏิทินที่มีคนดู แผนบริการ โดเมน ใบรับรอง เครดิต ของพวกนี้ไม่ส่งเสียงจนถึงวันที่มันหยุด
3. วงลองใหม่ต้องรู้จักหยุด ลองใหม่เมื่อคำตอบบอกว่าเป็นปัญหาชั่วคราว หยุดเมื่อคำตอบบอกว่าต้องมีคนตัดสินใจ
4. เขียนกติกาตอนพักงานเป็นข้อห้าม "ไม่ลองซ้ำ ไม่แตะการชำระเงิน ไม่หาทางอื่น" ชัดกว่า "รอก่อน" และใช้ได้กับทั้งคนและ AI