Coding with 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 帶來的操作節奏當成平台的正常負載，而不是例外流量。