周一那场长达七小时的当机,GitHub自己给出的说法很直接:不是程序出错,也不是设置改坏了,而是流量冲上了新高点,美国中部数据中心里一个关键基础设施组件,没能跟上这波成长速度。
数字才是这次故障真正的重点。GitHub表示,自四月以来,平台每月的commit数量从14亿次成长到29亿次,四个月内几乎翻了一倍。官方在声明中写道:「这样的成长解释了系统承受的压力,但无法为这次的中断开脱。」换句话说,GitHub清楚知道问题出在自家基础设施跟不上用户行为的变化速度,而不是把责任推给流量本身。
针对这次暴露出的弱点,GitHub在状态报告中列出的修复方向,集中在同时并发活动的处理机制上。团队正在重新查看服务器的CPU与内存警示设置,找出高流量期间可能失效的组件;同时导入一致的重试次数上限、重试预算,以及跨服务交互间的可变逾时设置,目的是避免「重试风暴」引发连锁式的系统重载。
至于这波commit成长从何而来,GitHub的说明仅止于数字本身,并未进一步指出成因。这段时间点恰好与Anthropic、OpenAI等公司持续扩充AI辅助编码工具的时间重叠,但这只是时间上的巧合观察,GitHub官方并未将两者直接画上等号。作为多数专业与业余开发者存放代码的预设平台,GitHub接下来要面对的,是如何让基础设施的扩充速度,追上这种成长曲线。
