เจาะลึก Dev.to: 4 จุดพลาดของระบบรันงานแบตช์ไอที

เมื่อวันที่ 16 มีนาคม 2026 ระบบรันงานแบตช์สำหรับคอนเทนต์ไพพไลน์ได้ถูกติดตั้งลงในคอมมิตเดียว โดยในคอมมิตนั้นมีทั้งแฟล็กการทำงานต่อ (resume flag) บันทึกสถานะแยกตามชิ้นงาน การจำแนกข้อผิดพลาด การหยุดพักโควตา และไฟล์ล็อก (lock file) การรองรับการทำงานต่อไม่ได้ถูกเพิ่มเข้ามาทีหลังหลังจากเกิดปัญหา แต่มีอยู่ตั้งแต่วันแรก ทว่ามันก็ยังคงใช้งานไม่ได้อย่างสมบูรณ์ไปอีกสามเดือนเต็ม

ลำดับการสร้างระบบของเราไม่ได้เรียงตามความเหมาะสมนัก โดยสิบเอ็ดวันก่อนที่จะมีตัวรันงาน เราได้สร้างระบบตัดไฟฉุกเฉิน (หยุดหลังจากความล้มเหลวเรื่องโควตาติดต่อกันสามครั้ง) และเส้นทางการปิดระบบที่ฆ่ากระบวนการลูกเมื่อกระบวนการแม่ถูกขัดจังหวะ สี่วันหลังจากมีตัวรันงาน เราได้ส่งมอบฟังก์ชันการลองทำซ้ำที่ทำหน้าที่สานต่อไฟล์ที่เขียนค้างไว้ครึ่งทางแทนที่จะสร้างขึ้นมาใหม่ ซึ่งสะท้อนความสับสนคลาสสิก: รูปแบบการลองทำซ้ำมีไว้เพื่อรับมือกับการเรียกใช้งานที่ล้มเหลว ส่วนการทำต่อมีไว้เพื่อไม่ให้ต้องเสียเงินซ้ำซ้อนสำหรับการเรียกใช้งานที่สำเร็จไปแล้ว

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

เอนทิตีหนึ่งตัว เช่น หัวข้อหนึ่งที่ครอบคลุมชุดบทความ จะอยู่ในสถานะใดสถานะหนึ่งจากห้าสถานะ โดยความล้มเหลวจะถูกจำแนกเพิ่มเติมออกเป็นหกประเภท ได้แก่ timeout, quota, validation, phase_error, planning_error และ unknown การแยกประเภทความล้มเหลวออกจากแกนสถานะคือสิ่งที่ทำให้สถานะหยุดพักและสถานะล้มเหลวกลายเป็นคนละคำกริยาอย่างแท้จริง การหมดโควตาไม่ใช่ข้อบกพร่อง แต่คือการที่ระบบถูกบอกให้กลับมาใหม่ภายหลัง

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

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

"การล็อกไฟล์บนเครื่องเดี่ยวไม่ใช่การประสานงานแบบกระจายศูนย์ และฉันจะไม่แสร้งทำเป็นว่าใช่"

Jula Markova

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

ที่มา: Dev.to