GitHub เผชิญการหยุดทำงานหลายครั้ง แม้ย้ายส่วนใหญ่ไป Azure

GitHub เผชิญการหยุดทำงานหลายครั้งในเดือนพฤษภาคม‑มิถุนายน 2569 แม้จะเพิ่มกำลังการประมวลผลและย้ายส่วนใหญ่ของระบบไปยังโครงสร้างพื้นฐานของ Azure ความเสถียรของบริการยังคงไม่สม่ำเสมอ การล่มของแพลตฟอร์มอาจส่งผลกระทบต่อนักพัฒนานับล้านที่พึ่งพาโค้ดเปิดเผยและ Copilot ในการเขียนโค้ดอัตโนมัติ

Overview

GitHub รายงานการเกิดเหตุการณ์ 9 ครั้งในเดือนพฤษภาคม 2569 ซึ่งลดลงจาก 10 ครั้งในเดือนเมษายนตามรายงานความพร้อมใช้งานประจำเดือนของบริษัท อย่างไรก็ตาม ตัวชี้วัดจากแหล่งข้อมูลภายนอกเช่นโครงการ “Missing GitHub Status Page” แสดงให้เห็นว่าการอัพไทม์ในช่วง 90 วันอยู่ที่ 87.26 % ซึ่งต่ำกว่าตัวเลขที่ GitHub แสดงบนหน้า Status อย่างเป็นทางการที่มักอยู่ราว 99.9 %

Jakub Oleksy, SVP of software engineering ของ GitHub ยอมรับว่ามี “งานที่ต้องทำต่อไป” แม้จะได้ทำการเปลี่ยนแปลงเชิงโครงสร้างเพื่อกำจัดจุดล้มเหลวแบบถาวรแล้ว การปรับปรุงเหล่านี้มุ่งหมายให้ระบบทำงานได้อย่างน่าเชื่อถือเมื่อต้องการ

Traffic Surge & AI Impact

การเพิ่มขึ้นอย่างรวดเร็วของการใช้ AI‑assisted coding และเวิร์กโฟลว์การพัฒนาแบบเอเจนต์ทำให้ปริมาณการส่ง Pull Request, Commit และการสร้างรีโพซิทอรีใหม่พุ่งสูงขึ้นอย่างต่อเนื่อง GitHub ระบุว่าปีที่ผ่านมาได้รับ 1 พันล้าน คอมมิตต่อปี ในขณะนี้มี 1.4 พันล้าน คอมมิตต่อเดือน ซึ่งเป็นสาเหตุสำคัญของความแออัดบนระบบ

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

Capacity Expansion & Azure Migration

GitHub ตั้งเป้าขยายกำลังการประมวลผล 10 เท่า ตั้งแต่เดือนตุลาคม 2568 แต่เมื่อกุมภาพันธ์ 2569 พบว่าต้องเพิ่มขนาด 30 เท่า เพื่อรองรับการเติบโตของปริมาณการทำงานที่เพิ่มขึ้น การย้ายงานส่วนใหญ่ไปยัง Azure ทำให้สัดส่วนการให้บริการจาก Azure เพิ่มจาก 8 % (กุมภาพันธ์) เป็น 40 % (ปัจจุบัน)

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

• ปริมาณคอมมิตต่อเดือน: 1.4 พันล้าน
• การเพิ่มความจุที่วางแผน: 10× (ตุลาคม 2568) 30× (กุมภาพันธ์ 2569)
• สัดส่วนการให้บริการจาก Azure: 8 % 40 %

Incident Statistics & Availability Metrics

ตามรายงานของ GitHub มีเหตุการณ์ล่ม 26 ครั้งในเดือนเมษายน, 23 ครั้งในเดือนพฤษภาคม, และ 12 ครั้งจนถึงปัจจุบันในเดือนมิถุนายน ตัวเลขนี้แตกต่างจากข้อมูลบนหน้า Status ของ GitHub ที่แสดงอัพไทม์ราว **99.9 % สำหรับบริการที่ระบุ

ข้อมูลจาก “Missing GitHub Status Page” ให้มุมมองที่แตกต่าง โดยคำนวณอัพไทม์โดยพิจารณาระยะเวลาการหยุดทำงานทั้งหมด การวัดผลที่แตกต่างกันทำให้การสื่อสารความเสถียรของระบบอาจทำให้ผู้ใช้สับสน

• อัพไทม์ 90 วันตาม “Missing GitHub Status Page”: **87.26 %
• อัพไทม์เดือนเมษายน: **78.33 %
• อัพไทม์เดือนพฤษภาคม: **93.86 %
• อัพไทม์เดือนมิถุนายน (จนถึงวันนี้): **88.39 %

Ongoing Challenges & Future Plans

แม้ว่าการย้ายส่วนสำคัญของระบบไปยัง Azure จะเพิ่มกำลังการประมวลผลและลดความเสี่ยงของการล่มที่แพร่กระจาย แต่ความแออัดของ Azure เองในช่วงที่มีการใช้งานสูงทำให้ความเสถียรของ GitHub ยังคงเป็นปัญหา Jakub Oleksy ย้ำว่าทีมกำลังทำ “การเปลี่ยนแปลงเชิงโครงสร้างที่ถาวร” เพื่อขจัดโหมดการล่มที่อาจเกิดขึ้นในอนาคต

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

Impact on Users

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

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

Summary

GitHub ยังคงเผชิญกับความท้าทายด้านความพร้อมใช้งานแม้จะเพิ่มกำลังและย้ายส่วนใหญ่ของระบบไปยัง Azure การเพิ่มปริมาณการทำงานจาก AI‑assisted coding ทำให้ความต้องการทรัพยากรสูงขึ้นอย่างต่อเนื่อง ผู้ใช้และองค์กรจึงต้องติดตามสถานะการให้บริการอย่างใกล้ชิดและเตรียมพร้อมรับมือกับการหยุดทำงานที่อาจเกิดขึ้นในอนาคต.