GitHub 八月 17 日宕机：规模增长不能替代容量工程

据 GitHub 官方复盘 披露，GitHub 在 8 月 17 日发生持续 7 小时 47 分钟的服务中断，影响 github.com、身份认证、GitHub Actions、API、Pull Request、Issue 和 Copilot 等多个服务。

GitHub 给出的核心结论很直接：这不是一次代码或配置发布导致的事故，而是关键基础设施在流量达到新峰值后没有及时扩容。中央美国区域的数据中心先出现容量压力，随后影响认证和其他共享服务。恢复过程中，Copilot 的客户端重试又增加了流量，使恢复变成了需要控制重试风暴的二次工程。

官方数据称，自 4 月以来 GitHub 的月提交量从 14 亿增长到 29 亿。平台同时增加了超过 300 万个 CPU 核心和 120PB 高速存储，并把更多工作负载迁移到 Azure。目前 Azure 承载约 58% 的平台负载，约一半 Git 操作也已经落在 Azure 上。

这些数字说明，规模增长本身不是可靠性的证明。提交量翻倍后，最先暴露的往往不是存储容量，而是身份认证、队列、缓存、侧车服务和服务间重试等共享环节。一个服务看似只是“暂时变慢”，可能因为客户端不断重试，迅速变成全局流量放大器。

GitHub 还承诺统一重试上限、重试预算和可变超时，并隔离关键系统、减少共享依赖。对于依赖 GitHub 的开发团队来说，这些措施比“增加硬件”更值得关注。平台真正需要建立的是从流量峰值到服务降级的可观测链路，以及能阻止局部失败扩散的边界。

关键事实

• 事故时长：7 小时 47 分钟。
• 受影响服务：认证、Actions、API、Pull Request、Issue、Copilot 等。
• 官方归因：关键组件未随流量峰值扩容，恢复期间又出现客户端重试放大。
• 修复方向：增加容量、迁移 Azure、限制重试、拆分共享依赖和改善观测。

OC 判断

GitHub 的问题不是“云不够大”，而是增长速度超过了平台对最关键共享组件的容量建模。对开发者来说，真正的可靠性不是永远不出错，而是一个认证服务出问题时，是否会把代码托管、构建和发布一起拖垮。

为什么重要

• 对开发者：重要发布不要只依赖单一托管平台，至少保留镜像、离线构建和应急凭证。
• 对团队：CI 的重试策略需要有预算，盲目重试会在平台故障时加重事故。
• 对平台工程：容量规划必须覆盖共享依赖和恢复路径，而不是只看正常峰值。

参考来源

• GitHub：The August 17 outage, and the work ahead
• GitHub 状态页