8 月 6 日，GitHub 再次出现大范围服务降级。根据事故摘要，GitHub Actions 完全不可用超过 5 小时，webhook 停止发送，自托管 runner 也因调度层故障无法领取任务；GitHub Pages、Copilot code review 和 Copilot coding agent 同时受到影响。从发现异常到完全恢复，整个过程约 12 小时。
这次事故提醒团队：把计算资源放进自己的机房，并不等于摆脱了托管平台的控制面。真正需要审视的不是“GitHub 会不会故障”，而是当它故障时，构建、发布和紧急修复是否还存在另一条可执行路径。
自托管 Runner 仍然依赖 GitHub 的调度层
自托管 runner 经常被误认为一种完整的容灾方案。它确实能让团队控制 CPU、网络、缓存和部署凭证，但工作流触发、任务排队、runner 注册与任务分配仍依赖 GitHub Actions 的控制面。
这次事故中，即使 runner 机器本身健康，调度层也无法把任务交给它们。可以把依赖关系简化为：
代码事件 -> GitHub webhook/workflow -> Actions 调度层 -> self-hosted runner -> 部署目标
只替换最后一段计算节点，没有消除前面的平台依赖。类似地，webhook 停发意味着外部系统即使完全正常，也可能根本收不到 push、pull request 或 release 事件。
因此，容灾设计需要区分两类组件：
- 数据面：真正执行测试、构建和部署的机器。
- 控制面：接收事件、创建任务、分配 runner、保存状态并批准发布的服务。
只有数据面自托管，而控制面仍由单一供应商承载，故障域依然集中。
同时受影响的产品暴露了故障半径
事故摘要还提到 Pages、Copilot code review 和 Copilot coding agent 均受影响。仅凭摘要不能断言这些产品共享了哪些内部组件，但多个开发流程同时降级，已经足以说明团队不能按产品名称孤立地评估风险。
一次平台事故可能同时阻断：
- push 后自动运行的测试和构建；
- webhook 驱动的内部机器人、审计与发布系统；
- 静态站点和文档更新；
- AI 代码审查与代理任务；
- 依赖 Actions 审批环境的生产发布。
摘要称，这是 2026 年 8 月的第六起事故，其中四起与 AI/Copilot 服务有关。这个数字不应直接推导为某个具体根因，但它值得被纳入供应商风险评估：新增 AI 能力不能成为核心交付链路的硬依赖，尤其不能阻止人工审查、普通测试或紧急发布。
建一条不经过 Actions 的应急发布路径
容灾方案不必一开始就复制整套 CI 平台。更务实的做法，是先把关键构建逻辑从 GitHub Actions YAML 中抽出来，放进仓库内可独立执行的脚本。Actions、开发机和备用 CI 都调用同一个入口。
下面是一个可以改造的最小示例。假设项目使用 Docker，并且测试命令可以在容器中运行。执行前需要设置镜像仓库地址，并确保本机已经登录仓库。
#!/usr/bin/env bash
set -euo pipefail
: "${IMAGE_REPOSITORY:?Set IMAGE_REPOSITORY, for example registry.example.com/team/api}"
GIT_SHA="$(git rev-parse --verify HEAD)"
IMAGE="${IMAGE_REPOSITORY}:${GIT_SHA}"
if [[ -n "$(git status --porcelain)" ]]; then
echo "Refusing to release a dirty working tree" >&2
exit 1
fi
echo "Running tests for ${GIT_SHA}"
docker build --target test -t "local/test:${GIT_SHA}" .
docker run --rm "local/test:${GIT_SHA}"
echo "Building ${IMAGE}"
docker build --target runtime \
--label "org.opencontainers.image.revision=${GIT_SHA}" \
-t "${IMAGE}" .
docker push "${IMAGE}"
printf 'RELEASE_IMAGE=%s\nRELEASE_SHA=%s\n' "${IMAGE}" "${GIT_SHA}" | tee release.env
运行方式如下：
chmod +x scripts/emergency-release.sh
export IMAGE_REPOSITORY=registry.example.com/team/api
./scripts/emergency-release.sh
正常情况下，GitHub Actions 只需要调用该脚本：
name: build
on:
push:
branches: [main]
jobs:
release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: docker/login-action@v3
with:
registry: registry.example.com
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}
- run: ./scripts/emergency-release.sh
env:
IMAGE_REPOSITORY: registry.example.com/team/api
在 Actions 不可用时，同一个脚本可以由受控运维机或备用 CI 执行。这里的关键并不是手工执行本身，而是保证构建步骤、镜像标签和测试门槛没有因切换通道而改变。
应急路径还需要补齐三项保护：发布人身份验证、生产环境的独立审批，以及不可修改的审计记录。不要为了绕过 CI，把长期有效的云密钥散落到开发者电脑上。
Webhook 中断要靠对账，不只靠重试
接收端的重试队列只能处理“事件已经到达但消费失败”的情况。如果 GitHub 没有发出 webhook，接收端没有任何消息可重试。
可以这样实践：让关键集成同时保存最后处理的提交 SHA，并定期比较远端分支状态。以下脚本适合放进备用调度器；它发现远端 main 已前进时退出码为 2，供后续任务触发补偿处理。
#!/usr/bin/env bash
set -euo pipefail
: "${REPOSITORY:?Set REPOSITORY to a git clone URL}"
STATE_FILE="${STATE_FILE:-./last-processed-sha}"
BRANCH="${BRANCH:-main}"
remote_sha="$(git ls-remote "${REPOSITORY}" "refs/heads/${BRANCH}" | awk '{print $1}')"
processed_sha="$(test -f "${STATE_FILE}" && cat "${STATE_FILE}" || true)"
if [[ -z "${remote_sha}" ]]; then
echo "Cannot resolve remote branch ${BRANCH}" >&2
exit 1
fi
if [[ "${remote_sha}" != "${processed_sha}" ]]; then
echo "Reconciliation required: ${processed_sha:-none} -> ${remote_sha}"
exit 2
fi
echo "No missing update"
这类轮询不是 webhook 的日常替代品，而是恢复后的对账机制。补偿任务必须具备幂等性，否则 webhook 延迟送达后可能造成重复部署、重复评论或重复写入。
采用前检查：恢复目标必须能被演练
团队可以从一条核心服务开始，不必立即建设昂贵的双平台热备。落地时至少确认以下事项：
- 构建和测试是否能脱离 GitHub Actions 在干净环境运行；
- 关键仓库是否存在经过验证的只读镜像或定期备份；
- 容器仓库、包仓库和部署控制面是否也依赖同一供应商；
- webhook 是否有事件去重、断点记录和定期对账；
- AI 审查不可用时，普通代码审查和合并规则是否仍可工作；
- 紧急发布是否保留双人审批、短期凭证和审计日志；
- 团队是否定期演练“GitHub 控制面不可用 8 小时”的场景。
多 CI 平台会增加配置、凭证和维护成本，因此不必追求所有流水线实时双跑。更合理的目标是：核心服务拥有一条测试过的备用路径，能够在明确的恢复时间内构建、验证和发布，而不是在事故发生后临时翻译数百行 Actions YAML。