关于GitHub Actions 8月26日事件的简要思考

上周，GitHub Actions 又发生了一起事件.正如GitHub公开报道的典型内容，事件发生后不久就发布了，但细节也不多。不过我们来看看能从中获得什么信息。

数据库饱和

我首先注意到的是，这次事件再次是与系统饱和相关的故障模式。具体来说，是因为写入流量导致数据库过饱和。

这种影响是由服务处理触发器主要用于Actions工作流的数据库写入次数饱和引起的。

正如我在我上一篇博客文章与数据库相关的饱和问题尤其严重，因为它们很难恢复。

有多位贡献者，但细节不多

报道提到了七个导致事件的因素。

• 峰值日负载不断增加（这增加了对数据库的写入量）
• GitHub事件处理基础设施的上游问题（？），进一步增加了负载
• 从主节点切换到副本并未实现完全恢复（？）
• 现有节气门设置得高出约10%，因此提供不足的过载保护
• 有些作业在恢复后仍停留在队列/等待状态（？）
• 另一个问题让一些工作在恢复后处于等待状态
• 有个bug导致有些运行显示为队列，尽管它们已经失败了

我用（？）注释了贡献者，觉得报告里几乎没有提供任何细节。提到上游问题引用另一个GitHub事件但另一个事件页面上完全没有任何细节。

页面上写着“一旦有详细的根本原因分析将立即发布”，所以也许我们会在接下来几天内获得更多关于这个问题的细节。

不过我最想知道的是数据库故障转移到底发生了什么。我们在介绍中只看到了这一句话：

初选失败，但系统未能完全恢复。

这里发生了什么???新晋升的主选是否像上一个一样被压垮了？还是出了别的问题？我希望他们能更详细地讲解具体的失败模式。

慢慢地将一个过载的数据库恢复正常

好消息是，报告中确实有一些关于他们如何缓解的细节。他们限制了数据库流量，直到数据恢复，然后又慢慢恢复流量，避免再次出现故障。

以下是实际内容：

15：45 UTC，限速结合服务重启恢复了服务核心健康。这些降速在15：54至17：22之间逐步提升，以恢复动作运行的全部 webhook 处理。这次加速故意放慢，以确保我们不会再次超负荷，因为我们原本的限速已被确认设置错误。webhook 事件队列于 17：40 UTC 完全烧毁。

我想说两点。首先，这种恢复方法是你未来某天在数据库超载时必须采取的（相信我，这确实会发生）。如果你准备好了，你将能使用一个油门旋钮，响应者可以手动控制，从而切断流量然后增加流量。

这不是你想在事件发生时自己构建的东西。

第二点需要注意的是，限速意味着你故意切断用户对数据库的访问，以便重新打开数据库。这意味着你会暂时增加用户的痛苦，以便恢复系统。

这很糟糕，但这是你在事件发生时必须做出的决定：你必须有意识地让系统正常运作更糟从用户的角度来看，以便让它恢复到健康状态。

如果你能做到类似QoS的限速功能，可以选择性地屏蔽不那么重要的请求，那么你可能能减少痛苦。但这同样是你需要提前内置到系统里的。

讽刺的是：事故发生时，修复已经在进行中

文章中的这句话让我心碎了一点（重点是我加的）：

为提升Actions部分整体可扩展性，进行了若干调整已经完成并部署到生产阶段.这些变更将在未来24小时内完成。

他们本来就在努力减少类似事件发生的可能性，但在推进改进之前就被打击了。这真的只是运气不好。

又一次GitHub事件，又一次限额出现

最后，随着持续增长，GitHub不断突破一个又一个极限。这样的系统里有太多不同的限制。我不会惊讶自己很快又要读到另一起与饱和相关的GitHub事件。