目錄
GitHub 公布了一組很難忽略的數字：平台每月處理的 commit 數量，從今年 4 月的 14 億增加到目前的 29 億，短短四個月已經超過兩倍。這組數字出現在一篇事故檢討裡，因為 8 月 17 日 GitHub 才剛經歷一場長達 7 小時 47 分鐘的全球性服務中斷，github.com、Authentication、GitHub Actions、API、Pull Requests、Issues 與 Copilot 都受到影響。GitHub 對外給出的結論很直接：流量碰到新的高峰，而美國中部資料中心的一個關鍵基礎設施元件沒有跟著需求擴充，容量壓力接著一路傳到其他服務。
29 億這個數字很容易被直接解讀成「AI Agent 已經把 GitHub 撐爆」，但目前公開資料還不能這樣下結論。GitHub 沒有公布這 29 億筆 commit 中多少由人直接建立、多少來自 Copilot、Claude Code、Codex 或其他 Agent，也沒有說 4 月之後增加的 15 億筆全部由 AI 造成。不過，GitHub 從今年 4 月開始就已經把流量快速上升和 agentic development workflows 放在一起談，5 月的 Reliability Update 甚至直接表示，GitHub 流量正在快速成長，而且很大一部分由 AI-assisted 與 agentic development workflows 推動，因此把這次 commit 暴增放進 Agent 普及的大背景裡看是合理的，只是不應該把相關性直接寫成單一因果。
對每天使用 GitHub 的開發者來說，這次事故比較值得看的地方也在這裡。AI 寫程式帶來的改變開始不只出現在 IDE 或 Pull Request 裡，Repository、API、Actions、Authentication、Code Review 與各種周邊服務都必須承接更多機器產生的操作。這不代表 GitHub 8 月 17 日的大當機可以直接歸咎於 AI，但至少已經能看到，GitHub 自己正在為一個和幾個月前完全不同的流量規模重新設計基礎設施。
GitHub每月Commit從14億變29億，這個數字到底代表什麼？
Commit數量翻倍代表平台活動增加，不等於有效程式碼產出翻倍
GitHub 在 8 月公布的數字，是每月 commits 從 14 億增加到 29 億；同一張圖裡，GitHub 顯示每月 merged pull requests 已經來到約 1.3 億、新 Repository 約 2,400 萬個，整體活動量在 2025 到 2026 年間明顯加速。
但 commit 本身不是軟體產值。一名開發者可以花三天完成一項功能後提交一次，也可以把同一份修改拆成十次 commit；Agent 更可能在修正、測試、收到失敗結果、再次修改的循環裡留下大量中間操作，因此 29 億比較適合理解成 GitHub 必須處理的 Repository Activity，而不是「全球軟體生產力增加一倍」。
GitHub 目前也沒有公開 human-authored commits 和 agent-authored commits 的完整比例。能確認的是，公司早在 4 月就表示，從 2025 年 12 月下半開始，Agentic Development Workflows 明顯加速，Repository Creation、Pull Request Activity、API Usage、Automation 與 Large-repository Workloads 都快速上升，原本 2025 年 10 月開始規劃的 10 倍容量擴張，到 2026 年 2 月就已經改成為未來 30 倍規模設計。
所以這次最值得留下的數字不是「AI 寫出了 29 億次 commit」，而是 GitHub 每月現在真的需要處理 29 億筆 commit，而且 GitHub 自己認為 Agentic Development 是目前流量快速成長的重要來源之一。
GitHub自己也沒有拿成長當成事故理由
GitHub 在事故說明裡特別寫了一句，大意是這些成長可以解釋系統承受的壓力，但不能替事故開脫。這個區分很重要，因為 29 億 commit 是需求端發生的事情，平台沒有事先把關鍵元件擴充到足夠容量，仍然是 GitHub 自己需要處理的可靠性問題。
這也是為什麼 GitHub 沒有把這篇事故報告寫成「AI 流量太多所以沒辦法」，反而直接承認公司沒有在需求超過容量之前完成關鍵元件的擴充，接下來要增加容量、移除架構瓶頸、改善 Observability，也要重新處理 Service-to-service Retry 的行為。
GitHub 8月17日為什麼當機7小時47分鐘？
不是當天部署壞掉，但也不能寫成完全沒有Configuration問題
GitHub 對這次事故的高階結論是 Capacity Failure，而且表示 8 月 6 日與 8 月 17 日兩起重大事故都不是由當天的 Code Change 或 Configuration Change 觸發。不過，如果往下讀 Technical Root Cause Analysis，會看到更完整的情況：新一波 Peak Traffic 先讓 Central US 的 Load Balancer 發生 Network Saturation，其中一個 Istio Sidecar Pod 達到 Concurrency Limit，而既有的 Autoscaling Policy 只觀察 Host Service，沒有把 Sidecar Limit 正確納入，因此 Sidecar 沒有隨需求正確擴充。
接著，一個服務的壅塞往其他節點蔓延，最後四個 HAProxy Nodes 用完 Flow Limits，Gateway Authentication Path 開始出現延遲與失敗，進一步波及 Issues、Pull Requests、API、Actions、Git Operations、Copilot 與企業驗證功能。事故最高峰時，Web 與 API Error Rate 約 20%，Archive 與 Raw Content Download Error Rate 一度接近 50%。
因此，「不是 Configuration Change 導致」和「技術報告裡有 Misconfigured Policy」其實不衝突。前者指的是當天沒有一個新部署或新設定直接把服務弄壞，後者則表示系統裡原本就存在一項沒有完整考慮 Sidecar Capacity 的 Autoscaling Configuration，只是在過去的流量下沒有爆開，直到 8 月 17 日的新高峰才被暴露出來。
這也比單純寫成「容量不夠所以當機」更接近實際情況。容量是核心問題，但事故能一路擴大的原因還包括 Autoscaling Policy、Load Balancer Flow Limits、Authentication Dependency 與 Retry Behavior，幾個地方一起碰到上限後，才讓一個區域的負載問題擴散成跨服務事故。
Retry Storm為什麼讓GitHub已經開始恢復，Copilot卻繼續出問題？
一次失敗可以被放大成十倍流量
GitHub 在事故報告裡揭露了一個很具體的數字。Central US 開始恢復後，部分流量被轉往 Northern Virginia，但一個 VS Code 裡原本沒有被發現的 Retry Bug，會在 Copilot Token Operation 失敗時快速產生額外 Request，最後把 Copilot Token Service 的正常 7,000～9,000 RPS 放大到 70,000～100,000 RPS，接近十倍。
這也是為什麼「服務恢復」不代表流量會馬上恢復正常。當大量 Client 同時收到錯誤，如果每一個都立刻 Retry，而且 Gateway、Client 與其他 Service 各自又有自己的重試邏輯，原本為了提高單一 Request 成功率的設計，反而會在事故期間創造出比正常使用量高很多的額外流量。GitHub 最後必須降低 Gateway Authentication Retries，甚至暫時對部分 Copilot Token Requests 回傳 403，讓 Retry Loop 先停下來，再分區逐步把流量放回去。
這裡的 Retry Storm 比「AI 不會累所以一直重試」更值得注意，因為重試風暴本來就不是 AI 專屬問題，傳統 Client、Microservices 與自動化系統一樣可能發生。Agent 普及後增加的是機器操作的數量與 Fan-out，一個人的一個 Intent 可能衍生多個 Tool Calls、API Requests、Repository Operations、Tests 與後續修正，如果這些流程沒有 Concurrency Limit、Backoff 與總時間預算，流量放大的速度會比單純的人工作業更難控制。
GitHub準備怎麼修？不只增加伺服器，也要限制連鎖負載
Autoscaling、Retry Budget與Regional Failover都要一起改
GitHub Technical RCA 列出的後續工作包括修正 Autoscaling Policy，讓 Service Mesh Sidecar 的 Concurrency 與 Capacity 也能正確參與擴縮；全面檢查相關服務的 Istio Request、Concurrency 與 Scaling Limits；重新檢視 Gateway 和 Client 的 Retry Limit 與 Backoff Behavior；修正 VS Code 放大 Copilot Token Traffic 的 Retry 問題，同時改善 Load Balancer Capacity Monitoring 與 Regional Failover Safeguards。
在 GitHub CTO 的整體說明裡，還多了一個很值得開發團隊參考的詞：Retry Budget。GitHub 接下來會把一致的 Retry Limits、Retry Budgets 與 Variable Timeouts 套進 Service-to-service Interaction，避免各服務只從自己的角度不斷重試，最後一起把下游壓垮。
Retry Budget 和單純的「失敗重試三次」差很多。假設某個下游服務正在過載，一千個 Caller 如果各自都認為多試幾次比較可靠，整體流量只會繼續上升；Retry Budget 則把重試視為有限資源，當系統正在大量失敗時，部分 Request 寧可直接 Fail Fast，也不要為了救單一操作把整個服務一起拖下去。
GitHub其實已經在大量加容量，只是需求還跑得更快
GitHub 也不是到 8 月才開始增加硬體。官方表示，今年的 Reliability Work 已經加入超過 300 萬個 CPU Cores、120 PB High-speed Storage 與大量 Network Capacity，也持續把服務往 Azure 移動。目前 Azure 大約已承接 GitHub 58% 的 Platform Load 與一半的 Git Operations，相較 5 月只有約 12% Platform Load，遷移速度已經相當快。
但這組數字也剛好說明為什麼 Agentic Software Development 對基礎設施團隊很麻煩：需求曲線本身還在快速變動。GitHub 去年 10 月規劃的是 10 倍容量，幾個月後已經開始按照 30 倍規模設計，而月度 commits 又在 4 月到 8 月之間從 14 億跳到 29 億，容量規劃不是只把目前數字乘上一個固定成長率就能結束。
AI Agent流量和過去的開發流量有什麼不同？
差別不在「AI不用睡覺」，而是一個任務可以展開成很多機器操作
用「人類會睡覺、AI 不會」來區分兩種流量很直覺，但會把問題講得太簡單，因為 GitHub Actions、CI Bot、Dependabot 與各種自動化服務早就已經 24 小時運作，GitHub 並不是第一次面對非人類流量。
Agent 帶來比較明顯的改變是 Fan-out。一個人只輸入一次「修掉這個 Bug」，後面的 Agent 可能讀 Repository、建立 Branch、修改多個檔案、執行 Tests、檢查 Failure Logs、再次修改、Push、建立 Pull Request，再根據 Review 或 CI 結果繼續下一輪。GitHub 自己在 4 月與 5 月的 Reliability Update 裡也把 Repository Creation、Pull Request Activity、API Usage、Automation 與 Large-repository Workloads 的快速增長，和 Agentic Development Workflows 的擴張放在一起說明。
所以未來平台要處理的，未必只是「凌晨也有人 Push」，而是單一使用者 Intent 背後可能對 GitHub 產生比過去更多的 API Calls、Git Operations、Actions Runs 與 Review Activity，而且這些行為可以同時發生、快速 Retry，也可以由很多 Agent 平行執行。
AWS同週擴大GPT-5.6跨區域推論，也在處理Agent流量的另一端
Amazon Bedrock 當天擴大 GPT-5.6 Sol、Terra、Luna 的 API 支援，讓三款模型可以透過 bedrock-runtime 使用 Responses、Chat Completions 與 Converse APIs，同時加入 Global 與 Geo Cross-Region Inference，讓 Request 可以在多個 AWS Region 之間自動路由，以取得更高 Throughput。
這次也不能寫成「GPT-5.6 已經直接部署到超過 25 個 AWS Regions」。目前 Sol 的 In-region Availability 主要在 US East，包括 N. Virginia 與 Ohio；Terra 與 Luna 另外還有 US West 的 Oregon，Cross-Region Inference 則透過 Inference Profile 在符合條件的 Region 之間調度 Capacity。AWS 8 月 18 日又另外替 Terra 與 Luna 加入 India Geo Cross-Region Inference，讓資料可以留在 Mumbai、Hyderabad 這個地理範圍內處理。
把 AWS 和 GitHub 放在一起，可以當成同一週裡很有意思的上下游對照，但不能寫成兩家公司有直接因果。AWS 做的是讓高需求的模型推論可以跨 Region 找 Capacity，GitHub 面對的是 Repository、Actions、API 與其他 Developer Infrastructure 的需求快速上升；兩邊共同反映的是，Agentic Workloads 開始要求平台重新處理 Throughput、Burst Traffic 與容量調度。AWS 自己在 GPT-5.6 上線時也直接形容 Agent Traffic 往往相當 Bursty，一個 User Request 可能衍生大量 Model Calls。
使用AI Coding Agent後，開發流程可以先補哪些防護？
本機Git繼續保留可工作的Repository
Git 本身是 Distributed Version Control，正常的本機 Repository 已經保存 Branch、Commit 與大部分工作歷史，因此 GitHub 無法使用時，Local Commit、Branch、Merge 與本機測試通常還能繼續進行。真正容易一起被 GitHub Outage 卡住的，是 Pull Request Review、Issues、GitHub Actions、Webhooks、Authentication，以及依賴 GitHub API 或 Hosted Runner 的 Deployment Workflow。
因此，比起單純準備另一個 Git Client，更值得檢查的是 GitHub 以外的工作還剩多少。如果 GitHub 掛掉一個下午之後連本機測試都不能執行，代表流程裡可能已經把太多必要步驟綁到 Remote Service。
Agent的Retry不要只設定「失敗就再試」
自建 Agent、Script 或 Automation 如果會呼叫 GitHub API，至少應該有最大 Retry 次數、Exponential Backoff、Jitter 與總 Deadline，也要遵守服務回傳的 Rate Limit 或 Retry-After 訊號。GitHub 這次 Copilot Token Service 從正常 7,000～9,000 RPS 被放大到 70,000～100,000 RPS，就是一個很極端的提醒：Retry 本來是為了提高成功率，但沒有總量控制時，反而可能變成事故的放大器。
對 Coding Agent 來說還可以再多一層 Concurrency Limit，例如同一個 Repository 最多同時跑幾個 Agent、同一分鐘最多 Push 幾次、CI Failure 後允許自動修正幾輪，超過就停下來交給人處理，這通常比讓 Agent 無限重新嘗試來得可控。
不需要為了幫GitHub省容量，把所有Commit都Squash掉
把 Agent 的細碎 Commit 全部 Squash 後再 Push，理由如果是「降低 GitHub 寫入壓力」，目前沒有足夠資料支持，也不適合當成一般最佳實務。Commit History 要不要 Squash，還是應該依 Review、Bisect、Rollback 與團隊的 Version Control Policy 決定。
比較值得控制的是 Push、PR 與 CI 的頻率。Agent 可以先在 Local Branch 完成數輪修改和測試，再 Batch Push 一次，不需要每改一行就把新的 Remote Event、Webhook 與 CI Run 觸發出去；如果最後希望 Main Branch 保持簡潔，再依團隊習慣使用 Squash Merge。這樣處理的是自動化流程本身的 Churn，也不會為了追求較少 Commit 數而犧牲有用的開發歷史。
GitHub Status可以直接納入事故確認流程
GitHub Status 持續更新 Issues、Pull Requests、Actions、API、Git Operations 與 Copilot 的恢復情況，而且 Status Page 本身提供 Email、SMS、Slack、Webhook、Atom 與 RSS 訂閱。對日常依賴 GitHub 的團隊，把官方 Status Feed 放進既有通知系統，比遇到錯誤後先花半小時重新安裝 Git 或檢查 Router 實際得多。
如果是小型團隊，也不需要另外搭一套大型監控平台，至少先讓 GitHub、主要模型 API、部署平台與雲端供應商的官方 Status 可以在同一個地方快速確認，就能先排除不少沒有必要的本地除錯。
重新檢查單點時，不要只看Git Repository
Git 的 Repository 可以很容易保留 Local Copy，GitHub 真正難替代的往往是周圍那一圈服務：Pull Requests、Code Review、Issues、Actions、Secrets、Branch Protection、Packages、Webhooks、Deployment Approval 與第三方 Integration。
所以可以先問一個很具體的問題：如果 GitHub 從上午停到晚上，哪些事情還能正常做，哪些會完全停止？如果某個 Repository 有非常嚴格的 Recovery Time Objective，再考慮 Secondary Remote、Mirror 或替代 CI 路徑；如果只是一般個人專案，知道本機仍能工作、等服務恢復再 Push，可能就已經足夠。備援本身也有維護成本，不需要所有專案都做成雙平台高可用。
GitHub這次事故說明的，不只是AI寫了更多程式碼
GitHub 每月 29 億 commits 是一個很大的數字，但它不是 AI 生產力排行榜，也不能拿來證明軟體產值四個月翻了一倍。比較能確定的是，GitHub 的平台活動正在非常快地增加，而且公司自己已經多次表示，AI-assisted 與 Agentic Development Workflows 是這波流量成長的重要來源。
新流量高峰碰上沒有正確隨 Sidecar Capacity 擴縮的 Autoscaling Policy，接著又遇到 Load Balancer Flow Limits、Authentication Dependency 與 Retry Amplification，才把局部容量壓力變成一場 7 小時 47 分鐘的跨服務事故。
對日常使用 Coding Agent 的開發者來說，比追究其中多少 commit 是 AI 寫的更實際的是另一件事：Coding 越來越便宜、越來越自動之後，Push、CI、Review、API、Deployment 與 Retry 都可能跟著增加。Agent 可以多快寫出下一版程式碼只是前半段，後面的基礎設施能不能穩定接住這些操作，現在也開始成為開發流程的一部分。
常見FAQ
目前不能這樣下結論。GitHub 確認每月 commit 從 4 月的 14 億增加到 29 億，也曾公開表示近期流量成長很大一部分受到 AI-assisted 與 Agentic Development Workflows 推動，但沒有公布 8 月 17 日 Peak Traffic 中有多少來自 AI Agent，更沒有表示 Agent 是事故的單一原因。這次直接技術原因是 Central US 的容量壓力，以及後續 Autoscaling、Load Balancer 與 Retry 問題造成的連鎖故障。
GitHub 的意思是事故不是被當天新部署的 Code 或 Configuration Change 觸發，但 Technical RCA 確實指出既有 Autoscaling Policy 只監控 Host Service，沒有正確監控 Istio Sidecar 的 Concurrency Limit，因此 Peak Traffic 出現後沒有正確擴縮。比較準確的說法是「沒有新設定變更觸發事故，但既有 Autoscaling Configuration 存在缺口」。
不是。29 億指的是 GitHub 現在每月處理的 commit 活動量，不能直接換算成有效程式碼量、軟體產值或開發者生產力，而且 GitHub 沒有公開其中人類與 AI Agent 各占多少。
不需要為了替 GitHub 降低平台負載而一律 Squash。Commit 是否保留應該依團隊的 Review、Bisect 與 History Policy 決定；如果希望降低 Agent 帶來的遠端操作量，比較實際的是讓 Agent 在 Local Branch 完成幾輪修改後 Batch Push，並控制 PR、CI 與 Retry 的觸發頻率。
一般情況下可以。Git 是分散式版本控制，本機 Repository 可以繼續 Commit、建立 Branch、Merge 與查看歷史；受到影響的主要是需要 GitHub Server 的 Pull Requests、Issues、Actions、API、遠端 Push／Pull 與其他 Hosted Services。
沒有直接關係。AWS 是在 8 月 17 日宣布 GPT-5.6 Sol、Terra、Luna 支援 Cross-Region Inference，目的是讓模型 Request 能在多個 Region 之間調度 Capacity、提高 Throughput；GitHub 則是在處理 Developer Platform 自身快速增加的 Repository、API、Actions 與其他流量。兩則新聞可以放在一起觀察 Agentic Workloads 對基礎設施容量的影響，但不能寫成 AWS 增加上游模型容量直接造成 GitHub 下游事故。