Title: GitHub Actions กลับมาใช้งานได้แล้ว แต่ยังต้องแก้ไขด้วยตนเอง

GitHub Actions กลับมาออนไลน์อีกครั้งเมื่อเวลา 02:04 UTC ของวันที่ 7 สิงหาคม เหตุการณ์ขัดข้องที่เกิดขึ้นส่งผลให้มีเหตุการณ์ push และ pull-request จำนวนมากที่ไม่ถูกรัน ดังนั้นนักพัฒนาจึงต้องทำการรันงานเหล่านั้นซ้ำด้วยตนเอง

หน้าสถานะ (status page) แสดงสถานะเป็นสีเขียวแล้ว แต่ workflow ใดๆ ที่ควรจะเริ่มทำงานในช่วงที่ระบบขัดข้องกลับไม่มีการตอบสนอง เนื่องจาก GitHub ไม่สามารถสั่งรัน trigger ที่พลาดไปโดยอัตโนมัติได้ ทีมงานจึงต้องทำการ push commit ใหม่, อัปเดต pull request หรือคลิก Re-run jobs ใน UI สำหรับผู้ใช้งาน Actions Runner Controller แบบ open-source จำเป็นต้องตรวจสอบด้วยว่า runner pods ไม่ได้ค้างอยู่ในสถานะ idle

เกิดอะไรขึ้นและทำไมเรื่องนี้จึงสำคัญ

GitHub Actions เป็นตัวขับเคลื่อน CI pipelines ของ repository นับล้าน เมื่อระบบหยุดชะงัก การเปลี่ยนแปลงโค้ดจะค้างอยู่โดยไม่มีการดำเนินการ ชุดทดสอบ (test suites) จะไม่ทำงาน และการ deployment จะล่าช้าออกไป เมื่อวันที่ 7 สิงหาคม บริการหยุดประมวลผลทั้งเหตุการณ์ push (commit ใหม่) และเหตุการณ์ pull-request (การอัปเดตการรีวิว) ซึ่งเป็นสอง trigger ของ CI ที่พบบ่อยที่สุด

วิธีการกู้คืน pipeline ของคุณ

  1. Push a new commit – การเปลี่ยนแปลงใดๆ ใน branch จะเป็นการสั่งให้ push trigger ทำงานอีกครั้ง
  2. Update the pull request – เพิ่มคอมเมนต์, เปลี่ยนชื่อหัวข้อ หรือ push commit เพิ่มเติมเพื่อสั่งให้ PR workflow ทำงานใหม่
  3. Rerun the workflow manually – ในหน้า Actions UI จะมีปุ่ม “Re-run jobs” แสดงขึ้นมาสำหรับแต่ละการรันที่ล้มเหลว

หากคุณใช้งาน self-hosted runners ผ่าน Actions Runner Controller ให้ตรวจสอบ runner pods เนื่องจากบางตัวอาจค้างอยู่ในสถานะ idle หลังจากบริการกลับมาใช้งานได้ ให้ทำการ restart หรือ redeploy ใหม่

ผลกระทบต่อทีม

  • การสูญเสียผลิตภาพ (Productivity loss) – นักพัฒนาต้องรอผลตอบรับที่ปกติควรจะได้รับภายในไม่กี่นาที
  • การเลื่อนกำหนดการ Release – pipeline ใดๆ ที่เป็นเงื่อนไขในการ release อาจทำให้กำหนดการส่งมอบงานล่าช้าออกไป
  • ภาระงานด้านปฏิบัติการ (Operational overhead) – ทีมงานต้องตรวจสอบการรันงานล่าสุด หาจุดที่ตกหล่น และดำเนินการตามขั้นตอน manual ด้านบน ซึ่งเป็นการดึงเวลาจากการพัฒนาฟีเจอร์ใหม่ๆ

บทสรุป: เหตุการณ์ขัดข้องครั้งนี้แสดงให้เห็นว่า แม้แต่บริการ CI ที่มีความเสถียรสูงก็อาจทำพลาดได้ และการสั่งรันซ้ำโดยอัตโนมัติก็ไม่ใช่สิ่งที่รับประกันได้เสมอไป ควรบรรจุขั้นตอนการกู้คืนด้วยตนเองไว้ใน incident-response playbooks ของคุณ และคอยติดตามความเคลื่อนไหวของ GitHub ในการพัฒนาการจัดการ event ให้มีความยืดหยุ่น (resilient) มากยิ่งขึ้น