脉搏：AI 负载压垮 GitHub——为何其他供应商没有？

📌 One-Sentence Summary

GitHub 近期出现的严重可靠性问题，包括数据完整性事件和频繁宕机，归因于 AI 智能体带来的意外负载激增，暴露了该公司未能像竞争对手那样为 AI 驱动的规模增长做好准备。

📝 Summary

本文来自《The Pragmatic Engineer》，分析了 GitHub 近期严重的可靠性危机。该平台正常运行时间已降至 86%，并出现了一个影响超过 2000 个拉取请求的数据完整性错误。作者详细阐述了其影响，包括知名开源贡献者 Mitchell Hashimoto 因生产力损失而退出 GitHub。正如 GitHub 首席技术官所解释，核心问题是 AI 智能体驱动的空前负载激增，压垮了平台的基础设施。文章批判性地审视了 GitHub 的应对措施，指出虽然负载在两年内增长了 3.5 倍，但该公司直到 2025 年 10 月才开始规划 10 倍的容量提升，远晚于 Google 等竞争对手。文章将 GitHub 的困境与 Vercel 和 Linear 等其他供应商进行了对比，后者在应对类似的 AI 驱动增长时并未出现类似的故障。分析表明，GitHub 的问题部分是咎由自取，源于技术债务、组织开销以及对 AI 影响规模预判失误的综合作用，使公司陷入了“创新者困境”。

💡 Main Points

1. GitHub 的可靠性灾难性下降，正常运行时间降至 86%，一次数据完整性事件影响了超过 2000 个 PR。 该平台遭遇了多次宕机，包括一个导致提交“丢失”的合并队列错误，以及一次持续 6 小时的 Elasticsearch 宕机，隐藏了 PR 和问题，严重影响了开发者的生产力。
2. 根本原因是来自 AI 智能体的意外且巨大的负载激增，GitHub 未能预见或为此做好准备。 GitHub 首席技术官确认，AI 智能体流量导致两年内负载增长了 3.5 倍。该公司直到 2025 年 10 月（问题变得严重数月后）才开始规划 10 倍的容量提升，现在已将目标修订为 30 倍。
3. Vercel 和 Linear 等其他供应商在应对类似的 AI 驱动增长时并未出现类似的可靠性问题，这表明 GitHub 的问题是咎由自取。 这种对比突显了 GitHub 的困境并非全行业不可避免。该公司 18 年的技术债务、拥有 4000 名员工的组织开销，以及同时进行的向 Azure 的迁移，共同加剧了其无法灵活应对的问题。
4. 这一情况导致一位杰出的开源贡献者 Mitchell Hashimoto 退出 GitHub，称其“不再是进行严肃工作的地方”。 Hashimoto 的公开退出是一次重大的声誉打击，突显出这些宕机不仅是技术问题，更是对专业开发者的信任和生产力危机。

💬 Key Quotes

• 这里不再是进行严肃工作的地方，如果它每天、每小时都把你拒之门外的话。
• 首席运营官费尽心思找一个巨大的分母来让影响看起来很小，这感觉非常不诚实；而不是真诚地道歉，说明这如何辜负了他们向客户做出的全部承诺。
• 一个拉取请求可能涉及 Git 存储、可合并性检查、分支保护、GitHub Actions、搜索、通知、权限、Webhook、API、后台任务、缓存和数据库。在大型规模下，小的低效问题会累积。
• 我们于 2025 年 10 月开始执行将 GitHub 容量提升 10 倍的计划，目标是大幅提高可靠性和故障转移能力。到 2026 年 2 月，我们清楚地认识到，需要为未来设计一个能够承载当前规模 30 倍的架构。

📊 Article Meta

Read Full Article