摘要

  • 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分钟内恢复了四个服务面，但客户承担的协调成本持续到队列和本地状态核对完成。

Sources