8月6日下午,GitHub状态页开始滚动更新,一挂就是五个多小时。到晚上八点半,工程师给出的进展是这样的:webhook投递被限流到只处理约15%,大部分push、pull request事件根本没能触发workflow;排队任务的成功率一度跌到30-40%,慢慢爬回65%。Actions、Pages、Copilot code review、Enterprise Importer迁移功能全部被波及。这不是刷新一下就能解决的小故障——它是这一个月里GitHub第四次同等规模的问题。
故障现场:五个小时,四类功能
用几句话说清这次事故:触发环节,webhook限流到15%,大部分事件没能唤醒workflow;执行环节,排队任务成功率最低30-40%,恢复到65%;连带影响覆盖Copilot code review、Copilot coding agent、Enterprise Importer迁移;收尾环节,部分runner卡在重试已经不存在的任务,GitHub-hosted和self-hosted都在其中。
不是偶然,是节奏
7月23日,8%的Actions运行启动延迟超过10分钟,5%的webhook投递超出SLO。7月25日,Redis维护叠加区域容量问题,峰值时段60%的运行直接失败——和这次30-40%的最低点几乎是同一量级。7月29日,某站点runner管理服务资源不足,API超时、注册失败。8月6日,这次。
四次故障,同一个月,反复卡在触发-排队-执行这条链路上。GitHub Actions过去90天的组件可用性是99.58%,CircleCI同期是99.94%。差距看着不大,但足够说明这不是单次运气问题,是一种节奏。
"保证"这个词,三家公司说的不是一件事
这次故障让不少团队开始想换个CI平台,但先看清一件事:三家公司嘴上的承诺,覆盖的范围完全不同。
GitHub的文档写得很实在:workflow 30分钟内没排上队,或排队任务45分钟内没被hosted runner接手,直接丢弃。没有自动重试,没有兜底。webhook投递失败了,要么客户手动重发,要么自己搭轮询。
GitLab的机制更细:webhook连续失败4次先临时禁用,40次永久禁用,期间保留投递历史和手动重发入口。听着更靠谱,但它给Ultimate客户的99.9%月度SLA,列出的保障范围是Issues、MR、Git操作、容器仓库——CI/CD执行本身有没有被明确覆盖,条款里并不清楚。
CircleCI最干脆,服务条款只承诺"商业合理努力"保持可用,没有量化数字,没有自动补偿。
三家谁都没把"你的workflow一定能跑起来"写成硬承诺。
- 风险.GitHub的90天可用性数字和SLA条款,保证的是响应速度,不是Actions真的能跑起来,这中间的落差很多团队没意识到
换个平台,躲不开的还是GitHub
最容易被忽略的一点是:如果打算把CI迁到CircleCI来避开GitHub的故障,大概率白折腾。
CircleCI的pipeline启动依赖GitHub的API和webhook去感知代码变化——GitHub那边一抽风,CircleCI一样启动不了。7月17日就有过真实案例:CircleCI的登录、checkout、pipeline启动、定时workflow,全部因为上游GitHub API故障连带趴窝。
代码托管和CI执行本来是两层,但只要托管方是GitHub,这两层就共享同一个故障域。换了执行引擎,没换托管方,故障照样能穿透过去。
迁移能换执行引擎,换不掉共享的故障域
能做的,不是等GitHub修好
真正能落地的缓解方式,不是换厂商,是给触发环节加一层自己的持久化:用事件队列先接住webhook再转发,给触发逻辑加幂等校验,workflow卡在排队环节超过阈值就走API轮询或手动触发兜底。GitHub文档里30分钟排队超时、45分钟处理超时这两条硬规则说得很清楚——平台自己的重试机制是有边界的,边界之外的可靠性,得自己兜。
- 建议.把webhook接收和workflow触发拆成两层,自己接一层持久化队列,不要把交付链路的唯一保障寄托在GitHub单点上
这次故障会不会拉低GitHub下一次的90天可用性统计,官方会不会给出根因复盘,值得接着看。但比等复盘更实际的问题是:你的交付链路,是不是也只挂在一根绳上。