สำหรับเหตุการณ์ระบบล่มนานถึง 7 ชั่วโมงในวันจันทร์ที่ผ่านมา GitHub ออกมาชี้แจงตรงไปตรงมาว่า ไม่ใช่เพราะโค้ดผิดพลาด และไม่ใช่เพราะการตั้งค่าเสียหาย แต่เป็นเพราะปริมาณการใช้งานพุ่งขึ้นสู่จุดสูงสุดใหม่ ขณะที่องค์ประกอบสำคัญของโครงสร้างพื้นฐานในศูนย์ข้อมูลภาคกลางของสหรัฐฯ ไม่สามารถขยายตัวรองรับการเติบโตที่รวดเร็วขนาดนี้ได้ทัน
ตัวเลขต่างหากที่เป็นประเด็นสำคัญที่แท้จริงของเหตุขัดข้องครั้งนี้ GitHub เปิดเผยว่านับตั้งแต่เดือนเมษายนเป็นต้นมา ยอด commit บนแพลตฟอร์มต่อเดือนเพิ่มขึ้นจาก 1.4 พันล้านครั้งเป็น 2.9 พันล้านครั้ง แทบจะเพิ่มขึ้นเป็นสองเท่าภายในเวลาเพียง 4 เดือน โดยในแถลงการณ์ระบุว่า "การเติบโตในระดับนี้อธิบายได้ว่าทำไมระบบถึงต้องแบกรับแรงกดดันมหาศาล แต่นั่นไม่ใช่ข้อแก้ตัวสำหรับเหตุขัดข้องครั้งนี้" พูดง่ายๆ คือ GitHub รู้ตัวดีว่าปัญหาอยู่ที่โครงสร้างพื้นฐานของตัวเองตามไม่ทันความเร็วในการเปลี่ยนแปลงพฤติกรรมของผู้ใช้ ไม่ใช่การโยนความผิดให้กับปริมาณการใช้งานเพียงอย่างเดียว
สำหรับช่องโหว่ที่เผยออกมาในครั้งนี้ แนวทางแก้ไขที่ GitHub ระบุไว้ในรายงานสถานะ มุ่งเน้นไปที่กลไกการจัดการกิจกรรมที่เกิดขึ้นพร้อมกันในเวลาเดียวกัน ทีมงานกำลังทบทวนการตั้งค่าแจ้งเตือน CPU และหน่วยความจำของเซิร์ฟเวอร์ใหม่อีกครั้ง เพื่อหาองค์ประกอบที่อาจล้มเหลวในช่วงที่มีทราฟฟิกสูง พร้อมกันนี้ยังนำระบบจำกัดจำนวนครั้งการลองใหม่ที่สอดคล้องกัน งบประมาณสำหรับการลองใหม่ รวมถึงการตั้งค่าไทม์เอาต์แบบยืดหยุ่นระหว่างการโต้ตอบข้ามบริการมาใช้ เพื่อป้องกันไม่ให้เกิด "พายุการลองใหม่" ที่จะนำไปสู่ระบบล่มแบบต่อเนื่อง
ส่วนที่มาของการเติบโตของ commit ในระลอกนี้ คำอธิบายของ GitHub ระบุไว้เพียงแค่ตัวเลขเท่านั้น ยังไม่ได้ชี้ชัดถึงสาเหตุที่แท้จริง ช่วงเวลานี้บังเอิญตรงกับช่วงที่บริษัทอย่าง Anthropic และ OpenAI ยังคงขยายเครื่องมือเขียนโค้ดด้วยความช่วยเหลือของ AI อย่างต่อเนื่อง แต่นี่เป็นเพียงข้อสังเกตที่บังเอิญเกิดขึ้นในช่วงเวลาเดียวกันเท่านั้น ทาง GitHub เองก็ไม่ได้ระบุอย่างชัดเจนว่าทั้งสองเรื่องนี้เกี่ยวข้องกันโดยตรง ในฐานะแพลตฟอร์มเริ่มต้นที่นักพัฒนามืออาชีพและมือสมัครเล่นส่วนใหญ่ใช้เก็บโค้ด สิ่งที่ GitHub ต้องเผชิญต่อไปคือการทำให้การขยายโครงสร้างพื้นฐานตามทันเส้นกราฟการเติบโตแบบนี้ให้ได้
