GitHub Actions 中断阻止 CI 作业和 Copilot 编程代理

Why it matters

GitHub uses Actions to run CI, Pages, Copilot agents, code reviews and migrations. Runner failures can now block several stages of software delivery at once.

GitHub Actions 在 8 月 6 日发生重大中断，导致软件构建和部署停滞，同时影响了 GitHub Pages、Copilot coding agent、Copilot code review 和企业迁移。GitHub 表示，由于 hosted-runner 的容量持续受限，工作流运行出现失败、长时间排队或超时。 (githubstatus.com)

GitHub 最早在 15:22 UTC（东部时间上午 11:22）承认 Actions 性能下降。到 16:33 UTC，GitHub 已将 Actions 和 Pages 都归类为重大中断。该事件在 18:46 UTC（开始后三个多小时）仍在调查中，GitHub 警告恢复比预期要花更长时间。 (githubstatus.com)

此次中断对使用 GitHub-hosted runners 的作业打击尤为严重。Self-hosted runners 并没有提供干净的逃生通道：GitHub 表示这些客户在注册 runner 时可能会遇到错误或速率限制。早些时候的更新还报告了来自 Actions REST API 的错误、意外的工作流速率限制以及在作业已开始后失败的情况。Webhook 的交付可能会被延迟。 (githubstatus.com)

核心仓库功能仍可用。Git 操作、pull requests、issues、packages 和一般 API 请求被列为正常运行，把故障的重心缩小到用于测试、构建和部署代码的自动化层。对于那些在合并前要求通过检查或使用 Actions 发布软件的工程组织来说，可用的仓库对保持交付流水线运转作用有限。 (githubstatus.com)

开发者很快就识别出这种模式。Ryan Brewer (@ryanbrewer) 写道，“又是一天，又是一次 github 中断。” Aida Issayeva (@Aida_Isay) 表示一连串的 Actions 事件正在变成常态，并描述在调试 CI 时，查看 GitHub 的状态页面是第一步。她分享的截图显示大多数 GitHub 服务的正常运行时间记录为绿色，而 Actions 带有红色的事件标记。

Actions has become GitHub's shared execution layer

8 月 6 日事件的广度反映出如今有多少 GitHub 服务依赖于 Actions。GitHub 的文档 指出，Copilot cloud agent 在由 Actions 提供动力的短期开发环境中运行，在该环境中它会读取代码、进行更改并运行测试。Copilot code review 也默认使用 GitHub-hosted runners。 (docs.github.com)

GitHub Pages 可以使用 Actions 来构建和部署站点，而 GitHub Enterprise Importer 将仓库和组织迁移到 GitHub Enterprise Cloud。因此，此次中断超出了传统 CI 作业的范围，影响到了 AI 辅助开发、网站发布和基础设施迁移。GitHub 将若干产品集中在同一工作流和计算层上，这在 runner 配置或编排失败时增加了运营成本。 (docs.github.com)

Pages 在 15:03 UTC 已经经历了另一起部署延迟事件。GitHub 在 16:22 UTC 将该事件标记为已解决，几分钟后 Pages 在更广泛的 Actions 事件下再次出现性能下降。随后 GitHub 将 Pages 与 Actions 一并列为重大中断。 (githubstatus.com)

Reliability pressure was already building

此次中断发生在 8 月 5 日另一宗 Copilot cloud agent 故障之后。GitHub 表示一个内部速率限制被比预期更广泛地启用，导致每个新提交的 cloud agent 作业在 11:02 到 11:54 UTC 之间被延迟。积压在 13:00 UTC 前清理完毕。 (githubstatus.com)

Actions 在 7 月也多次发生中断。7 月 25 日，GitHub 记录了与地区基础设施和 Redis 容量相关的两段性能下降。在第一段期间，25% 的工作流运行因基础设施错误失败；在第二段期间，失败率峰值达到 60%。7 月 29 日，一个资源配置不足的内部服务耗尽内存，延迟了约 2% 的工作流，并导致 runner 注册失败和 API 超时。 (githubstatus.com)

7 月早些时候的事件涉及 hosted-runner 的配置、自动伸缩配置和一个过期的内部证书。各个故障的具体原因不同，但对客户而言每次故障都会在同一位置显现：工作流在等待 runner、无法启动或耗尽重试次数。 (githubstatus.com)

这种重复性使得 GitHub 的状态页面成为常规 CI 诊断的一部分。8 月 6 日的中断强化了这样一种运营风险：随着 GitHub 将更多产品（包括其 AI 代理）绑定到 Actions，位于该层的故障可能会同时阻止测试、发布、审查、站点部署和自动化编码工作。