8月17日，GitHub 遭遇了一次持续7小时47分钟的服务中断。此次中断影响了 github.com、身份验证、GitHub Actions、API、拉取请求、issue 和 Copilot，波及世界各地的开发者和组织。如果你当天尝试发布软件，我们让你半途而废了。
这是继8月6日 Actions 故障之后，我们在8月发生的第二起重大事件。我曾在3月和4月分享我们为提升 GitHub 可靠性所开展的工作。我们取得了进展，但这些事件清楚地表明，我们必须加快这项工作的推进速度。
发生了什么
我们的调查显示，此次中断始于流量达到新高，而位于美国中部的数据中心中的一个关键基础设施组件无法相应扩展以应对这些流量。由此产生的容量压力蔓延至我们的系统，导致身份验证错误，并使多项 GitHub 服务受到影响。
恢复服务需要采取多项协调一致的措施。团队重新路由了流量，隔离了受影响的基础设施，并分阶段恢复了服务。大多数 GitHub 服务在当天早些时候就已恢复，但部分 Copilot 服务花费了更长时间。这些服务中的错误触发了客户端重试循环，在恢复期间进一步增加了流量。我们必须先缓解这一行为，才能安全地恢复流量。全面的根本原因分析包括一份详细的技术时间线。
两次中断均不是由代码或配置变更引起的。两起事件的根本原因都是容量不足。在需求超过容量之前，我们未能扩展关键组件。自4月以来，每月 commit 数量已从1.4十亿增加到2.9十亿。这一增长说明了我们的系统所承受的压力，但并不能为这些中断开脱。
我们采取了哪些措施，接下来还要做什么
作为今年年初作出的可靠性承诺的一部分，我们重点关注了三个优先事项：增加容量、提升效率，以及消除架构瓶颈。此后，我们新增了超过3百万个 CPU 核心、120拍字节高速存储和大量网络容量。在现有数据中心中，我们在现有电力容量允许的范围内安装硬件，同时加快了向 Azure 的迁移。
如今，Azure 承担着 GitHub 平台负载约58%以及全部 Git 操作的一半；这一比例高于5月平台负载的12%。不断扩大的基础设施也支撑了下方所示的 GitHub Actions 作业运行次数增长。
Azure 的基础设施和容量也加快了我们扩展最大型 monorepo 的工作。我们的下一个里程碑是采用一种架构，使读取容量能够随读取方数量线性扩展，并实现不受限制的读取操作。
我们将分阶段启用这项功能，并从最大型 monorepo 开始。
规模并不是我们面临的唯一挑战。随着变化的速度和复杂性不断增加，我们现有的运营实践未能跟上。我们将团队和资源转向提升可用性，并投入于更强大的测试、更安全的发布流程、更完善的可观测性以及更有效的告警机制。我们已经取得了进展，但这项工作尚未完成。
此外，我们正在隔离关键系统，并移除它们之间的共同依赖。这项工作旨在降低发生中断的可能性，并在中断发生时限制其影响。
我们从每次中断中吸取教训，并将新的工作项加入可用性工作清单。8月6日和8月17日发生的事件促成了两项紧急变更。
首先，为避免重试风暴和级联负载，我们正在服务间交互中实施一致的重试限制、重试预算和可变的超时时长。其次，我们正在重新审查低优先级 CPU 和内存告警，以识别在流量突然增加期间可能发生故障的组件。
我们对高可用性的承诺不仅是一项技术承诺。