Github.com 出现故障 [已解决]

原文 ↗ Hacker News 讨论 ↗

GitHub 反复出现、持续数小时的故障——影响了 pull requests、issues、Actions 和网页界面，而官方状态页却滞后或长期保持“全部绿色”——正在促使许多开发者质疑它作为关键基础设施的可靠性。评论者围绕根因展开争论，从微软迁移到 Azure、AI 驱动的代码生成激增，到对核心运维投入不足；同时也在争论是否应对重度（通常基于 LLM 的）使用实施限流或更高价格。越来越多的团队表示正在积极迁移，或计划迁移到 self-hosted 的 GitLab、Gitea/Forgejo，或更新的联邦式 forge，这凸显了对中心化、供应商锁定，以及单一主导代码托管平台脆弱性的更广泛担忧。

故障症状和影响

  • 许多用户报告 GitHub 无法使用：独角兽错误页、500、404、“无法检索最新提交”、PR 合并状态无法加载、Actions 失败、webhooks 不触发。
  • 核心 git 操作通常仍可用（clone、push），而且 CLI (gh) 或 API 有时在 Web UI 不可用时仍能工作，但 CI/CD 管道和基于网页的工作流会被阻塞。
  • 故障持续数小时，有些用户提到就在几天前也发生过类似事件；有人把它当作被迫休息，也有人认为这是严重的业务中断。

状态页和事件处理

  • 官方状态页最初显示“全部绿色”，之后才变成“性能下降”和“~20% 错误率”。
  • 许多人认为这低估了情况：对他们来说，PR/issue 实际上是 100% 挂了。
  • 有几位指出，“性能下降”类事件似乎没有反映在正常运行时间统计中；更早的故障也缺失，或者后来被回填成 100% 正常运行，削弱了信任。

怀疑的原因

  • GitHub/Microsoft 将近期可用性问题归因于巨大的增长，尤其是 AI/LLM 驱动的代码和 Actions 使用量（提交和 CI 分钟数增长了一个数量级以上）。
  • 一些评论者同意，规模问题确实很难；另一些则认为：
    • 故障早在 AI 热潮之前就已存在，并在微软收购和迁移到 Azure 之后加剧。
    • 其他 Web 规模服务能实现更高的可靠性。
    • 功能堆砌过多以及“vibe-coded”/AI 辅助改动可能正在损害系统稳健性。

业务、可靠性和 SLA

  • 许多组织现在把 GitHub（包括 Actions）视为关键基础设施；故障会阻塞紧急修复、发布和收入。
  • 有人认为用户应当准备应急方案、镜像，并且不要把第三方 SaaS 当作单点故障；但也有人回应说，GitHub 明确把自己营销为可靠的企业级基础设施，并提供 SLA。
  • “别发火，出去走走”和“我们是付费的；感到沮丧是合理的”之间存在张力。

替代方案和迁移

  • 经常提到迁移到：
    • 自托管 forge（GitLab、Gitea、Forgejo）加自托管 CI（Jenkins、Woodpecker、Buildkite 等）。
    • 其他托管 forge（GitLab.com、Codeberg、更新的联邦式选项）。
  • 讨论了这些取舍：
    • 网络效应和社交可见性让人们留在 GitHub 上。
    • 一些人认为自托管便宜且可靠，另一些人则认为运维负担很重。
    • CI/Actions 迁移以及集成丢失是最难的部分。

中心化、社区和定价

  • 更广泛的反思是，GitHub 的中心化把分布式 git 变成了单点故障，也变成了开发者的社交网络。
  • 一些人欢迎回到更分布式或联邦式的工具生态；另一些人则担心可发现性和共享规范会流失。
  • 许多人建议 GitHub 应更积极地对重度/LLM 流量和免费层使用进行限流或提高收费，优先保障付费用户和人类用户，但也指出商业激励可能会阻碍这一做法。