GitHub计划扩容30倍，应对AI代码提交激增

随着AI驱动的开发工作流将全球最大代码托管平台逼近极限，GitHub正面临日益严峻的基础设施压力。在4月27日发布的一篇博客文章中，GitHub首席技术官弗拉基米尔·费多罗夫承认了近期发生的两次服务故障，并阐述了公司的扩容计划——据估算，平台容量需要扩充至现有规模的30倍。GitHub

承压中的平台

挑战的规模令人震惊。GitHub（微软旗下）目前每周处理2.75亿次代码提交，按此速度推算，2026年的提交总量约将达到140亿次——相比2025年全年记录的10亿次提交，增长了整整14倍。这一数据由GitHub首席运营官Kyle Daigle披露。GitHub Actions的每周计算分钟数也从2025年的10亿翻倍，在今年某单周内达到了21亿分钟。据The Information报道，AI智能体发起的Pull Request数量从2025年9月的约400万激增至2026年3月的逾1700万。Quasa

该公司于2025年10月启动了将算力扩容十倍的计划，但到2026年2月便发现，即便是这一目标也远远不够。Fedorov在内部写道："主要驱动力在于软件开发方式的深刻变革。"他指出，自主式开发工作流（agentic development workflows）自2025年12月下旬起开始急剧提速。GitHub

故障频发

这些成长中的阵痛已有目共睹。仅在2026年2月和3月，GitHub就遭遇了八次重大故障，未能达到其向企业客户承诺的99.9%可用性标准。最近的几起事故发生在4月23日——一次合并队列回归影响了658个代码仓库和2,092个拉取请求；以及4月27日——一个过载的Elasticsearch集群（很可能由僵尸网络攻击触发）导致平台上依赖搜索功能的多项服务中断。4月29日又报告了一次额外的服务降级事件。

曾在Netflix和AWS任职的可靠性工程师Lorin Hochstein对2月份的事故进行了分析，并指出了一个核心弱点：GitHub的事故响应人员缺乏精细化的流量控制手段，无法在危机时期有选择性地卸载负载，只能在"拒绝所有请求"和"眼睁睁看着基础设施崩溃"之间二选一。Byte Iota

迈向 AI 时代的规模化之路

GitHub 概述了多管齐下的应对方案：将 Webhook 从 MySQL 迁移出去、重新设计会话缓存、用 Go 而非 Ruby 重写身份验证流程，并向超越现有 Azure 架构的多云部署迈进。与此同时，公司还在将 Git 和 Actions 等核心服务与其他工作负载隔离，并针对每日需处理数千个拉取请求的代码仓库投入资源优化合并队列。GitHub

另外，GitHub 于 4 月 27 日宣布，将从 6 月 1 日起把 Copilot 的计费模式由按请求计费改为按用量计费，并坦承随着推理成本持续攀升，现行模式"已难以为继"。这一定价调整揭示出，AI 驱动的使用量增长不仅正在重塑 GitHub 的基础设施，也在深刻改变其商业模式。Fedorov 写道："我们的优先级很明确：可用性第一，容量第二，新功能第三。"