4个月16起！GitHub崩溃不止！

作为承载着无数良心代码的平台和社区，Github成为全球开发者的开源圣地，然而此次的服务中断问题似乎点燃了用户们对于Github时不时就“玩中断”的不满情绪。

【资料图】

清一色读者成长计划社群招募，咨询小助手（微信号：CTOjishuzhan）

撰稿 | 言征

四个月，16次中断。Github真的惹恼了用户了。

微软旗下的GitHub为版本控制和协作提供了一个代码托管平台，在过去三个月发生了13起此类事件后，而就在刚刚过去的上周，该公司就发生三次服务中断。

5月16日，GitHub首席安全官Mike Hanley发表了一篇博文《解决Github最近的可用性问题》中表示：“上周，GitHub发生了几起可用性事件，包括长时间和短时间的可用性事件。此后，我们已经缓解了这些事件，所有系统现在都正常运行。”

Hanley补充道：“这些事件的根本原因并不相关，但总的来说，它们对组织和开发人员信任GitHub提供的服务产生了负面影响。这既不可接受，也不符合我们的标准。”

一、三起事件回溯及原因

该公司表示，这三起事件分别发生在5月9日、5月10日和5月11日，影响了GitHub提供的大部分关键服务。事件导致关键的GitHub服务中断如下：

1.5月9日Git数据库事件

日期：2023 年 5 月 9 日

事件：Git 数据库因配置更改而降级

影响：10 个主要服务中有 8 个降级

据该公司称，5月9日发生的事件由于配置更改而中断了GitHub的数据库。

Hanley在博客文章中表示：“5月9日，我们发生了一起事件，导致状态门户网站上的10项服务中有8项受到重大（红色状态）停机的影响。大部分停机时间仅持续了一个多小时。”

Git 推送错误率：在 11:30 左右，错误率从零上升到大约 30,000。汇率继续在 25,000 和 35,000 之间波动，直到 12:30 左右，此时它回落到零。

Hanley解释说，在中断时，许多服务无法读取新写入的Git数据，导致了大范围的故障，并补充说，中断后，一些拉取请求和推送数据的事件后恢复时间延长了。

Hanley表示，此次中断是由提供Git数据的内部服务的配置更改引发的。

“这一更改旨在防止连接饱和，之前曾在Git后端的其他地方成功引入。推出后不久，集群发生了故障切换。我们恢复了配置更改，并在几分钟内尝试回滚，但由于内部基础设施错误，回滚失败了。”

2.5 月 10 日GitHub App auth token 事件

日期：2023 年 5 月 10 日

事件：GitHub App 身份验证令牌颁发因负载下降

影响：10 个主要服务中有 6 个下降

5月10日发生的这起事件是由于GitHub的应用程序身份验证令牌发布能力下降，十分之六的关键GitHub服务也受到了影响。

Hanley在博客文章中表示：“5月10日，提供GitHub应用程序身份验证令牌的数据库集群发现GitHub App权限的写入延迟增加了7倍（状态为黄色）。在此次事件的大部分时间里，这些身份验证令牌请求的失败率为8-15%，但在短时间内达到了76%的峰值。”

5 月 10 日，为 GitHub 应用程序授权令牌提供服务的数据库集群发现 GitHub 应用程序权限（状态黄色）的写入延迟增加了 7 倍。在这一事件的大部分时间里，这些授权令牌请求的失败率为 8-15%，但在短时间内确实达到了 76% 的峰值。

延迟随时间变化的线图：显示从 5 月 10 日星期三中午 12 点 30 分到 5 月 11 日星期四午夜从零跳到“3e14”附近波动。峰值延迟在此期间有 5 次接近“1e15”。

首席安全官解释说，令牌颁发问题是由于管理GitHub应用程序权限的API“执行效率低下”造成的，并补充说该公司正在更新API以检查安装状态的变化。

3.5月11日Git数据库事件

日期：2023 年 5 月 11 日

事件：Git 数据库因只读副本丢失而降级

影响：10 个主要服务中有 8 个降级

该公司表示，由于读取副本丢失，GitHub的数据库于5月11日再次遭到攻击。Hanley在博客文章中表示：“在Git数据库事件中，Git读写是许多GitHub场景的核心，因此延迟和故障的增加导致GitHub Actions工作流无法提取数据或提取不更新的请求。”

随着时间的推移成功操作的线图，显示大约 250 万的典型值。该图显示在 13:30 下降到大约 150 万次操作，随后稳步增加回到 250 万次，并在 14:00 恢复正常。

二、为什么这些事件会影响其他 GitHub 服务？

在博客中，Hanley表示：“我们希望我们的服务能够尽可能地适应失败。分布式系统中的故障是不可避免的，但不应导致多个服务严重中断。在所有这三起事件中，我们都看到了普遍的退化。在 Git 数据库事件中，Git 读写是很多 GitHub 场景的核心，因此延迟和故障增加导致 GitHub Actions 工作流无法拉取数据或拉取请求不更新。”

此外，在 GitHub Apps 事件中，对令牌发布的影响也影响了依赖令牌运行的 GitHub 功能。这是 GitHub Actions 中每个 GITHUB_TOKEN 的来源，以及用于授予 GitHub Codespaces 访问存储库的令牌。它们也是保护私有 GitHub 页面访问的方式。当令牌发行失败时，GitHub Actions 和 GitHub Codespaces 无法访问它们运行所需的数据，因此无法启动。

三、GitHub正在采取行动来避免类似事件

Hanley 表示，为了避免未来发生类似事件，公司正在几个方面开展工作，例如仔细审查其内部流程，并进行调整，以确保变动始终得到更安全的部署。

“当然，并非所有这些事件都是由生产变化引起的，但我们认为这是一个需要改进的领域”。

此外，Hanley补充道：“除了标准的事件后分析和审查外，我们正在分析这些事件对各服务的影响范围，以确定在哪里可以减少未来类似故障的影响。”

同时，GitHub正在努力提高“高成本、低容量查询模式”的可观测性、快速诊断和缓解此类问题的通用能力。其他措施包括解决数据库故障转移问题，以确保故障转移始终在没有干预的情况下完全恢复，并了解多个Git数据库崩溃事件。

作为Github公司对透明度承诺的一部分，将会在月度可用性报告中发布了导致 GitHub 服务性能下降的所有事件的摘要。“鉴于最近这些事件的范围和持续时间，我们认为现在与社区一起解决这些问题很重要。”

Hanley表示，5 月的可用性报告将包括这些事件和更多相关的进一步细节，以及关于提高 GitHub 可用性的进展的一般更新。

四、四个月持续发生服务性能下降事件

尽管github声称正在努力解决停机问题，但GitHub在过去四个月里持续发生了不少中断事件，4月发生了4起，3月发生了6起，2月发生了3起。

五、用户炸锅了

一位Reddit用户表示，对于Github的可用性问题由来已久，不仅仅是最近才有。Github或者其中的某些服务经常出现故障，并对该公司根本不屑于写任何关于问题的东西刚到吃惊。“Actions经常崩溃，而他们与Codespaces的不断停机是让我的团队远离它的一个很大的动力。”此外，他还对于Github的状态页面事件历史更新表示不满。

有另一位网友回应：某云不更改状态页面的原因是因为这会引发一堆SLA积分和对客户的补偿。

也有不少网友附议：“每次我遇到代码空间问题时，状态页面肯定也没有显示问题”、“我很清楚某些服务降级的频率，在我们Slack的第三方状态频道中被发送垃圾邮件”、“哇，3月发生了20起事件，几乎每个工作日发生一次”。

六、写在最后

作为承载着无数良心代码的平台和社区，Github成为全球开发者的开源圣地，然而此次的服务中断问题似乎点燃了用户们对于Github时不时就“玩中断”的不满情绪。

正如Hanley所说，分布式系统中的故障是不可避免的。但给到用户的可用性承诺却是要遵守的。如果不能保障这一点，那SLA（service-level agreement）也就变成了空头支票，有何意义？

参考链接：

https://www.infoworld.com/article/3696279/github-owns-up-to-service-issues-multiple-outages.html

https://github.blog/2023-05-16-addressing-githubs-recent-availability-issues/

标签：