กับดักการดีบัก
วิศวกรผู้เชี่ยวชาญมักเสียเวลาไปกับการแก้ไขปัญหาที่ไม่ซับซ้อนเนื่องจากพวกเขาตกอยู่ใน กับดักทางความคิด ที่ทำให้ดำดิ่งลงไปในรายละเอียดลึกเกินไป แทนที่จะมองภาพกว้าง ปัญหานี้ไม่ได้เกิดจากความไร้ความสามารถ แต่เป็นข้อผิดพลาดทางปัญญาที่เกิดขึ้นได้กับทุกคน
บทความ "The Debug Trap: Why Smart Engineers Waste Hours on Trivial Problems" จาก CNCF กล่าวถึงปัญหาที่วิศวกรผู้เชี่ยวชาญมักใช้เวลาหลายชั่วโมงในการแก้ไขข้อผิดพลาดเล็กน้อย เนื่องจากพวกเขา เน้นการค้นหาสาเหตุเชิงลึก แทนที่จะ มองหาการเปลี่ยนแปลงล่าสุดที่เกิดขึ้น บทความนี้เน้นย้ำหลักการที่ว่า ระบบการผลิตมักไม่เสียเองโดยไม่มีสาเหตุ และ การเปลี่ยนแปลงที่เกิดขึ้นไม่นานมานี้มักเป็นตัวการ ผู้เขียนแนะนำให้วิศวกร ย้อนกลับการเปลี่ยนแปลงที่น่าสงสัยก่อน แล้วค่อยทำความเข้าใจสาเหตุที่แท้จริงในภายหลัง เพื่อลดเวลาการแก้ไขปัญหาให้รวดเร็วขึ้น ซึ่งสอดคล้องกับ ลำดับการตรวจสอบที่แนะนำ โดยเริ่มจากสิ่งที่เพิ่งปรับใช้หรือเปลี่ยนแปลงไป บทความนี้ชี้ให้เห็นว่าปัญหาหลักคือ การขาดการมองเห็นการเปลี่ยนแปลง ซึ่งนำไปสู่การแก้ไขปัญหาที่ไร้ประสิทธิภาพ
สาเหตุหลัก ๆ ได้แก่:
- ไม่ตั้งคำถามว่า "มีอะไรเปลี่ยนแปลงไปบ้างหรือไม่?" ตัวอย่างเช่น วิศวกรอาวุโสสามคนใช้เวลาสี่ชั่วโมงในการดีบักปัญหา Kubernetes ที่ดูเหมือนจะซับซ้อน แต่สุดท้ายกลับพบว่าเกิดจากการอัปเกรดเวอร์ชันของ
kubectlซึ่งทำให้การจัดการประเภทของ secret แตกต่างไป พวกเขาเสียเวลาไป 240 นาทีเพื่อแก้ปัญหาที่ใช้เวลาเพียง 5 นาที หากเพียงแค่ถามคำถามง่ายๆ ว่า "มีอะไรเปลี่ยนแปลงไปเมื่อเร็วๆ นี้หรือไม่?" - มองข้ามหลักการของการเปลี่ยนแปลง (The Change Principle) ระบบที่ใช้งานจริงไม่ได้พังโดยไม่มีเหตุผล แต่มีบางอย่างเปลี่ยนแปลงไปก่อนเสมอ การเปลี่ยนแปลงมักจะแบ่งออกเป็นสี่ประเภทหลักๆ ได้แก่:
- โค้ด (Code): การปรับใช้, การเปิด-ปิดฟีเจอร์, หรือการแก้ไขเล็กๆ น้อยๆ
- โครงสร้างพื้นฐาน (Infrastructure): การอัปเกรดเซิร์ฟเวอร์, การเปลี่ยนแปลงเครือข่าย, หรือการขยายการทำงาน
- การกำหนดค่า (Configuration): ตัวแปรสภาพแวดล้อม, การสลับการตั้งค่าที่ทำ "เพื่อทดสอบ"
- ปริมาณการรับส่งข้อมูล (Traffic): โหลดที่เพิ่มขึ้นกะทันหัน, การเปลี่ยนแปลงทางภูมิศาสตร์, หรือการโจมตีของบอท เมื่อยอมรับหลักการนี้ การดีบักจะกลายเป็นการสืบสวนสอบสวนมากกว่าการใช้ความรู้ทางเทคนิคขั้นสูง
- สัญชาตญาณที่อยากเข้าใจปัญหาอย่างถ่องแท้ก่อน วิศวกรมักจะต้องการทำความเข้าใจสาเหตุที่แท้จริง, แก้ไขสิ่งที่ผิดพลาดให้ถูกต้อง, และเขียนรายงานหลังเกิดเหตุ (post-mortems) ที่แสดงถึงความลึกซึ้งทางเทคนิค อย่างไรก็ตาม ผู้ใช้งานระบบไม่ได้สนใจเส้นทางการเรียนรู้ของวิศวกร แต่สนใจว่าซอฟต์แวร์สามารถทำงานได้ตามปกติ ตัวอย่างเช่น ปัญหา certificate pinning ที่ทีมงานใช้เวลาหกชั่วโมงในการแก้ไข โดยการวิเคราะห์ล็อกของ TLS handshake และการทำความเข้าใจรายละเอียดการเข้ารหัส ในขณะที่แนวทางแรก (First-principle approach) เพียงแค่ถามว่า "มีอะไรเปลี่ยนแปลงไป? อ๋อ, ใบรับรอง (certificates) งั้นก็ย้อนกลับไปก่อน" ซึ่งใช้เวลาเพียงหกนาที
- ความเชื่อผิดๆ เกี่ยวกับบั๊กที่ซับซ้อน (The Exotic Bug Fallacy) วิศวกรทุกคนมักมีทฤษฎีโปรดเกี่ยวกับสาเหตุที่ระบบขัดข้อง ซึ่งมักจะฟังดูน่าประทับใจ เช่น "อาจเป็น race condition ใน distributed cache ของเรา" หรือ "อาจเป็น memory leak ใน JVM garbage collector" หรือ "เป็นเพราะ Kubernetes เวอร์ชันใหม่ที่ทำให้เกิดปัญหาเครือข่าย" แต่ความจริงคือ 95% ของปัญหาที่เกิดขึ้นจริงเกิดจากการเปลี่ยนแปลงที่ชัดเจนและน่าเบื่อที่คุณได้ทำไปเมื่อเร็วๆ นี้ ส่วนอีก 5% ที่เหลือเกิดจากการเปลี่ยนแปลงที่ชัดเจนและน่าเบื่อที่คนอื่นทำไปเมื่อเร็วๆ นี้ โค้ดของคุณเอง, การปรับใช้ล่าสุดของคุณ, หรือการเปลี่ยนแปลงการกำหนดค่าที่คุณทำในเช้านี้ มักจะเป็นสาเหตุของปัญหา
- ลำดับการแก้ไขปัญหาที่ไม่เหมาะสม (The Debug Stack) แทนที่จะไล่เรียงตามลำดับความสำคัญ วิศวกรมักจะข้ามไปยังการตรวจสอบบั๊กแพลตฟอร์ม (ระดับ 5) ก่อนที่จะพิจารณาว่า:
- ฉันปรับใช้โค้ดอะไรไปเมื่อเร็วๆ นี้?
- โครงสร้างพื้นฐานมีอะไรเปลี่ยนแปลงไปบ้าง?
- การกำหนดค่ามีอะไรเปลี่ยนแปลงไปบ้าง?
- การพึ่งพาภายนอก (external dependencies) มีอะไรเปลี่ยนแปลงไปบ้าง? ปัญหาโดยส่วนใหญ่สามารถแก้ไขได้ที่ระดับ 1 หรือ 2 การตรวจสอบระดับ 5 ก่อนที่จะพิจารณาระดับ 1-4 คือการดีบักในโหมดที่ยากลำบากโดยไม่จำเป็น
ปัญหาที่แท้จริงไม่ใช่ความซับซ้อนทางเทคนิค แต่เป็นการมองเห็นการเปลี่ยนแปลงที่ไม่ชัดเจน (changes visibility) เมื่อระบบพัง ทีมงานไม่ควรต้องเสียเวลาค้นหาว่า "มีใครปรับใช้อะไรไปบ้าง" ผ่านคลังเก็บโค้ด, ประวัติการแชท, และระบบจัดการการเปลี่ยนแปลงหลายแห่ง เพื่อสร้างไทม์ไลน์ แหล่งข้อมูลแนะนำว่า เมื่อระบบขัดข้อง ให้ต้านทานสัญชาตญาณที่จะดำดิ่งลงไปในรายละเอียด แต่ให้หยุดคิดและถามคำถามที่ถูกต้องว่า "มีอะไรเปลี่ยนแปลงไปบ้าง?" จากนั้นให้แก้ไขปัญหาก่อน แล้วค่อยทำความเข้าใจในภายหลัง