2026 年 9 月 9 日，GitHub 发布 2026 年 8 月可用性报告。

5 起事故分别发生在 8 月 6 日、17 日、20 日、26 日和 27 日，GitHub Actions、Issues、Pull Request、Copilot 等服务受到不同程度影响。

8 月 6 日的事故持续 10 小时 42 分钟，主要影响 GitHub Actions，以及依赖 Actions 的 Copilot coding agent、Copilot code review、GitHub Pages、Dependabot 和代码库迁移等功能。

事故由一次 GitHub Actions 内部服务的常规部署触发。

部署过程中，一个数据中心运行中的 Pod 数量短暂减少。

GitHub 表示，部署的代码内容本身并没有问题，真正的问题是相关 Actions 服务此前已经接近容量和并发上限。随着流量转移至其他节点，剩余容量很快耗尽。

随后，服务网格 Sidecar 出现 CPU 限流和内存不足重启，并进一步引发缓存、DNS 和 API 错误。

核心服务开始恢复后，任务分配路径中的一个潜在 Bug 又拖慢了恢复速度。部分 Runner 收到已经失效的任务后不断重试，没有继续领取正常任务，造成任务积压进一步扩大。

GitHub 表示，至少 74 个组织出现 Actions 工作流无法启动、执行中失败或排队时间远超正常水平等问题。

8 月 17 日的事故持续 7 小时 35 分钟，Issues 和 Pull Request 受到的影响最为明显，REST 和 GraphQL API、GitHub Actions、Copilot、登录认证和 Webhooks 等服务也出现错误或延迟。

事故的直接原因是流量达到新的峰值，令一个数据中心的负载均衡系统超过容量上限。

其中一个服务网格 Sidecar 达到并发限制后没有及时扩容。随着请求不断积压，多台负载均衡节点耗尽网络连接能力，共享认证链路随后出现延迟和失败。

事故期间还存在一个客户端重试 Bug。该 Bug 向一个内部认证接口不断发送额外请求，进一步放大流量压力，也拖慢了 Copilot Token Service 的恢复。

故障高峰期，受影响服务 56.07% 的入口请求失败或响应缓慢。

整个事故期间，约 2.9 万个组织至少遇到一次失败或慢请求，相关请求总量约 480 万次。

GitHub 表示，没有数据丢失。

8 月 20 日的事故持续 9 小时 54 分钟，主要影响 Copilot cloud agent 的任务状态和结果更新。

Copilot cloud agent 会将每个 Agent 任务的状态和结果存储在一个托管云数据库中。当时，该数据库的一个区域发生供应商侧故障，相关区域的读写请求开始失败或变慢。

随着数据库延迟升高，负责将任务状态写入数据库的处理器无法及时处理数据，积压不断增加。

问题进一步扩大，是因为数据库的一项存储配置导致故障区域切换速度过慢。

GitHub 最初尝试进行区域故障转移，但没有成功，随后只能强制下线故障区域，将任务状态处理迁移至健康区域。

至少 54 个组织受到影响，部分 Copilot cloud agent 任务的状态和结果延迟最高达到 60 至 90 分钟。

不过，Agent 任务本身仍然正常运行并最终完成，没有工作丢失。

受到影响的主要是用户看到的任务状态和结果更新。

8 月 26 日的事故持续 2 小时 50 分钟，主要影响 GitHub Actions 任务启动，同时波及部分 GitHub Pages 部署和 Copilot code review。

GitHub 共享基础设施服务没有跟上 GitHub Actions 按月增长的业务量和峰值负载。

事故发生在日常流量高峰期间。

当时，一个 Actions 依赖的共享数据库已经接近容量极限，又有一批事件集中进入系统，写入和查询压力迅速上升，数据库主节点最终达到饱和状态。

数据库过载后，负责将事件转换为 Runner 任务的内部服务无法及时处理请求，Actions 任务开始大量排队或无法启动。

故障高峰期，每分钟超过五分之一的 Actions 任务启动失败或严重延迟。

GitHub 表示，至少 24 个组织出现明显的任务启动失败或严重延迟，累计 386 个组织出现了不同程度的任务启动异常。

GitHub 尝试将数据库主节点切换至副本，但只能短暂缓解问题。

事故期间，GitHub 还发现系统没有自动熔断机制，无法在数据库刚出现压力迹象时自动限制进入 Actions 的流量。工程师只能手动调整限流参数，让数据库逐步恢复。

8 月 27 日的事故持续 2 小时 8 分钟，影响 GitHub Copilot 中的 Kimi K3 模型。

GitHub 表示，Kimi K3 由一家上游模型供应商提供服务。当时，该供应商出现服务性能下降，导致大量 Kimi K3 请求失败。

事故期间，63.3% 的 Kimi K3 请求失败。

使用其他模型的用户没有受到影响。

使用 Copilot Auto 模式的请求会被路由至其他模型，可正常工作。

GitHub 的上游供应商完成修复后，恢复服务。

GitHub 表示将研究为 Kimi K3 增加备用服务容量，降低单一供应商故障造成的影响。

连续发生的故障也促使 GitHub 加快基础设施扩容和向微软Azure 迁移。

8 月 11 日，GitHub 首次在 Azure 上运行生产环境 MySQL 主节点，8 月 27 日又迁移了两个主节点。

GitHub 还将认证核心的 24 张表迁出其最老的共享数据库 mysql1，使相关副本每秒减少约 100 万次查询；其他查询优化又减少约 12 万 QPS。

GitHub Actions 同样获得了新增容量。

通过调整任务路由，GitHub 将 33% 的任务从容量受限的生产集群迁移至空闲资源，使缓存系统峰值 CPU 利用率从 98% 降至 80%。

不过，GitHub 估计，这部分新增容量只能提供约 3 个月的缓冲时间，并强调这只是短期措施，长期仍需要继续扩容并增强不同服务之间的隔离能力。

接下来，GitHub 还将继续迁移数据库主节点，将更多服务和流量迁往 Azure，同时改善共享数据库健康状况，并增加容量管理和自动扩容能力。

GitHub 将当前的基础设施优先级概括为一句话：“可用性，然后是容量，最后才是功能。”

云头条声明：如以上内容有误或侵犯到你公司、机构、单位或个人权益，请联系我们说明理由，我们会配合，无条件删除处理。