一次深夜排障：以为是自己的锅，结果是 GitHub 宕机了

发现问题

事情发生在 3 月 5 号晚上。

我的博客有一条自动化链路：在 Telegram 里发一条消息，内容会自动同步到网站上。这条链路已经稳定运行了两周多，我一直没怎么操心过。但那天晚上我发完消息后，习惯性地刷了一下网页，发现内容没有更新。

一开始我没太在意，以为是缓存延迟，等了几分钟又刷了几次，还是没有。于是打开 GitHub 的 Actions 页面看了一眼——果然，最近的几次 push 之后，部署流程根本没有被触发。

就在两天前，我刚刚调整过一个定时任务的频率，把原来每半小时检查一次改成了一天只在几个固定时段检查。当时觉得是个很小的改动，甚至没怎么仔细看就提交了。

所以第一反应就是：肯定是这次改动搞坏了什么。

我马上打开配置文件，反复对比改动前后的差异，逐行检查有没有不小心动到触发条件。看了好几遍，逻辑上没毛病，改的确实只是定时频率，跟 push 触发完全无关。

但问题就是摆在眼前——push 之后确实不触发了。那不是这次改动的问题，还能是什么呢？

带着"肯定是配置有问题"的执念，我开始往更深的地方挖。

回过头翻了翻更早之前的提交记录，发现两周前为了防止机器人账号的 push 触发重复部署，我加了一条过滤规则。当时这个改动运行得很正常，但现在我开始怀疑是不是这条规则在某种边界情况下误伤了正常的触发。

于是我把这条过滤规则去掉了，又重新整理了一下触发逻辑，让整个部署配置变得更"健壮"一些。改完之后提交，push 上去，满怀期待地等着看 Actions 页面……

还是没触发。

这下我有点慌了。既然 push 不行，那我手动触发总可以吧？

于是我去 Actions 页面点了"Run workflow"按钮。结果页面弹出一行红字：

Failed to queue workflow run. Please try again.

试了好几次，每次都是同样的报错。

这就很反常了。手动触发跟配置文件的触发条件完全无关，它走的是另一条路。如果连手动触发都失败了，那问题可能根本不在我的配置上。

为了进一步确认，我写了一个极其简单的测试流程，里面什么都不做，就打印一行文字。把它提交上去，然后 push 一次。

依然没有触发。

紧接着我又用命令行直接调用 GitHub 的 API，手动发起一次触发请求。这次 API 返回了一个服务器内部错误，HTTP 500。

到这里，事情已经很清楚了：这不是我的配置问题，是 GitHub 那边出了状况。

我去查了 GitHub 的状态页，虽然当时状态页上没有明确标注 Actions 全局故障，但结合手动触发失败、API 返回 500、push 事件明明已经记录了但就是不触发这几条证据，基本可以确定是 GitHub Actions 的调度服务出了问题。

后来也确实看到了一些其他开发者在社交媒体上反映同一时段遇到了类似的问题，进一步印证了这个判断。

整个排障过程大概花了两个多小时。最让人哭笑不得的是，前面大部分时间都花在了反复审视自己的配置上，改了好几轮，越改越复杂。直到最后发现手动触发都不行、API 也返回 500 的时候，才反应过来：问题不在我这边。

最后的结果是，我前面改的那些东西全都没有意义，配置也没有任何实质性的升级。等 GitHub 那边恢复之后，一切就自动正常了。两个多小时的折腾，纯粹是在跟一个不存在的 bug 较劲。

这次经历给我最大的教训是：当问题出现时，不要一上来就假设是自己的错。尤其是当依赖的平台和服务本身也可能出问题的时候，应该尽早建立一条验证链路——先确认问题到底出在哪一层，再针对性地修复，而不是在自己的代码里反复折腾。

当然了，凌晨一点钟排查 bug 的时候，这种理性的思路是很难保持的。下次再遇到类似情况，我希望自己能早一点想起来去试一下手动触发，而不是在配置文件里钻两个小时的牛角尖。