摘要

  • GitHub 在 8 月 11 日实质性更新事件 qcvjkzcs7j74；实际服务影响发生于 8 月 6 日 15:05 UTC 至 8 月 7 日 00:14 UTC。
  • 高峰时，71% 的工作流运行出现基础设施失败；在其余运行中，75% 的等待时间超过五分钟。
  • 例行部署替换 pod 时暴露既有容量与并发弱点，剩余容量饱和后造成服务崩溃，并向多个集群和下游服务蔓延。
  • GitHub 通过扩容、限制 webhook 触发的新任务并提高积压处理能力，完成第一阶段恢复。
  • 一个潜伏的分配缺陷又让 runner 反复领取已经无效的任务；部分 ARC runner 需人工恢复，部分 push 与 pull request 事件也无法自动重放。
  • GitHub 宣布加强部署保护、监控、队列韧性和自动恢复，但尚无证据证明这些措施已经全部上线并经受验证。

两个比例不能直接相加

71% 的分母是全部工作流运行，指基础设施失败。75% 的分母则是余下的 29%，指等待超过五分钟。后一个比例既不是 75 个百分点，也不能说明余下任务全部成功。

这组数据的价值在于区分硬失败与长时间排队。两者都会影响交付窗口，却需要不同的客户侧恢复判断。

部署过程吃掉了安全余量

GitHub 称，触发点是负责处理事件并生成任务的内部 Actions 服务进行例行部署。pod 被替换后，仍在线的容量无法承载负荷，服务随之崩溃并产生跨集群级联。

因此，部署余量不能只按平时流量计算。它还必须覆盖替换期间暂时退出的实例，以及并发变化导致的瞬时不平衡。

扩容之后仍有状态错误

工程团队先增加容量、压低 webhook 新任务进入速度，并提高积压处理吞吐。随后出现第二层问题：分配服务把已经无效的任务交给 runner，runner 持续重试，无法领取有效工作。

最终修复不只是“让队列跑快一点”，还要阻止无效任务继续占用执行者。只有任务状态与实际可执行性一致，清空队列才有意义。

绿色状态之外还有人工恢复

一次缓解措施意外影响部分 Actions Runner Controller runner，使其在事件结束后仍处于离线或卡住状态，需人工恢复。另有一些 push 和 pull request 触发没有被处理，且无法自动重放。

客户必须查看仓库历史，决定是重新触发、手动运行，还是先恢复 runner。提供商“已恢复”并不会自动完成这一步。

8 月 11 日是披露时间而非故障时间

服务影响在 8 月 7 日结束，详细根因说明到 8 月 11 日才补充。本文报道的是信息生命周期推进，不是同一服务在 11 日再次中断。

分开两只时钟，既避免夸大故障时长，也能衡量运营方从修复到解释所花的时间。

承诺的控制仍待落地验证

GitHub 提出的改进覆盖部署与容量保护、前兆监测、积压队列与 runner 分配韧性、级联控制以及自动恢复。这些方向与已经披露的故障链条相符。

但公告没有列出所有上线日期、阈值或成效指标。未来版本是否能自动拉起 ARC runner、淘汰无效任务并保持部署余量，才是实际检验。

企业需要自己的任务账本

仓库运营方可以记录预期触发、运行标识、终态和产物，把缺失任务与已完成任务区分开。这样既能发现没有重放的事件，也能避免盲目重复执行已经成功的操作。

平台恢复证明当前服务可用；客户账本才证明故障窗口内每项预期工作都已得到处置。

来源