เว็บไซต์ Deploy แต่ไม่อัปเดต? — เบื้องหลังการไล่จับบั๊กที่ Dashboard บอกว่า "สำเร็จ" แต่จริง ๆ ไม่ใช่

เกิดอะไรขึ้น?

วันหนึ่ง เราเพิ่มบทความใหม่ลงเว็บไซต์ ระบบ CI/CD build สำเร็จ ✅ deploy สำเร็จ ✅ Dashboard สีเขียวทุกอย่าง — แต่พอเปิดเว็บไซต์ดู ข้อมูลเก่า 3 วันยังอยู่ บทความใหม่หายไปหมด

ไม่ใช่แค่ครั้งเดียว — ย้อนกลับไปดูพบว่า deploy 3 ครั้งติดต่อกัน ถูกรายงานว่า "สำเร็จ" ทั้งหมด แต่ไม่มีครั้งไหนที่อัปเดตจริง

นี่คือบันทึกกระบวนการไล่หาสาเหตุ ตั้งแต่สิ่งที่เราเห็น → สิ่งที่เราคิด → สิ่งที่เราพบ

ขั้นที่ 1 — ยืนยันว่า "สำเร็จ" จริงหรือ?

สิ่งแรกที่ทำคือตรวจสอบ pipeline ทุกขั้นตอน:

• Build — image ถูกสร้างและ push ขึ้น registry ✅
• Deploy — ระบบ apply configuration เข้า cluster สำเร็จ ✅
• Rollout — ค้าง! timeout หลัง 2 นาที แต่ถูกจัดการด้วย fallback message แทนที่จะเป็น error ❌

จุดสำคัญ: ระบบรายงานว่า "สำเร็จ" เพราะ timeout ถูกจัดการเป็น warning ไม่ใช่ error — pipeline ผ่านหมดแม้ว่าขั้นตอนสุดท้ายจะล้มเหลว

บทเรียนแรก: "ไม่มี error" ไม่ได้แปลว่า "สำเร็จ" — Silent failure อันตรายกว่า loud failure เสมอ

ขั้นที่ 2 — ตรวจสอบสมมติฐานที่เห็นได้ชัดก่อน

เมื่อรู้ว่า rollout ค้าง คำถามต่อไปคือ "ทำไม?" เราเริ่มจากสมมติฐานที่พบบ่อยที่สุด:

สมมติฐาน A: ทรัพยากรไม่พอ?

เปิด monitoring dashboard ดู — CPU ใช้แค่ 7%, Memory ใช้แค่ 38%, Load Average ต่ำมาก

❌ ตัดออก — ทรัพยากรเหลือเฟือ

สมมติฐาน B: Health check ล้มเหลว?

ตรวจสอบ configuration — endpoint ที่ใช้ตรวจสุขภาพถูกตั้งค่าไว้ถูกต้อง เคยทำงานได้ในเวอร์ชันก่อนหน้า

❌ ตัดออก — configuration ไม่มีอะไรเปลี่ยน

สมมติฐาน C: Image ดึงไม่ได้?

ตรวจ registry — image ถูก push สำเร็จและดึงได้ปกติ

❌ ตัดออก — ไม่ใช่ปัญหา image

ขั้นที่ 3 — ย้อนเวลาหาจุดที่ "พัง"

เมื่อสมมติฐานแรก ๆ ตกหมด เราเปลี่ยนมุม — ย้อนกลับไปหาครั้งสุดท้ายที่สำเร็จจริง แล้วเปรียบเทียบ:

แพทเทิร์นชัดเจน: v1.1.195 สำเร็จปกติ ตั้งแต่ v1.1.196 เป็นต้นมาค้างทุกครั้ง

ตรวจสอบว่ามีอะไรเปลี่ยนระหว่าง 2 เวอร์ชันนี้ — ไม่มีอะไรเปลี่ยนเลย ในส่วน infrastructure มีแต่การเพิ่มเนื้อหาใหม่

ขั้นที่ 4 — Root Cause: "โดมิโน" ที่ล้มต่อกัน

เมื่อวิเคราะห์ลึกขึ้น จึงเข้าใจว่าเกิดอะไรขึ้น:

กลไกของ Rolling Update

ระบบ container orchestration ใช้กลยุทธ์ rolling update เพื่อ zero-downtime deployment:

1. สร้าง container ใหม่ ก่อน (surge)
2. รอจนใหม่พร้อม (readiness check ผ่าน)
3. ค่อยปิดเก่า (terminate)

ด้วยการตั้งค่า "ห้ามลดจำนวนที่ทำงานได้" — container เก่าจะถูกปิดได้ก็ต่อเมื่อ container ใหม่พร้อมแล้วเท่านั้น

ปัญหา: Chain Reaction

1. v1.1.196 timeout — rollout ไม่เสร็จภายในเวลาที่กำหนด ระบบทิ้ง rollout ไว้ใน "สถานะกำลังดำเนินการ" (in-progress)
2. v1.1.197 มา deploy ทับ — แต่ระบบยังประมวลผล rollout เก่าอยู่ ทำให้ใหม่ก็ค้างตาม
3. v1.1.198 มาอีก — ซ้อนอีกชั้น เหมือน โดมิโนที่ล้มต่อกัน

บทเรียนที่สอง: Rollout ที่ timeout ไม่ได้หายไป — มันค้างรอจนกว่าจะมีคนมาแก้