8 月 17 日的停电以及未来的工作

8 月 17 日，GitHub 发生了持续 7 小时 47 分钟的宕机。它扰乱了 github.com、身份验证、GitHub Actions、API、拉取请求、问题和 Copilot，影响了世界各地的开发人员和组织。如果您那天尝试发布软件，我们会让您失望。这是继 8 月 6 日行动失败后我们 8 月发生的第二起重大事件。在三月和四月，我分享了正在进行的提高 GitHub 可靠性的工作。我们已经取得了进展，但这些事件清楚地表明我们必须加快这项工作。发生了什么我们的调查发现，当流量达到新的峰值时，服务中断就开始了，而我们美国中部数据中心的一个关键基础设施组件无法随之扩展。由此产生的容量压力会在我们的系统中蔓延，导致身份验证失败并中断多个 GitHub 服务。恢复需要采取多项协调行动。团队重新路由流量，隔离受影响的基础设施，并分阶段恢复服务。大多数 GitHub 服务在当天早些时候恢复，但一些 Copilot 服务需要更长时间。这些服务中的错误触发了客户端重试循环，从而增加了恢复期间的流量。在安全恢复流量之前，我们必须减少这种行为。完整的根本原因分析包括详细的技术时间表。这两次中断都不是由代码或配置更改引起的。这两起事件的核心都是容量故障。我们未能在需求超出其容量之前扩展关键组件。自 4 月份以来，每月提交量已从 14 亿增加到 29 亿。这种增长解释了我们系统面临的压力，但并不能成为这些中断的借口。我们已经做了什么以及下一步做什么 作为我们今年早些时候做出的可靠性承诺的一部分，我们重点关注三个优先事项：增加容量、提高效率和消除架构瓶颈。此后，我们添加了超过 300 万个 CPU 核心、120 PB 的高速存储以及巨大的网络容量。我们在现有数据中心安装了尽可能多的可用电源允许的硬件，同时加快了向 Azure 的迁移。如今，Azure 承担着大约 58% 的 GitHub 平台负载和一半的 Git 操作，高于 5 月份的 12%。这种扩大的足迹也支持了 GitHub Actions 作业运行的增长，如下所示。 Azure 的基础设施和容量也加速了我们扩展最大单一存储库的工作。我们的下一个里程碑是一种架构，该架构可随读取器数量线性扩展读取容量，从而实现无限的读取操作。我们将逐步推出它，从最大的单一仓库开始。规模并不是我们唯一的挑战。随着变革的步伐和复杂性的增加，我们现有的运营实践跟不上。我们将团队和资源转向可用性，并投资于更强大的测试、更安全的部署、更好的可观察性和更有效的警报。我们已经取得了进展，但这项工作尚未完成。此外，我们还隔离关键系统并消除它们之间的共享依赖关系。这项工作旨在减少停电的可能性并限制停电发生时的影响。我们从每次中断中吸取教训，并将新的工作添加到我们的可用性工作流中。 8月6日和8月17日的事件导致了两个直接的变化。首先，我们在服务间交互中应用一致的重试限制、重试预算和可变超时，以防止重试风暴和级联负载。其次，我们正在审查优先级较低的 CPU 和内存警报，以识别在突然的流量高峰期间可能发生故障的组件。我们对高可用性的承诺不仅仅是技术承诺。开发者社区依靠 GitHub 来构建、发布和运营他们的作品。只有您可以信赖我们，这才有可能实现，而 8 月 17 日，您却不能。我们有责任解决这个问题。我们将通过平台的扩展性和可靠性赢得您的信任。作者：Vladimir Fedorov，是 GitHub 的首席技术官，在工程领导和创新方面拥有数十年的经验。 Vlad 是开发人员生产力的热情倡导者，他领导 GitHub 的工程团队以开发人员优先的心态塑造开发人员工具和创新的未来。在加入 GitHub 之前，Vlad 与他人共同创立了 UserClouds，这是一家专门从事数据治理和隐私的初创公司。他在 Facebook（现为 Meta）工作了 12 年，担任高级副总裁，领导隐私、广告和平台领域超过 2,000 人的工程团队。在其职业生涯早期，Vlad 曾在 Microsoft 工作，并在加州理工学院获得了计算机科学学士和硕士学位。他目前是 Codepath.org 的董事会成员，该组织致力于重新规划高等教育，以培养第一代人工智能原生工程师、首席技术官和创始人。弗拉德住在湾区，工作之余喜欢与家人一起在户外和水上度过时光。