GitHub CTO 刚发文承诺「用稳定性赢回信任」，不到六天，系统又崩了

GitHub CTO 刚发文承诺「用稳定性赢回信任」，不到六天，系统又崩了。 8 月 26 日，GitHub Actions 核心数据库写饱和，全球构建停摆整整三小时。 运维团队在告警亮起的第一时间，把流量切到了备用从库。 官方状态页随后更新了一句极具技术自嘲的定论： 切换到从库未能缓解问题。 备用节点只撑了几秒，就和主库一样瞬间瘫痪。 在互联网跑了三十年的主从容灾架构，为什么在这一天彻底失效了？ 因为这套架构的设计假设，从一开始就被颠覆了。 传统的主从备份，防的是硬件损坏。 某台服务器断电、主板烧毁、网线被拔，切到另一台完好的备用机，系统一秒复活。 这个机制成立的前提，是流量在正常范围内，崩掉的只是某台物理机器。 但这一次，没有任何机器损坏。 打垮主库的，是纯粹的并发写饱和。 推高这波洪水的，不是人类程序员。 人类工程师写代码有生理延迟，改一行、测一遍、喝口咖啡，再点一次提交。 把 GitHub 压到窒息的，是全天候自主运行的 AI 编程智能体。 智能体写代码不需要休息。 它们在死循环里以毫秒级速度自动生成代码、自动提 PR、自动触发 CI/CD 构建、报错后再自动修改。 GitHub 平台的每月代码提交量，从 4 月的 14 亿次，四个月内暴涨到 8 月的 29 亿次。 当千万个智能体在同一秒把巨量写事件塞进 Vitess 数据库管道时，主库被当场挤爆。 这时候做主从切换，等于把一艘被百吨洪水压沉的船，货物原封不动倒给另一艘载重十吨的备用船。 备用船不仅要承受原本就超载的洪水，还要接住切换瞬间积压的重试风暴。 它除了跟着一起沉，没有第二种可能。 过去十五年，整个软件工业的高可用架构，都是围绕「人类工程师的工作节奏」搭建的。 主从复制、读写分离、节点冗余、指数退避。 这些经验全部建立在一个默认事实上：人类制造代码的速度是有上限的。 具有讽刺意味的是，微软和 GitHub 是全世界最激进推广 AI 编程的推手。 他们把生产代码的速度推高了十倍。 而这台以 29 亿次提交疯狂运转的机器，第一个冲垮的，就是他们自己的容灾底线。 硬件损坏可以靠备用机顶上。 但当洪水来自吞吐量本身，世界上没有任何一台备用机能救你。