GitHub Actions 和 Pages 正在经历可用性下降

原文 ↗ Hacker News 讨论 ↗

GitHub Actions 和 Pages 经常发生持续数小时的故障，导致许多开发者和公司开始质疑 GitHub 的可靠性，尤其因为这些服务处在 CI/CD 和部署的关键路径上。评论者对原因的猜测包括 Azure 迁移、AI 驱动的负载爆炸式增长，以及 Microsoft 内部的组织和文化问题，同时指出官方正常运行时间数据和 SLA 与他们的实际体验严重脱节。因此，不少人正在探索或迁移到替代方案，例如自托管 GitLab、Forgejo、Woodpecker 或自定义 CI 方案，以减少对 GitHub 控制平面的依赖。

可靠性与正常运行时间担忧

  • 许多评论者表示，GitHub Actions 和 Pages 的故障已经变得很频繁，用户还半开玩笑地说它们实际上只有“one nine”甚至“zero nines”的正常运行时间。
  • 引用的第三方正常运行时间追踪器显示，在最近一段时间内可用性约为 94–98%，而 GitHub 自己公布的 SLA 数字高得多，因此有人指责官方指标具有误导性。
  • 这次事件持续时间很长（对一些人来说接近整整一个工作日），再加上最近几个月多次故障，让人感觉可靠性正在变差，而不是变好。

用户影响与挫败感

  • 工作被阻塞：CI 无法运行，PR 不能合并，热修复和客户发布被延迟，生产事故也更难处理。
  • 错误信息被描述为具有误导性或不透明，例如失败并没有清楚地表明“没有可用的 runners”。
  • 一些企业觉得即使付费也没有获得额外稳定性，而且支持/SLA 赔偿机制很弱，或者从设计上说就很“scummy”。

疑似原因

  • 两种主流理论：
    • 负载大幅增长，尤其是来自 AI agent 和 Copilot 的使用，导致提交量增加 10–14 倍、Actions 分钟数增加超过 4 倍，从而压垮了架构。
    • GitHub 正在从旧基础设施/AWS 迁移到 Azure，而 Azure 被描述为不稳定且是出于政治要求的迁移。
  • 许多人认为，负载和迁移，再加上激进的功能上线（尤其是 AI/Copilot），正在产生糟糕的相互作用。
  • 还有人认为，这些问题反映出糟糕的领导力、仓促的时间表，以及“表演性”的工程文化。

Actions 架构与自托管 runners

  • 用户对自托管 runners 也失败感到惊讶，因为中心调度器和 webhook 都挂了。
  • 许多人批评这种设计：集中式控制平面是单点故障，YAML 依赖过重，而且降级策略很差（没有清晰的负载削减或对付费客户的优先级保障）。

替代方案与自托管

  • 很多人有强烈兴趣把 CI 从 GitHub 上迁走：自托管 Jenkins、GitLab、Forgejo、Gitea、Woodpecker、Buildkite、Argo 以及各种小众 CI 系统都被提到。
  • 有些人表示，自托管 GitLab/Forgejo + runners（通常跑在单台服务器上）体验很好，声称可靠性和可控性更好。
  • 也有人指出，厂商锁定和迁移成本意味着 GitHub 尽管有故障仍然“赢了”，尤其是因为它的 PR/review 体验和网络效应。

更广泛的评论

  • 讨论串把 GitHub 的问题与更广泛的担忧联系起来：AI “slop”、RAM/数据中心压力、Microsoft 的产品质量，以及把关键开发基础设施集中到一个专有平台的风险。