摘要

  • 事故在 7 月 24 日 16:04 UTC 开始；GitHub 于 7 月 29 日 02:36:25 UTC 才加入详细根因说明。
  • 三个物理数据中心可用区中的一个出现故障，一个机笼的 spine 交换机到汇聚层的链路失去连接。
  • 25% 的可用网络互联容量因此消失，其余有效路径饱和并出现丢包。
  • 影响期内，10% 的 Actions 作业失败，另有 5% 延迟启动后成功；27% 的 Issues 交互缓慢或超时；Copilot 请求和 git push 各有 4% 受影响。
  • GitHub 借用了原本预留给未来扩容的光纤，17:07 消除丢包，17:36 恢复全部路径，并将旧机笼从 100Gbps 升至 400Gbps 的计划提速。

这份新说明最有价值的地方，是它没有把“GitHub 故障”当成一个不可拆分的数字。底层都是丢包，到了应用层却分别表现为失败、等待、超时、自动重试或延迟升高。不同症状意味着不同的核对动作，不能用一次批量重跑代替。

新闻发生在披露日，停机并未重演

服务中断发生在 7 月 24 日，状态页当天已经结束该事件。7 月 29 日进入本轮时间窗口的是新增证据：GitHub 首次说明故障所在的网络层级、容量损失比例、各产品影响、临时绕行方法和后续接口升级。

因此，标题若写成“GitHub 7 月 29 日宕机”，就会凭空制造第二次事故。它也不能与 7 月 25 日或 27 日的其他 GitHub 状态事件混在一起。官方事件编号 yjysg0xrl67m 是本篇的证据边界。

即便被称为根因分析，公开内容仍有缺口。GitHub 说明了链路失联之后的传播机制——剩余路径饱和、网络丢包——却没有说明最初为何失去连接，也没有点名设备故障、维护操作或配置变化。未披露的起点仍应保持未知。

四分之一容量损失没有变成一个统一错误率

GitHub 描述的每个计算机笼都采用 leaf-spine 交换结构，并通过汇聚层与同一可用区内的其他机笼相连。故障发生在一个可用区内，一个机笼的 spine 到汇聚层之间。依赖该机笼计算资源的工作负载受到丢包影响。

Actions 中有 10% 的作业失败，5% 的作业虽然成功但启动延迟。Issues 有 27% 的交互缓慢或超时。Copilot 有 4% 请求报错，不过多数会自动重试。git push 也有 4% 受到影响。认证请求延迟上升，但错误率仍低于 1%。

这些比例的分母完全不同，不能相加成“GitHub 总故障率”。它们真正说明的是同一网络压力如何穿过不同状态模型：队列型服务会延迟，交互型服务会超时，有重试能力的请求会隐藏首次失败，写操作则留下结果是否已提交的疑问。

临时恢复借用了未来扩容资源

GitHub 将受影响连接改道到原本为未来容量升级预留的光纤。17:07，网络重新获得足以消除丢包的容量；17:16，大多数服务显示完全恢复；17:36，全部路径复原且服务健康。

三个时间点代表三条不同的恢复线。停止丢包不等于全部应用立即稳定，大部分应用恢复也不等于网络拓扑已经完整。只保留最后一个绿色时间戳，会丢掉容量恢复和业务恢复分阶段发生的事实。

预留光纤提供了有效的应急手段，但公开记录没有说明绕行后还剩多少余量、临时配置持续多久，或者该光纤是否已经重新成为可用的应急储备。

失败作业可以重跑，写操作必须先查状态

GitHub 文档允许有写权限的用户重跑整个 workflow、所有失败作业或某个具体作业。重跑沿用原触发者的权限、原 commit SHA 和 Git ref。这样能保留执行语境，却不能保证部署、发布、付款或数据库迁移具备幂等性。

延迟启动的那 5% 可能在更新的执行已经开始后才完成。响应失败的 push 可能已经推进远端引用。客户端看到超时的 Issue 评论或修改也可能已经落库。正确动作应先读取远端状态、执行记录和外部副作用，再决定是否重试。

Copilot 自动重试会降低最终可见错误，却可能掩盖首次请求可靠性下降。认证错误低于 1% 也不表示完全无影响，因为延迟本身可能触发客户端超时。每一类业务都需要自己的恢复判据。

400Gbps 是直接补救，不是完整答案

旧机笼目前使用 100Gbps 网络接口。GitHub 表示将尽快推进原计划中的 400Gbps 升级，使交换结构各层在路径或设备丢失时拥有更多带宽。这项措施直指本次传播机制：幸存路径没有足够余量。

但标称速率提高四倍，并不自动等于端到端韧性提高四倍。GitHub 没有公布剩余旧机笼数量、完工日期、最低冗余余量、可容忍的组合故障，也没有说明检测与隔离控制是否会改变。

真正的验收标准应是在明确的失效场景下测量余量。若再次失去一条机笼到汇聚层的路径，幸存链路应不再饱和，事故工具应继续可用，告警也应早于用户症状出现。

下一步要同时关闭物理和业务两本账

客户现在就可以保存失败和延迟 workflow 的编号，核对远端 Git 引用，查找可能重复的 Issues 写入，并区分首次失败与重试成功。恢复不是把请求重新发送一遍，而是把实际状态对齐。

GitHub 下一份说明应补足最初失联的触发条件、绕行后的容量余量、400Gbps 项目的范围和进度，以及防止单个机笼拖满其余路径的控制。预留光纤何时恢复为应急资源也值得明确。

7 月 29 日的披露让抽象的云依赖重新具有物理形状：四分之一互联容量消失，幸存路径被填满，而用户面对的是五套不能用同一种方法清理的善后队列。

来源