关于8月17日故障的更新及我们为提高可靠性所采取的措施。2026年8月20日 | 4分钟分享：8月17日，GitHub经历了一次持续7小时47分钟的故障。这次故障影响了github.com、认证、GitHub Actions、API、拉取请求、问题和Copilot，影响了全球的开发者和组织。如果那天你在尝试发布软件，我们让你失望了。这是我们在8月发生的第二个重大事件，此前在8月6日发生了一个Actions故障。今年3月和4月，我分享了我们正在进行的提高GitHub可靠性的工作。我们已经取得了一些进展，但这些事件表明我们必须加快这一工作。发生了什么我们的调查发现，当流量达到新峰值时，位于美国中部的数据中心的一个关键基础设施组件未能随之扩展，从而引发了故障。由此产生的容量压力在我们的系统中传播，导致认证失败并中断多个GitHub服务。恢复需要几项协调的行动。团队重新路由流量，隔离受影响的基础设施，并分阶段恢复服务。大多数GitHub服务在当天早些时候恢复，但一些Copilot服务花了更长时间。那些服务中的错误触发了客户端重试循环，增加了恢复期间的流量。在我们安全恢复流量之前，必须缓解这种行为。完整的根本原因分析包括详尽的技术时间轴。故障既不是由于代码或配置更改引起的，两个事件都是容量失败本质上。我们未能在需求超过其容量之前扩展关键组件。自4月以来，每月的提交量从14亿增长到29亿。这种增长解释了我们系统上的压力，但不能为这些故障辩护。我们已经做了什么和接下来会做什么作为我们今年早些时候承诺的可靠性承诺的一部分，我们关注三个优先事项：增加容量、提高效率和消除架构瓶颈。我们已经增加了超过300万个CPU核心、120PB的高速存储和大量的网络容量。在我们现有数据中心安装了尽可能多的硬件，同时加速了我们向Azure的迁移。目前，Azure大约处理了58%的GitHub平台负载和一半的所有Git操作，较5月份的12%有所增长。这种扩展的足迹也支持了下面展示的GitHub Actions作业运行的增长。Azure的基础设施和容量还加速了我们扩展最大的单体代码库的工作。我们的下一个里程碑是一个能够线性扩展读取容量的架构，能够实现无限的读取操作。我们将逐步推出，首先从最大的单体代码库开始。规模并不是我们唯一的挑战。随着变化的速度和复杂性增加，我们现有的操作实践没有跟上。我们已将团队和资源重新定向至可用性方面，并在更强的测试，更安全的发布，更好的可观察性和更有效的警报方面进行了投资。我们已经取得了一些进展，但这项工作仍未完成。此外，我们还在隔离关键系统并消除它们之间的共享依赖关系。这项工作旨在减少故障的可能性，并在故障发生时限制其影响。我们会从每次故障中学习，并在我们的可用性工作流程中增加新工作。8月6日和8月17日的事件导致了两项即时变化。首先，我们在服务间交互中应用一致的重试限制、重试预算和可变超时，以防止重试风暴和级联负载。其次，我们正在审查较低优先级的CPU和内存警报，以识别在突发流量高峰期间可能发生故障的组件。我们对高可用性的承诺不仅仅是一项技术承诺。开发者社区依赖GitHub来构建、发布和运营他们的工作。这只有在您能够依赖我们时才有可能，而在8月17日，您无法做到。这是我们的责任去修复这一点。我们将通过平台的扩展和可靠性赢得您的信任。本文由弗拉基米尔·费多罗夫撰写，他是GitHub的首席技术官，拥有几十年的工程领导和创新经验。作为开发者生产力的热情倡导者，弗拉基米尔正在领导GitHub的工程团队，以开发者优先的思维塑造开发者工具和创新的未来。在加入GitHub之前，弗拉基米尔共同创办了UserClouds，这是一家专注于数据治理和隐私的初创公司。他在Facebook（现Meta）工作了12年，担任高级副总裁，领导着超过2000人的工程团队，专注于隐私、广告和平台。在他职业生涯的早期，弗拉基米尔曾在微软工作，并在加州理工学院获得了计算机科学的学士和硕士学位。他目前在Codepath.org的董事会任职，该组织致力于重新编程高等教育，以创造第一代原生于人工智能的工程师、首席技术官和...