本文翻译自 GitHub 官方博客《Introducing the GitHub Availability Report》
原文链接：https://github.blog/2020-07-08-introducing-the-github-availability-report/
作者：Keith Ballinger[1]
翻译：HelloGitHub-丫丫 | 校对：HelloGitHub-小鱼干
什么是可用性报告？
从历史上看，GitHub 对影响服务可用性的重大事件会发表事后评论。无论我们是分享新的基础设施投资，还是详细的网站停机时间，我们的信念是，可以通过相互学习共同成长为一个行业。这个月，我们很高兴介绍下 GitHub 可用性报告。
你能期待什么？
在每个月的第一个星期三，我们将发布一份描述 GitHub 可用性的报告，包括对可能发生的任何事件的描述，并向您介绍我们是如何发展工程系统和响应实践。您会期待这些更新，它包括对已有事件的总结，以及对我们认为是新奇事件的技术解释，并包含帮助世界各地的工程师学习如何大规模改进产品运营的信息。
为什么我们要做可行性报告？
可用性和性能是一个核心特性，包括 GitHub 如何响应服务中断。我们努力设计高可用、容错系统，我们希望这些每月更新可以回忆起 GitHub 高于 99% 的可用时间。当事情不按计划进行时，比起等待分享特别有趣的事件信息，我们更倾向于告知你所有可能影响你的事件。我们的希望是，通过提高我们的消息透明度、分享我们学到的东西，而不是简单地在状态页面上报告停机时间的分钟，从而让每个人都可以从我们的经验中受益。在 GitHub，我们非常诚挚地对待您的这份信任，我们希望这是您帮助我们对不断改进我们的卓越运营和我们的产品功能负责的一种方式。
五月和六月的可用性报告
在 5 月和 6 月，我们经历了四次不同的事件，导致 GitHub.com 缺乏可用性或服务降级。
UTC 5 月 5 日 00：45（持续 2 小时 24 分钟）
在事件发生期间，共享数据库表的自动增量 ID 列超过了 MySQL Integer 类型（Railsint（11)）：2147483647 可以表示的大小。当我们试图往列中插入较大整数时，数据库拒绝了该值，Rails 引发了 ActiveModel::RangeError，这导致 API 端的 500s 延迟。
这影响了依赖于获得安装令牌的 GitHub 应用程序。最受影响的 GitHub 内部应用程序包括 Actions、Pages 和 Dependabot。
GitHub 的监控系统当前在表达到主键所用大小的 70% 时会发出警报。我们在扩展我们的测试框架，以包含 int / bigint 外键不匹配的 linter。
UTC 5 月 22 日 16：41（持续 5 小时 09 分钟）
在原定的维护操作（MySQL 主实例失败）期间，在新升级的 MySQL 主服务器上 MySQL 进程经历了一次新的崩溃。为了减轻崩溃带来的影响，我们手动将流量重定向到原始主服务器。但是，崩溃的 MySQL 主服务器已经提供了大约 6 秒的写流量。此时，启动了从新主服务器恢复副本的操作，这大约需要 4 个小时，集群重新配置需要 1 个小时才能重新启用完全读取能力。在这近 5 个小时里，在 web 见面和 API 中看到数据写入到受影响数据库集群之前，用户可能已经观察到了延迟。
我们已经运行了多个内部模拟演习（gameday exercise），以应对类似的拓扑不一致，及继续训练我们的故障转移系统以减少故障恢复时间。
UTC 6 月 19 日 8：52（持续 51 分钟）
为改进 UI 的更好 A / B 实验工具引入了一种未知的依赖关系，依赖于独立应用提供的特定、动态生成文件的存在。
在应用部署期间，由于上游应用程序限制了较高的检索率，因此很大一部分的应用程序部署无法生成文件。这导致了参与实验的用户中有一定比例会出现应用程序错误。经过检测，我们能够禁用此文件需求，这将恢复对所有用户的服务。
接下来，A / B 和多元实验的配置将在内部缓存，以确保依赖关系的成功传播。
UTC 6 月 29 日 12：03（持续 2 小时 29 分钟）
作为维护的一部分，数据库团队在 6 月 22 日星期一推出了一个更新版本的 ProxySQL。一周后，我们的一个主数据库集群上的 MySQL 主节点出现故障，并被一个新主机自动替换。几秒钟内，新升级的主服务器崩溃。Orchestrator[2] 的防止互相踢皮球机制阻止了随后的自动故障转移。在我们手动恢复服务后，新的主服务器又开始耗尽 CPU 资源，并再次崩溃。为了恢复，我们回滚到 ProxySQL 旧版本并禁用了应用程序中 ProxySQL 新版本所需的变更。完成此操作后，我们可以允许在主节点上进行写操作而不会崩溃。
我们正在分析应用程序日志、MySQL 核心转储和我们的内部遥测，作为继续调查 CPU 耗尽问题的一部分，以避免类似的故障模式继续。
总结
作为一个组织，我们继续在可行性方面投入大量资金。我们把这里讨论的每一件事视为一个宝贵的机会来学习和成长。我们的系统和流程继续基于这些学习而发展，我们期待着在未来的更新中分享我们的进展。
请按照我们的状态页面[3]进行实时更新，并查看我们的博客下个月的可用性报告。
2020 年 7 月 2 日
参考资料
[1]Keith Ballinger:
https://github.blog/author/keithballinger/
[2]Orchestrator: https://github.com/openark/orchestrator
[3]状态页面: https://githubstatus.com/
HelloGitHub 推出的「译文亦舞」系列
如果小伙伴们有什么有趣的英文文章也可以留言把链接发给我（题材：GitHub、编程、程序员）。如果被采用了，我会偷偷加你给你发红包的💰。
关注公众号，第一时间收到推送
“分享”让本文被更多人看到、“在看”支持我们。
