GitHub 在 2026 年 8 月 17 日經歷一場長達 7 小時 47 分鐘的全球事故，github.com、登入驗證、Actions、API、Pull Requests、Issues 與 Copilot 都受到影響。Coding with Lewis 從這場事故出發，注意到 GitHub 近期的穩定度已低於大家習慣的水準；但他沒有只停在嘲諷當機，而是把鏡頭轉向平台上快速增加的 commits、pull requests 與 repositories，主張 GitHub 正在面對 AI Agent 改寫使用行為後的新負載。
近八小時不是單一服務壞掉
GitHub 的事故報告指出，當天流量碰到新高峰後，美國中部資料中心的一個 service-mesh sidecar 達到並行上限，卻沒有跟著擴充。接著，多個 load balancer 節點耗盡網路連線容量，共用的登入驗證路徑變慢，錯誤便沿著相依服務擴散。
GitHub 後來把公開事故時間列為 13:28 至 21:15 UTC，共 7 小時 47 分鐘；8 月可用性報告則把其中約 6 小時 44 分鐘列為使用者受影響時段。高峰時，受影響服務有 56.07% 的入口請求失敗或變慢；約 2.9 萬個組織至少遇到一次異常，累計約 480 萬次失敗或延遲請求，所幸沒有資料遺失。這不是 AI Agent 直接把 GitHub 撞垮，而是流量高峰碰上沒擴起來的元件。
流量成長是真的，AI Agent 是 Lewis 的解讀
GitHub 公布的數字顯示，每月 commits 從 4 月的 14 億次增加到 8 月的 29 億次；官方把兩次 8 月重大事故都歸為容量問題，承認關鍵元件沒有在需求超過上限前完成擴充。Lewis 在短片裡把這個「使用行為的巨大轉變」直接翻成 AI Agent，認為自動寫程式正在把原本給人類開發流程使用的平台推向另一種規模。
不過，GitHub 的事故報告沒有把成長全部歸因於 AI Agent，也沒有說 Agent 是 8 月 17 日事故的直接技術原因。流量成長是官方數字，AI Agent 是 Lewis 對成長來源的解讀。兩者可以放在同一個脈絡裡看，但不能合併成「AI Agent 造成 GitHub 當機」這個已獲官方證實的結論。
重試讓復原變成第二波壓力
Lewis 特別注意到，服務一壞，所有人都會立刻再試一次；在大規模平台上，復原期間的重試可能跟原本的流量一起壓回系統。GitHub 的詳細報告把範圍說得更精確：真正放大負載的是一個潛藏的 client retry bug，它讓某個內部登入驗證端點的流量急升，拖慢 Copilot Token Service 的復原。
工程團隊最後把流量移往其他資料中心、降低 gateway retries，並停掉飽和節點上的 load-balancer processes，再封鎖會觸發重試的請求，才出現大範圍且立即的恢復。復原本身也會製造負載，重試規則和容量同樣是可靠性設計。
GitHub 的補課不只是買更多機器
GitHub 表示，為了增加容量，已加入超過 300 萬個 CPU cores、120 PB 高速儲存空間與更多網路資源；截至 8 月 20 日，Azure 已承接約 58% 的平台負載與一半 Git 操作。這些數字說明它確實在擴大基礎設施，但官方同時承認，現有的測試、觀測、警示與跨系統隔離沒有跟上變化速度。
後續工作包括修正 service mesh 的 autoscaling policy、盤點 request 與 concurrency limits、替 gateways 與 clients 設定一致的 retry limits、retry budgets 與可變 timeout，並減少關鍵系統之間的共用相依。問題因此不只是「再加多少伺服器」，而是平台能不能在局部故障時阻止流量與重試互相放大。
留言把矛頭指回 GitHub 自己推動的 AI
本次擷取到 22 則留言，其中 18 則是第一層留言。互動最高的兩則都不太同情 GitHub：一則認為 GitHub 一面大力推 Copilot 與各種 AI 功能，一面又拿 AI 使用成長解釋壓力，這個反差很好笑；另一則直接把問題濃縮成「AI slop code」。也有人提到 Forgejo、Codeberg 等替代方案。
這些反應不能證明 AI 程式碼就是事故原因，卻抓到短片最尖銳的矛盾：GitHub 正積極把 Agent 放進開發流程，也就必須先把 Agent 帶來的操作節奏當成平台的正常負載，而不是例外流量。
WTF is going on at GitHub? ／ Coding with Lewis · 在 YouTube 觀看 ↗