摘要
- GitHub 于 7 月 19 日 23:34 UTC 报告 Actions 性能下降，并把事故定为 critical。新工作流可能延迟或无法启动，已经运行的任务也可能失败。
- 故障随后覆盖 API Requests、Pages 与 Issues。GitHub 明确表示，Actions 长时间不可用已经对其他服务造成连锁影响，并把另一条 Git LFS/API 事故并入同一调查。
- CircleCI 发现流水线未启动或停留在运行状态；OpenAI 也报告依赖 GitHub 的编程工作流出现失败或延迟。这两份记录独立证明影响越过了 GitHub 自身界面。
- GitHub 在 04:43 UTC 宣布 Actions 完全恢复，并在一分钟后结束事故。公司承诺发布详细根因分析，但在本文截点尚未提供。
代码仍在仓库，执行机器也可能在线，交付链却不一定还能前进。
这正是此次 GitHub 事故暴露的控制面风险。7 月 19 日 23:34 UTC，GitHub 首先报告 Actions 性能下降。数分钟后，状态页说明新工作流可能延迟、无法启动，已经开始的运行也可能失败。23:57，GitHub 称已经识别原因并着手恢复，但没有说明原因是什么。
此后，问题不再局限于执行容量。00:07，API Requests 进入部分中断；Pages 和 Issues 随后降级。另一条状态记录显示，部分 Git LFS 操作以及通过 API 加载文件也失败。到 01:11，GitHub 给出了关键关系：Actions 的持续停机开始对其他服务产生连锁影响，先前单独建立的事故其实属于同一问题。
执行故障变成了控制面故障
Actions 的价值不只是提供一台机器执行命令。仓库事件触发工作流，工作流生成任务，系统把任务分配给 runner，再把结果写回合并规则、审查页面和外部服务。
这条链中的状态可以彼此分离。代码 push 已经存在，流水线却没有创建；任务完成了，受保护分支等待的检查状态没有回来；大文件仍存放在 LFS，读取它所需的 API 调用却失败；现有 Pages 页面还能访问，下一次构建却无法推进。
GitHub 的恢复顺序证明这些表面并非同时起落。Pages 在 01:37 恢复，Issues 在 02:20 恢复。02:43，GitHub 表示 Issues、API Requests 与 Pages 已经恢复，但仍在处理使用自托管 runner 或大型托管 runner 的 Actions 任务。API Requests 到 03:03 才被宣布正常。Actions 在 03:34 进入监测，04:43 才被确认完全恢复。
这些时点是供应商发布状态的时点，不能直接当成每位客户的停机时长。GitHub 没有公布受影响仓库数、组织数、任务数、地区或总体失败率。只使用 Git 操作的团队与同时依赖 Actions、LFS、Pages 和外部平台的团队，经历很可能不同。
下游记录揭示状态不一致
CircleCI 的记录把这种差异变成了可操作的问题。其状态页把未启动或一直显示运行中的流水线归因于 GitHub API 错误，还记录到处理 push 事件 webhook 时发生失败。
GitHub API 错误率恢复后，CircleCI 建议客户重新触发从未开始的流水线，并取消后重跑仍卡在运行状态的流水线。这里的重点不是“重试”二字，而是上游恢复没有自动修正下游保存的任务状态。
OpenAI 提供了另一份独立印证。它把依赖 GitHub 的编程工作流失败或延迟，与 GitHub API 部分中断及 Actions 降级直接关联。该记录没有量化用户、任务或经济损失；它能证明的是，故障已经跨过企业边界，在另一项服务的客户入口出现。
这些信息不能证明 CircleCI 或 OpenAI 导致事故，也不能推断所有集成都失效。它们说明，依赖关系一旦跨平台，上游变绿只是恢复的起点，而不是所有系统状态已经一致的证明。
自托管 runner 不等于自有编排系统
GitHub 文档将自托管 runner 定义为由客户部署和管理、用于执行 Actions 任务的机器。客户控制硬件、操作系统和工具，并承担维护成本。
这类控制有助于满足网络隔离、数据位置、特殊硬件或容量要求，却没有把整条工作流控制面搬到客户手中。
GitHub 特别说明，在 Issues、API 与 Pages 已恢复后，使用自托管 runner 和大型托管 runner 的任务仍需要继续恢复。它没有说客户机器本身损坏。更准确的含义是：即使计算资源可用，事件接收、排队、任务分派与状态回写仍可能受制于 GitHub。
因此，备用交付路径不能只准备另一台服务器。团队还要事先决定：正常触发器不可用时谁能启动任务，哪一个版本获准交付，审批如何留下记录，结果怎样回到可审计的变更链。只有执行资源的备份，并不是完整的交付备份。
重跑之前先核对目标系统
显示为失败或运行中的任务，可能已经对外部系统产生了部分效果。它可能发布了软件包、开始部署、修改了基础设施，或发送了通知，只是在回写状态时中断。
不加核对地重跑，可能把同一个操作执行两次。更稳妥的顺序是同时检查仓库事件、Actions 运行历史、runner 日志、制品状态和实际目标系统。幂等设计与可验证的发布标识能够降低重复风险，但仍不能替代事实核对。
CircleCI 的取消和重跑建议符合它观察到的平台状态，客户仍需判断自己流水线内部做过什么。单纯的测试失败通常容易重做，执行到一半的生产变更则需要针对目标状态制定恢复动作。
尚缺的是解释扩散路径的根因
GitHub 在 04:44 UTC 结束事故，并表示会发布详细根因分析。现有时间线足以说明受影响组件与恢复先后，却没有说明最初哪个组件失效、为什么问题会扩散到 API 与其他服务、以及什么设计变化能够防止复发。
公开证据也不支持安全入侵、源代码丢失、数据丢失、某个具体部署失败、特定地区受损或自动获得 SLA 补偿等结论。GitHub 的 critical 是事故级别，不是每位客户损失的量化结果。
下一份真正有价值的披露，应当把初始故障、积压形成和恢复过程中的次生影响分开说明。在此之前，可以确认的是 GitHub 恢复了服务链；客户只有在事件、任务与目标系统三者相互吻合后，才能结束自己的事故。