GitHub 10月发生8起服务降级事故，并扩大Azure容量

10 月，我们经历了八起导致 GitHub 服务性能下降的事件。

15 分钟

分享：

我们继续每月分享 GitHub 可用性和可靠性相关工作的情况。

10 月的简要情况是：我们新增了大量可独立扩展的 Azure 容量，并消除了若干可能使故障升级的途径。然而，写入故障、数据迁移期间的监控缺口，以及一次区域网络中断，都进一步说明：容量增长必须与更安全的运维、更强的隔离和经过验证的区域恢复能力相配套。

截至 11 月 9 日，151 个生产服务中有 140 个、50 个 MySQL 主库中有 32 个运行在 Azure Central US。Azure 承载了已迁移服务 63% 的读取、单体应用 66% 的读取以及 Git 读取的 52%。我们还完成了全部九个 Central US Kubernetes 集群的计算扩容，容量增加了一倍以上。

这些容量已经在承载真实的增长。自 3 月以来，已迁移服务的流量增长了 82%，Central US 吸收了超出我们现有数据中心此前所承载的最高周平均负载之外的增量。这使 GitHub 有了更多增长空间，而不必把原有环境推到其既往运行范围之外。

我们还做了若干有针对性的可靠性改进。Actions 的改动为关键的 Azure 控制平面请求增加了容量。另一项 NAT 网关缓解措施将使用量降低了 85%；变更期间有四个生产作业失败，而如果没有这项缓解措施，预计约有 800 个作业会失败。连接数限制和其他客户端改进现在也降低了依赖中断演变为更大范围重连风暴的可能性。

我们也消除了集中的数据库负载来源。一个每天处理超过 2.5 亿次请求的高流量 GitHub Actions 端点迁移到了更高效的服务路径，使数据库峰值读取降低了 85%。在搜索仓库主题前要求至少输入三个字符，使这类模式的慢查询或被终止查询减少了约 98%。

可靠性仍未达到应有水平。10 月 7 日的写入故障暴露了数据库编排与生产路由之间不安全的交互。10 月 29 日的 Azure 网络中断影响了 Central US 全部三个可用区以及至少 34,128 名已登录用户。以下是这些事件及其他事件的更多细节。

East US 3 的建设比计划落后约一周。下一阶段将从 12 月第一周首次经过验证的流量爬坡开始，同时我们将继续加固迁移安全性、依赖隔离和区域恢复能力。

原则始终不变：先可用性，再容量，最后功能。

持续时间：约 3 小时 45 分钟。

客户可能看到 GitHub 托管的 runner 上的 GitHub Actions 作业排队时间远超平常，部分工作流运行未能启动。在持续约 90 分钟的最严重时段，GitHub 托管 runner 上的大多数作业在五分钟内没有启动。随着我们故障转移到健康区域并增加容量，影响有所缓解。自托管 runner 未受影响。使用 actions 构建的 GitHub Pages 站点更新缓慢，但现有站点仍正常提供服务。部分客户还在仓库列表、许可和账单页面以及部分 Copilot 功能中看到错误。

Actions 作业持续排队或无法启动，是因为向 GitHub 托管 runner 分配作业的服务无法可靠工作。我们云提供商侧的部分网络故障中断了我们的某个数据中心区域与该服务所依赖的云托管数据库之间的部分连接。该服务没有快速失败，而是等待这些调用超时。等待中的调用不断堆积，直到服务内存耗尽并重启。

随后作业转移到健康区域中的同一服务，而该服务没有足够容量应对额外需求，也开始失败。与此同时，数分钟未收到作业的 runner 关闭，且替换缓慢，因此可用于领取作业的 runner 变少。

我们如何降低此类事件发生的可能性或影响？

持续时间：github.com 上约 6 分钟的失败或缓慢请求，随后约 3 小时 30 分钟期间企业迁移暂停。

客户可能在登录、操作仓库和拉取请求、调用 API 或使用 GitHub Codespaces 时看到服务器错误或响应缓慢。稍后重试本会成功，延迟的 webhook 投递也在不久后补上。峰值时，约 1.3% 的请求失败或超时，约 6.4K 个组织至少出现一次失败或缓慢请求。

使用 GitHub Enterprise Importer 的客户迁移被暂停，修复部署后恢复。

迁移活动的激增导致 GitHub Enterprise Importer 向共享数据库发送了一大批超大查询。这些查询耗时远超平常，加上正常流量，耗尽了数据库所有可用连接，使依赖同一数据库的其他 github.com 功能无法完成请求。

数据库过载时，导入器没有降低其负载。导入器完成排队查询、数据库连接释放后，影响在几分钟内结束。

为防止再次发生，我们暂停了迁移，直到部署了将这些查询分批执行的缓解措施。

我们如何降低此类事件发生的可能性或影响？

持续时间：两次独立的写入故障分别持续约 10 分钟和 9 分钟，合计约 19 分钟。第二次是第一次的复发，原因相同。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）