GitHub 8 月 17 日长时间中断暴露什么：容量故障、重试风暴与平台可靠性改造

GitHub 在 2026 年 8 月 17 日经历了一次持续 7 小时 47 分钟的长时间中断，登录、GitHub Actions、API、Pull Request、Issue 和 Copilot 全部受影响。官方复盘把核心原因讲得很直白：流量冲到新的高峰之后，Central US 数据中心的一项关键基础设施没来得及完成扩容，容量压力很快传导到了多个依赖它的服务；恢复过程中，部分客户端发起的重试又把流量推到了更高的水平。

一次容量故障为什么会扩散到多个入口

GitHub 官方明确说明，这次中断不是“上线某份配置之后立刻触发的故障”，而是核心基础设施在流量峰值场景下拿不出足够的可用容量。认证服务挂掉之后，用户侧最先感受到的是登录异常；Actions 调度、Pull Request、Issue 和 API 这些功能，也会因为共享的关键路径承压，接连出现连锁异常。

这里有个很容易被忽略的判断：容量故障的表现从来不会只是机器 CPU 跑满。连接池占满、认证依赖超时、跨区域流量拥塞、队列积压、存储 I/O 打满，这些环节都可能先碰到瓶颈。如果运维只盯着 CPU 曲线看，大概率会错过真正的故障根因。

官方复盘给出的故障链：峰值、容量压力和依赖扩散

官方复盘把完整事故链拆成了三个可观测的阶段：流量攀升到新峰值，Central US 的关键基础设施扩容不足，容量压力扩散到多个依赖它的 GitHub 服务。这个拆解逻辑比“平台突然崩了”这种模糊描述有用得多，运维团队可以直接参照，把对应的几类监控指标放到同一个大盘里联动查看。

恢复期最危险的放大器是无边界重试

当服务刚启动恢复，客户端如果把超时的请求立刻重发一遍，故障区会迎来第二次流量高峰。GitHub 的复盘特别提到，Copilot 服务中的错误触发了客户端的重试循环，把恢复阶段的流量推得更高，团队必须先把这类行为压制住，才能安全地继续放开流量。

一个很容易落地的最小规则是：单次请求要设超时上限，调用方要设重试次数上限，服务或者租户维度还要配重试配额。只有临时性错误才值得重试，参数错误、权限错误和明确的业务拒绝响应，应该直接返回结果不需要重试。退避时间不能设成固定值，要加入随机抖动，避免大量调用方在同一时刻发起请求把流量再次冲高。

平台扩容之后还要补上哪几道验收

官方已经披露他们新增了 CPU 核数、高速存储和网络容量，同时加快推进往 Azure 扩展基础设施的迁移进度，目前 Azure 承载的 GitHub 平台负载占比也在持续上升。对其他平台的运维团队来说，这些具体数字不用直接照搬，核心是要把新增的容量和真实可能出现的故障路径绑定起来验证。

• 入口分层：认证、Git 操作、Actions 和 Copilot 分别统计独立的成功率，不要用一个笼统的总可用率掩盖局部的服务退化。
• 峰值压测：把提交量增长、Actions 运行量增长和异常重试流量叠加起来做压测，验证关键依赖能不能扛住压力。
• 恢复演练：先把受影响的区域隔离出来，再逐步放开流量；每推进一步都要检查错误率、重试量和剩余容量三个指标。
• 降级边界：给低优先级告警和非核心任务明确规定暂停触发条件，给认证和主业务链路留出足够的缓冲空间。

这次事故对日常架构决策的三个提醒

第一，做容量规划的时候，必须把业务增长趋势和故障恢复带来的额外流量放到一起计算。官方复盘提到，GitHub 的月提交量已经从 14 亿增长到 29 亿；哪怕日常业务流量看起来完全平稳，故障恢复阶段的重复请求也可能瞬间耗光平时看着很充足的容量余量。

第二，重试策略应该做成平台级的统一约束，而不是让每个客户端团队各自实现一套。统一的重试上限、配额和可变超时规则，既能减少不同团队的实现差异，事故发生的时候也能更快速地统一调整。

第三，恢复操作绝对不是“把所有服务同时重启放流”。分阶段恢复整体耗时会多一点，但能让团队先确认一条关键路径完全稳定，再把流量交给下一条路径。对大型开发平台来说，这种取舍比追求几分钟内全量恢复要稳妥得多。

相关问题

容量还有余量，为什么仍会发生超时？

因为瓶颈可能出现在连接池、认证依赖、区域网络、队列或者存储 I/O 环节，而不是整个平台的平均 CPU 指标体现出来的那样。必须按照请求路径拆分监控指标。

所有 HTTP 错误都适合自动重试吗？

不合适。只有临时网络错误或者部分服务不可用的场景可以做有限重试，权限错误、参数错误和明确的业务拒绝响应应该直接返回。

重试预算怎么定？

先按调用方、租户或者服务维度划出配额上限，再结合错误率、恢复速度和容量余量做压测验证，重试配额绝对不是越大越好。

把故障复盘变成可执行的检查清单

这次 GitHub 事故最值得其他团队参考的点，不是具体用了哪家云服务商，而是完整的故障传导链条：业务峰值增长先冲击容量水位，容量不足触发依赖错误，恢复期间的无边界重试又制造出第二个流量高峰。下次做容量评审或者故障演练的时候，把这三个环节放到同一个场景里验证，再最终敲定扩容、限流、降级的规则和服务恢复的顺序。