导读：GitHub的可靠性问题正导致用户大量流失。

本文要点：

• GitHub 的正常运行时间大幅下降
• 快速扩展的智能体人工智能工作流程使平台不堪重负
• GitHub 的管理层专注于修复，已经从不惜一切代价追求增长转变为以可用性为先，但耐心正在被消耗。

2024年，GitHub记录了119起服务事件，其中26起为重大事件。平均解决时间约为106分钟。虽然令人沮丧，但尚可控制。 

随后，在 2025 年 5 月至 2026 年 4 月期间，事件监控服务IncidentHub 追踪到 GitHub 上发生了 257 起独立事件，其中 48 起被归类为重大故障。这相当于平均每周发生一起重大故障，而 2 月份发生的 37 起事件使其成为有记录以来故障最严重的月份。GitHub 的 CI/CD 系统 Actions 是受影响最大的服务，在同一 12 个月期间发生了 57 起故障。Actions 的故障可能会导致整个工程工作流程停滞。

生产服务的行业标准是 99.9%。GitHub 的官方状态页面显示正常运行时间为 99.79%，但Marek Šuppa构建的非官方状态跟踪器显示，GitHub 在过去 90 天的测量正常运行时间仅为 84.88%。  

“这个非官方状态追踪器的目标是从GitHub自身的状态报告中提取所有服务的数据，并按服务以及总体进行汇总，” Šuppa告诉我。“区别在于，我们并不真正了解GitHub上那些平均数据的具体构成——因此我才搭建了这个小网站，直接从源报告重新计算这些数据。”

“出埃及记”

这些可靠性问题已经引发了一波知名用户的明显流失。

2025年12月，Zig编程语言项目迁移到了非营利性替代方案Codeberg，原因不仅在于其存在漏洞，还在于其维护者所称的“腐朽”的工程文化。他们指出GitHub Actions中存在一个严重漏洞，导致构建服务器无限期地挂起。该漏洞于2025年4月提交报告，但几个月后才得到修复。 

上个月， GitHub 的早期用户、Vagrant 和 Terraform 背后的公司 HashiCorp 的联合创始人Mitchell Hashimoto写道，过去一个月他一直在写日记，记录 GitHub 服务中断影响他工作的每一天。几乎每天都有 X帖子。在他写这篇文章的那天，由于 GitHub Actions 服务中断，他有整整两个小时无法进行任何 pull request 审查。

“如果这里每天都要占用你几个小时的时间，那就不再适合认真工作了，”他写道。他宣布，他拥有超过52000颗GitHub星标的终端模拟器项目Ghostty将离开该平台。“我想发布软件，但它却不让我发布软件。我希望它能做得更好，”他如此写道。

GitHub 团队的反应非常迅速。

公司首席运营官在 X 上回复 Hashimoto时表示道：“我很抱歉。团队将继续努力，让 GitHub 成为一个可以用实际证据而非空谈来证明其价值的地方。” 

在2026年4月下旬针对两起严重事件发表的博文中，GitHub首席技术官Vlad Fedorov直言不讳地指出了核心问题：该平台最初的设计规模无法应对如今的挑战。“我们于2025年10月启动了将GitHub容量提升10倍的计划，目标是大幅提升可靠性和故障转移能力，”Fedorov如此写道，“但到了2026年2月，我们意识到，未来的规模需要达到现在的30倍。”

直接原因是人工智能辅助开发带来的代码量爆炸式增长。 “主要驱动力是软件构建方式的快速变革。自2025年12月下半月以来，智能开发工作流程急剧加速。几乎从所有指标来看，发展方向已经很明确：代码库创建、拉取请求活动、API使用、自动化以及大型代码库工作负载都在快速增长。”

如果我们接受Fedorov的观点，即问题在于人工智能带来的快速扩张，那么其中的讽刺意味就很难忽视了。GitHub Copilot 于 2021 年 6 月以技术预览版的形式发布，并成为首个被专业开发者广泛采用的人工智能编码工具。该公司积极推广人工智能代码生成，帮助创建了相关市场，并培养了一整代依赖该技术的开发者。如今，它却不堪重负，难以承受随之而来的自动化人工智能生成活动带来的压力。 

微软在2018年以75亿美元收购了GitHub，并将Copilot视为其最具战略意义的产品之一，并将其整合到整个软件套件中，这加剧了当前的紧张局势。很难想象，为了持续提升Copilot的收入，微软没有将精力投入到可靠性方面，而可靠性目前迫切需要投入更多精力。 

这种压力已经重塑了GitHub的领导结构。2025年8月，CEO Thomas Dohmke卸任后，微软没有选择任命继任者，而是将GitHub直接并入其CoreAI部门，剩余的领导层向微软高管汇报。这家自被收购以来一直以独立运营为傲的公司，如今已没有任何高层人士的职责仅仅是代表GitHub的利益。

自由开发者大卫·布舍尔（David Bushell）在他的文章《GitHub 正在沉没》（GitHub is Sinking）中直言不讳地指出：微软已经把 GitHub 变成了一个代价高昂的负担。他认为，该平台正被大量低质量的、人工智能生成的代码、问题和拉取请求所淹没——这种自动化的噪音堵塞了代码库，淹没了合法的工作——以至于他们“实际上是在用垃圾代码对自己进行 DDoS 攻击”。   

换句话说，GitHub 的衰落并非源于外部攻击，而是源于其自身人工智能驱动的活动所带来的巨大压力。布舍尔的结论一针见血：“网络效应难以撼动，但如果有人能做到，那一定是微软。” 

问题不仅仅在于规模。

4月 23 日的事件是由 GitHub 合并队列功能的一个回归错误引起的，这意味着对于使用 squash 合并策略且包含多个 pull request 的合并组，之前已合并的 pull request 中的更改会被静默回滚。共有 658 个仓库的 2092 个 pull request 受到影响。提交仍然存在，但受影响仓库的默认分支处于错误状态，GitHub 无法安全自动地修复这些状态。

根本原因是功能标志未完成。原本应该通过一个未发布功能的标志来限制新代码路径的执行，但该限制并未完成。新行为在生产环境中激活，而现有的监控系统未能检测到，因为问题在于合并的正确性而非可用性；服务看起来运行正常，因此没有触发任何警报。最终，该缺陷是通过客户报告发现的。

这感觉像是糟糕的架构设计，而不是人工智能驱动的扩展性问题。

四天后，另一起事件导致 GitHub 的 Elasticsearch 子系统瘫痪，该子系统负责跨问题、拉取请求和项目进行搜索。集群不堪重负，显然是由僵尸网络攻击引发的，导致用户界面的大部分内容显示为空，并造成了大范围的混乱。

一个更完善的 GitHub 应该是什么样子的？

并非所有人都采取对抗姿态。

汉娜·福克斯韦尔（Hannah Foxwell）在《面向我们其他人的人工智能》杂志上撰文，思考这场危机对GitHub在世界上的角色有何启示。 

“我们需要GitHub。它是至关重要的全球基础设施，但它正在不堪重负，因为数百万（甚至数十亿）个人工智能代理都在源源不断地编写代码。”福克斯韦尔最后对那些身处瞬息万变的局面中的工程师们表示了合理的同情：那些试图解决这个问题的人正承受着巨大的压力。

曾在 GitHub 工作并花了十年时间思考开源基础设施的 Andrew Nesbitt 发表了一篇名为《GitHub for maintainers》的博客，他认为，虽然大多数 GitHub 替代方案的愿望清单都集中在单个开发人员的工作流程上，但这些问题已经在其他地方得到解决。 

堆叠式 PR 由 Graphite 和 Jujutsu 等工具处理；代码审查正在向 Cursor 和 VS Code 等编辑器转移。Nesbitt 认为，没人谈论的是只有像 GitHub 这样具有独特视角的平台才能提供的功能：项目间关系的可见性。谁依赖于谁，当库的维护者停止维护时会发生什么，即将发布的更改是否会破坏成千上万个下游项目。这正是 GitHub 多年来几乎没有触及的层面，也是所有潜在替代方案都没有解决的问题。

结语

GitHub 为超过 1 亿开发者提供服务，并正经历着前所未有的增长。在事件发生后的报告中，GitHub 展现出了异乎寻常的透明度，发布了详细的根本原因分析，并承诺进行具体的架构变更。

但事后的透明度并不等同于可靠性，社区的耐心显然正在逐渐消磨殆尽。

值得探究的是，为什么 GitHub 似乎遇到了与同类基础设施截然不同的困境。PyPI、npm 和 GitLab 都同样受益于人工智能驱动的开发热潮，并且没有出现类似的公共系统崩溃。这很可能是因为 GitHub 在智能体工作流程中占据着独特的核心地位。除了托管代码之外，GitHub 还是人工智能体发起拉取请求、触发持续集成运行、调用 API 以及以机器速度与代码仓库交互的地方。 

GitHub 目前公布的优先事项是：可用性第一，容量第二，新功能第三。这个顺序没错，但面对不断推出 Copilot 功能的竞争和商业压力，GitHub 能否坚持这一原则还有待观察。

目前，这个已成为开源代名词、让分布式协作变得轻松便捷的平台，正面临着一个令人不安的现实：它一直以来所承诺的与它目前能够实现的之间存在着差距。

作者：手扶拖拉斯基