站长视角：北京时间19点30分Cloudflare故障日的切肤之痛，长达三个多小时

2025年11月18日，一个普通的星期二。当全球数以亿计的用户像往常一样打开电脑，准备开始新的一天时，却意外地撞上了一堵无形的墙。

整个故障从北京时间19点30分到22点45分结束。长达三个多小时的故障时长。

一、失控的15分钟

上午9点，监控警报全红。
网站Error 500，控制面板同时失效。
更绝望的是——我连发公告告诉用户“我们崩了”的渠道，都依赖Cloudflare。
这一刻，我不是站长，只是个无助的旁观者。

二、集中化的陷阱

我们为效率牺牲了冗余：

• 一家CDN掌控全部流量

• 一套安防覆盖所有入口

• 一个控制台管理全球节点

当这根支柱断裂，才发现所谓的“云原生架构”，脆弱得像纸糊的城墙。

三、血的教训

1. 单点故障必须杜绝
   即使代价更高，也必须部署备用CDN。今夜就谈多家供应商。

2. 状态页面必须独立
   至少有一个沟通通道完全独立于主架构。用户不该从第三方才知道服务状态。

3. 故障演练不是可选
   从未真正测试过全站脱离Cloudflare的预案——直到今天被迫实战。

四、重建信任比修复服务更难

用户不会记得是Cloudflare的错，只会记住“你的网站又崩了”。
每500错误都在透支品牌信誉。

五、新共识

从此我的架构原则：

• 关键服务永远有Plan B

• 核心功能必须能降级运行

• 监控要跨多地域多运营商

这不是技术升级，是生存本能。