2026年9月13日,协调世界时(UTC)08:43至10:44期间,GitHub 大约28项服务的可用性下降,受影响服务包括 Issues、Pull Requests、Actions、Codespaces、Pages、Notifications、Code Scanning、Git LFS 以及新账户注册功能。在高峰期,8.8%的 GitHub App 安装访问令牌创建请求失败。Actions 工作流的令牌签发也受到影响,在故障期间大约有4%的工作流受到波及。通过网页界面创建 Issue 的尝试中约有96%失败,注册失败率则超过90%。
故障原因是一个内部数据清理任务,该任务于07:33 UTC开始向一个共享数据库集群写入数据。该集群存储着几乎每个已认证请求都会读取的权限数据。用于控制该后台任务节奏的保护机制只监测了一个健康信号——数据库副本的延迟程度,而该信号在整个过程中一直保持较低水平。它没有考虑到主库本身正在累积的负载,因此该任务持续写入数据,而主库则在悄然逼近其极限。
当主库耗尽可用连接后,需要访问它的请求便无法完成。首先,这些数据库调用没有设置快速超时机制,导致请求处理程序在停滞的数据库上持续等待,而不是快速失败,这使得共享的请求处理能力退化为全站范围的错误。其次,令牌创建过程中的一个重试循环不断重新发送本已失败的写入请求,这使数据库持续处于饱和状态,无法得到恢复。
监控系统于08:50 UTC确认了此次故障,但由于影响范围广泛,加之令牌创建带来的放大效应,定位负载来源花费了一定时间。第一响应人员通过卸载内部负载并暂停该任务进行了缓解,所有服务已于10:44 UTC恢复正常。
为防止此类问题再次发生,我们默认对针对共享的、面向客户的数据库的后台任务进行限流,并新增基于主服务器负载(而不仅仅是复制延迟)的自动暂停和寻呼机制。我们还将在数据库健康信号旁直接展示正在运行的后台任务,以便响应人员无需离开这些仪表盘即可查看并暂停任务;同时对令牌签发路径中的重试次数设置上限,并新增请求级别的超时机制,以防止某一个不健康的数据库耗尽共享网页服务器的处理能力。此外,我们正在拆分这个数据库集群,以消除单点故障。在接下来的两周内,我们将把包括授权数据在内的各项特定服务数据迁出这个共享集群。
