บทเรียนจาก CI Gate จอมปลอม: เมื่อโปรแกรมตรวจโค้ดล่มก่อนรันจริง
อุทาหรณ์จากระบบทดสอบ Python ที่พังทลายเงียบๆ ก่อนตรวจเช็คอะไรเลย แต่กลับรายงานผลเป็นสีเขียวผ่านฉลุย
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- CI Gate ของ Python ล่มเพราะไม่มี git บน test pod
- กระบวนการพังก่อนรัน assertion ทำงาน แต่ระบบกลับตีความว่าสำเร็จ
- ปัญหานี้อันตรายยิ่งกว่าการไม่มีระบบตรวจโค้ดเสียอีก
- แนวทางแก้ปัญหาต้องตรวจทั้งความพร้อมของสภาพแวดล้อมและผลลัพธ์
ทีมนักพัฒนาซอฟต์แวร์แห่งหนึ่งเพิ่งค้นพบข้อผิดพลาดร้ายแรงในระบบ CI Gate ที่รายงานสถานะเป็นสีเขียวติดต่อกันมานานหลายสัปดาห์ ทั้งที่มันไม่ได้ตรวจสอบอะไรเลยตั้งแต่แรก ระบบดังกล่าวเป็นชุดทดสอบภาษา Python ขนาดเล็ก ที่ทำหน้าที่แจกแจงรายชื่อไฟล์ที่ถูกติดตามผ่านคำสั่ง git ls-files ก่อนจะเริ่มรันชุดคำสั่งตรวจสอบในแต่ละไฟล์
ระบบนี้ทำงานได้อย่างไร้ที่ติบนเครื่องของนักพัฒนาทุกคน รวมถึงบนพอดทดสอบส่วนใหญ่ จนกระทั่งมันถูกนำไปรันบน test pod แบบถูกตัดทอนที่ไม่มีโปรแกรม git ติดตั้งอยู่ ส่งผลให้คำสั่ง subprocess.run(['git', ...]) เกิดข้อผิดพลาด FileNotFoundError ขึ้นทันที กระบวนการจึงต้องยุติลงก่อนที่ assertion แม้แต่ตัวเดียวจะถูกประเมินผล
ความซวยคือตัวเรียกใช้งานกลับตีความความผิดพลาดนี้ว่า "ไม่สามารถใช้งานได้" แล้วปล่อยผ่านไป โดยใช้เวลาประมวลผลทั้งหมดเพียง 63 มิลลิวินาทีเท่านั้น แต่ระบบกลับรายงานผลลัพธ์ว่าประสบความสำเร็จอย่างงดงาม
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ปรากฏการณ์ที่เกิดขึ้นนี้สะท้อนให้เห็นถึงจุดบอดคลาสสิกในการออกแบบระบบทดสอบอัตโนมัติ ซึ่งนักพัฒนาส่วนใหญ่มักให้ความสำคัญกับการตรวจสอบเงื่อนไขของโค้ด แต่หลงลืมที่จะตรวจสอบความพร้อมของเครื่องมือหรือสภาพแวดล้อม (Environment Setup) ก่อนเริ่มรัน ความผิดพลาดแบบ Fail-Open ในลักษณะนี้มักอันตรายมาก เพราะมันสร้างความรู้สึกปลอดภัยจอมปลอม (False Security) ทำให้ทีมงานชะล่าใจและปล่อยบั๊กหลุดรอดสู่ระบบจริงได้ง่ายดายยิ่งกว่าการไม่มีระบบตรวจสอบเสียอีก
นี่คือกับดักที่อันตรายที่สุด การทดสอบที่ล่มก่อนจะทำการตรวจสอบข้อเท็จจริงนั้นแย่ยิ่งกว่าการไม่มีการทดสอบใดๆ เลย เพราะการไม่มีระบบทดสอบเปรียบเสมือนช่องโหว่ที่มองเห็นได้ชัดเจนในระบบ แต่การทดสอบที่พังแล้วรายงานผลเป็นสีเขียวคือช่องโหว่ที่ถูกปลอมแปลงมาในคราบของการรับประกัน มันทำลายความไว้วางใจที่ควรจะมีลงอย่างสิ้นเชิงโดยที่ไม่มีใครสังเกตเห็น จนกระทั่งข้อผิดพลาดนั้นหลุดรอดออกไปสู่มือผู้ใช้งานจริง
การแก้ไขปัญหาในเรื่องนี้ประกอบด้วยสองส่วนสำคัญด้วยกัน และมีเพียงส่วนเดียวเท่านั้นที่เห็นได้ชัดเจน การทำระบบสำรอง (Fallback) จะช่วยให้เส้นทางการทำงานปกติกลับมาใช้งานได้อีกครั้ง ขณะที่การสร้างตัวคุ้มกันที่ไม่ว่างเปล่า (Non-empty guard) คือสิ่งที่จะช่วยป้องกันไม่ให้ปัญหาความไม่สอดคล้องของสภาพแวดล้อมในอนาคตกลับมาแสดงผลเป็นสีเขียวหลอกตาอีก
สำหรับผู้ที่ดูแลระบบ CI Gate ในมือทุกท่าน ลองตั้งคำถามดูว่าระบบของคุณจะตอบสนองอย่างไรเมื่อขั้นตอนการตั้งค่า (Setup Step) เกิดล้มเหลว ไม่ใช่แค่ตอนที่คำสั่ง assertion ล้มเหลวเพียงอย่างเดียว เพราะสิ่งเหล่านี้คือโหมดความล้มเหลวที่แตกต่างกันโดยสิ้นเชิง และมักจะมีเพียงกรณีเดียวเท่านั้นที่ถูกนำมาทดสอบ
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น