บทเรียนจากเหตุ GitHub ล่ม 7 ชั่วโมง 47 นาที: เมื่อปัญหาไม่ได้มาจากโค้ด แต่มาจากความจุ

GitHub เผยแพร่รายงานหลังเหตุการณ์ล่มยาว 7 ชั่วโมง 47 นาที เมื่อ 17 สิงหาคม 2026 ซึ่งกระทบทั้งการล็อกอิน Actions API และ Copilot ทั่วโลก สาเหตุไม่ได้มาจากการเปลี่ยนโค้ดหรือคอนฟิก แต่มาจากความจุที่ตามการเติบโตไม่ทัน บทความนี้สรุปสิ่งที่เกิดขึ้นและเช็กลิสต์ที่ทีมไทยเอาไปใช้ได้ทันที

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

เหตุขัดข้องกินเวลา 7 ชั่วโมง 47 นาที และกระทบบริการหลักแทบทั้งหมดของแพลตฟอร์ม ตั้งแต่การเข้าใช้ github.com ระบบยืนยันตัวตน GitHub Actions ชุด API ไปจนถึง pull request, issue และ Copilot ซึ่งหมายความว่าทีมพัฒนาทั่วโลกที่ผูกไปป์ไลน์ไว้กับบริการนี้หยุดชะงักไปพร้อมกัน

ต้นเหตุคือส่วนประกอบสำคัญของโครงสร้างพื้นฐานในศูนย์ข้อมูลภูมิภาค Central US ไม่สามารถขยายรองรับปริมาณทราฟฟิกที่สูงเป็นประวัติการณ์ได้ เมื่อจุดนั้นรับไม่ไหว แรงกดดันจึงลามต่อไปยังระบบที่เชื่อมโยงกันจนเกิดความล้มเหลวแบบต่อเนื่อง (cascading failure) ที่เริ่มจากระบบยืนยันตัวตนแล้วขยายวงออกไป

สาเหตุคือความจุ ไม่ใช่การเปลี่ยนโค้ด

ประเด็นที่ GitHub เน้นย้ำคือทั้งเหตุการณ์นี้และเหตุ Actions ขัดข้องเมื่อวันที่ 6 สิงหาคม ไม่ได้เกิดจากการปล่อยโค้ดใหม่หรือการเปลี่ยนคอนฟิก แต่เกิดจากความจุล้วน ๆ ตัวเลขที่อธิบายสถานการณ์ได้ดีที่สุดคือจำนวนคอมมิตต่อเดือนบนแพลตฟอร์มที่เพิ่มจาก 1.4 พันล้านในเดือนเมษายน เป็น 2.9 พันล้านในเดือนสิงหาคม หรือมากกว่าเท่าตัวภายในสี่เดือน

นี่คือรูปแบบความล้มเหลวที่ทีมส่วนใหญ่เตรียมตัวไว้น้อยที่สุด เพราะกระบวนการ code review, staging และ canary deployment ทั้งหมดออกแบบมาจับความผิดพลาดจากการเปลี่ยนแปลง ไม่ได้ออกแบบมาจับสถานการณ์ที่ระบบเดิมซึ่งไม่มีอะไรเปลี่ยนเลย ค่อย ๆ เดินเข้าใกล้เพดานของตัวเอง

ทำไม Copilot ฟื้นตัวช้ากว่าบริการอื่น

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

ปรากฏการณ์นี้เรียกว่า retry storm และเป็นสาเหตุคลาสสิกที่ทำให้เหตุขัดข้องยืดเยื้อกว่าที่ควร ระบบกลับมาไหวแล้วแต่ถูกคำขอที่ค้างสะสมถล่มซ้ำจนล้มอีกรอบ วนแบบนี้ไปเรื่อย ๆ

GitHub จะทำอะไรต่อ

แผนที่ประกาศไว้มีสี่เรื่อง หนึ่งคือกำหนดขีดจำกัดการส่งซ้ำ งบประมาณการส่งซ้ำ และค่า timeout ให้สอดคล้องกันทั่วทุกบริการเพื่อไม่ให้เกิด retry storm อีก สองคือทบทวนการแจ้งเตือนระดับความสำคัญต่ำเพื่อค้นหาส่วนประกอบที่เปราะบางเมื่อทราฟฟิกพุ่ง สามคือขยายการใช้โครงสร้างพื้นฐานบน Azure ซึ่งปัจจุบันรองรับภาระงานของแพลตฟอร์มแล้ว 58% จากที่เคยเป็นเพียง 12% เมื่อเดือนพฤษภาคม และสี่คือปรับสถาปัตยกรรมให้ขยายความจุการอ่านของรีโปขนาดใหญ่ได้แบบเชิงเส้น

เช็กลิสต์สำหรับทีมไทย

เรื่องแรกที่ควรทำคือทบทวนนโยบายการส่งคำขอซ้ำของทุกไคลเอนต์ในระบบ ต้องมีการหน่วงแบบทวีคูณพร้อมค่าสุ่ม (exponential backoff with jitter) มีเพดานจำนวนครั้ง และมีงบประมาณการส่งซ้ำรวมทั้งระบบ ไม่ใช่ปล่อยให้แต่ละบริการส่งซ้ำตามใจ เรื่องที่สองคือใส่ circuit breaker และกลไกทิ้งงานส่วนเกิน (load shedding) เพื่อให้ระบบยอมปฏิเสธคำขอบางส่วนอย่างมีสติแทนที่จะล้มทั้งหมด

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