GitHub ล่มครั้งใหญ่ 17 ส.ค. กระทบดาวน์โหลด, Actions และ Copilot รู้ข้อเท็จจริงอะไรบ้าง

เวลา 12:36 น. EDT GitHub ระบุว่าแพลตฟอร์มมีสัญญาณฟื้นตัวอย่างชัดเจน หลังทีมงานระบุคอมโพเนนต์ที่เป็นต้นเหตุของปัญหาและดำเนินมาตรการแก้ไข อย่างไรก็ตาม ขณะนั้นบริการยังไม่ได้กลับสู่ภาวะเสถียรอย่างสมบูรณ์.

การกู้คืนไม่ได้เกิดขึ้นพร้อมกันทุกบริการ สถานะของบริการหลักหลายรายการกลับมาเป็นปกติ ขณะที่ Copilot ยังมีปัญหาการยืนยันตัวตนในบางแอปพลิเคชัน. รายงานเหตุการณ์อีกชุดระบุว่าภาพรวมของเหตุขัดข้องสิ้นสุดลงราว 21:15 UTC ทำให้ระยะเวลาของเหตุการณ์ทั้งหมดนานกว่าช่วงที่แพลตฟอร์มมีอาการรุนแรงในระยะแรก.

บริการใดได้รับผลกระทบบ้าง?

ผลกระทบที่ GitHub และรายงานเหตุการณ์ต่าง ๆ ระบุไว้มีดังนี้

• เว็บไซต์และ API: พบข้อผิดพลาดประมาณ 20%.
• การดาวน์โหลด archive และเนื้อหารีโพสตอรีแบบ raw: พบข้อผิดพลาดประมาณ 50%.
• เครื่องมือสำหรับนักพัฒนา: Pull Requests, Issues, Actions, Webhooks, Git operations และ Pages มีอาการทำงานช้าลง ใช้งานไม่ได้ หรือมีความพร้อมใช้งานลดลงในช่วงเวลาต่าง ๆ.
• ผู้ช่วยเขียนโค้ดด้วย AI: GitHub Copilot ได้รับผลกระทบ และยังเป็นหนึ่งในปัญหาที่ค้างอยู่หลังบริการหลักบางส่วนเริ่มฟื้นตัวแล้ว.
• ระบบตัวตนขององค์กร: มีรายงานผลกระทบต่อการยืนยันตัวตนแบบ SAML และ OIDC รวมถึงการจัดสรรบัญชีด้วย SCIM และ Team Sync ซึ่งอาจทำให้องค์กรไม่สามารถให้ผู้ใช้เข้าสู่ระบบหรือจัดการสิทธิ์ได้อย่างน่าเชื่อถือ.

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

จำนวนรายงานบน Downdetector บอกอะไรได้บ้าง?

ตัวเลขจากแพลตฟอร์มติดตามเหตุขัดข้องแตกต่างกันตามช่วงเวลาที่เก็บข้อมูลและวิธีนับ รายงานหนึ่งระบุว่า Downdetector มีรายงานมากกว่า 10,000 รายการ เมื่อเวลา 8:12 น. ตามเวลาแปซิฟิก ขณะที่รายงานช่วงการฟื้นตัวอีกชิ้นระบุจุดสูงสุดเกือบ 3,000 รายการ.

ตัวเลขเหล่านี้ไม่ควรถูกตีความว่าเป็นจำนวนผู้ใช้ที่ได้รับผลกระทบโดยตรง เพราะ Downdetector นับรายงานที่ผู้ใช้ส่งเข้ามา ไม่ใช่ผู้ใช้ทั้งหมดที่ประสบปัญหา อีกทั้งยอดยังเปลี่ยนแปลงตามภูมิภาค เวลา และวิธีการรายงาน

ทำไมการเกิดเหตุในเช้าวันจันทร์จึงยิ่งสร้างผลกระทบ?

เหตุการณ์เริ่มขึ้นในเช้าวันจันทร์ของสหรัฐฯ ซึ่งเป็นช่วงเริ่มต้นสัปดาห์ทำงานของทีมวิศวกรรมจำนวนมาก ช่วงเวลาดังกล่าวมักเป็นจังหวะที่ทีมเริ่มเปิดรีโพสตอรี ตรวจ Pull Requests รันการทดสอบอัตโนมัติ วางแผนงาน และเริ่มกระบวนการดีพลอย

เมื่อ Actions, Pull Requests, API และ Webhooks ได้รับผลกระทบ ทีมงานจึงอาจเจอความล้มเหลวต่อเนื่องหลายขั้นตอนในสายงานเดียวกัน แทนที่จะพบปัญหาแยกอยู่ในฟีเจอร์ใดฟีเจอร์หนึ่ง. สำหรับทีมที่พึ่งพา GitHub เป็นศูนย์กลางของการพัฒนา เหตุขัดข้องลักษณะนี้จึงมีโอกาสหยุดทั้งการเข้าถึงโค้ด การรีวิว การทดสอบ และการส่งมอบซอฟต์แวร์พร้อมกัน

GitHub แก้ปัญหาอย่างไร และยังไม่เปิดเผยอะไร?

ข้อมูลอัปเดตสาธารณะของ GitHub ยืนยันขั้นตอนหลัก 3 ประการ

1. ทีมวิศวกรตรวจสอบปัญหาประสิทธิภาพที่เพิ่มขึ้นในหลายบริการ
2. บริษัทระบุคอมโพเนนต์ที่เกี่ยวข้องและดำเนินการแก้ไข.
3. GitHub ใช้มาตรการบรรเทาปัญหาเพิ่มเติมหลังบริการหลักเริ่มฟื้นตัว รวมถึงการแก้ปัญหาการยืนยันตัวตนของ Copilot ที่ยังเกิดขึ้นเป็นระยะในบางแอปพลิเคชัน.

แต่สิ่งที่ยังไม่มีคำตอบคือคอมโพเนนต์ดังกล่าวคืออะไร การแก้ไขที่ดำเนินการมีรายละเอียดอย่างไร และเหตุการณ์นี้เกิดจากข้อจำกัดด้านความจุโดยตรงหรือไม่

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

เหตุการณ์นี้สะท้อนปัญหาความเสถียรของ GitHub ในปี 2026 อย่างไร?

เหตุขัดข้องเดือนสิงหาคมเกิดขึ้นหลัง GitHub รายงานว่าเดือนกรกฎาคมมีเหตุการณ์ด้านความพร้อมใช้งาน 8 ครั้ง หนึ่งในนั้นคือเหตุวันที่ 8 กรกฎาคมที่กินเวลานานกว่า 7 ชั่วโมง และกระทบ Web UI, REST API, GraphQL API, Actions, Packages, Copilot และ Git operations ในสภาพแวดล้อม Enterprise Cloud บางส่วน.

GitHub ยังอธิบายความท้าทายด้านโครงสร้างพื้นฐานว่า ปริมาณทราฟฟิกกำลังเพิ่มขึ้นอย่างรวดเร็ว โดยมีแรงผลักสำคัญจาก workflow การพัฒนาด้วย AI และ agentic development บริษัทระบุแนวทางรับมือ เช่น ย้ายความจุไปยัง Azure เพิ่มขึ้น แยกบริการออกจากกัน และลดจุดล้มเหลวร่วมของระบบ.

ขนาดของแผนดังกล่าวเปลี่ยนไปอย่างมาก จากเดิมที่ GitHub ตั้งเป้าเพิ่มความจุ 10 เท่า ต่อมาบริษัทประเมินว่าจำเป็นต้องออกแบบระบบให้รองรับระดับสูงสุด 30 เท่า ของขนาดในขณะนั้น. รายงานอื่นยังกล่าวถึงการเพิ่มความจุผ่านโครงสร้างพื้นฐานหลายคลาวด์ รวมถึง AWS ควบคู่กับ Azure แต่แผนเหล่านี้ไม่ได้พิสูจน์ว่าเป็นสาเหตุของเหตุขัดข้องในเดือนสิงหาคม.

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

องค์กรควรเตรียมตัวอย่างไร?

เหตุการณ์นี้ยังไม่ใช่หลักฐานว่านักพัฒนาจะเลิกใช้ GitHub ในเร็ว ๆ นี้ และข้อมูลที่มีอยู่ยังไม่รองรับการคาดการณ์ว่าจะเกิดการย้ายแพลตฟอร์มครั้งใหญ่ในทันที แต่เหตุการณ์ชี้ให้เห็นว่าองค์กรที่ใช้ GitHub ในกระบวนการส่งมอบซอฟต์แวร์ควรทบทวนสมมติฐานเมื่อระบบล่ม

มาตรการที่ทำได้ ได้แก่

• สำรองรีโพสตอรีหรือมี mirror ของโค้ดไว้
• ออกแบบการตั้งค่า CI/CD ให้ย้ายไปใช้ระบบอื่นได้เมื่อจำเป็น
• จัดทำขั้นตอนปล่อยซอฟต์แวร์ฉุกเฉินและทดสอบให้ทีมเข้าใจตรงกัน
• เตรียมแนวทางทำงานเมื่อ SSO, webhook หรือ hosted runner ใช้งานไม่ได้

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

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