GitHub 公布了 8 月 17 日大規模故障的原因說明。引爆這次事故的並不是程式碼或設定變更，而是基礎架構跟不上創新高的流量。真正讓復原時間拉長的，則是失敗請求被機械式反覆重送所形成的重試連鎖。

中斷持續了 7 小時 47 分

故障從協調世界時 8 月 17 日 13 時 28 分延續到 21 時 15 分，總共 7 小時 47 分。受影響的服務包括 Issues、拉取請求、API、Actions 以及 Copilot。尖峰時段，網頁與 API 流量的錯誤率約為 20%，封存檔下載與儲存庫原始內容下載的錯誤率約為 50%。

認證環節的傷害同樣不小，SAML 與 OIDC 認證、SCIM、Team Sync 都受到牽連。在啟用資料落地的 GitHub Enterprise Cloud 環境中，凡是依賴 GitHub.com 上公開工作流程步驟定義的 Actions 工作流程，也都無法運作。

復原是分階段完成的。隨著美國中部資料中心恢復，多數服務在 16 時 36 分前後回穩，Actions 的不穩定狀態延續到 18 時 3 分左右，Copilot 權杖服務則在 21 時 2 分完全恢復。

起點是 sidecar 的自動擴縮設定

直接原因是美國中部負載平衡器上的網路飽和。而走到這一步的路徑，是這次說明中技術上最耐人尋味的部分。

起點是服務網格 Istio 伴隨各服務執行的 sidecar Pod。這些 Pod 觸及並行處理上限，卻沒有自動增加，因為擴縮政策只監看主服務的指標，並未納入 sidecar 本身的上限。當瓶頸先出現在政策沒有觀察的位置，自動擴縮就會判定一切正常。

一處堵塞牽動下一處堵塞。最終有 4 台 HAProxy 節點耗盡流量上限，導致閘道的認證路徑劣化，大範圍出現認證延遲與失敗。再加上失敗就重送這種樂觀的重試邏輯，內部負載平衡器被壓得更沉。處置方式是同時暫停這些節點上的 HAProxy，隨即換來大範圍的即時復原。

讓流量暴增約 10 倍的重試風暴

部分正在失敗的流量被從美國中部移往北維吉尼亞。但在移轉的目的地又冒出另一個問題：某個內部端點回應延遲，誘發了 VS Code 中潛藏的重試瑕疵，使流量放大約 10 倍。

用數字看更能理解規模。Copilot 權杖服務的負載平時為每秒 7,000 到 9,000 個請求，當下卻飆升到每秒 70,000 到 100,000 個請求。一次失敗的權杖處理會衍生出大量額外請求，並就此陷入重試迴圈。

要收拾局面需要兩個步驟。團隊先送出一個暫時削弱閘道重試邏輯的拉取請求，接著在負載平衡器前以 403 阻擋權杖請求，之後再依站點逐步把流量放回去。復原期間針對 codeload 端點的爬取攻擊，也讓處理過程更加棘手。

4 月以來每月提交數翻了一倍

GitHub 承認，這次故障與 8 月 6 日的 Actions 故障都不是由程式碼或設定變更造成，本質上都是容量不足。用該公司自己的說法，就是沒能在需求超過容量之前先把關鍵元件擴充起來。

背後是負載的成長。該公司表示，自 4 月以來每月提交數從 14 億成長到 29 億，翻了一倍有餘。對此，GitHub 已追加超過 300 萬個 CPU 核心、120 PB 高速儲存以及相應的網路容量，並在既有資料中心塞進電力允許範圍內的全部硬體，同時加快遷移到 Azure 的腳步。

結果是 Azure 目前承擔了平台整體負載的約 58%，以及一半的 Git 操作。考量到 5 月時這個比例還只有平台負載的 12%，遷移速度相當快。下一個里程碑，是讓讀取處理能力隨讀取端數量線性成長的架構，並從規模最大的單體儲存庫開始逐步推展。

防止重演的措施與尚未做完的功課

公開的後續行動，幾乎逐一對應這次出問題的環節：修正自動擴縮政策，把服務網格 sidecar 的並行處理量與容量納入考量；在受影響的服務範圍內稽核 Istio 的請求數、並行數與擴縮上限；重新檢視閘道與用戶端兩側的重試上限與退避行為；處理放大 Copilot 權杖流量的 VS Code 行為；強化負載平衡器的容量監控與跨區域備援機制。

除此之外，GitHub 也要在服務之間的呼叫上，一致地套用重試次數上限、重試預算與可變逾時。把它想成阻止重試風暴與負載連鎖的共用煞車，會比較好理解。另一項工作是盤點先前優先度設得較低的 CPU 與記憶體警示，找出可能在流量突增時失效的元件。

該公司技術長 Vlad Fedorov 寫道，規模並不是唯一的課題。當變更的速度與複雜度上升，既有的維運實務沒有跟上；雖然已把人力與資源轉向更強的測試、更安全的部署、更好的可觀測性與更有效的警示，但這項工作尚未完成。GitHub 同時也在推動關鍵系統之間的隔離，減少彼此共用的相依關係。

總結

8 月 17 日的 GitHub 故障持續 7 小時 47 分，Issues、拉取請求、API、Actions 與 Copilot 都受到影響。原因並非程式碼或設定變更，而是從 Istio sidecar 自動擴縮失效開始的容量不足，並連鎖造成 HAProxy 飽和與認證劣化。復原之所以拖延，主因是 VS Code 端的重試瑕疵帶來約 10 倍的流量放大。背後則是負載的快速成長，每月提交數從 4 月的 14 億增加到 29 億。GitHub 正以增設 CPU 核心與儲存、加速遷移到 Azure，以及統一重試控制的方式重新整備平台。