週一那場長達七小時的當機,GitHub自己給出的說法很直接:不是程式出錯,也不是設定改壞了,而是流量衝上了新高點,美國中部資料中心裡一個關鍵基礎設施元件,沒能跟上這波成長速度。
數字才是這次故障真正的重點。GitHub表示,自四月以來,平台每月的commit數量從14億次成長到29億次,四個月內幾乎翻了一倍。官方在聲明中寫道:「這樣的成長解釋了系統承受的壓力,但無法為這次的中斷開脫。」換句話說,GitHub清楚知道問題出在自家基礎設施跟不上用戶行為的變化速度,而不是把責任推給流量本身。
針對這次暴露出的弱點,GitHub在狀態報告中列出的修復方向,集中在同時併發活動的處理機制上。團隊正在重新檢視伺服器的CPU與記憶體警示設定,找出高流量期間可能失效的元件;同時導入一致的重試次數上限、重試預算,以及跨服務互動間的可變逾時設定,目的是避免「重試風暴」引發連鎖式的系統過載。
至於這波commit成長從何而來,GitHub的說明僅止於數字本身,並未進一步指出成因。這段時間點恰好與Anthropic、OpenAI等公司持續擴充AI輔助編碼工具的時間重疊,但這只是時間上的巧合觀察,GitHub官方並未將兩者直接畫上等號。作為多數專業與業餘開發者存放程式碼的預設平台,GitHub接下來要面對的,是如何讓基礎設施的擴充速度,追上這種成長曲線。
