Git 操作、Pull Request 和 Actions 相关事件——已解决

原文 ↗ Hacker News 讨论 ↗

频繁影响 git push、pull request、Actions 乃至认证等核心功能的 GitHub 故障，正促使开发者质疑其可靠性，并考虑 GitLab、Forgejo、Gitea 和自托管方案。评论者将原因指向 AI 驱动使用增加、GitHub 迁移到 Azure，以及免费额度等激励机制，同时也指出停机通常仍短到不足以证明彻底迁出的成本和复杂度。许多人认为，这一模式暴露了对单一集中式 forge 过度依赖于关键工作流和部署的风险。

故障影响与范围

  • 用户报告无法 push、创建 PR 或 issue，认证失败（例如通过基于 GitHub 的 SSO），以及 PR 上缺少提交。
  • Actions 和 Pages 出现失败或延迟，部分任务未触发，或合并队列卡住数小时。
  • 一些人看到 git push 时偶发 “Internal Server Error”，从 HTML 500 页面解析 JSON 时出错，以及前几天短暂但未报告的波动。

对 GitHub 可靠性的看法

  • 许多人觉得故障现在是“每隔几天一次”，而不是罕见的每月事件。
  • 一些人说 GitHub 已成为他们技术栈中最不可靠的服务之一；有人已经在积极把关键工作负载迁移出去。
  • 也有人认为故障时间仍然很短（几十分钟）且可以接受，尤其考虑到 git 的离线特性，不过这一点遭到强烈质疑。

推测原因

  • 常见主题：从自定义裸机 MySQL 迁移到 Azure；AI/agentic 编码带来的负载增加；功能更多、复杂度更高。
  • 有人指出内部曾警告延迟问题和复杂的实时数据迁移；也有人质疑 Azure 是否真的是直接原因。
  • 少数人半开玩笑或认真地把问题归因于“AI 编码”的系统，以及深度人工理解的流失。

状态页与事件处理

  • 多条评论称状态网站低估了持续时间/影响，并在错误仍然存在时就标记事件“resolved”。
  • 有人把这视为误导性的“统计美化”；也有人认为可能是诚实失误，但注意到这种模式反复出现。

替代方案与自托管

  • 用户报告自托管 Forgejo/Gitea/GitLab 体验良好，通常还会结合 S3/OCI 镜像仓库和独立 CI 系统。
  • 其他人强调了运营负担：要复制 issues、PR、actions、pages 和项目管理并不容易。

业务与架构考量

  • 争论焦点在于是否要：
    • 完全迁出 GitHub，
    • 增加冗余的部署路径，或
    • 接受偶发故障，因为这比大幅改造更便宜。
  • 有人认为 GitOps / 与 GitHub 紧耦合的 CI 很脆弱；也有人说对大多数企业来说，真正的多路径部署很少有充分理由。

生态锁定

  • 一些人指出 GitHub 在某些领域实际上是必需的：Homebrew taps、Terraform/OpenTofu registry、某些云工作流、免费的 macOS/Windows runners。
  • 建议的折中方案是：把 GitHub 当作只读镜像以便被发现，同时使用另一个主要 forge。