GitHub披露，8月17日影响其平台、持续7小时47分钟的中断，是由于其位于美国中部地区的数据中心内，一个关键基础设施组件在流量达到创纪录水平时无法扩容。由此产生的容量压力扩散到多个系统，导致github.com、身份验证、GitHub Actions、API、合并请求和议题，以及Copilot均受到影响；此次中断的影响还波及全球各地的开发者和机构。
这是GitHub在8月遭遇的第二起重大事件，此前Actions曾于8月6日发生故障。该公司表示，调查未发现两起事件与代码或配置变更有关；两起事件的核心都是容量不足，即在需求超出关键组件承载能力之前，相关组件未能及时扩容。GitHub称，每月提交次数已从4月的14亿次增至此后的29亿次，但公司承认，使用量增长并不能免除其防止中断的责任。
服务是如何恢复的？
恢复过程需要重新引导流量、隔离受影响的基础设施，并分阶段恢复服务。GitHub的大多数服务在当天恢复运行，但部分Copilot服务耗时更长。这些服务的错误导致客户端出现重试循环，在恢复期间增加了流量，因此团队不得不限制这种行为，之后才安全地重新引导流量。
GitHub表示，完整的根因分析报告包含详细的技术时间线；与此同时，公司继续落实此前宣布的改善可用性和可靠性的承诺。
实际将发生哪些变化？
GitHub的计划重点在于增加容量、提高效率并消除架构瓶颈。该公司宣布已增加超过300万颗CPU核心和120PB高速存储，同时增加网络能力。公司还在现有数据中心可用的电力范围内尽可能安装了更多硬件，并同步加快向Azure的迁移。
目前，Azure承载GitHub平台约58%的负载和一半的Git操作，相比之下，5月份Azure承载的平台负载占比为12%。这一扩展也帮助支持了GitHub Actions任务执行量的增长。公司正在开发一种新的架构，使大型仓库的读取能力能够随读取者数量线性扩展，理论上可实现无限的读取操作；该架构将首先逐步部署到最大的单体仓库中。
缩小故障范围并防止风暴
GitHub认为，仅靠扩容并不足够；公司已为可用性投入更多团队和资源，并投资于更强的测试、更安全的发布流程、更完善的监控以及更有效的告警。公司还在隔离关键系统，并移除它们之间的共享依赖，以降低发生中断的可能性，并在中断发生时缩小其影响。
基于8月6日和17日的两起事件，公司将实施统一的重试限制和重试预算，并在服务之间的通信中采用可变超时，以防止重试风暴和级联负载。公司还在审查低优先级的CPU和内存告警，以发现可能在流量突然上升期间发生故障的组件。对于依赖GitHub构建、交付和运行软件的开发者及机构而言，这些措施具有直接意义，因为平台的恢复不仅取决于恢复服务，还取决于防止故障重演，并在故障发生时限制其范围。