GitHub披露了2026年8月影响其服务可用性的五起事件详情，其中包括GitHub Actions故障、Copilot Cloud Agent结果延迟，以及Kimi K3模型请求失败。该公司将这些事件归因于平台增长和容量余量收窄，以及自动扩展、重试策略和恢复机制方面的缺陷。
GitHub表示，正在投资改进架构并将更多服务迁移至Azure，同时优先考虑可用性，其次是容量，最后是功能。该公司还宣布改进容量监控、队列管理、重试策略以及核心服务的韧性。
五起原因各异的事件
- 8月6日：事件持续了10小时42分钟。由于对Actions的一项内部服务进行例行部署，某个站点的容量暂时下降，导致服务饱和，并将错误扩散至缓存、DNS和API接口；随后，任务分配路径中的一个缺陷又拖慢了恢复过程。大量工作流运行失败或延迟，部分事件不得不手动重启。
- 8月17日：性能下降持续了7小时35分钟，原因是数据中心的负载均衡器达到容量峰值，同时服务网络中的一个旁路组件在达到并发上限后未能扩展。这导致共享身份验证路径延迟和失败，影响扩大至Issues、Pull Requests、API接口、Actions和Copilot。此外，重试机制中的一个缺陷使发往内部身份验证节点的请求流量增加了一倍。
- 8月20日：事件持续了9小时54分钟，至少影响了54家组织的Copilot Cloud Agent任务状态和结果。存储任务状态的云数据库服务商的一个区域发生故障，由于存储配置问题，区域切换未能快速完成，导致状态更新积压。任务本身没有丢失，但结果显示出现延迟，直到处理恢复并清空队列后才恢复正常。
- 8月26日：性能下降持续了2小时50分钟。一批事件使一台原本已接近上限的共享数据库达到饱和，导致Actions运行启动延迟，并影响依赖该数据库的服务，例如Copilot Code Review和部分GitHub Pages操作。GitHub需要逐步限制传入负载，因为当出现压力指标时，没有自动熔断器启动保护。
- 8月27日：事件持续了2小时8分钟，仅影响Copilot中发往Kimi K3模型的请求，原因是外部模型供应商出现性能下降。事件高峰期，这些请求的失败率超过一半，而其他模型和Auto设置仍然可用。
实际发生了哪些变化？
已公布的措施表明，GitHub将这些事件视为容量、隔离和恢复问题，而不仅仅是单次部署错误。该公司已将33%的Actions作业从受限生产集群迁移至备用容量，使高峰期缓存处理器使用率从98%降至80%，并据其估算增加了约三个月的余量。此外，迁移至Azure的服务读取量峰值为60.4%，单体系统读取量为64.3%，Git读取量为54%。
在数据库层面，首个Azure生产MySQL主数据库于8月11日启用，客户可观测到的写入操作未受到明显影响；8月27日，另外两个核心数据库也采用了同样的方式。此外，GitHub从旧版数据库副本中移除了每秒约100万次查询，其他改动还减少了每秒12万次查询，并将每小时约5.9万秒的浪费工作量降了下来。
为什么这份报告很重要？
这些事件表明，当服务共享数据库、身份验证路径或同一套Actions基础设施时，仅依赖横向扩展并不足够。不受控制的重试还可能将局部性能下降转化为更广泛的负载；与此同时，区域切换延迟可能导致状态积压，即使原始任务并未丢失。Azure计划、隔离措施和负载熔断器仍在实施中，因此该报告并不能证明风险已经消除；它说明了GitHub下一阶段工作的重点：迁移更多核心数据库、自动化容量管理，以及扩大对依赖项故障的处理能力。