摘要
2026-02-09，GitHub 经历两段相关的可用性降级，影响 github.com、API、Actions、Git（HTTPS）操作、Copilot 等；第一段 16:12–17:39 UTC，第二段 18:53–20:09 UTC，累计约 2 小时 43 分。根因是用户设置缓存机制的一次配置变更，导致大量缓存重写同时发生。
时间线
- 16:12 UTC :: 第一段开始，页面加载错误、HTTPS Git 推拉失败、Actions 失败、Copilot 报错
- 17:39 UTC :: 第一段恢复（禁用异步缓存重写 + 重启 Git 代理）
- 18:53 UTC :: 第二段开始（另一缓存更新源产生大量同步写，复制延迟再触发连接耗尽）
- 20:09 UTC :: 全面恢复
根因
用户设置缓存机制的一次配置变更（将缓存刷新间隔从 12 小时改为 2 小时），使本分散在 12 小时内的缓存重写被压缩进 2 小时，形成密集的「缓存重写风暴」；异步重写压垮负责协调后台任务的共享基础设施组件，级联导致代理 HTTPS Git 操作的 Git 代理连接耗尽，无法接受新请求。
放大因素
初次缓解后，另一处未被覆盖的缓存更新源产生大量同步写，造成复制延迟，以相似模式再次级联并再次耗尽 Git 代理连接，引发第二段中断。
缓解措施
禁用异步缓存重写并跨多数据中心重启 Git 代理；禁用该缓存重写源并再次重启；优化缓存机制以避免写放大并加入批量更新时的自节流；为缓存系统变更增加回滚响应与发布校验；修复 Git HTTPS 代理连接耗尽的根因，使其可自动恢复。
经验教训
一个缓存 TTL 的数字改动即可引发平台级风暴；带写放大的缓存/批量机制必须有自节流与发布校验，且任何缓解需覆盖全部更新源，否则会二段复发。
检查清单
- 缓存/批量机制加入写放大防护与自节流
- 缓存系统变更强制回滚响应与发布校验
- 缓解措施须覆盖全部更新源
- Git 代理层实现连接耗尽的自动恢复