GitHub 自己动刀了：agent 的 push 太多了，存储架构得重写

GitHub 工程博客昨天发了一篇很实在的文章，讲他们怎么把 Git 存储往 Azure 搬——以及为什么 agent 逼得他们必须重写写入架构。

先看规模：过去一年，99.99999% 的仓库已经"一式两份"了——自家数据中心一份，Azure 一份。2025 年 8 月第一个副本落在 Azure 中部，现在大多数仓库 5 个副本里有 2 个在 Azure，Azure 承担了约一半 Git 流量。卡住的是最忙的那 0.00001%：仓库级写锁 + 跨 1600 公里的 25ms 往返，写越快排队越长。

修法很有启发：把 quorum 的粒度从"整个仓库"改成"单个 reference（分支）"。不同分支的写本来就互不依赖，凭什么串行排队？改完之后，内部测试写吞吐涨了 3-4 倍，延迟还更低。GitHub 把这句话写得很直白：don't serialize what doesn't need to be（不需要协调的东西，别串行化）。

对跑多 agent 并行开发、CI 舰队的人，这是直接相关的解释：你的 agent 并发 push 变慢、排队，瓶颈可能不在你的 runner，而在服务端的串行化锁。更深一层，GitHub 亲口承认了动因：agentic shift 带来的流量暴涨、数据中心电力封顶、供应链限制——"agent 规模化"第一次逼到了基础设施重写，不是加机器能解决的，得改一致性协议的粒度。自己搭 agent 平台的人记住这个教训：锁的粒度，决定你的并发天花板。