8月17日 GitHub 故障复盘与后续工作
8月17日，GitHub 发生了持续 7 小时 47 分钟的故障，影响了 github.com、身份认证、GitHub Actions、API、Pull Request、Issue 以及 Copilot，波及全球的开发者和企业。如果那天你正试图发布软件，是我们没扛住。
这是 8 月我们的第二次重大事件，此前在 8 月 6 日出现过一次 Actions 故障。今年 3 月和 4 月，我曾分享了 GitHub 在可靠性方面正在推进的工作。我们取得了一些进展，但这些事件表明，我们还需要加快节奏。
发生了什么
我们的调查结果显示，故障始于流量达到历史峰值，而我们位于美国中部的数据中心的一个关键基础设施组件未能随之扩容。容量压力蔓延至各个系统，导致认证失败并影响了多项 GitHub 服务。
恢复过程需要多项协调操作。团队重新路由了流量、隔离了受影响的设施，并逐步恢复了服务。大部分 GitHub 服务在当天早些时候就已恢复，但部分 Copilot 服务的恢复时间更长。这些服务中的错误触发了客户端的重试循环，导致恢复期间流量进一步攀升，我们不得不先抑制这一行为，才能安全地恢复流量。完整的 根因分析（RCA）中包含了详细的技术时间线。
这两起故障均非代码或配置变更导致，核心都是容量不足——在需求超过组件承载能力之前，我们没有完成扩容。4 月以来，每月提交量已从 14 亿增长至 29 亿。这一增长解释了系统所承受的压力，但不能成为故障的借口。
已完成的工作与下一步计划
作为今年早些时候可靠性承诺的一部分，我们聚焦于三大方向：扩容、提升效率和消除架构瓶颈。截至目前，我们已新增超过 300 万 CPU 核心、120 PB 高速存储以及大量网络容量。在加速向 Azure 迁移的同时，我们在现有数据中心里尽可能多地部署了硬件。
目前，Azure 承载了 GitHub 平台约 58% 的负载和全部 Git 操作的一半，而五月份这一数字仅为平台负载的 12%。这一扩展也支撑了下方 GitHub Actions 作业运行量的增长。
Azure 的基础设施和容量也加速了我们应对超大单体仓库的扩展工作。下一个里程碑是实现一个能随读者数量线性扩展读容量的架构，从而实现无限读操作。该架构将逐步推出，先从最大的单体仓库开始。
8月17日故障及后续工作
规模并非我们面临的唯一挑战。随着变更的速度和复杂度不断上升，现有的运营实践已跟不上节奏。我们将团队和资源重新投入可用性建设，加大了对更强测试、更安全发布、更好可观测性以及更有效告警的投入。目前已有进展，但这项工作远未完成。
同时，我们也在隔离关键系统，并消除系统间的共享依赖，以降低故障发生的概率，并在故障发生时限制其影响范围。
我们从不间断地从每一次故障中学习，并将新工作纳入可用性改进轨道。8月6日和8月17日的两次事件推动了两项立即落地的改进：第一，在服务间交互中统一应用重试上限、重试预算和变量超时机制，防止重试风暴和级联负载；第二，审查低优先级的 CPU 和内存告警，识别在突发流量高峰下可能出现问题的组件。
我们对高可用的承诺不止于一句技术保证。开发者社区依赖 GitHub 来构建、发布和运营他们的工作，而这只有在你们能够信任我们时才成为可能——而8月17日，你们无法信任我们。这是我们的责任，我们将通过平台的扩展能力和可靠性来赢回你们的信任。