GitHub 可用性报告：2026 年 4 月

分享：
[](https://x.com/share?text=GitHub%20可用性报告%3A%202026年4月&url=https%3A%2F%2Fgithub.blog%2Fnews-insights%2Fcompany-news%2Fgithub-availability-report-april-2026%2F)
[](https://www.facebook.com/sharer/sharer.php?t=GitHub%20可用性报告%3A%202026年4月&u=https%3A%2F%2Fgithub.blog%2Fnews-insights%2Fcompany-news%2Fgithub-availability-report-april-2026%2F)
[](https://www.linkedin.com/shareArticle?title=GitHub%20可用性报告%3A%202026年4月&url=https%3A%2F%2Fgithub.blog%2Fnews-insights%2Fcompany-news%2Fgithub-availability-report-april-2026%2F)

4 月，GitHub 各项服务共发生 10 起事件，导致整体性能下降。

为提升透明度，我们于 4 月底发布了一篇博客文章，详细说明了 4 月 23 日和 4 月 27 日发生的两起重大事件。此外，我们还采取措施进一步丰富 GitHub 状态页的信息内容。

感谢您在我们持续推进短期与长期投入过程中的耐心等待。

4 月 1 日 15:02 UTC（持续 8 小时 43 分钟）

2026 年 4 月 1 日，北京时间 14:40 至 17:00（UTC），GitHub 的代码搜索服务完全不可用，100% 的搜索请求失败。服务于 17:00 UTC 恢复至降级状态，返回结果存在临时性陈旧问题；最终于 23:45 UTC 完全恢复，所有搜索结果均反映最新数据。

在长达 2 小时 20 分钟的完全不可用期间，100% 的代码搜索请求均失败。首次恢复后（17:00 UTC），搜索功能虽可返回结果，但无法体现当日约 07:00 UTC 之后对仓库所作的任何变更。索引系统于 23:45 UTC 完成全部补全。

此次故障源于一次常规基础设施升级——为支撑代码搜索的消息系统进行升级时，一项自动化变更执行过于激进，导致内部服务间协调失败，进而中断搜索索引进程，使搜索结果逐渐陈旧。在团队紧急修复消息基础设施过程中，一次非预期的服务部署意外清除了内部路由状态，致使陈旧问题进一步升级为全面服务中断。

我们通过受控重启成功恢复消息基础设施，重建各服务间的协调机制；随后将搜索索引重置至故障发生前的某个时间点。仓库数据本身未丢失——搜索索引仅为基于 Git 仓库生成的二级索引，而原始 Git 仓库完全未受影响。待重新索引完成后，所有搜索结果均准确反映仓库当前状态。

后续我们将引入更渐进式的升级流程与更完善的健康检查机制，以便在问题蔓延前及时发现；强化部署防护措施，防止在活跃故障期间发生非预期变更；开发更快捷的恢复工具以缩短服务恢复时间；并增强流量隔离能力，避免突发流量高峰在故障期间引发连锁影响。

4 月 1 日 16:06 UTC（持续 4 分钟）

2026 年 4 月 1 日，北京时间 15:34 至 16:02（UTC），由于凭证轮换失败，我们的审计日志服务与其后端数据存储失去连接。在此 28 分钟窗口期内，审计日志历史记录无法通过 API 或网页界面访问，导致 4,297 个 API 调用方及 127 名 github.com 用户收到 5xx 错误。此外，该时段内产生的审计事件在 github.com 及事件流中最多延迟达 29 分钟。值得注意的是，无任何审计日志事件丢失——所有事件最终均被成功写入并正常流式传输。使用 GitHub Enterprise Cloud 并启用数据驻留功能的客户未受本次事件影响。

我们在故障发生 6 分钟后（即 15:40 UTC）收到基础设施告警，并通过重启受影响环境快速解决问题，于 16:02 UTC 全面恢复服务。事后，我们已落实多项改进措施以降低同类事件复发风险并提升检测能力：团队优化并加固了凭证轮换流程，以增强系统韧性、防范未来类似故障；同时，我们升级了监控配置，包括调低告警触发阈值，从而加快问题识别速度，并提升运维人员对同类异常的可见性。

4 月 9 日 09:50 UTC（持续 25 分钟）及 16:20 UTC（持续 4 小时 16 分钟）

2026 年 4 月 9 日，我们共发生两起故障：第一起发生于协调世界时（UTC）09:05 至 19:05，第二起发生于 UTC 16:05 至 20:36。在此期间，Copilot 编码智能体（coding agent）服务性能下降，用户在启动新的智能体会话时遭遇显著延迟。四次独立的中断波次中，约 84% 的新智能体会话请求被延迟，队列等待时间峰值达 54 分钟，远高于正常基线的 15–40 秒。该服务平均错误率达 83.9%，峰值高达 97.5%。本次事件共导致约 22,700 次工作流创建操作被延迟或失败。

根本原因在于速率限制逻辑中存在一个缺陷：该逻辑错误地将速率限制全局应用于所有用户，而非按触发限流的单个安装（installation）进行作用域隔离。另一促成因素是某次客户端更新引发 API 流量激增，导致对某一内部端点的请求量增长至原来的 3–4 倍，从而加速了速率限制配额的耗尽。第二次类似故障同样由某内部服务超出 API 速率限制所致，并叠加了一个缓存缺陷——该缺陷使“已被限流”的状态在实际速率限制窗口结束后仍持续存在，进而引发反复中断。

我们的团队在 15 分钟内即检测到问题并立即展开调查。为缓解故障，我们通过功能开关（feature flag）禁用了有缺陷的速率限制缓存机制，并更新服务以在 API 调用中使用按安装粒度生成的凭据，确保速率限制能正确限定在各独立安装范围内。服务于 UTC 20:36 全面恢复。中断期间被延迟的任务已进入队列，并在服务恢复后完成处理。

此后，我们已新增自动化监控与告警机制，以主动识别此类故障模式；部署了多项修复措施，通过优化缓存策略减少不必要的 API 流量；并持续推进工作，进一步按客户端类型隔离速率限制的作用域，以防未来再次发生同类问题。

2026 年 4 月 13 日 19:56 UTC（持续 39 分钟）

2026 年 4 月 13 日，GitHub Pages 服务于 UTC 18:53 至 20:30 期间出现错误率上升。该服务平均错误率为 10.58%，峰值达 12.77%，共造成约 1750 万次请求返回 HTTP 500 错误。

此次故障源于一款自动化 DNS 管理工具的误操作：其上游数据源曾短暂未能返回某 GitHub Pages 后端存储主机的 DNS 记录，该工具遂将该记录误判为“过期”，并将其错误删除。随着系统各处缓存的该 DNS 记录陆续过期，GitHub Pages 服务器便无法再访问受影响的存储主机，从而导致部分请求失败。

问题定位后，我们的团队迅速追溯至缺失的 DNS 记录并立即重建。服务于 UTC 20:30 恢复正常，整个事件于 UTC 20:35 全面解决。我们认识到，本次故障的发现耗时较长（约 53 分钟），主要原因在于错误率呈渐进式上升，且我们此前缺乏针对此类故障类型的告警机制。

为防止类似问题再次发生，我们将重点推进三项改进：一是在 GitHub Pages 前端实现支持可用区容错的路由机制，确保当某个后端主机 DNS 解析失败时，系统可自动故障转移至健康主机，而非直接返回错误；二是增加防护机制，禁止自动化工具删除由其他系统所拥有的 DNS 记录；三是增强 GitHub Pages 服务路径中 DNS 解析失败的日志记录与告警能力。

2026 年 4 月 16 日 15:06 UTC（持续 3 小时 22 分钟）

2026 年 4 月 16 日，GitHub Codespaces 用户于 UTC 09:30 至 17:15 期间，在使用 VS Code 编辑器连接 Codespaces 时遭遇失败。此期间约 40% 的 Codespace 启动操作失败；但通过 SSH 方式连接的用户未受影响。

故障根源在于某上游服务异常，致使 Codespace 启动过程中无法成功获取 VS Code Server。我们通过实施一项临时方案缓解了影响：当主下载端点性能下降时，自动切换至备用下载路径。与此同时，我们协同上游依赖服务团队共同排查并修复了下载失败的根本原因。

后续，我们将持续优化回退（fallback）机制，以降低未来类似上游服务故障带来的影响；同时精简流程，加快同类变更的部署速度。

2026 年 4 月 20 日 13:28 UTC（持续 15 小时 36 分钟）

2026 年 4 月 20 日，GitHub 于 UTC 10:28 至 15:04 期间，代码扫描默认配置（code scanning default setup）、代码质量分析（code quality）及项目看板（project boards）服务均出现性能下降。其中，受影响项目看板的修复工作延续至 4 月 21 日 UTC 05:04。

在此期间，新打开的拉取请求（pull request）未触发代码扫描默认配置及代码质量分析；此外，新创建的问题（issue）亦未同步显示在项目看板上。

根本原因为一处序列化错误，导致代码扫描、代码质量分析及项目看板更新等关键事件无法被正确触发。

我们于约 40 分钟内定位问题，并通过部署修复补丁恢复了代码扫描与代码质量分析相关的事件发布功能。针对项目看板，我们额外部署了一项代码变更以更新事件消费者，并对受影响的项目条目执行了重新索引操作。

为避免问题重现，我们正加强数据结构（schema）校验机制，并提升对关键主题（topic）下事件发布量骤降的监控能力。此外，我们正在全面审计系统其他模块，确保不存在类似限制性缺陷。

2026 年 4 月 22 日 15:35 UTC（持续 3 小时 43 分钟）

2026 年 4 月 22 日，GitHub 用户于 UTC 15:16 至 19:18 期间，在 github.com 上使用 Copilot Chat 及 Copilot Cloud Agent 时遭遇错误。此期间，用户完全无法使用 Copilot Chat 或 Copilot Cloud Agent 功能；处于预览阶段的 Copilot Memory 功能亦在本次中断期间对所有 Copilot 智能体会话不可用。

该问题由一项基础设施配置变更引发，导致数据库连接异常。团队迅速定位了根本原因，并恢复了数据库连接。Copilot Chat 和 github.com 的 Cloud Agent 于 UTC 时间 18:16 恢复；其余区域部署逐步恢复，最终于 UTC 时间 19:18 全面恢复正常。

我们已采取措施，防止未来类似基础设施变更再次引发此类数据库操作故障。

4 月 23 日 16:12 UTC（持续 1 小时 18 分钟）

2026 年 4 月 23 日，UTC 时间 16:03 至 17:30 期间，用户在 GitHub Copilot、Webhooks、Git 操作、GitHub Actions、迁移（Migrations）及部署（Deployments）等服务中普遍遭遇错误率上升与性能下降。在长达 1 小时 27 分钟的影响窗口期内，约 5–7% 的整体流量受到影响。具体而言：

Copilot 方面：约 7% 的 AI 模型请求失败，约 10% 的 Copilot 云代理（Cloud Agent）会话受影响，约 9% 的 Copilot Insights 仪表板请求返回错误；
Webhooks 方面：峰值时段约 0.35% 的 API 请求返回错误，最多达 10% 的流量出现显著延迟（>3 秒）；
Git 操作方面：事件期间平均错误率为 1.25%，峰值达 2.07%；
GitHub Actions 方面：工作流运行状态更新延迟最高达约 8 秒；
迁移（Migrations）方面：0.88% 的活跃仓库迁移失败，79% 的迁移耗时明显增加；
部署（Deployments）方面：事件窗口期内部署功能一度被临时阻断。

问题根源在于某数据中心的 DNS 基础设施进入降级状态，开始间歇性地无法解析服务地址。这引发了连锁反应：所有依赖域名解析来调用内部 API、外部服务及存储系统的组件，几乎同时出现错误。

根本原因是近期为支持业务增长而分阶段上线的一项新流量均衡机制。在特定负载模式下，该机制导致 DNS 解析器开始失效。既有 DNS 缓存机制提供了部分保护——那些拥有近期缓存记录的服务仍能正常运行，因此整体影响被限制在约 5–7% 的流量范围内，而非全面中断。

在首次回滚相关配置未能解决问题后，我们重启了受影响的 DNS 基础设施。服务数分钟内即开始恢复，并于 UTC 时间 17:30 全部恢复正常。本次事件未造成任何数据丢失，所有仓库、数据库及工作流数据均完好无损。

为避免此类事件重演，我们正从以下几方面加强建设：

提升 DNS 基础设施韧性，防止单数据中心故障波及其他服务；
建立更安全的基础设施变更发布与验证流程，在专用环境中使用类生产流量进行充分测试；
加快自动化检测与自愈能力落地，针对 DNS 解析失败构建快速响应与自我修复机制；
审查各服务对共享基础设施组件的依赖关系，进一步收窄故障影响范围（blast radius）。

4 月 27 日 16:31 UTC（持续 6 小时 15 分钟）

2026 年 4 月 27 日，UTC 时间 16:15 至 22:46，GitHub 搜索服务因前置搜索基础设施的负载均衡层过载，出现连接质量下降。这导致依赖搜索数据的多项服务（包括 Issues、Pull Requests、Projects、Repositories、Actions、Package Registry 及 Dependabot Alerts）发生间歇性故障。不同搜索目标所受影响程度不一：在 UTC 时间 16:15 至 18:00 期间，部分服务高达 65% 的搜索请求超时或返回错误。

我们通过持续监控发现搜索结果数量骤降，并于 UTC 时间 16:21 正式宣布启动事件响应。事件于 UTC 时间 21:33 被标记为“已缓解”，随后我们持续监控系统直至 UTC 时间 22:46，确认服务完全恢复正常并正式宣告事件终结。

此次过载源于大量匿名分布式爬虫流量涌入，其设计刻意规避了 GitHub 公共 API 的速率限制。该爬虫流量占当日总搜索流量的 30%，但高度集中于四小时之内；源头覆盖超过 60 万个唯一 IP 地址，且所有请求中均携带一致的行为者标识信息。现有监控体系未能将此类激增的爬虫活动识别为风险，该维度的问题是在应急处置过程中才被发现。

为缓解影响，我们立即双线并行：一方面紧急减轻负载均衡器压力，另一方面同步推进负载均衡层扩容、屏蔽异常流量，并对均衡器参数进行精细调优，最终彻底解决事件。

面向未来，我们不仅完成了负载均衡层的扩容，还实施了多项优化以提升连接管理与复用效率，从而降低同类饱和事件再次发生的可能性；同时新增了平台级监控与管控能力，可主动限制匿名流量，最大限度保障注册用户的正常使用体验。我们仍在持续强化防御体系，以应对此类大规模自动化滥用行为。