บทเรียนจาก Dev.to: เมื่อ Health Check พังแต่ระบบจริงทำงานปกติ
นักพัฒนาแชร์อุทาหรณ์ระบบ Red-team ใช้งานจริงไม่ได้เพราะตั้งค่า Liveness Check ผิดพลาด ทั้งที่ API หลักอย่าง /v1/chat/completions ยังคงทำงานเป็นปกติ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ระบบ Red-team ล้มเหลวทุกงานเนื่องจาก Health Check ตรวจสอบเส้นทางผิดจุด
- เส้นทาง liveness check ไปเรียก GET /v1/models ที่ใช้ token หมดอายุทำให้ได้ค่า 500
- API หลักอย่าง POST /v1/chat/completions ยังคงทำงานและตอบกลับ 200 เป็นปกติ
- ทางแก้คือการทำ End-to-end monitor ทดสอบจริงทุก 2 ชั่วโมงแทนการเช็คแค่ Metadata
นักพัฒนาซอฟต์แวร์รายหนึ่งได้ออกมาเผยแพร่ประสบการณ์ผ่านแพลตฟอร์ม Dev.to เกี่ยวกับปัญหาชวนปวดหัวของระบบ Red-team endpoint ที่ถูกซื้อมาใช้งาน โดยในหน้าเว็บสำหรับผู้ซื้อนั้นสามารถโหลดข้อมูลได้ตามปกติ ส่งแบบฟอร์มได้สำเร็จ และได้รับรหัสสถานะ 202 running กลับมา แต่ทว่าระบบกลับรายงานสถานะเป็น error ทุกครั้งที่ทำการตรวจสอบ โดยแสดงข้อความแจ้งเตือนว่าไม่สามารถเข้าถึงโมเดลได้ที่พอร์ต http://127.0.0.1:10100/v1
จากการตรวจสอบเชิงลึกพบว่า ตัวโมเดลไม่ได้ออฟไลน์หรือใช้งานไม่ได้แต่อย่างใด แต่ปัญหาที่แท้จริงเกิดจากระบบตรวจสอบความมีชีวิตชีวา (Liveness Check) ของระบบทำงานผิดพลาดตั้งแต่ก่อนจะเริ่มทดสอบการทำงานจริง โดยขั้นตอนแรกของระบบคือการส่งคำขอแบบ GET ไปยังเส้นทาง /v1/models ซึ่งเส้นทางนี้เชื่อมต่อกับพร็อกซีโมเดลท้องถิ่นที่ต้องดึงข้อมูลบัญชีภายนอกผ่านรีเฟรชโทเค็น (Refresh Token)
เนื่องจากโทเค็นดังกล่าวหมดอายุลง ทำให้ระบบย่อยนี้ตอบกลับด้วยรหัสข้อผิดพลาด 500 Internal Server Error ทว่าระบบ Liveness Check กลับถูกตั้งค่าไว้ว่าหากได้รับรหัสสถานะใดๆ ที่ไม่ใช่ 200 จะถือว่าตัวโมเดลไม่สามารถเข้าถึงได้ทันที ส่งผลให้ระบบตัดจบการทำงานและยกเลิกการทดสอบทั้งหมดก่อนที่จะได้รันคำสั่งจริงเสียอีก
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในความเป็นจริงแล้ว เส้นทางที่ทำหน้าที่ประมวลผลหลักคือ POST /v1/chat/completions ซึ่งควบคุมโดยเราเตอร์ของผู้ให้บริการรายอื่น และเส้นทางนี้ยังคงทำงานได้ดีตลอดเวลาโดยตอบกลับด้วยรหัส 200 พร้อมผลลัพธ์ที่ถูกต้อง เจ้าของปัญหาได้ยืนยันข้อเท็จจริงนี้ด้วยการส่งคำขอทดสอบเพียงหนึ่งโทเค็น (max_tokens: 1) และอ่านเนื้อหาการตอบกลับโดยตรง ซึ่งพิสูจน์ให้เห็นว่าเส้นทางการประมวลผลยังคงสมบูรณ์ดี
"The model was not unreachable. The health check was asking the wrong question."
Dev.to Author
ปัญหานี้สะท้อนให้เห็นว่าระบบมีเส้นทางการอนุมานที่ใช้งานได้จริง แต่มีเส้นทางข้อมูลเมตา (Metadata Path) ที่เสียหาย และมีประตูกั้นที่ดันไปตรวจสอบผิดจุด ทำให้ทุกงานถูกสกัดกั้นตั้งแต่หน้าประตูก่อนจะเริ่มประมวลผลเสียด้วยซ้ำ ความน่ากลัวของปัญหานี้คือทุกบันทึก (Logs) ของระบบมีความถูกต้องในตัวเอง ทำให้ไม่มีความผิดปกติใดๆ ที่ระบบตรวจสอบอัตโนมัติจะสามารถแจ้งเตือนได้
บทเรียนสำคัญจากเหตุการณ์นี้คือความแตกต่างระหว่าง "การตรวจสุขภาพระบบ" (Health Check) กับ "การทดสอบฟังก์ชันการทำงานจริง" (End-to-End Test) หลายครั้งที่ทีมนักพัฒนามักพึ่งพากลไกการตรวจสอบส่วนประกอบย่อย เช่น การเช็คสถานะการเชื่อมต่อฐานข้อมูลหรือโทเค็นภายนอก โดยละเลยการทดสอบเส้นทางหลักที่ผู้ใช้งานต้องใช้งานจริง แนวทางแก้ไขที่เหมาะสมคือการจำลองการใช้งานจริงขนาดเล็กที่สุดเท่าที่จะทำได้ เช่น การส่งข้อความความยาว 1 โทเค็น เพื่อตรวจสอบเส้นทางหลักโดยตรง หลีกเลี่ยงการปล่อยให้ระบบเมตาเดตาที่อาจหมดอายุหรือถูกจำกัดอัตราการเรียกใช้งานมาเป็นตัวตัดสินสถานะภาพรวมของระบบ
หลังจากแก้ไขปัญหาดังกล่าว นักพัฒนาได้เพิ่มระบบตรวจสอบอัตโนมัติที่จำลองงานจริงตั้งแต่ต้นจนจบทุกๆ สองชั่วโมง พร้อมกำหนดเงื่อนไขว่าต้องได้รับสถานะเสร็จสมบูรณ์พร้อมรายงานที่ไม่ว่างเปล่า วิธีนี้ช่วยให้มั่นใจได้ว่าระบบทั้งหมดตั้งแต่หน้าเว็บ ระบบคิว คนงาน ไปจนถึงการเขียนรายงานยังคงทำงานประสานกันได้อย่างแท้จริง แทนที่จะต้องเสียเวลาตลอดทั้งวันให้กับระบบที่ล่มเงียบอย่างที่ผ่านมา
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น