8 月 17 日，GitHub 宕机了 7 小时 47 分钟。影响范围不只是 github.com 打不开。认证系统瘫痪、Actions 中断、Pull Request 和 Issue 不可用、Copilot 也挂了。

官方事后分析了故障原因：负载均衡配置错误触发了客户端的重试风暴。故障发生时，负载均衡的错误配置导致部分请求处理不当，客户端在收到错误响应后发起大量重试。重试请求进一步压垮了本已脆弱的基础设施，形成了典型的 "重试风暴" 模式。

GitHub CTO Vlad Fedorov 在事后分析中直接承认：「如果你那天正在发布软件，我们让你失望了。」

这是 GitHub 8 月份的第二次重大事故。上一次是 8 月 6 日的 Actions 故障。再往前，3 月和 4 月也都出过事。Fedorov 说得很直白：我们做了不少工作，但翻车说明做得还不够快。

事故原因，官方的调查结论是：Central US 数据中心的一个关键基础设施组件在流量达到新峰值时没能跟上扩容，容量压力向整个系统蔓延，先导致认证失败，再拖垮多个服务。

一个值得注意的细节：既不是代码变更引入的 bug，也不是配置错误。纯粹是容量问题——东西没撑住。

Fedrov 给了一个数据：从 4 月到现在，GitHub 上每月 commit 数从 14 亿涨到了 29 亿。翻了一倍。

这个增速背后显然有 AI 驱动的自动化提交。GitHub 自己可能就是 Copilot 最大的受害者。

恢复过程也不顺利。大部分服务当天恢复，但 Copilot 比预期慢。原因是某些服务返回错误时，客户端进入了重试循环——错误越多，重试越多，流量越大，恢复越难。团队必须先把这波重试风暴压下去，才敢把流量重新灌回来。

这种「重试风暴」是典型的分布式系统反模式。你在客户端加个重试逻辑，觉得这样更可靠，但所有人的重试叠加在一起，就等于在故障系统上再踩一脚油门。Fedorov 说他们会立即推动两项改进：一是给所有服务间调用加上统一的 retry limit、retry budget 和可变超时，防止重试风暴；二是审查所有低优先级 CPU 和内存告警，找出那些在流量尖峰时可能崩掉的组件。

GitHub 去年开始就在做几件事：加容量、提效率、拆架构瓶颈。Fedrov 披露了一些数据：

• 新增 300 万+ CPU 核心
• 120 PB 高速存储
• 大规模网络扩容
• 现有数据中心能装的硬件都装了，同时加速迁往 Azure

Azure 现在承载了 GitHub 约 58% 的平台负载和一半的 Git 操作。5 月时这个数字只有 12%。顺便说，这可能是 GitHub 被微软收购后，Azure 迁移进度最透明的一次公开披露。

Git 存储层面也有动作。最大 monorepo 的读扩展方案正在推进——目标是让读容量随节点数线性增长，实现「无限读」。听起来跟 Cursor 那篇《Git at any scale》里提到的架构思路不谋而合。

但 Fedorov 也承认，扩容不是唯一的问题。运营实践没跟上变化的速度。团队正在投更多资源到测试、灰度发布、可观测性和告警上。

「开发者社区依赖 GitHub 来构建、交付和运营自己的工作。只有在你们能依赖我们的前提下，这一切才有可能。8 月 17 日，你们没能依赖我们。」

「修复它是我们的责任。」

参考来源：

• GitHub Blog: The August 17 outage, and the work ahead
• GitHub Status: Root cause analysis