นักพัฒนาตัดสินใจไม่แก้โค้ดเสียหายที่อาจทำให้เมืองดับไฟ

การพัฒนาและบำรุงรักษาซอฟต์แวร์ในอุตสาหกรรมพลังงานต้องเผชิญกับความเสี่ยงสูงเมื่อต้องทำงานบนระบบโบราณที่ไม่มีเอกสารกำกับ การเล่าเรื่องของผู้อ่าน “Socrates” ในคอลัมน์ On Call ของ *The Register* แสดงให้เห็นว่าผู้ดูแลระบบบางคนอาจเลือกละทิ้งภารกิจซึ่งอาจทำให้เมืองตกไฟได้ เพียงเพื่อหลีกเลี่ยงการสร้างความเสียหายที่ไม่สามารถย้อนกลับได้

Overview

Socrates ซึ่งเคยดำรงตำแหน่งผู้จัดการฝ่ายซอฟต์แวร์ขนาดเล็ก ได้รับมอบหมายจากนายจ้างให้ไปตรวจสอบระบบเฝ้าติดตามอุปกรณ์ของโรงไฟฟ้า ลูกค้าซึ่งผลิตเครื่องจักรสำหรับสถานีไฟฟ้านั้นไม่ได้บันทึกข้อมูลการติดตั้งอย่างเป็นทางการ เมื่อ Socrates ไปถึงไซต์ เขาได้พบกับ turbine overspeed detector ที่เชื่อมต่อกับคอมพิวเตอร์รุ่นเก่าแบบ CP/M พร้อมบอร์ด I/O หลากหลายชนิด

Background

ตามรายงานของ *The Register* ระบบนี้ถูกติดตั้งในโรงไฟฟ้าที่มีเครื่องจักรขนาดมหึมา ซึ่งทำหน้าที่หมุนด้วยไอศักดิ์เพื่อผลิตกระแสไฟฟ้า การควบคุมความเร็วเกิน (overspeed) ของเทอร์ไบน์เป็นสิ่งสำคัญเพราะหากเกิดเหตุการณ์ดังกล่าว เครื่องจักรอาจเสียหายและส่งผลให้ระบบไฟฟ้าทั้งเมืองดับไปได้ แม้ว่าตอนนั้นภาพยนตร์ Mission: Impossible ยังไม่ออก และ The Matrix ยังไม่มีในตลาด แต่จินตนาการของ Socrates ถูกผูกติดกับฉากแอคชันเหล่านั้น ทำให้ความเสี่ยงดูเหมือน “ภารกิจที่เป็นไปไม่ได้”

The Legacy System

เมื่อ Socrates นั่งทำงานบนคีย์บอร์ด เขาพบว่าโค้ดที่ควบคุม turbine overspeed detector มีลักษณะดังต่อไปนี้

• มีการใช้คำสั่ง GOTO อย่างสุ่มโดยไม่มีโครงสร้างชัดเจน
• การเข้าถึง I/O ทำที่อยู่แบบสุ่มโดยไม่มีการอธิบายหรือคอมเม้นต์ใด ๆ
• การคำนวณและการทำงานของบิต (AND, OR) ใช้ค่าคงที่ที่ดูเหมือนจะเป็น “ตัวเลขลึกลับ”

โค้ดเหล่านี้ขาด documentation และไม่มีคำอธิบายประกอบ ทำให้ยากต่อการเข้าใจหรือแก้ไขโดยผู้ที่ไม่ได้เขียนมาตั้งแต่แรก

Code Condition & Risks

สภาพของซอฟต์แวร์ดังกล่าวถือว่า “horrible” ตามที่ Socrates ระบุไว้ ความไม่เป็นระบบและไม่มีคอมเม้นท์ทำให้การเปลี่ยนแปลงใด ๆ มีความเสี่ยงต่อการสร้างข้อบกพร่องใหม่ ซึ่งอาจกระตุ้นให้เครื่องเทอร์ไบน์หยุดทำงานหรือเกิดเหตุการณ์ overspeed ที่อาจนำไปสู่การดับไฟฟ้าทั่วเมืองได้ การแก้ไขโดยไม่มีข้อมูลพื้นฐานจึงเป็นการเสี่ยงที่สูงเกินกว่าจะยอมรับ

Decision & Lessons

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

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

Impact

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

Summary

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