GitHub availability report: September 2026

我们上一次更新涵盖了 8 月的内容。由于其他公开内容正在说明 8 月 17 日的中断事件，我们未在 9 月发布新报告。本期内容涵盖过去两个月的进展。

8 月和 9 月的简要总结：我们缓解了共享数据库压力，新增了过载控制机制，为 GitHub Actions 创造了容量空间，扩展了拉取请求的故障隔离范围，并将更多生产工作负载迁移至 Azure。重大事件、容量暂停以及未达成的迁移目标表明，相关工作尚未完成。

截至 10 月 7 日，160 个生产服务中有 120 个已部署至美国中部区域，51 个主要 MySQL 数据库中有 13 个已完成迁移。Azure 当前处理了 GitHub 核心应用 65.4% 的读取流量、Git 读取流量的 48.3% 以及流处理流量的 80.2%。这些百分比反映的是不同工作负载，不应简单相加。

由于可用性区域间的容量分布不均，我们于 9 月 11 日暂停了美国中部区域的部署和流量增长。临时缓解后，9 月 18 日恢复了逐步扩容，但持久性容量优化工作仍在继续，目标是到 10 月底前释放所有可用容量。我们未能实现 9 月 30 日将所有生产服务迁移至该区域的激进目标。在一次计划中的数据库故障转移过程中，自动化应急流程意外断开了美国中部区域的数据库副本，导致该区域客户中断。我们已在计划交接期间禁用该流程，同时改进恢复机制。

除区域迁移外，24 个认证核心表已从 GitHub 最古老的共享数据库迁移出去，每秒减少约 100 万次查询请求。支撑问题和拉取请求的数据库集群清理了约 9.8 亿条冗余编辑历史记录，释放了约 1.8 太字节的可恢复存储空间。每周死锁数量较 6 月峰值下降约 77%，持续清理机制现已防止同类无限制增长问题重现。

目前，当共享依赖项失效时，一半采样拉取请求流量可有限功能继续运行。生产环境数据显示，在共享数据库事件期间，多个读取操作仍保持可用。数据库流量路由机制也能在流量高峰时自动扩容；9 月 23 日拉取请求活动激增期间，某组实例数量从 14 个扩展至 19 个。生产环境现部署了过载控制机制，允许响应者在更广泛饱和前拒绝低优先级请求，以保护高优先级 API 和 Web 工作流。操作文档和培训已全部完成。

GitHub Actions 的运营容量也获得提升。生产环境变更使 Redis 操作量减少约 28%，相对 CPU 使用率下降约 30%。独立的基础设施缓存使 Redis 带宽减少 84%，平均响应时间缩短 66%，主要库存请求的中位响应时间缩短 96%，排队请求数量减少 95%。

8 月 6 日的操作中断、8 月 17 日的 github.com 中断、9 月的故障转移中断以及受控容量暂停事件提醒我们，只有在真实场景下降低客户风险时，可衡量的改进才有意义。核心原则始终如一：先确保可用性，再提升容量，最后添加功能。

• * *

9月13日 09:16 UTC（持续1小时28分钟）

发生了什么？

问题原因

后台数据清理任务增加了共享数据库的负载。该任务设计了保护机制，当数据库副本滞后时会减缓写入速度，但该机制未考虑主数据库服务器的入站负载。因此，任务持续运行直至主数据库达到连接限制。当主数据库连接耗尽时，依赖它的请求无法可靠完成。

另外两个因素加剧了影响并延迟了恢复。首先，这些数据库调用没有快速超时机制，导致请求处理程序在数据库阻塞时等待而非快速失败。其次，围绕令牌创建的重试循环持续发送已失败的写入请求，使数据库保持饱和状态而非恢复。

我们如何应对？

1. 后台数据清理任务开始向共享数据库写入数据。
2. 该任务的保护机制监控副本延迟，但未考虑主数据库服务器的负载增长。
3. 主数据库连接耗尽，导致依赖服务的请求失败或运行缓慢。
4. 自动监控检测到事件，并将故障追溯到共享数据库的负载。
5. 我们减少了内部负载并暂停了后台任务。
6. 数据库恢复后，受影响服务的错误率恢复正常。

我们如何减少类似事件的发生或影响？

• 我们正在实施额外的保护机制，以提高数据库弹性和服务可用性。这些措施将更好地根据数据库可用容量控制后台处理，减少故障期间不必要的重试，并限制缓慢数据库请求的影响。
• 我们还改进了服务启动行为，确保临时数据库连接问题不会影响服务恢复。

9月28日 21:16 UTC（持续52分钟）

发生了什么？

问题原因

Copilot代码审查使用独立服务执行审查，并返回两种版本的结果：一种是排除审查评论的精简版，另一种是包含完整审查结果的完整版。Copilot代码审查仅从完整版发布审查结果。该服务的一项更改开始仅向部分客户发送完整版，而向其他客户仅发送精简版。

因此，Copilot代码审查无法生成审查结果，但报告称任务已成功完成。由于缺乏监控，缺失的审查结果未被检测到。由于部分审查在30分钟后仍未完成，触发了向一线响应人员的警报，从而发现了这一事件。

我们通过撤销更改来缓解了此次事件。

我们是如何应对的？

1. 运行Copilot代码审查的服务发生变更并开始逐步部署，审查结果停止显示在拉取请求中。该变更影响了所有环境。
2. 审查开始超时，触发了Copilot代码审查团队的警报。我们宣布了此次事件。
3. 我们将故障追溯到此次变更，并开始撤销该变更。
4. 在撤销操作完成所有必要检查的同时，我们在GitHub状态页面上发布了此次事件。
5. 撤销操作覆盖了所有受影响的区域。我们解决了此次事件，并建议客户重新请求受影响的审查。

我们如何减少类似事件的发生或降低其影响？

• 我们通过在整个审查和交付流程中增加保护措施，来提高Copilot代码审查的可靠性。这些改进将有助于确保已完成的审查能够成功交付，允许失败的审查自动恢复，并在出现问题时提供更早的通知。
• 我们还改进了监控和部署流程，以便更快地发现和解决问题。

• * *

请关注我们的状态页面，获取状态变更和事件后总结的实时更新。想要了解我们正在推进的工作，请查看GitHub博客上的工程板块。

作者

探索更多GitHub内容

文档

一站式掌握GitHub所需的一切。

前往文档

GitHub

在GitHub上构建未来，这里是任何人都能从任何地方构建任何事物的地方。

立即开始构建

客户案例

了解使用GitHub构建产品的公司和工程团队。

了解更多

GitHub Universe 2026

10月28日至29日，加入我们在旧金山或在线举办的GitHub Universe，这是我们的旗舰开发者大会，汇聚了人们、代理和全球代码。

立即注册