2026 年 8 月 6 日深夜，全球最大的代码仓库 GitHub 出事了。它的自动化服务（Actions）大面积瘫痪：任务排队几小时起不来，跑起来的也大量失败，网页托管服务 Pages 跟着降级，连 AI 助手 Copilot 的代码审查都时好时坏。这个帖子在程序员社区 Hacker News 上 8 小时攒了 299 分、253 条评论。程序员们很快拼出线索：压垮平台的，可能正是 AI 写代码的热潮。GitHub 首席运营官 Kyle Daigle 放出的数据显示，Actions 每周运行量从 2023 年的 5 亿分钟涨到 2025 年的 10 亿分钟，本周冲到 21 亿分钟——两年翻四倍。
对不写代码的读者，先交代背景。GitHub 是程序员界的微信加网盘：全世界的程序员把代码存在这里，几亿个项目在上面协作，你手机里绝大多数 App 的代码都从这条路走过。Actions 是它上面的一项自动化服务，相当于给代码请的自动管家：程序员写一段规则，之后每次代码有改动，管家自动帮忙测试、打包、发布。人工要干半小时的杂活，机器几分钟跑完。
图：本次 GitHub 故障的报道配图。来源：The Register
这次故障的官方记录是这样的：北京时间 8 月 6 日晚上 11 点过，任务开始排队、超时，成功率一度掉到三四成；官方一边限流一边修，还只放行了 15% 的「代码变更通知」，大量改动根本没触发后续任务。8 小时后，任务成功率回到 99%，但 Copilot 和 Pages 仍有间歇性问题，企业数据迁移服务干脆暂停。这不是孤例：7 月 29 日刚发生过类似的 Actions 故障，官方状态页显示 7 月记录了 26 起事故，8 月头 6 天又添 6 起。GitHub 4 月为故障潮道过歉，6 月有高管承诺结构性整改，一个月后还是崩了。
图：GitHub 官方状态页的故障记录，从降级到恢复约 8 小时。来源：githubstatus.com
故障报告里有一句值得细读：「干活的机器被分配了已经失效的任务，卡在反复重试。」翻译过来：机器拿到的是作废的工单，跑完发现没用，回头再领，领到的还是作废的。系统越堵，作废越多，死循环越深。这是高负载系统的典型死法，机制后文细说。
量从哪里来：AI 把整个厨房的订单翻了几倍
官方数据摆出来了。2025 年全年 GitHub 收到 10 亿次代码提交；现在一周就是 2.75 亿次，按这个速度全年 140 亿次。Actions 运行量两年翻四倍。换算成大众能感知的量：21 亿分钟，等于平均每一刻都有超过 20 万台电脑同时在 GitHub 上替程序员干活；2.75 亿次提交，等于平均每秒 450 次。一个平台每秒被敲 450 次门，还要给每次进门的人分配机器跑任务。
图：Actions 每周运行量两年翻四倍；每周提交量约为 2025 年平均水平的 14 倍。数据来源：GitHub 官方（COO Kyle Daigle），笔者制图
量从哪里来？AI 编程。AI 助手现在能自己读代码、改代码、提交代码、跑测试，一个会话能循环十几轮，每轮都触发一串自动化任务。以前一个程序员一天提交一两次，现在 AI 代劳，一天提交几十次。程序员社区有人统计：AI 代开的合并请求从去年 9 月的每月 400 万涨到今年 3 月的 1700 万；单是 Claude Code 一个工具，每周就贡献 260 万次提交，半年涨了 25 倍。人写代码是点菜，AI 写代码是把整个厨房的订单量翻了几倍。
订单翻倍，厨房没扩建，接下来就是连锁反应。HN 上一位做过多年高负载系统的工程师（cortesoft）把机制讲得很透：系统设计时都留了余量，负载涨到九成以上时，任何一个小波动都会引爆——任务排队，排队超时，超时后客户端重试，重试又制造更多排队。像高速公路，平时 80% 占用率随便开，到 95% 时一脚刹车就能堵死整条路。他直言：这种时候加机器也没用，瓶颈在你想不到的地方。
官方说在修，用户说不够
两边说法都放出来。GitHub 官方承认容量受限，说工程师已找到问题所在、正在部署修复。付费用户不买账：一位用自建服务器的企业用户抱怨，连自己掏钱维护的机器都瘫痪了一整天，付费服务就这水平？HN 上一位 2009 年就开始用 GitHub 的老用户（zehaeva）说得更重：过去一年 GitHub 从「四个九」的可用性掉到「一个九」，他没法不把这事和 AI 使用量暴涨联系起来。四个九是每年停机不超过一小时的标准，一个九意味着每年可以挂掉三十多天。
评论区还翻出一笔旧账：迁移之争。GitHub 被微软收购后，正把基础设施从自建机房搬到 Azure 云。有用户（toomuchtodo）回忆，自建机房时代反而更稳，这次迁移本可以只把弹性扩容的部分放云上，结果全押进去了；也有用户怀疑是迁移时间表定得太激进。反过来，另一位用户指出：被微软收购八年，抱怨是最近一年才多起来的，时间上恰好和 AI 编程爆发吻合。两种解释都有人支持，笔者不站队，只说两个事实：过去一年 GitHub 的故障频率确实明显上升；流量增长也是实打实的。
效率革命和物理世界的赛跑
这件事和普通人有什么关系？你手机里每个 App 的更新、修复、上线，大概率都走过 GitHub 的自动化流水线。平台堵一天，全球无数软件团队的发布节奏跟着乱一天。往深了说，这是产出速度和物理世界的赛跑：AI 让软件产出成倍增长，但服务器、带宽、机房的扩张是物理过程，有天花板。GitHub 去年 10 月把扩容目标定为 10 倍，今年 2 月上调到 30 倍，仍然被流量追着跑。有报道称，微软甚至临时向竞争对手 AWS 租了容量给 GitHub 救急——一个云厂商的旗舰产品，靠对手的机房撑过高峰期，这幅画面本身已经说明问题。
「什么都能自动做」是 AI 时代最动听的口号。现实是：自动化制造的任务，最终都要排队等机器。GitHub 的这次故障是一个信号——当所有人都更快地生产时，最稀缺的资源变成了承载这一切的基础设施。AI 的生产速度是软件问题，基础设施的扩张速度是物理问题。后者跟不上前者，崩的就是前者脚下的地。
参考链接：
- GitHub Status: Actions 与 Pages 故障报告
- HN 讨论 (item?id=49198302)
- The Register: Latest GitHub outage squeezes Actions, Pages to death
- Waxell: GitHub’s AI Agent Crisis: What 9 Outages Cost
- danilchenko.dev: GitHub’s AI Agent Problem: 17 Million PRs, Five Outages, and a Kill Switch
