GitHub 近八小時故障點樣由容量盲點滾大，開發團隊要預備咩後路

GitHub 喺 8 月 17 日遇上一次橫跨多項核心服務嘅故障，由香港時間當晚 9 時 28 分一路拖到翌日朝早 5 時 15 分，合共 7 小時 47 分鐘。官方話 GitHub.com、身份驗證、API、Pull Requests、Issues、Actions 同 Copilot 都受影響；高峰時網頁同 API 錯誤率約 20%，原始檔案及壓縮檔下載錯誤率更去到約 50%。對開發團隊嚟講，呢種半壞狀態往往麻煩過完全斷線：有啲請求成功、有啲失敗，自動化工具就會一路重試，結果更難判斷一個部署究竟做咗幾多。

Autoscaling 有開，但睇錯咗地方

GitHub 官方技術報告顯示，Central US 資料中心喺流量創新高時，負載平衡器網絡開始飽和。最先頂唔順嘅係一個 Istio sidecar pod，佢撞到 concurrency 上限，autoscaling 政策監察緊主服務容量，但冇睇 sidecar 自己仲剩幾多空間。系統以為容量未爆，實際入口已經塞車，故障之後一路擴散，最後有四個 HAProxy 節點用盡 flow limit，連 gateway 身份驗證都慢落嚟。今次出事嘅正正係服務旁邊嗰啲共用元件；平時較少人留意，容量規劃亦容易漏咗佢哋。

內部 retry 隨即令情況惡化。當服務開始延遲，系統用較進取嘅方式重試，原意係捱過短暫錯誤，結果就不停向已經過載嘅負載平衡器加單。GitHub 暫停涉事 HAProxy 後，大部分服務喺 16:36 UTC 左右恢復，Actions 就拖到約 18:03 UTC。呢條時間線反映各項功能共用身份驗證、gateway 同控制層；前台開得返，唔代表 CI/CD 已經可以放心重新開閘。

圖片：GitHub

Copilot 點解特別遲先恢復

GitHub 將部分流量搬去 Northern Virginia 後，Copilot 又撞中另一個潛伏已久嘅問題。某個內部 endpoint 回應變慢，觸發 VS Code 客戶端 retry bug，將 Copilot Token Service 流量放大約十倍。官方數字顯示，平時每秒約 7,000 至 9,000 個請求，事故期間升到 70,000 至 100,000 個。工程團隊要削減 gateway retry、用負載平衡器回覆 403 截停部分 token 請求，再逐個站點慢慢恢復流量，服務先至喺 21:02 UTC 穩定返。團隊要留意，retry 應該設上限，亦要加入退避同隨機延遲，否則服務恢復期間只會再推高流量。

圖片：GitHub

增長太快解釋到壓力，解釋唔到盲點

GitHub 話每月 commit 數由今年 4 月嘅 14 億次升到 29 億次，亦已加咗超過 300 萬個 CPU 核心、120PB 高速儲存，同時把約 58% 平台負載及一半 Git 操作搬到 Azure。iThome 報道亦將焦點放喺基建容量追唔上使用量。不過今次唔宜簡化成「機器買得唔夠」：真正引爆點係 scaling policy 漏睇 sidecar 上限，跟住共用身份驗證路徑同 retry 行為再將局部擠塞推到其他服務。GitHub 已話會重新檢查 Istio 上限、regional failover、負載平衡器監察，同統一 retry budget。

有本機 Git clone，都未必開到工

Git 本身係分散式，開發者斷網仍然可以改 code 同 commit；但現代交付流程早已綁埋 pull request、branch protection、Actions、webhook、API、身份驗證、套件同雲端 coding agent。今次官方受影響清單冇單獨列出 GitHub Packages，所以唔應該話佢一定停過；不過團隊如果建置時要即場向 GitHub 拉 action definition、dependency 或 token，任何一段控制層同身份驗證出錯，都足以令條 pipeline 卡住。自設 runner 只係保住執行機器，Actions 控制層出事時一樣未必接到新 job。

降級方案要喺故障前定好

實際做法可以由最常壞嗰幾個接點入手：鎖實 dependency 版本，將關鍵 action、套件同建置工具放入受控 cache 或內部 mirror；保存已簽署、可重新部署嘅 release artifact，避免每次回滾都要重新 build；替緊急修正準備獨立於 GitHub Actions 嘅最小部署路徑，但保留審批同 audit log。涉及 GitHub API 嘅程式亦要識得排隊、退避同熔斷，唔好見 timeout 就無限重試。狀態頁警報之外，最好再用 synthetic check 測試團隊真正依賴嘅 clone、token、package pull 同 workflow dispatch，因為綠色首頁未必代表你條路已經通返。

雲端 coding agent 普及之後，repo、身份驗證、模型入口同 CI 更容易集中喺同一個平台。團隊未必值得為幾個鐘故障即刻搬走全部工具，但至少要寫清楚 GitHub 停一個鐘、四個鐘同一日各自點處理：邊啲工作照排隊、邊啲部署凍結、邊啲修正可以行後備路線。等到下一次 status page 轉紅先即場研究，通常已經太遲。

參考來源

• iThome — GitHub揭露8月大當機原因，基礎設施容量未跟上使用成長 — original report
• GitHub：The August 17 outage, and the work ahead — GitHub 官方交代事故背景、平台用量增長、Azure 遷移進度同後續可靠性工作。
• GitHub Status：Incident with GitHub.com — 官方技術事故報告，提供完整時間、錯誤率、受影響服務、Istio／HAProxy 連鎖故障同 Copilot retry 數字。
• GitHub availability report：July 2026 — 補充 GitHub 近期容量、共用基建拆分、Actions 架構同 Azure 遷移背景。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。