GitHub 停機由 AI 驅動的流量激增和配置錯誤引起

今年 2 月 9 日，北京時間深夜，全球數以千萬計的開發者打開 GitHub，看到了同一個頁面。

不是 404，比 404 更讓人焦慮——是那個讓所有工程師後背發涼的黃色警告條，加上狀態頁上一排排從綠色變成紅色的指示燈。

github.com 崩潰了。

API 已斷線。

GitHub Actions 崩潰了。

Git 操作掛了——就連 Copilot 也沒能倖免。

那一晚，有人的 CI/CD 流水線在最關鍵的節點停擺，有人的自動化部署卡在了半空中，還有人在等待一個遲遲無法合併的 PR——背後是一個等待上線的功能，等待的是真實用戶。

事後 GitHub 發布了事故報告。根本原因，用技術語言說，是「一個負責認證和用戶管理的核心資料庫叢集過載」。但這幾個字背後藏著一條觸目驚心的觸發鏈——

兩天前，工程團隊為了盡快向用戶推送一個新模型，將「用戶設置緩存」的刷新時間從 12 小時改為 2 小時。就是這個配置數字的更改。

結果，原本分散在 12 小時內完成的快取重寫，被壓縮至 2 小時內，形成了一次密集的「快取重寫風暴」，非同步任務佇列瞬間被擊潰，共享基礎設施組件崩潰，連鎖反應蔓延至負責代理 HTTPS Git 操作的服務，最終導致整個平台的連接耗盡。

一個數字，從 12 改到 2。

GitHub 被自己修改的一個配置擊穿了。

但如果你只看到這一個配置更改，那你大概錯過了這個故事最重要的部分。

2 月 9 日的事故，不是一個孤立事件。

事實上，2026 年的前三個月，GitHub 經歷了至少 8 次重大事故。2 月份單月就有 37 次大大小小的故障記錄。GitHub 的 CTO Vlad Fedorov 後來在部落格中承認，這兩個月 GitHub 沒能維持它向企業客戶承諾的「三個九」——99.9% 可用性。

翻開這兩個月的故障檔案，你會發現一個奇特的規律：每一次事故，看起來都是不同的原因。

2 月 2 日：Azure 計算提供商出現問題，GitHub Actions 停擺近 4 小時，Copilot 編碼代理、CodeQL、Dependabot 全部受牽連。

2 月 9 日：快取重寫風暴，認證資料庫過載。

3 月 5 日：Redis 集群故障，GitHub Actions 95% 的工作流程在 5 分鐘內無法啟動，平均延遲 30 分鐘。

3 月 18 日：Webhook 延遲飆升至正常水平的 32 倍。

每一次看起來都像是「意外」，每一次的直接原因都不盡相同。但 Fedorov 的解釋將它們串聯成同一個故事。他說，這些事故背後有三個共同的結構性原因：「負載快速增長、服務之間的緊密耦合導致局部故障擴散，以及系統缺乏對異常客戶端流量的保護能力。」

用工程師的話說，GitHub 的地基已經開始在新負載的重壓下出現裂縫。

而這個「新負載」，有一個具體的名字。

關鍵數據

2025 年全年 commit 總量：約 10 億次

2026 年單週 commit 量：2.75 億次

按此速度，2026 年全年預計：140 億次（同比增長 14 倍）

GitHub Actions 計算量：2023 年每週 5 億分鐘 → 2025 年 10 億 → 2026 年初某週 21 億分鐘

如果你是 GitHub 的基礎設施工程師，2025 年和 2026 年的監控儀表板對比，大概會讓你目瞪口呆。

在 2025 年全年，GitHub 處理了大約 10 億次代碼提交。這個數字本身已經非常龐大，是 GitHub 平台多年累積的成果。但到了 2026 年，單週的提交量已達到 2.75 億次。換算一下——如果以這個速度持續一整年，2026 年的總提交量將接近 140 億次，是 2025 年全年的整整 14 倍。

這不是一條平滑增長的曲線，而是一道陡坡。GitHub 的 Actions 計算量變化更能說明問題：2023 年每周消耗 5 億分鐘，2025 年翻倍到 10 億，然後在 2026 年初的某一周，直接飆到了 21 億分鐘。

是什麼在瘋狂提交代碼？

不是人類開發者。

GitHub 的數據顯示，AI Agent 正成為該平台上最活躍的「用戶」。僅 Claude Code 這一個工具，目前就貢獻了 GitHub 所有公開倉庫提交量的 4.5%。每周達 260 萬次提交，而在 2025 年 9 月底，這一數字僅為 10 萬——三個月內增長了 25 倍。

AI Agent 開啟的 PR 數量同樣在爆炸。2025 年 9 月，AI 生成的 PR 大約是每月 400 萬個，到 2026 年 3 月，這個數字跳到了 1700 萬——四倍多，半年內。

有一個畫面可以幫助你理解這意味著什麼。

過去，GitHub 的「用戶」主要是人類程式設計師。他們白天工作，晚上睡覺，週末休息，每次提交都會思考、猶豫，手速有上限。系統的負載跟著人類的作息走，有峰谷，可以預測。

現在，越來越多的「用戶」是 AI Agent。它們不睡覺，不休息，不猶豫，一個任務可以同時啟動多個並行的 Agent，每個 Agent 每小時的提交量，輕鬆超過一個真實工程師一週的工作量。更重要的是，它們不只是在提交程式碼，還在不斷建立新倉庫——把倉庫當成工作流的「輸出產物」，而不是人類的「工作空間」。

GitHub 的基礎設施工程師們，面對的已經不是一個流量更大的同類問題，而是一個性質完全不同的問題。

故障頻發只是問題的一面，GitHub 還有另一個更讓人頭疼的麻煩——算賬的時候發現虧了。

Copilot 最初的定價邏輯基於一個合理的假設：用戶主要以「輔助補全」的方式使用，每次互動時間短暫，計算量可預測。個人版每月 10 美元，商業版每月 19 美元，按座位收費，這個模式在過去幾年運作良好。

然後，Agentic AI 來了。

Agentic 工作流與傳統補全屬於兩種不同的物種。標準的程式碼補全，請求是線性且可預測的，計算週期短暫；而一個 Agentic 編碼會話，可能運行數小時，同時啟動多個平行線程，進行多步推理、自我糾錯、跨倉庫重構——一個會話消耗的 token 數量，輕鬆超過一般用戶一整月的訂閱費用。

GitHub 面對的局面是，少數重度 Agentic 用戶，正在用幾美元的月費消耗相當於幾百美元的計算資源。

面對這個局面，GitHub 的反應很直接——先控流，再改價。

自今年年初起，GitHub 為 Copilot 啟動了兩套並行的限流機制：會話時長上限和每週使用量上限，兩個維度均按 token 消耗量乘以模型計算權重來計算。同時，部分個人 Copilot 套餐已暫停新用戶註冊。

On June 1, GitHub completed a more fundamental pricing reform: Copilot fully switched to usage-based billing, replacing the original subscription fees with "AI Credits," where 1 AI Credit equals US$0.01, and usage is calculated in real time based on token consumption.

在 Agentic AI 面前，按座位收費的時代走到了終點。

這個轉變不只是 GitHub 的煩惱。這是整個 AI 工具行業在 2026 年正在經歷的一次集體定價危機——當 AI 開始替代人類執行完整的工作流程，而不只是「輔助」人類工作時，所有基於「每人每月」的訂閱邏輯都會失效。

回到基礎設施問題。GitHub 到底準備怎麼應對這個「14 倍增長」？

這裡有一個細節，能說明問題的嚴重程度：

2025 年 12 月下旬，Agentic 工作流突然開始加速。GitHub 的工程師們意識到，10 倍不夠。到 2026 年 2 月，也就是那次嚴重停機之後，GitHub 宣布需要按照今天規模的 30 倍重新設計架構。

不是擴容，是重新設計。

這兩個詞的區別很大。擴容是增加現有機器數量、為現有資料庫增加記憶體——方向不變，只是規模變大。重新設計則意味著，現有架構的假設在 30 倍規模下會系統性失效，必須從底層重新思考服務拆分、資料流和故障隔離的方式。

GitHub 披露的具體方向包括：解耦關鍵服務以防止級聯失敗、引入背壓機制和流量降級能力、為熱點服務部署獨立主機、消除單點故障，以及更完善的變更管理——避免「將快取 TTL 從 12 小時改到 2 小時」這種操作在沒有充分壓測的情況下直接上線。

值得注意的是，GitHub 並不孤單。

Stripe 已經遇到 AI Agent 批量建立帳戶的問題，AWS 正在構建專為 Agent 設計的身份系統、日誌系統和生產控制機制。這些舉措並非未雨綢繆，而是因為監控儀表板上已出現它們不得不解決的訊號。

GitHub 只是第一個被攻破的——因為它位於 AI 工具鏈的最核心。

停下來想一想這整件事的性質。

GitHub 是什麼？最直觀的回答是，它是程式員存放程式碼的地方。但更深一層，它是人類軟體協作的基礎設施——提交記錄是協作的軌跡，PR 是討論的容器，Issues 是意圖的留存，Action 是執行的管道。整套系統，是為人類的工作節奏、思維方式和協作模式設計的。

AI Agent changed all of this.

當一個 AI Agent 一天可以提交數百次代碼，每一次「提交」背後都沒有人類的思考與權衡，僅僅是任務迴圈的進度步驟——代碼倉庫還是「協作的容器」嗎？

當 AI 工具自動生成倉庫、自動開 PR、自動運行 CI、自動合併——開發者仍是這個流程的主體，還是已退化為「審核者」甚至「旁觀者」？

GitHub 的首席技術官在描述這次危機時，使用了「負載快速增長」這個詞。但這個詞很可能低估了問題的本質——這不只是數量的增長，更是使用方式的質變。在舊模型中，GitHub 是「開發者的工具」；在新模型中，GitHub 正在變成「AI 的排氣管」，一個自動化工作流的輸出管道。

這對 GitHub 意味著什麼，其實還沒有答案。30 倍擴容能解決流量問題，但解決不了商業模式的再定義，也解決不了「誰是我的真正用戶」這個身份問題。

最近出現了一個頗具深意的現象：GitHub 在停機後發布了大量工程博客，詳細描述了每次事故的根本原因，透明度幾乎達到令人驚訝的程度。有人認為這是 GitHub 主動建立信任，也有人認為這是用透明度換取開發者社區的耐心——因為接下來的重構期，還會有更多不穩定。

一個平台，在被自己的成功擊穿之後，需要將自己拆解並重建——而這個過程本身，也是一次能否撐住的考驗。

那晚 2 月 9 日，那位等待 PR 合併的工程師，大概最終還是等來了綠燈。但他可能沒有意識到，讓他等待的那次當機，不是 GitHub 的一次意外，而是整個軟體開發行業進入新時代的一聲響動。

本文來自微信公眾號 “極客公園”（ID：geekpark），作者：宇航猿