GitHub宕机7小时47分钟复盘：故障原因、影响范围与修复措施

GitHub宕机7小时47分钟，问题不只是“挂了”

GitHub 这次长达 7 小时 47 分钟的故障，不是单点失灵，而是多个环节连续失控的结果。受影响的不只是网页访问，连 Issues、Pull Requests、API、Actions、Copilot 以及部分身份认证能力都出现了异常。

如果只看表面，会觉得是一次普通的服务波动；但从官方复盘看，它更像是一场典型的“连锁反应”事故：

• 先是局部组件扩容失败
• 再是网关和负载均衡压力升高
• 接着客户端重试把流量越放越大
• 最后演变成多项核心服务同时降级

这类问题对所有做云服务、平台架构和高并发系统的人都很有参考价值。

受影响范围有多大

这次故障从 8 月 17 日 13:28 UTC 开始，到 21:15 UTC 才完全恢复。期间，多个关键能力都受到了冲击：

• Issues、Pull Requests 无法正常使用
• API 错误率和延迟明显升高
• Actions 执行异常，部分工作流受影响
• Copilot 服务波动明显
• SAML/OIDC、SCIM、Team Sync 等企业能力也被波及

尤其是 archive 和 raw content 下载接口，错误率一度接近 50%。这说明问题并不局限于某个“前台页面”，而是已经影响到底层服务链路。

故障是怎么一步步放大的

第一层：Istio sidecar 扩容没及时生效

GitHub 说明，最初的问题出现在美国中部数据中心。一组运行 Istio sidecar 的 Pod 达到了并发限制，但自动扩容策略没有正确触发。

根本原因在于：扩容策略只看了 host service 的容量，没有把 sidecar 的并发限制算进去。结果就是，看起来还有空间，实际上已经顶满了。

这类问题很容易被忽略，因为监控指标“表面正常”，但真实瓶颈已经先到了。类似场景里，常见的修正方向是把自动扩容判断条件做得更完整，避免只看单一维度。

第二层：HAProxy 节点被压满

随后，故障扩散到其他节点，4 个 HAProxy 节点耗尽了连接流量限制，网关认证链路开始大量延迟和失败。

这一步很关键。因为当入口层开始排队、超时和拒绝连接时，后面的服务即使本身正常，也会被上游拖住。

这也是为什么平台架构里，入口网关、认证链路和负载均衡器通常会被重点保护。它们一旦拥堵，影响面会迅速放大。

第三层：重试机制反而帮倒忙

很多人会以为“重试”是自动恢复的好办法，但这次事故里，它变成了放大器。

当请求失败后，大量客户端不断重试，进一步抬高内部负载均衡器压力，形成典型的“重试风暴”。这时系统并不是在修复自己，而是在用更多请求消耗自己。

如果没有合理的退避、限流和熔断机制，重试通常不是救命药，而可能是加速器。

为什么 Copilot 的恢复时间更长

VS Code 内部 Bug 让请求被放大

GitHub 发现，Copilot 相关链路里还有一个额外问题：某个内部接口延迟后，触发了 VS Code 中隐藏的重试 Bug，导致请求量继续放大，最高放大约 10 倍。

正常情况下，Copilot Token Service 的流量只有 7000～9000 RPS，但事故期间暴涨到 7万～10万 RPS。这个级别的增幅，足以把原本还能支撑的链路直接压垮。

这说明客户端行为同样重要。服务端稳定，不代表客户端不会把压力再推高一层。

临时止血措施

为了控制局面，GitHub 采取了几步措施：

• 降低网关 retry 次数
• 在负载均衡器层面阻断相关请求
• 对部分流量返回 403
• 逐站点恢复流量，避免一次性回灌

这些动作的核心思路只有一个：先把流量压下来，再谈恢复。

这次事故给技术团队的几个提醒

1. 扩容判断不能只看单一指标

如果系统里有 sidecar、代理层、缓存层等组件，容量判断就不能只看主服务。否则很容易出现“主服务看似有余量，实际链路已经堵死”的情况。

2. 重试一定要有边界

重试要配合：

• 退避时间
• 最大重试次数
• 熔断策略
• 限流控制

否则一旦上游抖动，重试就会把小问题扩大成大事故。

3. 客户端 Bug 也可能是事故源头

这次 Copilot 的问题就说明，服务端和客户端要一起排查。只盯着后端接口，可能会漏掉真正的流量放大器。

4. 故障切换要足够快

GitHub 将部分流量切到 Northern Virginia 后，请求恢复得更快。这说明跨区域容灾和故障切换依然是大型平台的关键保障。

5. 监控要能看见“真实瓶颈”

监控不能只看高层成功率，还要关注：

• 连接池是否耗尽
• 网关是否排队
• 代理层是否限流
• 某个组件是否触顶

很多事故的前兆，往往藏在这些细节里。

GitHub后续会怎么改

GitHub 已经给出改进方向，重点包括：

• 修正自动扩容策略，把 sidecar 并发和容量纳入判断
• 重新审查 Istio 相关请求与限制
• 检查网关和客户端的重试与退避机制
• 修复 VS Code 的重试行为，避免再次放大 Copilot 流量
• 加强负载均衡器容量监控和跨区域故障切换能力

这些措施看起来很“工程化”，但本质上都指向同一个目标：减少连锁故障的机会。

一次宕机，暴露的是系统设计能力

GitHub 这次宕机之所以引发关注，不只是因为影响时间长，更因为它非常典型：局部扩容异常、入口层过载、重试风暴、客户端 Bug、跨区恢复，几乎把大规模在线系统常见风险都串了一遍。

对于做平台、SaaS 和 AI 服务的团队来说，这类事故最值得学的不是“谁出了错”，而是“为什么一个小问题会变成大故障”。

简单说，真正稳定的系统，不是不会出问题，而是出了问题后，能不能把它拦在第一层、第二层，不让它继续传染。