GitHub 八天崩六次！Actions 宕机 10 小时波及 Copilot 和 Pages，AI 流量压垮了全球最大代码平台！

admin@yesmiracle.net (万戈) — Sat, 08 Aug 2026 00:00:00 +0000

如果你在过去一周 push 过代码、等过 CI 绿、或者依赖 Copilot 做 code review，你一定感受到了：GitHub 正在「慢性崩塌」。

8 月 6 日，GitHub Actions 从 UTC 15:22 开始降级，整整 10 小时 42 分钟后才宣告恢复。但这不仅仅是一次孤立事故——这是 8 月份前 6 天的第 6 次故障。

平均每天一次。不是玩笑。

更让人脊背发凉的是，这次宕机并不是 Actions 一个人在扛——Copilot code review、Copilot coding agent、GitHub Pages、Webhook、Enterprise Importer 迁移，全线瘫痪。你自建 Self-Hosted Runner？也没用——调度层一崩，所有 Runner 都成了摆设。

GitHub 8 月「故障日历」：6 天，6 次

先别急着说我夸张。直接看 GitHub Status 的历史记录：

月份	故障次数	备注
2026 年 8 月（前 6 天）	6	日均 1 次
2026 年 7 月	26	接近每天一次
2026 年 6 月	23
2026 年 5 月	23
2026 年 4 月	26	约 86% 月正常时间，超过 100 小时宕机
2026 年 2 月	37	峰值，日均 1.3 次

三个月内超过 70 次故障。作为对比，四个 9 的可靠性意味着全年宕机不超过 52 分钟——GitHub 的 4 月单月就超过了 100 小时。

对于全球数百万开发者将 CI/CD 管线、代码审查、甚至生产部署都绑在 GitHub 上的生态来说，这不是一个 nuisance，这是结构性的交付阻塞。

8 月 6 日事故全还原

我们来拆解一下这次事故的时间线（UTC）：

时间	事件
15:22	首次报告 Actions 降级
15:41	Actions 可用性标记为 degraded
15:45	工作流无法启动、中途失败、API 返回错误、意外限流
15:53	Pages 被拉入事故
17:02	开始缓解，但仍在扩散
17:40	Copilot code review、Copilot coding agent、Hosted Runner、Enterprise Importer 全中
18:11	Self-hosted Runner 注册也报错/限流
20:34	Webhook 吞吐降到正常水平的 15%；队列任务成功从 30-40% 爬回 65%
21:30	发现「无效 job 分配」问题——调度层给 Runner 分配了已经失效的任务
00:05 (8/7)	标记缓解
02:04 (8/7)	事故关闭。但提醒用户：部分 push/PR 触发事件已丢失，无法回放

10 小时 42 分钟。从 Actions 到 Copilot 到 Pages 到 Webhook，整个 GitHub 的 CI/CD 和 AI 代码工具链被打了一个贯穿。

最讽刺的是 GitHub 说的那句话：“工程师已经确认了中断源，正在推进修复”——这话在 15:45 就说了，然而直到午夜才标记缓解。中间经历了 Copilot 被拖下水、Webhook 吞吐只剩 15%、到最后发现调度层分配了「无效 job」给所有 Runner。

为什么 GitHub 就是修不好？

这个问题很多人都在问。答案比想象中复杂，但也比想象中残酷。

原因一：AI 代码流量爆炸

GitHub CTO Vlad Fedorov 自己承认：AI 生成的代码在过去两年让基础设施负载增长了 3.5 倍。2025 年 10 月，GitHub 规划了 10 倍容量增长。到 2026 年 2 月，修正为 30 倍。

但容量规划是一回事，基础设施能不能在扩容过程中保持稳定是另一回事。《The Pragmatic Engineer》的分析一针见血：

在大规模系统中，小低效会叠加：队列加深 → 缓存未命中 → 数据库负载 → 索引落后 → 重试放大流量 → 一个慢依赖拖垮多个产品体验。

原因二：AWS → Azure 迁移撞上了负载高峰

GitHub 正在从 AWS 迁移到 Azure——一个本身就极其复杂的跨云基础设施迁移，偏偏撞上了史上最大的流量增长期。就像一个高速公路在拓宽施工的时候，车流量翻了 3 倍。

原因三：18 年的技术债

GitHub 的代码库和架构是从 2008 年的 Rails 应用一路长起来的。你不可能在不停产的情况下重写所有东西。

4 月 GitHub 为此道歉过。6 月 SVP Jakub Oleksy 承诺「结构性改进将永久消除故障模式」。但从 7 月的 26 次故障和 8 月的 6 天 6 次来看，这些承诺和道歉一样，没什么实质变化。

Self-Hosted Runner 不是逃生舱

很多团队以为自建 Runner 就能躲过 GitHub 的平台故障。8 月 6 日的事故彻底证伪了这个假设。

Self-hosted Runner 依赖 GitHub 的调度服务来接收和分配任务。当调度层崩了，你的 Runner 要么注册失败，要么被分配了无效 job。Hacker News 上的开发者直接验证了：“就算是自托管 worker，宕机时一样不工作。”

这不是单个节点的失效，这是控制面的失效。你可以在边缘加再多计算节点，控制面塌了，所有节点都是瞎子。

那些已经离开的人

Mitchell Hashimoto，GitHub 第 1299 号用户，Vagrant 和 HashiCorp 的创始人，在 GitHub 上活跃了近 18 年。今年 4 月，他花了一个月时间做了一件事：每天在日历上打一个 X，记录 GitHub 宕机是否影响了他的工作。

结果是——「几乎每天都有一个 X」。

他把自己 52000+ Star 的终端模拟器 Ghostty 搬离了 GitHub。“我想发布软件，但平台不让我发。18 年了，我得走了。”

他并不孤独。Zig 编程语言的维护团队在 2025 年 11 月就把项目迁到了 Codeberg，理由是「Actions 有严重 bug，GitHub 的工程文化也出了问题」。

这不是 casual users 因为小不爽而离开。这些人是在 GitHub 上建立了一整个职业生涯的开发者。当他们都觉得「够了」，说明问题真的到了临界点。

写在最后：GitHub 的「慢性崩塌」

GitHub 正在经历一个所有高速增长平台都会遇到的致命问题：成功本身就是失败的种子。

AI 代码生成推动的流量暴涨不是 GitHub「做错了什么」，而是它做对了所有事之后的结果。但问题在于——当一个平台的可靠性从「基础设施」退化为「运气」，开发者的信任就会一点一点流失。

8 月初的 6 天 6 次故障告诉我们的不是一个「运维事故」，而是一个生态级信号：当全球最大的代码托管平台开始成为发布管线的瓶颈，整个软件行业的交付效率都会被打上一个问号。

对于还在犹豫要不要离开的团队，我的建议很简单——开始做多平台冗余。GitLab、Codeberg、自建 Gitea，至少让 CI/CD 管线不绑定在单一平台上。不是 GitHub 不好，而是它现在的可靠性，已经配不上你对它的信任。

延伸阅读：《Microsoft 急刹车：下令工程师停止「Tokenmaxxing」》——微软系产品全线承压的另一面。

可靠性 on AI博士 万戈