GitHub availability report: May 2026

标题：GitHub 可用性报告：2026 年 5 月

URL 来源：https://github.blog/news-insights/company-news/github-availability-report-may-2026/

发布时间：2026-06-11T14:30:15-07:00

Markdown 内容： 在3月和4月，我们分享了有关 GitHub 可用性和基础设施投资的更新。随着这些工作的持续推进，并且我们即将达到一些重要的里程碑，我们希望在每月的可用性报告中开始提供更加定期的更新。在深入探讨 5 月的事件之前，先来看看我们在持续努力使 GitHub 更加可靠方面所取得的进展。

我们在提高 GitHub 健壮性方面的进展

简短版：GitHub 的流量正在迅速增长，这在很大程度上是由 AI 辅助和代理式开发工作流程驱动的，我们一直在改造基础设施以跟上这一增长。这意味着迁移到 Azure 以实现弹性容量，将我们的单体架构拆分为独立的服务，并消除过去事件中导致问题的共享故障点。

目前我们的进展如下。我们现在有 40% 的单体流量来自 Azure（2 月份为 8%），Git 流量为 30%，仓库复制为 99%。我们在四个月内将有效容量增加了两倍以上。同时，我们正在完成主数据库集群的隔离：将用户、认证和授权拆分为独立的域，这样在一个域出现问题时，将不再影响整个平台。我们的新用户服务已经完全切换，处理的流量是原来的两倍，同时数据库成本显著降低。无状态认证令牌也在逐步推出，消除了在流量高峰期间导致压力放大的每请求数据库查询。

我们正在做出结构性的改变，永久性地消除故障模式。我们承认还有工作要做，但我们致力于完成这些工作，确保 GitHub 在你需要的时候和地方是可靠的。指导我们决策的原则很简单：可用性，其次是容量，最后是功能。

感谢你们在我们继续构建 GitHub 的可靠性和韧性方面的合作。

• * *

在 5 月，我们经历了九起事件，导致 GitHub 服务性能下降。

5 月 4 日 15:45 UTC（持续 55 分钟）

2026 年 5 月 4 日，UTC 时间 15:34 至 16:40 之间，github.com 出现了服务中断，导致大量面向客户的服务出现延迟增加和请求失败率上升。总客户影响持续了大约 1 小时 6 分钟。

受影响最严重的服务是拉取请求，其在高峰期影响期间状态为 Red。问题、操作、Webhook 和 Git 操作经历了延迟增加和间歇性错误。一些依赖服务（包括 Codespaces、Pages、Packages、OAuth 和 GitHub Apps、Marketplace 以及 Copilot）也由于共享数据依赖关系，出现了不同程度的性能下降。在高峰期，约 1.3% 的请求返回了 5xx 响应，整个事件期间平均约为 0.46%。

此次中断是由一次针对一个大型、高访问量数据库表的常规在线模式迁移触发的。该迁移在数小时内一直顺利进行，但随着流量逐渐上升至每周高峰，迁移与正常生产流量的负载相结合，使数据库连接容量达到饱和。这导致主数据库上出现查询竞争，并引发依赖该数据库的服务出现级联超时。

在首次出现影响迹象后约三分钟内，通过自动化监控和值班人员观察，事件被检测到。一旦确定了导致问题的迁移，便暂停了该迁移，随后相关服务很快恢复。缓解措施耗时约33分钟，约30分钟后问题得到完全解决。

作为后续改进措施，我们正在实施多项改进，以降低类似事件发生的可能性及其影响范围。针对大型、高流量表的迁移将更加紧密地与低流量时段对齐，并将使用能够根据实时集群负载进行动态限流的机制。我们正在添加自动熔断器，当底层数据库的延迟或连接利用率超过安全阈值时，将自动暂停正在进行的迁移。同时，我们正在扩展监控功能，使迁移引发的压力（如写入速率、锁时间、连接饱和度）在对用户产生影响之前就触发警报。同时，我们正在审查连接池容量，以确保在迁移运行期间保持充足的缓冲空间。

May 05 13:37 UTC（持续3小时49分钟）

May 06 07:19 UTC（持续2小时25分钟）

5月5日和5月6日，GitHub Actions因两次相关事件导致托管运行器性能下降。这两个事件相互关联：5月5日事件后的修复工作引入了配置问题，从而触发了5月6日的事件。

2026年5月5日，UTC时间13:22至17:05期间，GitHub Actions在东美地区托管运行器的性能下降。大约13.5%请求标准运行器的作业失败，约16%请求较大运行器且私有网络固定在东美地区的作业失败或延迟超过五分钟。Copilot代码审查请求也受到影响。在此期间，大约8,500个代码审查请求超时。受影响的用户在其拉取请求上看到错误评论，并可以通过重新请求审查来重试。大多数运行器请求会自动由其他地区处理，但仍有一部分请求路由到东美地区，因此受到影响。

此次事件由东美地区托管运行器虚拟机的扩容操作触发。这是一项常规操作，但在从存储中拉取镜像时，虚拟机创建负载达到了内部速率限制。由于此情况下返回的响应代码未触发现有退避逻辑，因此速率限制和虚拟机创建失败通过减少负载以实现恢复，并允许排队的工作被处理。到UTC时间15:34时，排队和失败的作业分配已大部分得到缓解，在15:34至17:05完全恢复期间，受影响的运行器分配比例低于0.5%。

2026 年 5 月 6 日 UTC 时间 06:45 至 09:15，GitHub Actions 标准 Ubuntu 主机运行器再次出现性能下降，约有 17.1% 的请求标准运行器的作业失败。此次问题是由于在处理前一天事件的修复工作中引入了意外的配置数据，导致随着每日负载增加时新分配被阻塞。我们在 UTC 时间 08:51 移除了有问题的数据，使分配恢复，并让运行器池重新扩展和恢复。

我们正在改进系统在达到限制时的限流行为，优化控制机制以更快地缓解类似情况，并对所有限制进行端到端的审查，以确保类似操作的稳定性。此外，我们正在更新该分配数据的过滤逻辑，使其能够抵御异常数据形态的影响，并增强监控，以便在分配被阻塞时发出警报，使团队能够在对用户造成影响之前做出响应。

UTC 时间 2026 年 5 月 6 日 11:21（持续 38 分钟）

2026 年 5 月 6 日 UTC 时间 11:02 至 11:13 期间，用户无法启动或查看 Copilot 云代理或远程会话。在此期间，所有对会话 API 的请求均返回错误，阻止用户创建新会话或查看现有会话。该问题是由服务网络路由的配置更改引起的，该更改意外地移除了服务的入口路径。团队在 UTC 时间 11:13 撤销了该更改，恢复了服务。事件在团队验证完全恢复之前保持开放状态，直至 UTC 时间 11:59。我们正在采取措施改进部署验证流程，以防止未来类似的配置更改影响生产流量。

UTC 时间 2026 年 5 月 6 日 15:25（持续 3 小时 39 分钟）

2026 年 5 月 6 日 UTC 时间 15:12 至 19:02 期间，github.com 上新拉取请求评论线程的创建失败。这包括拉取请求中的新行评论和文件评论。现有的拉取请求和之前创建的评论未受影响。

此次事件是由于在创建拉取请求评论线程时使用的 Vitess 查询表中一个 32 位整数键达到了最大值。主表已迁移至 64 位整数键，但 Vitess 查询表仍为 32 位。当主表中的值超过可用的 32 位 ID 空间后，创建新评论线程的尝试开始失败，导致新线程创建请求的失败率接近 100%。我们通过更新所有分片中受影响的查询表定义，使用 64 位整数列类型，扩大可用 ID 范围，从而缓解了问题，并恢复了正常操作。一旦全局模式更改完成，服务已完全恢复。

为了防止类似事件再次发生，我们正在扩展现有数据库列的监控，以包括 Vitess 查询表，并启用对任何接近列大小限制的表的早期检测。

该问题是由一个独立的pull request 事件后续恢复工作引起的。作为该恢复工作的一部分，我们执行了一次大规模的数据库迁移，导致多个副本主机出现复制延迟。

虽然这些副本没有处理用户流量，但我们的保护机制正确地将复制延迟的增加视为一个信号，从而减缓了受影响数据库集群的写入操作。因此，一些 pull request 的后台处理工作被暂时延迟。这些处理负责发送 Copilot 代理使用的内部事件，以启动工作，因此受影响的代理直到数据库副本追上进度后才开始运行。

当复制延迟恢复正常且 pull request 处理恢复后，系统也恢复正常。我们正在使关键的后台处理更加耐受复制延迟，使其在压力下能够优雅降级，保持关键事件的流动，从而减少未来恢复工作中出现类似次级影响的可能性。

UTC 时间 5 月 15 日 08:13（持续 35 分钟）

2026 年 5 月 15 日，UTC 时间 07:43 至 08:48 期间，GitHub Actions 出现了性能下降，导致部分客户的工作流程运行失败或启动延迟。此次事件是由 GitHub Actions 使用的支持基础设施的计划故障转移触发的。在该操作过程中，一个自动的服务发现更新未能正确传播，导致流量被错误路由，从而增加了工作流程编排核心依赖项的请求超时。

在影响高峰期，42% 的 Actions 运行失败。依赖 Actions 工作流程执行的下游服务也受到影响，包括 GitHub Pages 和 Copilot 云服务。UTC 时间 08:12，响应人员手动纠正了服务发现路由问题。超时和失败率很快恢复，我们继续监控，直到所有受影响服务完全稳定。事件在 UTC 时间 08:48 被标记为已解决。

为防止再次发生，我们正在采取多项措施。首先，我们正在实施故障转移防护措施，在完成故障转移操作之前验证服务发现状态。其次，我们正在加强验证检查。最后，我们正在提高对依赖项的耐受性，以减少基础设施事件期间的超时级联效应。

UTC 时间 5 月 26 日 10:57（持续 2 小时 21 分钟）

2026 年 5 月 26 日，UTC 时间 10:40 至 12:56 期间，GitHub Actions 的任务出现了性能下降。UTC 时间 10:40 至 12:16 期间，所有新排队的运行均无法启动。UTC 时间 12:16 至 12:56 期间，需要下载操作以执行其工作流程的运行继续失败。GitHub Pages、Copilot 代码审查、Copilot 编码代理、Octoshift 和 GitHub 企业导入器也受到影响，因为它们依赖于 GitHub Actions。

这是由于我们的自动化账户审查系统错误地暂停了 GitHub Actions 用于认证工作流程运行和下载操作的服务账户。

我们通过在 UTC 时间 12:16 恢复该账户、在 UTC 时间 12:20 将其标记为免于进一步的自动化审查，并在 UTC 时间 12:48 重新部署相关服务以清除缓存的账户状态来缓解问题。在 UTC 时间 12:56 确认了完全恢复。

在此次事件中，当服务账户被禁用时，少量的问题、pull request、评论和讨论被标记为隐藏。没有数据丢失。所有因此次事件而隐藏的内容已恢复，并且完整的搜索索引恢复已完成。

为防止类似情况再次发生，我们已添加了一个允许列表，列出了所有无法被自动化系统暂停的服务账户，并确保这些保护措施在所有账户管理工具中得到一致执行。我们还在改进账户的诊断工具，减少缓存传播延迟，以缩短未来应对类似事件所需的时间。

5月28日 19:01 UTC（持续1小时40分钟）

2026年5月28日，UTC时间18:27至20:41之间，由于上游提供商的Responses API出现问题，影响了GPT-5.2、GPT-5.3-Codex、GPT-5.4和GPT-5.5模型，GitHub Copilot服务因此降级。通过Responses API路由到这些模型的请求出现了较高的错误率，这也影响了Copilot代码代理和Copilot代码审查。其他模型未受到影响。

我们通过将流量转移到未受影响的模型上，同时上游提供商部署了修复措施，缓解了此次事件。

GitHub正在努力改进受影响模型的自动故障转移机制，并加强监控，以防止未来发生类似事件。

• * *

请关注我们的状态页面，以获取状态变化和事件后回顾的实时更新。想要了解我们正在开展的工作，请查看GitHub博客上的工程部分。

作者