2026 年 8 月 20 日，GitHub CTO Vlad Fedorov 發表官方報告，說明三天前那場讓全球開發者卡住的服務中斷：8 月 17 日，github.com、登入驗證、GitHub Actions、API、pull requests、issues 與 Copilot 同時出現問題，整整 7 小時 47 分鐘才完全恢復。這是 GitHub 繼 8 月 6 日 Actions 故障之後，同月第二起重大事件。
七小時四十七分鐘：發生什麼事
中斷期間，網站、認證、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%；正在建立可隨讀者數線性擴充的讀取能力，先在最大型的 monorepo 上推出；同時隔離關鍵系統、移除共享依賴，加強測試、安全發布與可觀測性。也值得留意節奏：這些承諾大多沒有附上時程表，真正的驗證就是下一次流量尖峰。
給依賴 GitHub 的團隊的提醒
三件事值得帶走。第一，重試策略是自己的責任：這次讓 Copilot 恢復變慢的正是客戶端重試，你的 CI、腳本與代理工作流若沒有 backoff 與上限，下一次就是放大器。第二，容量要按尖峰規劃，不是按平均：月 commit 四個月翻倍，任何「夠用到年底」的估計都值得重算。第三，關鍵流程要有降級路徑——當身分驗證或 API 掛掉時，團隊能不能繼續合併程式碼、部署到客戶端，取決於你今天有沒有備案。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。