摘要

  • GitHub 把事故标为 major，时间为 07:53:59.358 至 09:39:19.558 UTC，共 1 小时 45 分 20.200 秒。
  • 受影响的组件包括 Actions、Issues、Webhooks 和 Pull Requests。
  • Actions 任务可能需要更长时间启动，Issues 搜索可能返回过期结果。
  • GitHub 在 09:22:21 称已识别延迟来源并应用修复，剩余服务随着处理积压清空而改善。
  • GitHub 承诺另行发布详细根因分析；现有记录没有披露具体机制、用户规模或经济损失。

事故修复和业务恢复之间存在一段容易被忽略的时间。修复可以阻止新的延迟继续产生，但此前排队的任务、事件和请求仍要被处理。

GitHub 的状态记录显示了这个过程。事故于 07:53:59.358 开始，最初涉及 Actions、Issues 和 Webhooks，随后加入 Pull Requests。平台描述的症状包括 Actions 任务启动变慢和 Issues 搜索结果过期。

Issues 在 09:18:37 被标记为已缓解，Actions 在 09:19:49 缓解。GitHub 于 09:22:21 表示已经识别延迟来源并应用修复，但同时指出，其他服务仍在等待处理积压清空。

Pull Requests 到 09:27:35 缓解，Webhooks 到 09:35:17 报告正常。完整事故在 09:39:19.558 解决。

队列让客户面对重试选择

当自动化任务没有启动时，团队可以等待、重试或取消。等待会延迟测试和发布；重试可能在原任务随后执行时产生重复工作；取消则需要确认操作是否真正生效。

状态页没有说本次出现了重复执行。可验证的事实是存在慢启动和积压，这让客户不得不管理上述风险。

Issues 搜索过期带来另一种不确定性：没有搜索到一项工作，不代表底层记录不存在。Pull Request 审查和 Webhook 事件又可能处于不同恢复阶段。代码、自动化和协作界面因此暂时反映不同时间点。

服务恢复后，客户还要核对哪些任务已运行、哪些事件已送达、哪些审查基于最新状态。这个协调时间不会出现在平台的事故时长里。

“已识别来源”不是公开根因

GitHub 说已经识别延迟来源，却没有公开具体组件、依赖、代码变更或基础设施故障。结案更新承诺尽快发布详细根因分析。

因此，不能因为四个服务同时受影响就断言它们共享某个数据库、队列或外部云供应商。共同症状说明存在传播关系，不能证明传播机制。

GitHub 也没有公布受影响用户、任务、仓库或 Webhook 数量，没有给出财务损失或服务补偿。1 小时 45 分 20 秒是事故状态跨度，不是每名客户损失的工作时间。

本次事件还不同于 7 月 22 日的托管 runner 延迟。两次事故的时段、产品范围和披露症状不同，接近发生不能证明相同根因。

后续 RCA 应说明触发条件、跨服务传播、为什么保护机制没有隔离影响，以及积压如何安全恢复。在此之前，能得出的经济结论是：GitHub 在 105 分钟内恢复了四个服务面，但客户承担的协调成本持续到队列和本地状态核对完成。

来源