GitHub 公布了 8 月 17 日大规模故障的原因说明。触发故障的并不是代码或配置变更，而是基础设施没能跟上创下新高的流量。真正让恢复过程变长的，是失败请求被机械地反复重发所形成的重试连锁。

中断持续了 7 小时 47 分

故障从协调世界时 8 月 17 日 13 时 28 分持续到 21 时 15 分，长达 7 小时 47 分。受影响的服务包括 Issues、拉取请求、API、Actions 以及 Copilot。高峰时，网页与 API 流量的错误率约为 20%，归档下载和仓库原始内容下载的错误率约为 50%。

认证环节的损伤同样严重，SAML 与 OIDC 认证、SCIM、Team Sync 都受到波及。在启用数据驻留的 GitHub Enterprise Cloud 中，依赖 GitHub.com 上公共工作流步骤定义的 Actions 工作流也无法运行。

恢复是分阶段完成的。随着美国中部数据中心恢复，大部分服务在 16 时 36 分前后回归，Actions 的不稳定状态持续到 18 时 3 分左右，Copilot 令牌服务则在 21 时 2 分完全恢复。

起点是 sidecar 的自动扩缩容策略

直接原因是美国中部负载均衡器上的网络饱和。而通往这一结果的路径，是本次说明中技术上最值得玩味的部分。

起点是服务网格 Istio 为各个服务附带运行的 sidecar 容器组。它们达到了并发上限，却没有自动扩容，原因是扩缩容策略只监控宿主服务的指标，而没有关注 sidecar 自身的上限。如果瓶颈先出现在策略没有观察的位置，自动扩缩容就会判断一切正常。

一处堵塞引发了下一处堵塞。最终有 4 台 HAProxy 节点耗尽了流量上限，导致网关认证路径劣化，认证延迟与失败大范围出现。再加上失败即重发这种乐观的重试逻辑，内部负载均衡器被进一步压垮。作为处置手段，团队同时暂停了这些节点上的 HAProxy，随即换来了大范围的立即恢复。

流量暴涨约 10 倍的重试风暴

部分正在失败的流量被从美国中部转移到了北弗吉尼亚。但在转移目的地又出现了另一个问题：某个内部端点响应延迟，诱发了 VS Code 中潜藏的重试缺陷，使流量放大了约 10 倍。

从数字上更能看出影响的规模。Copilot 令牌服务的负载平时为每秒 7,000 到 9,000 个请求，此时飙升到每秒 70,000 到 100,000 个请求。一次失败的令牌处理会派生出大量额外请求，并就此陷入重试循环。

收拾局面需要两步走。团队先提交了一个临时削弱网关重试逻辑的拉取请求，随后在负载均衡器前用 403 拦截令牌请求，再按站点逐步恢复流量。恢复过程中，针对 codeload 端点的抓取攻击也让事情变得更加棘手。

自 4 月以来月度提交量翻了一倍

GitHub 承认，这次故障和 8 月 6 日的 Actions 故障都不是由代码或配置变更引起的，其本质都是容量不足。用该公司自己的说法，就是没能在需求超过容量之前扩充关键组件。

背景是负载的快速增长。据该公司介绍，自 4 月以来月度提交量从 14 亿增长到 29 亿，翻了一倍有余。对此，GitHub 已经追加了超过 300 万个 CPU 核心、120 PB 高速存储以及相应的网络容量，并在现有数据中心里塞进了电力允许范围内的全部硬件，同时加快了向 Azure 的迁移。

结果是，Azure 目前承担了平台整体负载的约 58%，Git 操作的一半。考虑到 5 月时这一比例还只有平台负载的 12%，迁移速度相当快。下一个目标是让读取处理能力随读取方数量线性增长的架构，并从规模最大的单体仓库开始逐步推广。

防止复发的举措与尚未完成的功课

公开的防复发措施基本对应着此次出问题的每一个环节：修正自动扩缩容策略，使其考虑服务网格 sidecar 的并发与容量；在受影响的服务范围内审计 Istio 的请求数、并发数与扩缩容上限；重新审视网关与客户端两侧的重试上限和退避策略；处理放大 Copilot 令牌流量的 VS Code 行为；强化负载均衡器的容量监控与跨区域故障转移保护。

在此之上，GitHub 还提出要在服务间调用中统一应用重试次数上限、重试预算和可变超时。把它理解为遏制重试风暴与负载连锁的公共刹车会更直观。另一项工作是梳理此前优先级设置较低的 CPU 与内存告警，找出可能在流量骤增时崩溃的组件。

该公司首席技术官 Vlad Fedorov 写道，规模并非唯一的挑战。变更的速度与复杂度提升之后，既有的运维实践没有跟上；虽然已经把人力和资源投向更强的测试、更安全的发布、更好的可观测性和更有效的告警，但这项工作尚未完成。与此同时，GitHub 也在推进关键系统之间的隔离，减少彼此共享的依赖。

总结

8 月 17 日的 GitHub 故障持续了 7 小时 47 分，Issues、拉取请求、API、Actions 和 Copilot 均受影响。原因不是代码或配置变更，而是从 Istio sidecar 自动扩缩容失效开始的容量不足，并连锁引发 HAProxy 饱和与认证劣化。恢复迟缓的主因，则是 VS Code 侧重试缺陷带来的约 10 倍流量放大。其背景是负载的快速增长，月度提交量从 4 月的 14 亿增至 29 亿。GitHub 正通过增设 CPU 核心与存储、加快向 Azure 迁移以及统一重试控制来重整旗鼓。