GitHub 四個月 commit 倍增：AI coding agent 點樣推高平台壓力

GitHub 最近一次冧機，除咗服務停咗接近八個鐘，官方披露嘅 commit 增長亦值得留意。官方披露，平台每月 commit 數量由今年 4 月嘅 14 億急升到 29 億，四個月多少少已經翻倍。以前一個開發者逐個改檔、commit、開 pull request，而家幾個 coding agent 可以同時拆任務、推 branch、叫 API 同觸發 CI，GitHub 面對嘅負載模式已經完全唔同。

8 月 17 日到底壞咗啲咩

GitHub 官方事故報告指，8 月 17 日嘅故障由 13:28 UTC 持續到 21:15 UTC，合共 7 小時 47 分鐘。Issues、Pull Requests、API、Actions、Copilot 同登入服務都受影響；最嚴重嗰陣，網頁同 API 錯誤率約 20%，下載 archive 同 raw file 嘅錯誤率更去到約 50%。多數服務較早恢復，不過 Copilot Token Service 要到接近事故尾段先完全正常。

直接觸發點係 Central US 數據中心嘅流量創新高，一個 Istio sidecar pod 撞到 concurrency 上限，但 autoscaling policy 只監察主服務，冇計 sidecar 本身嘅容量。故障一路擴散，最後四部 HAProxy 節點耗盡連線流量上限，連登入路徑都塞住。Commit 增長加重咗背景壓力，而今次故障亦涉及擴展設定出錯、load balancer 飽和同系統耦合。

圖片：GitHub

AI agent 推高嘅遠超 commit 數字

GitHub 早喺 4 月已經話，agentic development 由 2025 年 12 月下半月起明顯加速，repository 建立、pull request、API、automation 同大型 repository 負載都一齊上升。一次 pull request 背後會掂到 Git storage、branch protection、Actions、搜尋、通知、webhook、cache 同 database；agent 密密做細 commit、重試失敗任務或者同時開幾條 branch，消耗嘅其實係成串服務容量。

不過，GitHub暫時冇公布 29 億個 monthly commits 入面有幾多直接由 AI 產生，亦冇證據話所有增長都來自 coding agent。可以確認嘅係，官方已經將 agentic development 視為 repository、API 同自動化活動急升嘅主要推力；至於每個 agent 實際佔幾多，只靠 commit author、co-author 標記或者特定訊息都會漏計，唔適合硬砌一個百分比。

圖片：GitHub

Retry 先係最容易失控嗰一下

今次另一個幾典型嘅問題係 retry storm。GitHub話，內部 gateway 嘅樂觀重試加重 load balancer 壓力；Copilot Token Service 出錯之後，VS Code 一個潛藏 retry bug 更將請求量放大約十倍，由平時每秒 7,000 至 9,000 次，衝到 每秒 70,000 至 100,000 次。服務開始恢復嗰刻，大批 client 同 backend 一齊補交請求，反而再塞多次。

呢種情況對用 agent 嘅團隊一樣啱用：agent 遇到 API timeout、runner 起唔到或者檢查未回覆，唔可以無限即時再試。要設 exponential backoff、jitter、retry 上限同全局 budget，亦要限制每個 repository 同組織同時跑幾多任務。否則平日提高產量嗰套自動化，故障嗰陣會變成流量放大器。

GitHub Actions 冧機，self-hosted runner 都未必救到你

有人會以為轉用 self-hosted runner 就避到 GitHub Actions 故障，但 runner 仍然要靠 GitHub 嘅排程、認證、API 同 workflow 定義。GitHub 控制層出事，機房入面有幾多部 runner 都可能只係排隊等。8 月 17 日連 Actions、API、登入同 raw content 一齊受影響，正好說明淨係將 runner 擺喺自己地方，都唔代表有完整後備能力。

實際做法要按服務重要性分級。普通網站可以暫停部署，保留本機 Git clone，同時準備清楚嘅人工發布指引；每日都要出 production 嘅產品，可以定時同步 repository 去另一個 Git host，將 build artifact 放喺獨立 registry，再保留一條唔經 GitHub Actions 都行到嘅部署入口。涉及付款或核心系統，就要定期演練 alternate CI，確認 secrets、權限同 rollback 真係用得到，而唔係事故發生先臨時駁線。

GitHub 加容量，團隊亦要減少無謂負載

GitHub話已經加咗超過 300 萬個 CPU core、120PB 高速儲存，Azure 而家承擔約 58% 平台負載同一半 Git operations；官方亦會修正 autoscaling policy、審核 Istio 限制、收緊 retry 行為，同改善跨區 failover。不過 monthly commits 已經由 14 億升到 29 億，單靠加機器追流量，未必長期追得切。

開發團隊都應該管好 agent 產生嘅負載：合併冇必要嘅碎片 commit、限制 bot concurrency、取消過時 CI run，同避免每次小改動都跑完整測試矩陣。下一步要睇 GitHub 能否喺 commit、Actions run 同 API 請求繼續急升之下，將關鍵服務真正分隔，同喺單一區域出事時維持基本 Git、認證同部署能力。

參考來源

• Engadget — GitHub says commits have doubled in the last four months — original report
• The August 17 outage, and the work ahead — GitHub 官方交代事故時長、commit 增長、容量投資同後續改善方向。
• Incident with GitHub.com — August 17, 2026 — 官方技術事故報告，列出 Istio 擴展設定、HAProxy 飽和、retry storm 同各服務影響。
• An update on GitHub availability — GitHub 早前對 agentic development、API、pull request 同自動化負載增長嘅背景說明。
• GitHub availability report: July 2026 — 補充 Actions 架構、Azure 遷移進度同近期容量事故背景。

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