今年 2 月 9 日,北京时间深夜,全球数以千万计的开发者打开 GitHub,看到了同一个页面。
不是 404,比 404 更让人焦虑——是那个让所有工程师后背发凉的黄色警告条,加上状态页上一排排从绿色变成红色的指示灯。
github.com 挂了。
API 挂了。
GitHub Actions 挂了。
Git 操作挂了——就连 Copilot 也没能幸免。
那一晚,有人的 CI/CD 流水线在最关键的节点停摆,有人的自动化部署卡在了半空中,还有人在等待一个迟迟无法合并的 PR——背后是一个等待上线的功能,等待的是真实用户。
事后 GitHub 发布了事故报告。根本原因,用技术语言说,是「一个负责认证和用户管理的,核心数据库集群过载」。但这几个字背后藏着一条触目惊心的触发链——
两天前,工程团队为了尽快给用户推送一个新模型,把一个「用户设置缓存」的刷新时间从 12 小时改成了 2 小时。就是这一个配置数字的改动。
结果,本来分散在 12 小时内完成的缓存重写,被压缩进了 2 小时,形成了一次密集的「缓存重写风暴」,异步任务队列被瞬间打爆,共享基础设施组件崩溃,连锁反应蔓延到了负责代理 HTTPS Git 操作的服务,最终导致整个平台的连接耗尽。
一个数字,从 12 改到 2。
GitHub,是被自己改的一个配置打穿的。
但如果你只看到这一个配置改动,那你大概错过了这个故事最重要的部分。
01 不是一次意外,是十次意外
2 月 9 日的事故,不是一个孤立事件。
事实上,2026 年的前三个月,GitHub 经历了至少 8 次重大事故。2 月份单月就有 37 次大大小小的故障记录。GitHub 的 CTO Vlad Fedorov 后来在博客里承认,这两个月 GitHub 没能维持它向企业客户承诺的「三个九」——99.9% 可用性。
翻开这两个月的故障档案,你会发现一个奇特的规律:每一次事故,看起来都是不同的原因。
2 月 2 日:Azure 计算提供商出问题,GitHub Actions 停摆近 4 小时,Copilot 编码代理、CodeQL、Dependabot 全部受牵连。
2 月 9 日:缓存重写风暴,认证数据库过载。
3 月 5 日:Redis 集群故障,GitHub Actions 95% 的工作流无法在 5 分钟内启动,平均延迟 30 分钟。
3 月 18 日:Webhook 延迟飙升到正常水平的 32 倍。
每一次看起来都是「意外」,每一次的直接原因都不一样。但 Fedorov 的解释把它们串成了同一个故事。他说,这些事故背后有三个共同的结构性原因:「快速的负载增长、服务之间的紧耦合导致局部故障扩散,以及系统缺乏对异常客户端的流量保护能力。」
用工程师的话说,GitHub 的地基,已经开始在新负载的重压下出现裂缝。
而这个「新负载」,有一个具体的名字。
02 每周 2.75 亿次提交
关键数据
2025 年全年 commit 总量:约 10 亿次
2026 年单周 commit 量:2.75 亿次
按此速度,2026 年全年预计:140 亿次(同比增长 14 倍)
GitHub Actions 计算量:2023 年每周 5 亿分钟 → 2025 年 10 亿 → 2026 年初某周 21 亿分钟
如果你是 GitHub 的基础设施工程师,2025 年和 2026 年的监控仪表盘对比,大概会让你目瞪口呆。
2025 年全年,GitHub 处理了大约 10 亿次代码提交。这个数字本身已经很大了,是 GitHub 平台多年积累的结果。但到了 2026 年,单周的提交量就达到了 2.75 亿次。换算一下——如果按这个速度走完全年,2026 年的总提交量将接近 140 亿次,是 2025 年全年的整整 14 倍。
这不是一条平滑增长的曲线,而是一道陡坡。GitHub 的 Actions 计算量变化更能说明问题:2023 年每周消耗 5 亿分钟,2025 年翻倍到 10 亿,然后在 2026 年初的某一周,直接飙到了 21 亿分钟。
是什么在疯狂提交代码?
不是人类开发者。
GitHub 的数据显示,AI Agent 正在成为这个平台上最活跃的「用户」。Claude Code 单独一个工具,现在贡献了 GitHub 所有公开仓库提交量的 4.5%。每周 260 万次提交,而在 2025 年 9 月底,这个数字还只有 10 万——三个月内增长了 25 倍。
AI Agent 开启的 PR 数量同样在爆炸。2025 年 9 月,AI 生成的 PR 大约是每月 400 万个,到 2026 年 3 月,这个数字跳到了 1700 万——四倍多,半年内。
有一个画面可以帮你理解这意味着什么。
以前,GitHub 的「用户」主要是人类程序员。他们白天工作,晚上睡觉,周末休息,每次提交会思考,会犹豫,手速有上限。系统的负载跟着人类的作息走,有峰谷,可以预测。
现在,越来越多的「用户」是 AI Agent。它们不睡觉,不休息,不犹豫,一个任务可以同时开多个并行的 Agent,每个 Agent 每小时的提交量,轻松超过一个真实工程师一周的工作量。更重要的是,它们不只是在提交代码,还在不断创建新仓库——把仓库当成工作流的「输出产物」,而不是人类的「工作空间」。
GitHub 的基础设施工程师们,面对的已经不是一个流量更大的同类问题,而是一个性质完全不同的问题。
03 Copilot 的钱不够烧了
故障频发只是问题的一面,GitHub 还有另一个更让人头疼的麻烦——算账的时候发现亏了。
Copilot 最初的定价逻辑,建立在一个合理的假设上:用户主要是「辅助补全」式的使用,每次交互是短暂的,计算量可预测。个人版每月 10 美元,商业版每月 19 美元,按座位收费,这个模型在过去几年里运转良好。
然后,Agentic AI 来了。
Agentic 工作流和传统补全是两个物种。标准的代码补全,请求是线性的、可预测的,计算周期短暂。而一个 Agentic 编码 session,可能运行几个小时,同时启动多个并行线程,进行多步推理、自我纠错、跨仓库重构——一个 session 消耗的 token 量,轻松超过一个普通用户一整月的订阅费用。
GitHub 面对的局面是,少数重度 Agentic 用户,正在用几美元的月费消耗相当于几百美元的计算资源。
面对这个局面,GitHub 的反应很直接——先控流,再改价。
今年年初开始,GitHub 对 Copilot 启动了两套并行限流机制:session 时长上限和每周使用量上限,两个维度都按照 token 消耗量乘以模型计算权重来算。与此同时,部分个人 Copilot 套餐暂停了新用户注册。
6 月 1 日,GitHub 完成了更根本的定价改革:Copilot 全面切换按用量计费,用「AI Credits」取代原来的套餐费用,1 个 AI Credit 等于 1 美分,使用量按 token 消耗实时计算。
按座位收费的时代,在 Agentic AI 面前,走到了终点。
这个转变不只是 GitHub 的烦恼。这是整个 AI 工具行业在 2026 年正在经历的一次集体定价危机——当 AI 开始替代人类执行完整的工作流,而不只是「辅助」人类工作时,所有基于「每人每月」的订阅逻辑都会失效。
04 30 倍,不是 10 倍
回到基础设施问题。GitHub 到底准备怎么应对这个「14 倍增长」?
这里有一个细节,能说明问题的严峻程度:
2025 年 12 月下旬,Agentic 工作流突然开始加速。GitHub 的工程师们意识到,10 倍不够。到 2026 年 2 月,也就是那次严重停机之后,GitHub 宣布需要按照今天规模的 30 倍重新设计架构。
不是扩容,是重新设计。
这两个词的区别很大。扩容是把现有的机器变多、把现有的数据库加内存——方向不变,只是规模变大。重新设计意味着,现有的架构假设在 30 倍规模下会系统性失效,必须从底层重新思考服务拆分、数据流、故障隔离的方式。
GitHub 披露的具体方向包括,解耦关键服务以防止级联失败、引入背压机制和流量降级能力、为热点服务部署独立主机、消除单点故障,以及更完善的变更管理——避免「把缓存 TTL 从 12 小时改到 2 小时」这种操作在没有充分压测的情况下直接上线。
值得注意的是,GitHub 并不孤单。
Stripe 已经遇到了 AI Agent 批量创建账户的问题,AWS 正在构建 Agent 专用的身份系统、日志系统和生产控制机制。这些动作不是未雨绸缪,而是监控仪表盘上已经出现了它们不得不解决的信号。
GitHub 只是第一个被打穿的——因为它在 AI 工具链的最核心。
05 代码仓库,正在变成 AI 的排气管
停下来想一想这整件事的性质。
GitHub 是什么?最直观的回答是,它是程序员存代码的地方。但更深一层,它是人类软件协作的基础设施——提交记录是协作的轨迹,PR 是讨论的容器,Issues 是意图的留存,Action 是执行的管道。整套系统,是为人类的工作节奏、思维方式和协作模式设计的。
AI Agent 改变了这一切。
当一个 AI Agent 一天可以提交几百次代码,每一次「提交」背后没有人类的思考和权衡,只有一个任务循环的进度步骤——代码仓库还是「协作的容器」吗?
当 AI 工具自动生成仓库、自动开 PR、自动跑 CI、自动 merge——开发者还是这个流程的主体,还是说他们已经退化成了「审核者」甚至「旁观者」?
GitHub CTO 在描述这次危机时,用了「负载快速增长」这个词。但这个词很可能低估了问题的本质——这不只是量的增长,是使用方式的质变。在旧模型里,GitHub 是「开发者的工具」;在新模型里,GitHub 正在变成「AI 的排气管」,一个自动化工作流的输出管道。
这对 GitHub 意味着什么,其实还没有答案。30 倍扩容能解决流量问题,但解决不了商业模式的再定义,也解决不了「谁是我的真正用户」这个身份问题。
最近有一个颇为意味深长的现象:GitHub 在停机之后开了大量工程博客,非常详细地描述了每一次事故的根本原因,几乎达到了令人意外的透明程度。有人认为这是 GitHub 在主动建立信任,也有人认为这是在以透明度换取开发者社区的耐心——因为接下来的重构期,还会有更多不稳定。
一个平台,在被自己的成功打穿之后,需要把自己拆开重建——而这个过程本身,也是一次能不能撑住的考验。
2 月 9 日那晚,那个等待 PR 合并的工程师,大概最终还是等来了绿灯。但他可能没有意识到,让他等待的那次宕机,不是 GitHub 的一次意外,而是整个软件开发行业进入新时代的一声响动。
本文来自微信公众号 “极客公园”(ID:geekpark),作者:宇航猿
