GitHub Git 因配置更新错误而停机

GitHub 这项数以百万计的组织在使用的关键服务，在 1 月 13 日因配置更改错误而遭遇了 49 分钟或更长时间的 Git 停机，这凸显了对这项云服务的依赖所存在的风险。

GitHub 的官方状态报告称 Git 停机时间为 49 分钟，但有人报告了更长的停机时间。“那天停机了大约 2 个小时……要么是 GitHub 不知道如何沟通，要么是他们还没法确定实际的影响范围，”一位用户说。

这可能是自 2024 年 8 月 14 日以来最严重的 GitHub 停机，彼时所有 GitHub 服务在一段时间内都无法供所有用户访问，而且那次同样是由配置更改错误引起的，只不过出问题的是 GitHub.com 数据库。

8 月，这家微软旗下的 DevOps 巨头表示，“为了防止再次发生事故，我们正在数据库变更管理流程中实施额外的防护措施”以及“提高对依赖项故障的恢复能力”。

这次问题出在内部负载均衡器的配置上，该公司又做出了类似的承诺，称其将改进“监控和部署实践，以减少检测时间，并在未来自动缓解此类问题”。

Git 是分布式版本控制系统，是 GitHub 存储库的核心。虽然不是整个 GitHub 都出现了故障，但 Git 是许多其他服务的关键依赖项，这些服务依赖它来检索存储库中最新和正确的代码版本。

一个缓解因素是，像 Git 这样的分布式版本控制系统使开发人员能够使用自己机器上的存储库副本继续工作，因此短暂中断的损害是可以控制的。但是，GitHub Actions 等工具或设置为使用 GitHub 存储库的 CI/CD（持续集成/持续部署）系统仍然存在问题，从而影响了部署。

一些开发人员误解了正在发生的事情，导致他们做了很多额外的工作。例如，一位开发人员收到了消息“权限被拒绝（公钥）。致命：无法从远程存储库读取”，导致他们检查了 SSH 密钥；另一个开发人员也遇到了同样的问题，他“花了最后一个小时排除故障，删除/重新添加密钥，重新启动我的服务器，生成新密钥。”也许，教训是，在进一步排除故障之前，总是要先检查 GitHub 状态。

GitHub 拥有超过 1 亿开发人员，即使是短暂的中断也会造成严重后果。自托管的风险更小吗？“我们使用 GitHub Enterprise Server 自托管 GitHub……我想说，在过去 12 个月中，我们的正常运行时间轻松超过了 GitHub.com，”对最新事件的一条评论这样说道。话虽如此，自托管也有其自身的风险，而且 GitHub.com 无与伦比的规模赋予了它让自托管无法比拟的全球资源。

原文链接：https://devclass.com/2025/01/15/github-git-downtime-caused-by-bad-configuration-update/