📰 概要

GitHub 正在经历一场来自自身的压力测试。

2026年4月29日，GitHub 官方披露：平台正在重建底层基础设施，以应对 AI 编程热潮带来的 30 倍增长。

这不是夸张。2025年10月，GitHub 计划扩容至 10 倍；到2026年2月，目标已调整为 30 倍。

增长太猛，系统撑不住了。

---

🔍 解读

GitHub 的问题本质是：AI 编程工具把开发者的生产力放大了，但基础设施没有跟上。

代码仓库创建、PR 活跃度、接口调用、自动化流程——所有指标都在暴增。

一个典型的例子：Ghostty 编辑器的开发者米切尔·桥本公开宣布，因为平台频繁故障，决定将项目迁移到其他平台。

这是真实流失，不是小众案例。

GitHub 目前的应对优先级是：先保可用性，再扩容量，最后才是新功能。

具体措施包括：部分算力迁移至 Azure 实现弹性扩容，Git 和 Actions 核心服务与业务负载物理隔离，推进多云架构。

---

💎 深挖

GitHub 在2026年4月发生的两次故障值得细看。

4月23日，合并队列功能回退，影响了 658 个代码仓库、2092 个合并请求。

4月27日，Elasticsearch 搜索子系统独立故障，依赖搜索的页面无法展示结果。

这两起事件的共同点：都不是灾难性的数据丢失，而是"能用但不好用"的慢性衰退。

对你来说，这意味着：PR 可能卡在队列里，代码搜索可能搜不到东西，Actions 可能莫名其妙超时。

GitHub 的选择是大规模重构，而不是缝缝补补。

背后的逻辑是：AI 驱动的开发模式不是一阵风，它会持续增长。平台必须在架构层面做好准备。

对微软来说，Azure 的弹性扩容能力成了关键棋子。把非核心负载甩到 Azure，GitHub 自己的集群只保核心服务的稳定性。

这个思路对其他 PaaS 平台也有参考价值。

什么情况不适合关注这个事件？ 如果你的开发工作不依赖 GitHub，这个事件对你的直接影响有限。 但如果你是重度 GitHub 用户，建议关注平台稳定性动态，因为它可能影响你的 CI/CD 流程。