摘要： GitHub 官方報告說明，8 月 17 日的中斷波及網站、登入、Actions、API、pull requests、issues 與 Copilot，耗時 7 小時 47 分鐘才完全恢復。肇因不是程式碼，而是中西部資料中心一個關鍵元件在需求超過容量前未能擴充；補救包括重試上限、新增超過 300 萬個 CPU 核心與擴大 Azure 承載。
2026 年 8 月 20 日，GitHub CTO Vlad Fedorov 發布官方報告，交代三天前那場讓全球開發者動彈不得的中斷。8 月 17 日當天，github.com、登入驗證、GitHub Actions、API、pull requests、issues 與 Copilot 一同出事，前後足足花了 7 小時 47 分鐘才完全恢復。這也是 GitHub 同月第二起重大事件，前一回是 8 月 6 日的 Actions 故障。
那 7 小時 47 分鐘裡發生了什麼
中斷期間淪陷的範圍，從網站、認證、CI/CD、API 一路延伸到負責 AI 輔助寫程式的 Copilot；GitHub 穩坐全球軟體供應鏈的中樞位置，這一停等同於同時掐住無數團隊的部署與協作。要把服務救回來，沒有按一下開關這種事：流量得先重新導向，服務再分階段一項項拉起來。其中 Copilot 回來得最慢，原因是服務仍在復原時，客戶端的重試迴圈持續把流量往上堆，GitHub 必須先把這股放大效應壓下去，全面復原才走得完。
肇因是容量，不是程式碼
報告對原因的說明毫不含糊：問題既非程式碼也非組態變更所引起，而是中西部資料中心的一個關鍵基礎設施元件，在流量衝上歷史新高時沒辦法擴充——GitHub 用自己的話承認「我們未能在需求超過容量之前完成擴充」。壓力究竟從何而來，背景數字給了答案：從 4 月至今，GitHub 每月 commit 數已由 14 億倍增為 29 億。平台規模翻倍之後，最脆弱的那個元件終究會浮上檯面，而且總挑在最糟的時刻。
這類報告往往帶著一種讓人不舒服的坦白。程式碼的錯誤有明確修法，還能靠迴歸測試守住；容量捉襟見肘卻是一場押在成長曲線上的賭注，而曲線跑得比賭注更快。四個月內月 commit 翻倍，多出來的不只是原本路徑上的流量——Copilot、代理式自動化這類新工作負載，連流量本身的形狀都改寫了：一個 commit 背後跟著更多 API 呼叫、連線維持得更久，還有一批不會先打聲招呼就自行重試的客戶端。
GitHub 端出的補救清單
報告列出的措施分成三層。在立即修補上，所有服務對服務的呼叫統一加上重試上限、重試預算與可變逾時，擋下重試風暴；那些容易受尖峰衝擊的元件，其低優先 CPU 與記憶體警報也重新檢查過一輪。在容量補強上，新增超過 300 萬個 CPU 核心、120 PB 高速儲存，網路頻寬同樣擴充——這樣的量體，等於平台裡憑空冒出一座中型雲端區域。在架構調整上，Azure 目前承載約 58% 的平台流量，5 月時不過 12%；GitHub 同步打造能隨讀者數線性擴充的讀取能力，並先從最大型的 monorepo 開始推出；此外還隔離關鍵系統、移掉共享依賴，在測試、安全發布與可觀測性上加大力道。節奏同樣值得留意：這些承諾大多沒有附上時程表，真正的驗收，是下一次流量尖峰。
依賴 GitHub 的團隊該帶走什麼
三件事值得放在心上。其一，重試策略得自己負責：這次拖慢 Copilot 復原的元凶就是客戶端重試；CI、腳本與代理工作流若少了 backoff 與上限，下一回變成放大器的就是它們。其二，容量要照尖峰規劃，而不是照平均：月 commit 四個月翻倍，任何「夠用到年底」的估算都該重新算過。其三，關鍵流程必須準備降級方案——當身分驗證或 API 倒下時，團隊還能不能照常合併程式碼、把東西部署到客戶端，取決於你今天有沒有把備案做出來。