8 月 17 日，GitHub 经历了近年来最漫长的一次宕机：网站、身份验证、Actions、API、Pull Request、Issues 等服务先后中断，合计持续 7 小时 47 分钟。四天之后，GitHub 公布了调查结论——这次没有代码可以背锅，也没有配置变更可以回滚，答案朴素得近乎扫兴：基础设施的容量，没有跟上平台使用量的快速增长。
事件要点
根据 GitHub 的官方说明与 IT 之家的报道，事件的大致脉络如下：
- 8 月 17 日当天，平台流量创下历史新高；
- 美国中部数据中心的一项关键基础设施组件容量不足，最先成为瓶颈；
- 压力随即向其他系统扩散，身份验证率先失败，网站、API、Actions、PR、Issues 等服务接连异常；
- 恢复过程中，部分服务错误地触发了客户端重试机制，海量重试进一步推高系统流量，反而拖慢了整体恢复，最终耗时近八小时才完全复原。
GitHub 明确排除了程序代码和配置变更这两个最常见的嫌疑。换言之，这不是一次“改坏了”的事故，而是一次“被压垮”的事故。值得注意的是，这已经是 GitHub 本月第二起重大故障——8 月 6 日 Actions 刚刚出过一次问题。
背景：是谁在把 GitHub 压满
单看“使用量快速增长”这个表述，放在当下几乎不需要注解。AI 编程工具的爆发正在改写开发者平台的使用模型：过去 git 操作、CI 触发、PR 创建大多由人手动发起，节奏是间歇式的；如今 Copilot、Codex、Claude Code 这类编程智能体把仓库当成工作台，克隆、改写、提交、跑流水线都以机器的频率进行，API 调用与 Actions 运行量随之上了一个量级。GitHub 并未把流量新高归因于某个具体来源，但“容量跟不上增长”在 AI 热潮的语境下，更像是一份甜蜜的烦恼清单。
真正值得咀嚼的是恢复阶段的细节：重试风暴（retry storm）。当服务部分恢复时，积压的客户端请求与被错误触发的重试逻辑同时涌入，形成二次洪峰——这是分布式系统的经典陷阱，教科书上的对策包括指数退避、重试预算、jitter 抖动、熔断与限流。从复盘看，这次事故中显然有环节没能挡住这波放大效应，导致恢复曲线被人为拉长。
影响层面，GitHub 早已不只是代码托管站，而是全球软件供应链的枢纽：CI 停摆意味着部署冻结，PR 不可用意味着协作中断，大量团队当天被迫切换到“离线模式”。社区里那句老玩笑——“GitHub 挂了，全球程序员提前下班”——这次被拉长到了接近一个完整工作日。
简短点评
这次复盘最值得记住的一点是：故障的元凶不一定在代码里，也可能在增长曲线上。传统事故分析习惯从“变更”入手，而容量型故障提醒我们，成功本身也是一种故障注入源。
对平台方而言，容量的前瞻规划、自动扩缩的边界、面向降级的设计（只读模式、核心链路保护），以及对客户端重试行为的治理，需要被当作与功能开发同等重要的工程事项。对依赖方而言，近八小时的中断则是一个提醒：关键仓库的镜像、CI 的备用通道、对单一平台的路径依赖，都值得重新评估。
增长是所有平台乐见的事，但增长不会等人把容量补齐。这大概是 GitHub 用 7 小时 47 分钟换来的教训，也是 AI 时代所有“被智能体高频使用”的基础设施迟早要面对的一课。