GitHub Actions、GitHub Pages 和 Webhooks 出现可用性下降

原文 ↗ Hacker News 讨论 ↗

GitHub Actions、Pages 和 webhooks 的频繁故障促使工程师质疑 GitHub 的可靠性，以及把 CI/CD、代码托管和 GitOps 全部集中在单一供应商上的做法是否明智。评论者认为，不稳定性来自 Azure 迁移挑战、AI 驱动流量激增以及宽松的免费层等多种因素，并争论 Microsoft 是否没有优先考虑付费用户和架构修复。许多人正在积极评估自托管 GitLab、Forgejo 或新平台等替代方案，而另一些人则认为 GitHub 的社交网络效应和工具集成使迁移成本高且复杂。

故障的即时影响

  • 很多报告称 GitHub Actions 运行卡在“Queued”状态，包括自托管 runner 也是如此。
  • 一些用户看到任务实际上已在自己的 runner 上完成，但 GitHub 的界面仍然显示为排队中。
  • 人们在意识到这是平台问题之前，白白花时间调试自己的工作流。
  • 许多人对状态页面是在用户已经察觉并排查出问题之后才更新感到沮丧。

供应商锁定与组织风险

  • 一些评论指出，公司把 GitHub Actions 和 GitOps “全押”在 GitHub 上，制造了单点故障。
  • 有些工程师说他们曾反对这样做，但没有被采纳；现在这些故障被视为管理层的问题。
  • 也有人担心，切换供应商的感知风险，加上 GitHub 的网络效应，使迁移在政治上和实践上都很困难。

替代方案与自托管

  • 提到的托管替代方案包括：GitLab、Bitbucket、Cursor Origin，以及各种较小的 CI/CD 工具。
  • 一些人强烈偏好自托管的 GitLab、Forgejo、Gitea 等，通常还会配合自托管 runner。
  • 用户强调，云托管的 GitLab 也会出现故障；他们报告的主要可靠性提升来自自托管以及对维护窗口的控制。
  • 有人认为，对于关键部署，应该把 GitHub 当作镜像，而不是事实来源的主站。

不稳定性的感知原因

  • 一派将问题归咎于 Microsoft 的收购、Azure 迁移以及公司文化；他们引用历史可用性图表和内部人士的文章。
  • 另一派强调的是由 AI 驱动的爆炸式增长（LLM/agent 提交、把 PR 当作“日志”）而不是收购本身。
  • 关于 AI/机器人流量是否是主要驱动因素，还是架构/组织问题才是主因，存在争论；现有证据被描述为部分的或不清楚的。

免费层、定价与多层级服务

  • 建议包括：大幅减少免费 Actions 分钟数、降低免费用户的并发数，或者提高价格以资助更多容量。
  • 也有人警告这可能会把用户推向竞争对手，不过也有人质疑所谓可信的“鲨鱼”到底在哪里。
  • 付费客户对自己与大量免费层和 AI 使用者共享同一条退化的服务通道感到不满；一些人要求隔离，或要求企业专用实例（例如单独的托管选项）。

状态沟通与用户应对

  • 用户希望更早看到“系统出问题了，我们正在调查”的消息，最好由自动检测（例如队列深度）触发。
  • 有些人开玩笑说可以把故障当作强制休息；也有人把反复故障视为该计划退出的时候了。