GitHub availability report: June 2026

上个月，我们在月度报告中新增了一个部分，用于更新 GitHub 的可用性工作进展和相关基础设施投资情况。收到的反馈和提出的问题表明一个明确的事实：客户希望获得更多信息，而不是更少——即使消息是混合的。

6 月简要总结： 我们在架构层面取得了实质进展，当某个扩容计划出现异常时我们主动暂停了推进，并且我们错过了一个目标，现已重新设定基准线。

本月 Azure 中的单体流量在美国中部地区达到 45% 的峰值。这个数字低于我们的预期，因为 5 月 21 日的一次稳定性事件表明环境尚未准备好承载更多流量，因此我们暂停扩容约一个月。6 月 17 日我们重启扩容，新增了每阶段扩容前的稳定性验证机制，要求环境必须可验证健康后才能继续推进。以更谨慎的方式放慢速度是正确的选择——受控暂停优于在更高负载下重复学习相同的经验教训。

Azure 中的 Git 流量从 30% 上升至 43%（HTTP 和 SSH 合计），但未达到 50% 的 6 月目标。我们预计 Git 会暂时稳定在 45% 左右，这是出于两个刻意避免增加用户延迟的决策：我们正在等待更多 vPoP 流量路由至美国中部地区，而非回传 IAD HUB 的 Git 流量；目前仅路由 HTTP，因为 SSH 在边缘层没有读写分离能力。我们仍会优先推进此工作，但目前没有新的目标可供分享。我们将继续以尽可能快速且安全的方式推进，并在下次更新中报告具体数据。

在这些关键数据背后，我们实现了特别令人兴奋的进展。我们新推出的独立拉取请求服务 pullsd 现在已处理 100% 的匿名拉取请求读取请求，这些流量不再由单体服务提供。新推出的独立仓库服务 reposd 成为首个从 Azure 提供生产 REST 流量的独立服务，在主动因 Redis 容量限制降低负载前达到了 50% 的读取流量占比。整个过程没有发生任何事故，也未因压力进行回滚。一旦完成容量优化工作，该服务将重新提升负载。我们新推出的用户服务现已从主数据库卸载了 每秒约 50 万个查询峰值，身份验证和授权表的物理迁移预计在 7 月初完成。我们的 API 限流现已在网关处理了 约 97% 的请求，因此限流决策不再需要与单体内部的请求处理工作线程竞争。客户端数据库负载削减机制现已针对 5% 的真实生产流量运行，这意味着我们已获得实际证据证明：在压力情况下可以优先丢弃低优先级查询，避免其演变为面向用户的故障。此外，对于交互式生产访问和 ChatOps 变更，现在需要在整个流程中进行 双人确认，并配有统一的审计追踪记录。

事件分析报告呈现的是系统表现的另一面：系统运行良好的地方、存在的不足、我们已经做出的改进以及仍在持续优化的方面。我们始终遵循同样的原则：可用性优先，其次是容量，最后是功能。

• * *

2026年6月，我们经历了六起导致GitHub服务性能下降的事件。

6月4日 17:30 UTC（持续1小时25分钟）

2026年6月4日UTC时间17:30至18:55期间，github.com上的Copilot代码审查功能出现大量审查请求失败。受影响用户在提交代码审查请求时，会看到“Copilot发生错误”的提示。

在事件期间，平均有81.6%的Copilot代码审查请求失败，峰值失败率高达93.9%，总计约36,800次代码审查请求失败。支持数据驻留的GitHub Enterprise Cloud未受影响。

问题源于Copilot代码审查处理工作流使用的一个新发布的依赖项。该依赖项的发布与运行时环境存在兼容性问题。由于工作流自动获取最新版本，未经充分兼容性验证的版本被引入，导致审查处理失败。受影响的审查任务未能快速失败，许多任务持续运行直至超时。

我们通过移除问题依赖项版本并重新部署受影响的处理服务来缓解事件。新代码审查任务于UTC时间18:44开始恢复，失败率于UTC时间18:55恢复至基准水平。剩余超时任务于UTC时间19:59完成清理。

为降低重复风险，我们采取了以下措施：固定依赖项版本而非自动获取最新版本、为未来版本添加兼容性检查、改进审查处理器无法启动时的快速失败机制、为审查工作流添加更短的超时控制、以及增强审查完成失败的监控能力。

6月8日 06:30 UTC（持续2小时6分钟）

2026年6月8日UTC时间约06:30至08:36期间，未登录用户在访问拉取请求、问题、发布版本、补丁差异等github.com页面时持续遭遇HTTP 504错误。事件期间，受影响的github.com接口约17%的未认证请求返回网关超时错误，在UTC时间06:50左右达到峰值约34%。部分依赖发布版本下载或相关github.com接口的GitHub Actions工作流也受到影响。影响持续约两小时，且仅限于未认证流量；已登录用户未受影响。

问题源于特定github.com接口遭遇大量恶意自动化匿名流量的显著增长。由于未认证请求由专用的Web应用服务器池处理，导致我们处理未认证请求的能力下降，请求排队超过超时阈值并返回网关超时错误。

我们通过识别异常流量模式，并在负载均衡器和应用层实施针对性阻断来缓解事件。一旦阻断措施完全生效，错误率即恢复正常，受影响服务于UTC时间08:36完全恢复。

为降低未来发生类似事件的可能性和影响，我们正在改进对这些流量模式的自动化检测和阻断机制，优化紧急流量阻断的部署流程，并评估对已登录用户和自动化工作流共用端点的路由变更方案。

6月10日 15:05 UTC（持续1小时20分钟）

2026年6月10日UTC时间15:05至16:25期间，由于偶发的认证失败影响了约9%的请求，GitHub API服务出现可用性下降。REST和GraphQL API请求均受到影响。客户遇到间歇性“已登出”行为，错误的401（未授权）响应导致第一方和第三方应用集成触发重复认证流程。由于仅经过受影响基础设施的请求失败，同一客户端可能在一次请求成功后下一次请求失败，产生间歇性行为。受影响的请求还经历了约800ms的额外延迟，因为网关在返回错误前重试了认证。

内部API基础设施部署的memcached代理服务导致认证服务获取了错误的主机配置，引发间歇性认证查询失败。我们通过向memcached服务部署配置变更，使用正确的主机解决了该问题。

为防止未来出现类似问题，我们计划将认证系统迁移至新的缓存基础设施，以提高系统弹性并增强整体可靠性。同时我们正在改进网关区分短暂认证系统错误与真正无效凭证的机制，使临时查询失败不再表现为用户已登出。

6月16日 17:20 UTC（持续55分钟）

2026年6月16日UTC时间17:20至18:15期间，GitHub Copilot的Opus 4.8模型出现可用性下降。在此期间，部分对Opus 4.8的请求失败或报错。其他Copilot模型未受影响，仍作为替代方案可用。该问题由上游模型提供商的故障引起。

在问题持续期间，我们启用了降级模式通知功能告知受影响用户。上游提供商解决了问题，我们监控Opus 4.8直至成功率恢复正常。该事件已完全解决。

我们正在减少对特定模型单一推理提供商的依赖，通过在多个提供商之间平衡容量，使流量在上游故障时能够切换到健康容量。另外，我们加强了公共状态页面工具，确保事件更新可靠发布，改进了在缓解期间向客户传达信息的方式。

6月17日 03:50 UTC（持续54分钟）

2026年6月17日UTC时间约03:50至04:44期间，GitHub Copilot服务降级，其前沿聊天模型在所有地区暂时不可用。在此期间，受影响模型在网页、编辑器和CLI体验中的模型选择器中消失，或在选择时返回“模型不可用”错误。客户可通过选择仍可用的模型继续使用GitHub Copilot。该事件发生在非高峰时段，限制了受影响客户的数量。

由于生产系统将此次配置更改判定为无效，导致了这一问题。我们通过撤销该配置更改缓解了事件，随后受影响的模型在服务重新加载先前配置后自动恢复正常。

我们正在逐步推出配置更改，并加强验证机制，添加对可用模型数量突然下降的警报功能，同时对触发这些警报的配置更改自动执行回滚操作。

2026年6月25日 17:33 UTC（持续23分钟）

2026年6月25日UTC时间17:33至17:55期间，我们的后台作业服务出现性能退化，导致拉取请求、仓库推送、操作工作流和网络钩子的延迟显著增加，延迟峰值达到7分钟。该问题由底层虚拟机管理程序问题和突发的流量高峰引发，导致服务超时，进而引发连接风暴和持续的重新平衡操作。

我们在17:49替换受影响节点后，所有服务于18:07恢复正常。

为降低未来发生类似事件的可能性和影响，我们已提升后台作业处理对突发流量高峰的弹性，减少降级场景下的连接波动，分离关键节点以避免单个故障节点影响其他节点，并提前添加了对导致此次退化条件的预警机制。

• * *

请通过我们的状态页面获取状态变更和事件回顾的实时更新。想了解我们正在推进的工作，请查看GitHub博客的工程板块。

作者