GitHub近期公布了一份关于8月17日服务中断事件的事后分析报告，此次中断持续近8小时，是GitHub当月发生的第二次重大故障。报告中披露的数据显示，GitHub目前每月处理29亿次代码提交、1.3亿次合并拉取请求以及2400万个新建仓库。而就在今年4月，GitHub在仅14亿次月提交量的情况下就已出现明显的承载压力。
这一增长在很大程度上源于编程智能体的迅速普及以及软件开发方式的深刻变革。
GitHub首席技术官弗拉德·费多罗夫在事后分析报告中指出，此次中断并非由代码变更引发，而是纯粹的扩容问题。"我们的调查发现，中断始于流量触及新峰值之时，美国中部数据中心的一个关键基础设施组件未能随之扩展。由此产生的容量压力在系统间蔓延，导致身份验证失败并波及多项GitHub服务。"
费多罗夫同时披露，GitHub平台58%的负载目前已由Azure承载，较5月份的12%大幅提升；所有Git操作中也有一半转移至Azure处理。今年以来，团队新增了300万个CPU核心及120拍字节的高速存储。然而，GitHub自有数据中心的扩容空间已告罄。"我们在现有数据中心内安装了可用电力所允许的最大硬件量，同时加速向Azure迁移。"
费多罗夫坦承，GitHub在运营层面同样面临挑战："随着变更节奏加快、复杂度提升，我们现有的运营实践未能跟上步伐。我们已将团队和资源重新聚焦于可用性，并在更严格的测试、更安全的发布流程、更好的可观测性以及更有效的告警机制上持续投入。我们取得了一定进展，但这项工作尚未完成。"他还表示，GitHub正在推进关键系统的隔离，并消除系统间的共享依赖，以降低故障发生概率并限制其影响范围。
为避免近期故障的诱因再度出现，GitHub已采取若干具体措施：统一应用重试限制与预算，并调整服务间交互的超时设置，以防止重试风暴和级联负载。
GitHub是开发者生态系统的核心枢纽，其近期的稳定性问题也为竞争对手创造了入局机会。其中包括由GitHub前首席执行官托马斯·多姆克创立的初创公司Entire，该公司押注分布式架构以更好地应对智能体驱动的开发负载；代码编辑器Cursor也通过Origin项目进入这一赛道。
Q&A
Q1：GitHub这次8月17日的大规模中断是什么原因造成的？
A：此次中断并非代码变更所致，而是纯粹的基础设施扩容问题。流量触及新峰值时，GitHub美国中部数据中心的一个关键组件未能及时扩展，由此引发的容量压力在系统间蔓延，导致身份验证失败并波及多项服务，中断持续近8小时。
Q2：GitHub目前的流量规模有多大，为什么增长这么快？
A：GitHub目前每月处理29亿次代码提交、1.3亿次合并拉取请求和2400万个新建仓库。增长的主要驱动力是编程智能体的迅速普及以及软件开发方式的快速演变，今年4月时月提交量还只有14亿次。
Q3：GitHub是如何应对基础设施容量不足的问题的？
A：GitHub正在加速向Azure迁移，目前平台58%的负载已由Azure承载，一半的Git操作也已转移至Azure。今年新增了300万个CPU核心和120拍字节高速存储。自有数据中心已扩容至电力上限，后续将持续推进云迁移，同时隔离关键系统、消除共享依赖，并优化服务间的重试与超时机制。
