2025年11月18日，Cloudflare遭遇了一次罕见的全球性系统故障，导致其核心服务（包括CDN、安全防护、用户登录、仪表盘等）中断近6小时。最初，工程师们误以为这是一场大规模网络攻击，但最终发现故障根源竟是一个内部配置文件更新错误。
故障时间线：从误判到真相
- 故障爆发（11:20 UTC）
◦ 服务器5xx错误率瞬间飙升，核心功能瘫痪。
◦ 故障模式异常：每5分钟崩溃一次，随后自动恢复，像“幽灵攻击”。
- 初期误判：追查“不存在”的黑客
◦ 工程师怀疑是DDoS攻击，但流量模式不符合典型攻击特征。
◦ 关键矛盾：本应独立的故障状态页面也同时崩溃，加剧“内外勾结”的猜测。
- 真相浮出：内部配置文件错误
◦ 根本原因：一个名为“特征文件（Feature File）”的配置文件更新出错。
◦ 技术细节：
▪ 本应从default数据库读取数据，但因权限变更，错误地从i0数据库重复读取。
▪ 数据量翻倍，导致文件体积超出系统预分配的200个特征限制，内存溢出。
4. 多米诺骨牌效应
graph LR
A[权限变更] --> B[数据重复查询]
B --> C[特征文件体积翻倍]
C --> D[内存超限]
D --> E[核心服务崩溃]
修复与教训
- 恢复过程（耗时6小时）
◦ 11:28 UTC：问题爆发。
◦ 13:05 UTC：临时绕行方案减轻影响。
◦ 14:30 UTC：定位问题并停止错误配置传播。
◦ 17:06 UTC：所有服务恢复正常。
- 未来防护措施
◦ 严格校验内部数据：像对待用户输入一样审核配置文件。
◦ 全局紧急停止开关：快速隔离故障模块。
◦ 全面审查核心系统：排查类似隐患。
深层反思
• 一行代码的代价：一个看似微小的权限变更，引发了全球性服务中断。
• 系统脆弱性：高度互联的架构中，局部错误可能通过依赖链无限放大。
• Cloudflare的承诺：此前6年无重大故障记录被打破，凸显运维复杂性与技术债风险。
争议点：
• 自动化运维是否过度依赖“默认信任”？
• 分布式系统如何平衡性能与容错？
