GitHub在2026年9月可用性报告中披露了两起影响其服务性能的事故，同时基础设施重新分配和数据库承压能力方面也取得了进展。该公司表示，修复工作尚未完成，尽管已经实施了旨在降低高负载或某个共享组件发生故障时故障风险的变更。
截至10月7日，160项生产服务中有120项已部署在Central US区域，51个核心MySQL数据库中有13个已完成迁移。Azure处理了GitHub核心应用65.4%的读取流量、Git读取流量的48.3%以及流处理流量的80.2%。公司强调，这些比例对应不同的负载，不应将其相加。
基础设施迁移取得进展，但落后于计划
由于可用性区域之间的容量不均衡，GitHub于9月11日暂停了Central US区域的部署和流量增加。9月18日，在提供临时容量后，永久性流量增加工作恢复，但长期容量工作仍在继续，目标是在10月底前提供全部可用容量。公司未能实现其雄心勃勃的目标，即在9月30日前将所有生产服务部署到该区域。
在一次计划中的数据库切换过程中，自动化紧急措施导致Central US区域的数据库副本被断开，从而对该区域的客户造成影响。在改进恢复机制之前，GitHub已在计划中的交接操作期间禁用该措施。
降低数据库压力并遏制故障
GitHub将身份验证系统的24张表从其最老的共享数据库中迁出，从属副本每秒因此减少了约100万次查询。此外，支持Issues和Pull Requests的集群删除了修改历史中约9.8亿条不必要的记录，释放了约1.8太字节可恢复存储空间。每周事务冲突次数较6月峰值下降了约77%。
样本中一半的Pull Requests流量已经能够在共享依赖发生故障时，以功能受限的方式继续运行。数据库流量路由还可以在流量高峰期间自动增加容量；在9月23日Pull Requests活动增加期间，其中一个集群的副本数从14个扩展到19个。GitHub还增加了一套负载控制机制，可在服务达到更广泛的饱和状态之前拒绝优先级较低的请求。
9月的两起事故
9月13日，一项后台数据清理工作导致共享数据库负载增加。保护机制监控的是从属副本延迟，却没有监控主服务器上不断累积的负载，而主服务器最终达到可用连接上限。由于缺少较短的查询超时，请求处理程序一直处于等待状态；与此同时，重试循环仍在发送失败的写入操作。事故持续了1小时28分钟，最终在降低内部负载并停止该任务后结束。
9月28日，运行Copilot代码审查的服务发生变更，导致部分客户收到有限版本的审查结果，而不是包含评论的完整版本。因此，任务看起来已经完成，但审查结果并未显示在拉取请求中。事故持续了52分钟，GitHub通过回滚该变更进行了处理，并要求客户重新请求受影响的审查。
实际会发生哪些变化？
这两起事故表明，容量改进本身并不足够；可靠性还取决于及早发现故障、停止无效的重试操作，以及确保任务在其输出确实交付之前不会被宣布成功。GitHub正在增加后台处理控制措施，改进服务启动行为，并加强Copilot代码审查结果的监控和交付。
GitHub还记录了GitHub Actions基础设施方面的改进：Redis操作量下降了约28%，相对处理器使用率下降了约30%。独立的缓存层使Redis使用的带宽下降了84%，平均响应时间下降了66%，核心库存请求的中位响应时间下降了96%，等待中的请求下降了95%。仍待解决的问题在于，公司能否完成容量工作，并防止共享依赖在实际生产环境条件下再次发生故障。