GitHub 服务可用性报告：2026 年 9 月

GitHub 于 2026 年 10 月 14 日发布 9 月服务可用性报告。8—9 月的主要变化是分流共享数据库、增加过载控制、隔离故障，并将部分生产负载迁至 Azure，但全部迁移目标尚未完成。

截至 10 月 7 日，GitHub 称 160 个生产服务中已有 120 个部署至 Central US，51 个主 MySQL 数据库中迁移了 13 个。Azure 分别承担核心应用读流量 65.4%、Git 读流量 48.3% 和流处理流量 80.2%；这些口径对应不同负载，不能相加。

容量与数据库治理

• 9 月 11 日因可用区容量不均，GitHub 暂停 Central US 部署和流量提升，9 月 18 日恢复永久扩容，但错过 9 月 30 日的全部迁移目标；10 月底释放全部可用容量的计划仍待验证。
• 计划内数据库切换时，自动紧急流程断开 Central US 副本并影响当地客户，GitHub 随后在计划切换期间禁用该流程。另有 24 个认证核心表移出最老的共享数据库，其副本每秒约少承担 100 万次查询。
• 问题与拉取请求数据库集群清除约 9.8 亿行无用编辑历史，预计释放 1.8 TB 可恢复存储；周死锁数较 6 月峰值下降约 77%，并加入持续清理。
• 抽样拉取请求流量中，一半可在共享依赖故障时保留有限功能；数据库路由可在峰值自动扩容，9 月 23 日一个实例组由 14 个增至 19 个。过载控制可先拒绝低优先级请求，以保护 API 和网页流程。

GitHub Actions 的运行余量

GitHub 称，生产调整使 Actions 相关 Redis 操作数减少约 28%、相对 CPU 使用量减少约 30%；基础设施缓存使 Redis 带宽下降 84%、平均响应时间下降 66%，主要 inventory 请求的中位响应时间下降 96%，排队请求减少 95%。这些是厂商内部测量结果，并非独立基准。

9 月 13 日：共享数据库过载

后台清理任务的保护机制只观察副本延迟，未计入主库负载，任务持续写入至连接耗尽；缺少快速超时和令牌写请求重试又延长了恢复。问题与拉取请求操作、API 调用、令牌创建、Actions 启动和注册可能失败或变慢。官方事件页记持续 1 小时 28 分，影响摘要记约 2 小时，口径不一致。约 96% 的网页问题创建请求、90% 的新用户注册和约 4% 的 Actions 工作流受到间歇性影响。GitHub 暂停任务并降低内部负载后恢复，后续将增加容量感知控制、减少失败重试并限制慢调用影响。

9 月 28 日：Copilot 代码审查交付不完整

一次变更使部分客户只收到不含评论的精简结果，而非完整审查结果；系统仍报告任务成功，监控也未及时发现缺失结果。部分请求延迟约 30 分钟至 2 小时；github.com 上部分审查正常完成，数据驻留区域未完成。事件页记持续 52 分钟，影响摘要记约 2 小时 45 分，同样存在口径差异。GitHub 回滚变更并建议客户重新发起审查，后续将加强交付保障、失败自动恢复和更早告警。

如何理解这些改进

这些改动已进入生产，但 10 月底容量目标仍未验证。GitHub 回顾的 Actions 中断、github.com 中断、数据库切换故障和受控暂停表明，指标只有转化为真实故障中的客户风险改善才有意义。其给出的优先级仍是：先可用性，再容量，最后功能。

资料来源：GitHub availability report: September 2026（2026-10-14）。