摘要
2026 年 2 月 9 日（周一），GitHub 发生高影响全局故障：负责认证与用户管理的核心数据库集群过载，导致 github.com、API、GitHub Actions、Git 操作乃至 Copilot 同时失效。直接诱因是 2 月 7 日（周六）为快速上线新模型，将用户设置缓存的刷新 TTL 从 12 小时改为 2 小时，叠加两个高调用量客户端应用的无意改动带来 10 倍以上读流量，在周一峰值与新模型发布共振下击穿数据库集群。
时间线
2026-02-07为加速新模型上线，将用户设置缓存刷新 TTL 由 12h 改为 2h（周末低负载，未触发告警）
2026-02-09 早高峰常规峰值 + 大量用户升级到新版本客户端 + 又一次新模型发布，读写压力叠加
2026-02-09 事中认证/用户管理数据库集群过载，依赖该集群的服务连锁失效，连接耗尽
2026-02-09 数小时后识别 TTL 为元凶并回退，但读流量持续攀升的根因排查耗时更久，最终恢复
根因
核心数据库集群同时承载认证与用户管理数据，且用户设置以「每用户数 KB」存储于该集群（早期为简单性选择，随模型与治理策略增长而膨胀）。2 月 7 日 TTL 12h→2h 的改动把原本分散在 12 小时的缓存重写压缩进 2 小时，形成密集「缓存重写风暴」，异步任务队列被打爆；同时两个流行客户端应用的无意改动带来 10 倍以上读流量，在周一峰值与新模型发布共振下彻底压垮集群。TTL 改动被快速识别，但读流量持续攀升的根因（客户端升级 + 模型发布）排查更久，延长了故障。
放大因素
- 架构耦合：认证/用户管理数据与普通用户设置共置于同一核心集群，局部问题级联全平台
- 缺乏细粒度限流/熔断开关，无法在上游精准阻断异常流量
- 监控粒度不足，未能在 TTL 改动后、峰值到来前捕捉潜伏的负载异常
- 周末低负载掩盖了 TTL 改动的风险，周一峰值才暴露
缓解措施
- 重构用户设置存储，将其从认证核心集群剥离
- 补齐负载丢弃（load shedding）与限流能力
- 提升端到端监控与早期信号告警
- 加强客户端发布与模型上线的容量评估
经验教训
- 一个缓存 TTL 数字（12→2）即可击穿全局：配置变更的影响面需做全链路推演
- 认证等核心路径必须与普通业务数据隔离，避免单点耦合
- 周末低负载下的「正常」不代表上线后安全，需在变更窗口内模拟峰值
检查清单
- 缓存 TTL / 刷新频率类变更是否做过写入放大估算
- 核心认证集群是否与普通用户数据物理/逻辑隔离
- 是否具备上游按流量来源精准限流的能力
- 模型/客户端发布是否与容量评估绑定
- 变更后是否在峰值前设置早期负载告警