8 月 17 日北京时间晚上 21:40，GitHub 挂了。
如果你当时正好在提 PR，看到的应该是转不完的超时圈。微博上当时最火的调侃是"今天全世界的程序员都在摸鱼"。知乎但这次"摸鱼"时间有点长：从事发到全部恢复，一共 7 小时 47 分钟。微博Issues 打不开，PR 提不上，Actions 卡住，很多人赖以干活的 Copilot 也跟着罢工。
一周过去，GitHub 官方复盘报告出炉。对咱们这种把写代码这件事搬进云里的人来说，里面有几个数字和教训，比官方的道歉信值得看。
先看这次是怎么挂的
官方复盘的结论先摆出来：不是代码变更，不是配置失误，是容量扛不住了。IT之家
故障链大概是这么走的：当天流量创下新峰值，Central US 数据中心的 Istio sidecar pod 并发连接数先被打满；按理说自动扩容应该跟上，但伸缩策略只监控宿主服务的 CPU 和内存，没把 sidecar 的并发算进去——宿主服务一切正常，系统判断"不用扩"，真正干活的 sidecar 却已经累趴。哔哩哔哩请求开始堆积、传导，最后压垮了 4 个 HAProxy 负载均衡节点。而 HAProxy 是网关认证的必经之路，它一倒，认证链路退化，Issues、PR、Actions、Copilot 全被拖下水。
流量为什么突然这么大？官方给了组数字：月提交量从 4 月的 14 亿涨到了 29 亿，4 个月翻倍，其中很大一部分是 AI 辅助编程和代理式开发带来的。知乎GitHub 不是没做准备——已经加装了超过 300 万 CPU 核、120PB 高速存储，Azure 承载的平台负载比例从 5 月的 12% 拉到约 58%——还是没追上。
反常识的一点：Copilot 恢复得最慢，放大器竟是客户端自己
这次受影响的服务里，Copilot 是恢复最慢的。而复盘披露的细节里，拖慢它的重要原因，是 Copilot 客户端自己掀起的"重试风暴"。
正常情况下，Copilot Token Service 的流量是每秒 7000 到 9000 次请求；故障期间，这个数字飙到了 7 万到 10 万——差了 10 倍以上。哔哩哔哩起因是 VS Code 客户端里一个潜在的重试循环 bug：一次令牌操作失败，就触发大量额外请求。GitHub 的 VS Code 用户是千万量级的，一个 bug 乘以千万用户，就成了重试风暴。服务端本来已经在恢复，又被客户端一轮轮"热心重试"重新压垮。
最后 GitHub 不得不暂停过载的负载节点、用 PR 临时降低网关重试逻辑、在负载均衡层直接 403 拦掉令牌请求，再逐站放量，Copilot 才在 21:02 缓过来。用复盘里的话说：服务端做对了所有事，一个客户端 bug 就能让恢复多花 3 个小时。知乎
对我们普通用户，这里有两个现成的经验：
一是服务拥堵时疯狂重试不会更快，只会更慢。这个道理对你自己写的脚本、配的 CI 同样成立——给重试加上限，是这次事故给所有人的提醒。
二是这次通过 GitHub CLI（gh）和 GitHub App 访问的用户基本不受影响。主站挂掉的时候，命令行往往是最后还活着的那条路。
别急着恐慌，先把几个口径说清楚
事故之后，不少文章写得挺吓人，但有几个口径值得先掰清楚：
网页和 API 峰值错误率约 20%、归档与原始文件下载错误率约 50%——这是请求级的错误率，不等于"两成用户掉线"，也不等于一半仓库访问失败。哔哩哔哩
时长上，官方博客说 7 小时 47 分，状态页按 13:40 到 21:15 UTC 记录约 7 小时 35 分，两个口径都成立，引用时别混着写。知乎
社区反应方面，Hacker News 上"Ask HN: Alternatives to GitHub"的讨论拿了 479 分，但第三方观察目前没有看到成规模的迁移潮。知乎吵归吵，生产环境搬家没那么容易。
但有一个事实值得认真对待：这不是孤立事件。官方可用性报告显示，6 月记录了 6 起事故，7 月记录了 8 起，其中 7 月 8 日那场持续了 7 小时 4 分钟；8 月 6 日 Actions 还有一次长时间故障，官方自己的措辞是"影响与时长均不可接受"。知乎这次 8·17 是 8 月内的第二起重大事故，而且官方把 8 月这两起都定性为"容量型故障"——扩容速度追不上增长曲线。按官方路线图，自有数据中心的生产流量要到 2026 年底才全部迁到 Azure，而迁移窗口期本身就是高风险期。
所以与其说"GitHub 不行了"，不如说：云服务偶尔抽风是常态，真正的问题是，你准备好了没有。
下次宕机之前，哪些"保险"值得买
这部分按人群拆开说，依赖程度不同，要买的保险完全不一样，不必人人全套照搬。
轻度用户（刷项目、star、偶尔 clone）：不用折腾。两个零成本习惯就够——看上的重要仓库别只 star，顺手 clone 一份到本地，这次归档和 raw 文件下载错误率到了 50%，离线的时候 star 救不了你；再把 githubstatus.com 收进书签，下次页面转圈先看状态页，省得怀疑自家网络。
靠写代码吃饭、订了 Copilot 的打工人：一是把 GitHub CLI 用起来，这次 gh 和 GitHub App 的通道基本没受影响，至少 commit、push、看 PR 还能继续；二是给自己的代码留条后路，本地仓库推两个 remote，GitHub 堵几个小时，代码还躺在自己手里；三是依赖包做好本地缓存，拉不动依赖比看不了代码更耽误干活；四是 Copilot 转圈的时候别反复重启硬刷——这次的重试风暴就是千万客户端"热心帮忙"帮出来的，补全不出来先手写，别把摸鱼时间也浪费在转圈上。
带团队、管平台的：CI 的鸡蛋别全放 Actions 一个篮子里，至少留一条备用流水线，这次 Actions 是同步卡住的；给所有重试加预算——重试上限、重试预算、可变超时，这是 GitHub 官方整改清单的头几条，自建网关同样适用；企业版用户该看 SLA 看 SLA，7 小时 47 分钟白纸黑字，怎么算账按合同来。
最后，留两个值得持续关注的信号
第一，GitHub 官方路线图有三个检查点：2026 年底前生产流量全部迁出自有数据中心、读容量线性扩展架构落地、服务间重试治理到位。知乎下次大事故还会不会来，就看这三件事能不能跑赢月提交量的增长曲线，每月翻一眼可用性月报即可。
第二，这次宕机的第二天，Cursor 官宣了代码托管平台 Origin。量子位定位"面向智能体时代的 Git forge"，选在 GitHub 宕机当天开门营业。微博托管赛道要不要变天不重要，对订阅用户来说重要的是：替代品越多，越不用急着搬家，但退路该留还是得留。
毕竟，真正的安全感不来自"平台永不宕机"，而是来自"它宕机的时候，我的活儿不至于全停"。
