GitHub 故障追踪器：GitHub 是不是完蛋了？

原文 ↗ Hacker News 讨论 ↗

一个带着戏谑意味的“GitHub 是不是完蛋了？”故障追踪器，引发了人们对 GitHub 可靠性的更广泛担忧，尤其是对企业用户而言，如今频繁的事故会通过 GitHub Actions 干扰 push、PR 和 CI 等核心工作流。评论者争论，一个被 Microsoft 收购、利润丰厚的公司究竟应不应该得到多少同情，并指出对 AI 工具和免费套餐的激进推广，很可能在没有对韧性或付费/免费流量隔离进行足够投入的情况下放大了负载。许多人认为这暴露出中心化和产品臃肿带来的自我伤害问题，而一些组织已经在认真评估替代方案，尽管目前还没有任何替代品能匹配 GitHub 的生态。

对故障追踪器的反应

  • 许多人觉得这个概念很有趣，也很贴切（比如拿“Outrage Tracker”开玩笑、提到 xkcd 等）。
  • 有人指出，把贡献图做成故障日历是个反复出现的点子。
  • 也有几位评论者查看了网站的数据和 JS，指出最初存在数学/标注错误（每月事故数、事故重叠、“最糟糕的一天”超过 24 小时），并注意到这些问题很快被修正了。
  • 还有人提醒，这些统计有点“半成品”，可能并不完全可靠。

对 GitHub 可靠性现状的看法

  • 普遍观点认为 GitHub 的故障频率“令人发指”，尤其是对企业用途而言。
  • 也有人表示自己很少注意到问题，说明故障可能与时区或工作负载有关。
  • 还有几位说，过去几个月里故障感觉更频繁也更严重，经常阻塞 CI、部署和 PR 工作流。

故障原因与规模争论

  • 一派强调前所未有的规模：AI 驱动的提交、构建和推送被描述为几乎等同于在对 GitHub 发起 DDoS。
  • 另一派认为流量确实很大，但仍在大厂长期知道如何应对的范围内；他们把问题归咎于技术债、迁移到 Azure，以及管理层优先级。
  • 也有人怀疑是架构脆弱、可靠性多年被降级处理，而不只是突然出现的规模问题。

付费用户与免费用户、公平性与限流

  • 许多付费/企业用户对自己被免费账户和 AI 机器人带来的流量影响感到不满。
  • 提议包括：
    • 为付费组织设置独立基础设施或保留容量。
    • 对自动化使用、免费套餐或类似 AI 的行为实施更严格的速率限制或限流。
  • 反方观点：对流量进行分层可能与 GitHub 的开源/社区定位，以及 AI 数据收集激励相冲突。

GitHub Actions、Copilot 与 AI 流量

  • 一张共享图表显示，如果移除 Actions/Copilot，事故数量几乎会减半。
  • Actions 被称为对很多人来说“是关键功能，不是次要功能”，但也因缓慢、脆弱和设计糟糕而遭到猛烈批评。
  • 多条评论提到，GitHub 自己大力推动 Copilot 和 AI 工作流，因此它“是自食其果”，也没什么资格抱怨 AI 驱动的负载。

替代方案与自托管

  • 一些组织因为反复故障而认真讨论迁出 GitHub，但迁移成本、合规要求和锁定效应都很高。
  • 据称，自托管 GitLab 或类似方案对某些人来说运行稳定，粗略成本估算表明，相比 GitHub 企业版可节省很多。
  • 也有人认为，大多数替代方案在 GitHub 这种流量规模下同样会出问题，而且对小型或个人仓库来说，GitHub 的免费套餐仍然是最实用的选择。

对 Microsoft 和 GitHub 未来的看法

  • 一些人对 Microsoft 的反感很强：他们声称收购会让产品停滞，而 GitHub 在被收购时就已经“完了”。
  • 也有人区分对个别工程师/SRE 的同情与对公司管理层的零同情。
  • 还有几位认为，如果出现一个可信、简单的竞争对手，很多客户都已经准备好离开；不过网络效应和功能膨胀也可能让 GitHub 像“Excel 一样”继续牢牢占据市场。