GitHub 与软件开发的罪行：基础设施衰败的缩影

来源：Hacker News / Efron Licht 时间：2026年5月

背景

本文作者 Efron Licht 是一名专注于高性能、高可用性及高容量分布式系统的专业技术人员。文章发表于 2026 年 5 月，正值 GitHub 再次陷入大规模服务中断之际。尽管《The Verge》等媒体已报道过 GitHub 在可靠性、安全性和性能方面的挣扎，但作者认为这些报道仅触及表面。

GitHub 作为软件开发领域的标志性平台，其服务状态被视为大型科技公司基础设施衰败的一个“信号”。作者指出，虽然 AWS、Google Search 等巨头服务也存在类似问题，但鉴于 GitHub 在开发者社区中的核心地位（甚至曾有招聘者因开发者没有 GitHub 账号而质疑其专业性），其表现具有极强的代表性。作者试图从技术架构和运营策略的角度，深入剖析 GitHub 当前面临的系统性危机。

核心内容

文章详细列举了 GitHub 在技术、产品策略及运营透明度方面的多重问题，并驳斥了微软（Microsoft）官方关于服务中断原因的公关声明。

1. 基础设施与工程质量的系统性崩溃

作者指出，GitHub 的问题远不止于偶尔的服务不可用，而是深层次的工程缺陷：

• 极高的故障率：根据 GitHub 自身的公开通信，每月发生数十起事故，这意味着实际故障率可能高达数百起。
• 缺乏透明度：GitHub 不公开 Bug 列表或问题追踪页面，将问题隐藏在电子邮件链条中，拒绝向公众展示真实状况。
• SLA 违约：即使按照 GitHub 自己的指标，其服务也频繁违反服务等级协议（SLA）。
• 前端代码臃肿且低效：
  • 前端页面加载缓慢，内存占用极高（作者观察到 Pull Request 页面的堆内存峰值超过 512 MiB）。
  • 在 Firefox 和 Safari 等主流浏览器上频繁出现兼容性问题。
  • 用户体验（UX）频繁无预警变更，且往往用导向其“AI”系统的漏斗替换了原本有用的功能。
• GitHub Actions 的设计缺陷：
  • 被作者形容为“用 YAML 编写的 Shell 脚本”中最糟糕的一类。
  • 日志系统存在内存泄漏，长期导致浏览器崩溃。
  • 缺乏基本的标准输出（stdout）管道功能。
  • 默认缓存行为（如 setup-go）极其天真，许多操作甚至从不进行缓存失效处理。

2. 对 AI 功能的盲目狂热与资源错配

文章批评 GitHub 及其母公司微软将大量资源投入到 flashy（花哨）的 AI 功能中，而牺牲了基础可靠性：

• AI 按钮泛滥：在仓库页面的右上角，存在多达四种启动 Copilot 的方式。对于未明确禁用 AI 的项目，甚至会出现第四个 Agent 按钮。
• 公关辞令的虚伪：微软在声明中声称“代理式开发工作流（agentic development workflows）加速”导致负载增加。作者反驳称，这种被动语态的使用是故意推卸责任。GitHub 和微软多年来一直在所有产品中强行植入 AI 和 Agent 功能，并通过补贴成本来驱动采用，这实际上等同于对自己发起分布式拒绝服务攻击（DDoS）。
• 更新日志的真相：在 GitHub 发布可用性更新后的 30 天内，其更新日志中“Copilot”出现 59 次，“Agent”出现 8 次，而“性能”和“可靠性”均为 0 次。在分类过滤中，Copilot 有独立类别，而性能和可靠性根本不存在。

3. 社区治理的失职

• 虚假互动：GitHub 容忍并推广“购买关注者”和“购买 Star”的行为。存在名为 githubstars.com 的网站公然广告买卖 Star，卡内基梅隆大学的研究论文也指出“假 Star 与恶意活动高度相关”，但 GitHub 对此视而不见。
• 设置重置：GitHub 经常重置或更改项目和用户设置，新功能往往在未经警告的情况下默认开启，其中一些功能甚至具有危险性。

4. 对微软官方声明的逐条驳斥

针对微软声称的“指数级增长导致系统压力”，作者指出：

• 微软声称“小效率在大规模下会累积”，但作者认为 GitHub 面临的不是“小效率”，而是“巨大且令人震惊的低效”。
• 微软声称优先级是“可用性第一，然后是容量，最后是新功能”，但这与 GitHub 实际的产品路线图和更新日志完全相悖。

关键要点

• 故障率被严重低估：GitHub 每月公开承认数十起事故，实际故障次数可能高达数百起，且缺乏公开的 Bug 追踪机制。
• AI 优先策略损害基础体验：GitHub 明显优先开发花哨的 AI 功能（如 Copilot、Agent），而非解决基础的性能和可靠性问题。更新日志中 AI 相关词汇频现，而性能优化词汇为零。
• 技术债务深重：前端代码臃肿、内存泄漏严重，GitHub Actions 设计糟糕，存在日志泄漏和缓存策略缺陷。
• 浏览器兼容性差：在 Firefox 和 Safari 上频繁出现功能故障和性能问题。
• 社区生态污染：平台容忍虚假的 Star 和关注者交易，破坏了开源社区的信任基础。
• 管理层缺乏诚意：微软的公关声明试图将责任归咎于“AI 工作流的自然增长”，但这与其长期强制推广 AI 产品的行为自相矛盾。

意义与影响

这篇文章不仅仅是对 GitHub 服务质量的批评，更是对大型科技公司（Big Tech）在追求新技术风口时忽视基础设施稳健性的深刻警示。

1. 基础设施衰败的信号：GitHub 作为软件开发的基础设施，其稳定性直接关系到全球软件供应链的安全。其频繁的故障和低效反映了大型平台在规模扩张过程中可能出现的系统性熵增。
2. AI 热潮下的冷思考：在 AI 概念泛滥的背景下，GitHub 的案例表明，过度追逐 AI 功能而忽视底层工程质量和用户体验，最终会损害平台的核心价值。这种“本末倒置”的策略不仅影响开发者效率，也可能导致用户流失。
3. 透明度的重要性：GitHub 拒绝公开问题列表、隐瞒故障真实频率的行为，加剧了用户的不信任。在开源社区，透明度是建立信任的基石，缺乏透明度将削弱平台作为“代码协作中心”的合法性。
4. 替代方案的兴起：文章末尾提及了 GitLab、Codeberg 和 Forgejo 等替代方案，暗示随着 GitHub 体验的恶化，开发者可能会重新评估其依赖关系，转向更开放、更可控的平台。这将对 GitHub 的市场主导地位构成长期挑战。

总之，GitHub 的现状是“软件开发的罪行”——在追求短期 AI 利益的同时，牺牲了长期积累的可靠性、透明度和用户体验。这一案例提醒所有技术领导者，无论技术趋势如何变化，基础架构的稳健性和对用户的诚实始终是产品成功的根本。