GitHub 挂了 7 小时 47 分，官方说“容量不够”：运维该看的是这 4 个放大器

源自123位全网作者

07:29

周一（8 月 17 日）北京时间 21:40，相信很多运维人都经历了同一个场景：CI 队列卡住不动，PR 页面一直转圈，Webhooks 回调开始成批丢失，群里有人甩出一句“GitHub 又挂了？”

这次“又挂了”，持续了 7 小时 47 分钟。8 月 20 日 GitHub 官方发布复盘，随后两天社区对事故的拆解也陆续出炉。今天想聊的不是人人都能看到的“GitHub 宕机”新闻，而是我们这些自己管系统的人，真正值得带走、拿去对照自家生产环境的东西：一个单点容量问题，是怎么被连续放大四倍的，每一级放大又对应哪个自查项。

先看账面：这 7 小时 47 分钟发生了什么

先给快速事实。8 月 17 日 13:40 UTC 起，GitHub 网页与 API 流量错误率一度约 20%，仓库归档与原始内容下载错误率约 50%，当日 21:15 UTC 全部恢复。知乎从 API 请求到 GitHub Actions 再到拉取请求（PR）全面停摆。微博

被波及的范围包括：Git 操作、API、Webhooks、Issues、PR、Actions、Pages 等核心操作，企业身份集成（SAML、OIDC、SCIM、Team Sync），以及 Copilot——Copilot 出现间歇性认证失败，但通过 GitHub CLI 和 GitHub App 使用的用户不受影响。

持续时间有两个口径：官方博客称 7 小时 47 分钟，状态页从 13:40 UTC 计到 21:15 UTC 约 7 小时 35 分钟。还有一个容易被运维人忽略的细节：事故发生在周一上午，正是工程团队集中做代码拉取、评审、CI 构建和发布的时段，你的交付链可能是多个环节同时断的。

真正该看的：四级放大器

官方归因只有一句话：流量达到新峰值时，美国中西部数据中心的一个关键基础设施组件没有随之扩容，容量压力在系统内扩散，引发认证失败并波及其他服务。知乎官方把 8 月两起事故都定性为容量失败，与代码或配置变更无关。

但这句话只是第一块多米诺骨牌。把社区拆解和官方信息拼起来，能看到一条完整的四级放大链——每一级都是一个教科书级的自查点。

放大器一：sidecar 打满，自动扩容却说“不用扩”

起点是 Central US 数据中心。流量达到新峰值，承载流量的 Istio sidecar pod 首先撑不住了，并发连接数打满了上限。知乎

按理说 HPA 应该自动扩容。但问题恰恰出在这里：自动伸缩策略（HPA）只监控了宿主服务的 CPU 和内存，没有把 sidecar 的并发和容量纳入判断。知乎于是出现了荒诞的一幕：宿主服务指标一切正常，伸缩系统认为“不用扩容”，真正扛吞吐的 sidecar 已经累趴下了。瓶颈在 sidecar，决策却只看宿主。如果你的 K8s 集群也跑 sidecar 式服务网格，这一条今天就可以查：你的伸缩指标，覆盖真正的瓶颈层容量了吗？官方复盘里附了一张 git fetch 吞吐对比图，当天并发请求冲击服务端的强度，一眼可见。

放大器二：4 个 HAProxy 的流限制全部耗尽

sidecar 撑不住，请求开始堆积、超时、失败，压力顺着链路传导，最后砸到了 4 个 HAProxy 负载均衡节点上，它们的流限制（flow limits）被全部耗尽。知乎HAProxy 是网关认证的必经之路，它一倒，认证路径直接退化，Issues、PR、Actions、Copilot 全都跟着遭殃。

到这一步，故障已经从局部过载演变成全局认证危机。注意，这不是“认证服务自己坏了”，而是认证被共享路径的容量拖垮了。对应的问题给你：你家的登录、鉴权这类关键共享路径，有没有独立容量和限流保护？

放大器三：重试死亡螺旋

第三个放大器，藏在每个分布式系统里：重试。请求失败时，客户端和网关会重试；系统过载时，每一次重试都是往超载的负载均衡器上再压一块砖。越失败越重试，越重试越过载——一个完美的死亡螺旋。

GitHub 工程师后来透露的处理方式，正好印证了这条链：暂停过载节点的 HAProxy 后，大部分流量立刻恢复；再用一个 PR 临时降低网关的重试逻辑，才稳住了局面。知乎翻译成一句话：先减载，再治重试，顺序不能反。

放大器四：一个客户端 bug，让恢复多花 3 个小时

前三块骨牌，撑死了算教科书级故障。真正让这次事件延长了几个小时的，是客户端的一个 bug。Copilot Token Service 的正常流量是 7,000-9,000 RPS。但在故障期间，这个数字飙到了 70,000-100,000 RPS。知乎接近 10 倍的放大，源头是 VS Code 客户端里一个潜在的重试 bug。

GitHub 有海量的 VS Code 用户，一个 bug 乘以百万用户，就是一场重试风暴——即使服务端开始恢复，客户端的重试风暴也能把服务端再次打垮。最扎心的地方在于：服务端做了所有正确的事，一个客户端 bug 就能让恢复多花 3 个小时。知乎

工程师们的处置同样值得抄作业：又是降低网关认证重试，又是在负载均衡器层面用 403 阻断令牌请求，再逐站放流量，Copilot 才在 21:02 彻底缓过来。知乎

这条放大链的依据需要说明：官方复盘认定的只有“关键组件没有同步扩容”和“客户端重试反向推高恢复期流量”；sidecar、HAProxy、Token Service 级别的细节来自社区拆解与工程师披露。截至事故后数日，GitHub 尚未公布问题组件的具体名称和纠正措施的技术细节，在完整 RCA 发布前，不能把“AI 流量”或“容量不足”当作已被证实的唯一根因。知乎

为什么今年 GitHub 格外脆弱

这不是一次偶发。官方 6 月可用性报告记录 6 起事故，7 月记录 8 起。知乎

7 月 8 日那场持续 7 小时 4 分钟，峰值时段 5xx 错误率约 96%；8 月 6 日，GitHub Actions 又长时间故障，官方称其“影响与时长均不可接受”。知乎8 月 17 日的中断，是这一串事故里最近的一起。

压力从哪来？数字会说话：月提交量从 4 月的 14 亿增至 29 亿。GitHub 已加装超过 300 万 CPU 核、120PB 高速存储，Azure 承载的平台负载从 5 月的 12% 升至约 58%。知乎官方复盘里的这张增长曲线图，就是“容量追不上”的最直观注脚。

压力的另一个来源是 CI 与自动化的暴涨。7 月报告披露，8 月 6 日的 Actions 故障源于“launch service”（连接单体系统与 Actions 的桥接组件）尚未迁移到 Azure，级联失败拖慢了恢复，官方为此加快 Actions 迁往 Azure。知乎官方复盘还给了一张 Actions 运行量的独立增长曲线：AI 流量叠加迁移窗口期，哪个组件还没迁走，哪个就是下一次峰值来临时的受击点。

GitHub 的两项即时整改，值得直接抄

两起 8 月事故还带出两项即时整改：在服务间交互中统一施加重试上限、重试预算和可变超时，防止“重试风暴”和级联负载；同时复查低优先级 CPU/内存告警，找出可能在流量突增时失效的组件。知乎

这两条恰好对应这次事故里最隐蔽的两个坑：重试没有预算，等于自己打自己；没人看的低优先级告警，往往是容量事故的前奏。顺着这两条和前面四级放大器，整理一份自查清单，对照之前，先想清楚你自己系统的“周一早高峰”是什么样：

自动扩容决策覆盖真正的瓶颈层了吗？sidecar、网关、连接池都算，HPA 只看宿主 CPU 和内存，sidecar 倒下的场景就会在你家重演。
认证这类关键共享路径有独立容量和限流保护吗？HAProxy 流限制耗尽拖垮全局认证，你家的登录鉴权可能就挂在同一种共享路径上。
所有重试都有上限和预算吗？重试上限、重试预算、可变超时，这三样是 GitHub 用 7 小时 47 分钟换来的对策。
调用方的重试行为可控吗？一个客户端 bug 能把 Token Service 流量放大约 10 倍。你对外分发的 SDK 和插件、对内依赖的第三方 SDK，重试参数都值得复查。
恢复期有防护吗？GitHub 恢复过程中，codeload 端点还遭遇了多轮爬虫攻击。知乎恢复预案不能只写“怎么修”，还得写“怎么挡住外面的洪水”。
低优先级告警多久没复查了？那些长期没人处理的，可能正是下一次流量突增时会失效的组件。

现在要不要迁移？以及三个值得盯的信号

大事故之后，社区第一反应永远是“要不要跑路”。这次 Hacker News 上一篇“Ask HN: Alternatives to GitHub”的帖子被顶到 479 分，部分开发者在事故后重新讨论替代方案，但目前没有证据表明出现成规模的迁移潮。知乎

不过，事故之前就开始的撤离案例确实存在，而且理由不只是宕机。MitchellHashimoto 宣布，他的开源终端模拟器 Ghostty 将从 GitHub 迁出。微博尽管用户数仍在增长，但 Ghostty、Zig 等知名开源项目已率先撤离，转向 Codeberg 或自建 Gitea/Forgejo 实例。微博

同一天的另一个动向：2026 年 8 月 17 日，Cursor 推出了内嵌于 AI 编辑器的代码托管平台 Origin，直接挑战 GitHub。同一天，GitHub 遭遇了持续 6 小时以上的全球性宕机。知乎托管赛道的竞争，正在出现真正的备选。

那到底动不动？我的判断是：不迁移，但随时准备好迁移。对依赖方，更实际的做法是把仓库镜像、CI 可迁移性和紧急发布流程当作标配，而不是花力气争论要不要离开 GitHub。知乎按角色拆开：

个人和小团队：给关键仓库做第二平台镜像，至少做本地裸备份；提前在镜像侧配好 SSH key 和令牌，真出事可以直接切。
CI 依赖 Actions 的团队：评估流水线有多少能跑在第二套 CI（GitLab CI、Jenkins、自建 runner）上，构建产物和密钥别只存一处。
企业用户：把 SLA 违约应对和紧急发布流程提前演练。这次事故连 SAML、OIDC、SCIM 这类企业身份集成都被波及，意味着出事时你连登录备用系统都可能做不到。

GitHub 的路线图里有几个明确的检验点，可以当作接下来半年的观察信号：2026 年底前把生产流量全部迁出自有数据中心、读容量线性扩展架构落地、服务间重试治理到位。知乎提醒一句：迁移窗口本身就是高风险期，7 月报告已经验证过一次“没迁走的组件”就是事故诱因，窗口内如果再出容量事故，这份路线图的可信度会大打折扣。