GitHub 连续故障之后，企业该怎样检查 CI/CD 的单点依赖

8 月连续两次 GitHub 重大故障后，团队最该检查的不是“要不要换掉 GitHub”，而是发布链路里有多少关键动作只能依赖一个平台。GitHub 官方对 8 月 17 日事故的复盘称，故障持续了 7 小时 47 分钟，影响了 GitHub Actions、API、认证、Pull Request、Issues 和 Copilot；8 月 6 日还发生过一次 Actions 故障。对企业来说，这已经足够触发一次 CI/CD 单点依赖盘点。

把 CI/CD 画成一条从提交到生产的链路，逐项标出“平台不可用时谁来接管、凭据在哪里、制品能不能独立取回、回滚是否绕开原流水线”。标不出来的节点，就是当前最真实的单点。

先画出从提交到生产的真实依赖图

事故当天最容易出现的误判是：仓库页面还能打开，所以发布链路应该没问题。实际上，一次发布通常同时依赖代码托管、身份认证、工作流调度、Runner、制品仓库、云平台凭据、审批和告警。任意一个环节不可用，最后的“部署按钮”都可能只是一个看得见却按不下去的入口。

可以从最近一次生产发布倒推，不要从组织架构图猜。把提交 SHA、构建任务、制品摘要、部署身份、目标集群和回滚命令写在同一张清单里。每一项补两个字段：替代入口 和 最长可接受中断时间。没有替代入口的项先标红；只是“以后考虑多云”的口号不算替代方案。

准备一个不依赖原流水线的接管入口

备用入口不一定要立刻再建一套完整 CI。更实用的第一步，是保证最近一批经过验证的制品可以独立取回，并准备一份受控的手工部署流程。它至少要说明制品摘要怎么核对、目标环境怎么选、谁能批准、如何观察健康状态，以及失败后执行哪条回滚路径。

接管文档里不要只写“登录云平台发布”。真实操作需要落到制品仓库路径、镜像 digest、环境变量清单和数据库变更边界。对于不可重复构建的制品，保留构建输出与依赖锁文件；对于必须重新构建的项目，把构建机和基础镜像的来源也列为依赖。

这一步的成功状态很明确：关闭 GitHub Actions 后，值班工程师仍能从制品仓库拿到指定版本，核对 SHA256 或镜像 digest，并在审批记录中留下发布人与目标环境。演练只要有一个字段靠猜，就说明接管入口还没有达到可用标准。

把凭据、权限和制品从单一平台边界里拆出来

很多团队以为有备用 Runner 就够了，但 Runner 只是执行位置，不会自动解决认证单点。应分别检查云平台短期凭据、制品仓库读取权限、生产部署权限和人工接管权限。生产发布账号不应依赖某个仓库页面的交互登录，也不应把长期密钥直接写进工作流变量。

• 凭据：为自动发布和人工接管准备不同身份，默认只授予目标环境的最小权限。
• 制品：用不可变版本或 digest 标识，禁止回滚时重新拉取“latest”。
• 审批：把批准记录放在独立可审计的位置，至少记录版本、环境、操作者和时间。
• 网络：确认生产环境能从备用入口访问制品仓库，而不是只能通过原 Runner 的网络出口访问。

限制重试风暴，并让告警在平台故障时仍能到达

GitHub 官方复盘提到，部分 Copilot 服务的错误触发了客户端重试环路，恢复期间反而增加了流量。这个细节值得迁移到企业自己的发布系统：工作流失败重试、部署控制器重试、Webhook 重投和通知机器人重试叠在一起时，平台恢复窗口可能被自己的流量再次推高。

检查清单里应写出每一层的最大重试次数、退避方式和总时间预算。发布任务遇到平台不可用时，先进入待处理状态，不要让每个提交都无限创建新任务。告警则至少保留一条不依赖 GitHub Actions 的通道，例如独立监控服务的短信、电话或值班系统；这里的重点不是通道越多越好，而是故障时有人能收到并确认。

用一次小规模演练验证，而不是相信文档存在

演练可以选择一条低风险服务，在发布窗口前暂时禁止原 CI 调度，保留已验证制品，然后按接管文档完成一次部署和一次回滚。GitHub Actions 的工作流日志可以帮助定位正常运行时的步骤与产物，但故障演练还必须记录“原平台不可访问时”的人工证据，例如独立审批记录、制品摘要和目标环境健康检查。

建议把验收结果分成三档：能拿到制品但无法批准，说明权限边界有问题；能批准但无法观察，说明告警或健康检查依赖原平台；能发布却无法回滚，说明制品保留和数据库变更策略仍是单点。只有三项都通过，备用路径才值得写进事故手册。

相关问题

企业一定要准备第二套完整 CI/CD 吗？

不一定。先保证制品可取、凭据可用、人工发布和回滚可审计，再根据业务的中断成本决定是否建设第二套完整流水线。

备用 Runner 能消除 GitHub Actions 的单点吗？

不能。Runner 仍可能依赖 GitHub 的调度、认证、Webhook、制品和网络出口。它只是执行层的替代，不是整条链路的替代。

怎么判断回滚路径真的独立？

在原流水线不可用时，仍能取到固定版本制品，完成权限审批，执行部署并确认健康状态，且整个过程有独立记录，才算真正独立。

应该从哪里开始盘点？

从最近一次生产发布开始，沿着提交 SHA、构建产物、部署身份和回滚命令逐项倒推。真实发布路径比抽象架构图更容易暴露隐藏依赖。

把单点检查变成发布前的固定动作

GitHub 的连续故障不等于所有企业都必须迁移平台，但它提醒团队重新定义“可发布”：不是页面恢复就算恢复，而是提交、制品、权限、部署、回滚和告警都能在边界条件下工作。把这六项写入每月一次的轻量演练，才有机会在下一次平台波动时少靠临场记忆。

需要复查具体事故进展时，可查看 GitHub 官方复盘、Actions 工作流日志文档 和 GitHub Status。企业自己的清单则应以内部真实发布路径和权限记录为准。