撰稿人 | 言征

五个月，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 中每个 GIitHub 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的状态页面该事件历史更新则表示不满。