GitHub可用性报告

从历史上看，GitHub发布了对影响服务可用性的重大事件的事后评估。无论我们是分享基础设施的新投资，还是详细说明现场停机时间，我们都相信，作为一个行业，我们可以通过相互学习来共同成长。这个月，我们很兴奋地介绍GitHub可用性报告。

在每个月的第一个星期三，我们将发布一份报告，介绍GitHub的可用性，包括可能发生的任何事件的描述，并向您通报我们是如何发展我们的工程系统和实践以应对的。您应该预料到这些更新将包括所发生事件的摘要，以及我们认为发生的事件的技术解释，这些事件包含可帮助世界各地的工程师了解如何大规模改进产品运营的信息。

可用性和性能是一项核心功能，包括GitHub如何应对服务中断。我们致力于设计具有高度可用性和容错能力的系统，我们希望这些每月更新中的大部分将回顾GitHub 99%可用的时间段。当事情没有按计划进行时，与其等待分享关于特别有趣的事件的信息，我们想要描述所有可能影响你的事件。我们希望通过增加我们的透明度和分享我们所学到的东西，而不是简单地在状态页面上报告几分钟的停机时间，每个人都可以从我们的经验中学到东西。在GitHub，我们非常重视您对我们的信任，我们希望这是一种帮助您追究我们的责任，让我们不断改进我们的运营以及我们的产品功能的一种方式。

在5月和6月，我们经历了四起截然不同的事件，导致GitHub.com缺乏可用性或服务降级。

在事件期间，共享数据库表的自动递增ID列超过了MySQL Integer类型(rails int(11))可以表示的大小：2147483647。当我们试图在列中插入更大的整数时，数据库拒绝了该值，并且Rails引发了ActiveModel：：RangeError，这导致我们的API端点出现500。

这影响了依赖获取安装令牌的GitHub应用程序。在内部受影响最大的GitHub应用程序包括Actions、Pages和Dependabot。

GitHub的监控系统目前会在表达到所用主键大小的70%时发出警报。我们现在正在扩展我们的测试框架，以包括针对int/bigint外键不匹配的Linter。

在计划维护操作(故障转移MySQL主实例)期间，我们在新升级的MySQL主服务器上的mysqld进程中遇到了一次新的崩溃。为了减轻崩溃的影响，我们手动将流量重定向回原来的主服务器。但是，崩溃的MySQL主数据库已经为大约6秒的写入流量提供了服务。此时，从新的主节点开始恢复复制副本，大约需要四个小时，群集重新配置还需要一个小时才能重新启用全部读取容量。在大约五个小时的时间内，用户可能在写入受影响的数据库群集的数据在Web界面和API中可见之前观察到延迟。

我们已经进行了多次内部比赛日演习，以确保对类似拓扑不一致有更高程度的准备，并将继续使用我们的自动故障转移系统，以减少恢复时间。

对用于UI改进的更好的Instrument A/B实验的更改引入了对由单独的应用程序提供的特定的、动态生成的文件的存在的未知依赖。

在应用程序部署期间，由于上游应用程序限制较高的检索率，在相当大比例的应用程序部署上无法生成文件。这会导致实验中注册的一定百分比的用户出现站点范围的应用程序错误。在检测到后，我们能够禁用对此文件的要求，从而恢复了对所有用户的服务。

下一步，A/B和多变量实验的配置将在内部缓存，以确保依赖项的成功传播。

作为维护的一部分，数据库团队在6月22日星期一推出了更新版本的ProxySQL。一周后，我们的一个主数据库集群上的主要MySQL节点出现故障，并被一台新主机自动替换。在几秒钟内，新升级的主节点崩溃。Orchestrator的防摆动机制阻止了后续的自动故障转移。在我们手动恢复服务之后，新的主节点变得CPU匮乏并再次崩溃。一个新的初选得到了推广，不久之后也崩溃了。为了恢复，我们回滚到以前版本的ProxySQL，并禁用了应用程序中需要新ProxySQL版本的更改。完成此操作后，我们可以在不使主节点崩溃的情况下允许在主节点上进行写入。

我们正在分析应用程序日志、MySQL核心转储和我们的内部遥测，作为继续调查CPU匮乏问题的一部分，以避免未来出现类似的故障模式。

作为一个组织，我们继续在可靠性方面投入巨资。我们将这里讨论的每一起事件视为学习和成长的宝贵机会。我们的系统和流程在这些经验的基础上继续发展，我们期待着在未来的更新中分享我们的进展。

请关注我们的状态页面以获取实时更新，并关注我们的博客以获取下个月的可用性报告。