昨晚整整六个小时，大半网络都瘫了。

推特、ChatGPT、Canva 全都断流，连游戏进不去，甚至用来看其它网站状态的 Down Detector 自个儿也挂了。你要搜点东西，网页不是报 500 就是卡在加载那一条进度，刷着刷着就断线。很多人当时懵了：这是几个网站出事，还是底层网络真塌了？

我当时正好在 Product Hunt 投票，点了半天没反应，屏幕像被按了暂停键。朋友圈一堆人开始互相提醒“之前你推荐的链接打不开了”。有人闹着说“我的 AI 女友联系不上了”，也有人开玩笑说“美国这下没汉堡吃了”。最逗的是一个叫 MrShibolet 的账号发了张图，配文“入职第一天就下班”，被一堆人转发。场面既尴尬又有点好笑，但问题是真实的——一家公司的毛病，把很多服务都牵连了。

讲清楚这事得先解释 Cloudflare 是干啥的。别把它想成单纯的服务器，它更像互联网的物业公司：帮网站加速、挡攻击、调流量。人们把流量先导到 Cloudflare，再让它去跟原始服务器拿数据。好处显而易见：访问快、稳定，安全也更靠得住。缺点也明显——你把太多权力交给它，一旦它出问题，吃它豆腐的站点就全都跟着倒霉。

这次事故的关键在一个叫 Bot Management 的功能。它是用来分辨访客是不是机器人：每次请求都会被打个分，网站根据分数决定放行、降速还是封禁。这个判断靠的是一份“特征清单”，上面有几十项规则：访问速度、IP 模式、浏览器信息这些。系统每隔五分钟去后台拉一次最新特征，保证追得上新的攻击手法。

Cloudflare 存这类数据，用的是 ClickHouse 这种数据库。它能处理海量数据，但不能放在一台机子上，所以要分成多个分片。想像成把库存拆到不同仓库，还有个“总管”节点不存货，只负责告诉你东西在哪个仓。原来查特征是问总管，他告诉你去哪个分仓拿就行。

问题出在 11 月 18 日上午 11:00（UTC）的一次权限调整。工程师做了改动，把原本只发给“总管”的请求，意外地广播到了所有分仓。换句话说，本来应该是问总管再去取的一次性操作，变成了向每个仓库都跑一遍。结果是每个分仓都把那份特征清单给了出来，本来应该是 60 条的清单，被重复成了好几百条。系统对特征数设置了上限——200 条，平时谁也想不到会被刷爆。

特征数量一超过阈值，系统就开始报错。状况更复杂的是数据库更新是分阶段的：有的节点已经换到新版，有的还停在旧版。用户请求时，碰上旧版节点就正常，碰上新版节点就被那堆重复数据糊住，表现就是“时好时坏”。这也解释了为什么大家感觉是间歇性断连：有时候能进，有时候炸。

工程师们最初也以为是外部攻击，看流量图有时像遭遇 DDoS——毕竟他们前段时间刚抵挡过一次 7.3Tbps 的巨型流量打击。排查过程中又发现自家状态页也挂了（后来查是个巧合），这反过来把诊断难度拉高。团队先试了限流、切路由、打补丁，结果都不稳。最终把排查重点放在自动生成配置的那套流程上：那套流程生成的 Bot 特征文件里出现大量重复条目，超过了处理能力。

锁定问题后，团队在 14:24 停掉了自动配置生成，手工把之前已知可用的旧版本拉出来，做完测试后逐步推向全球节点。大部分下游服务在逐步恢复，直到 17:06，相关服务才基本回到正常。整个过程差不多就是六个小时左右。

用户端的画面五花八门。有的人在推特刷不出新内容；ChatGPT 的请求被挡在外头；Canva 的设计师们被迫把工作搁浅；玩在线排位的玩家被踢出比赛，活生生断了关键局。最离谱的是，大家去 Down Detector 看别的服务咋样，结果 Down Detector 自己也躺下，想看热闹的人也进了这场热闹里。

再掰开了说，ClickHouse 的分片本来是为了解决单机装不下量这个问题：每个分片负责一块数据，总管只保留索引和路由信息，这样查询既快又稳。问题暴露出两个短板：一是分片在回答请求时没有做好去重控制，同一查询被多处并行响应，结果像把拷贝复印了好几次，数据直接膨胀；二是生成端缺少限制重复回答传播范围的保护。换句话说，既没有在请求边把重复响应挑掉，也没在生成端阻止重复条目扩散。这个设计缺陷，恰恰在那次权限变动时被触发。

工程师们处理问题时走的是老路子：先看流量图，判断是外部攻击还是内部异常；再翻改动历史，逐条回溯。这个过程里不确定性很多，所以会有临时操做：对某些数据中心限流、给某些路由打临时补丁、禁掉那些会触发重复响应的更新机制。这些动作都得小心翼翼，一不留神就把局面弄更糟。最后还是靠把系统回滚到已知稳定版本，然后一点点把新配置替换上去，才把事儿拉回来。

这样的基础设施故障不只是技术问题。对普通用户来说，多半是“网页打不开，过会儿再试”。可对靠在线服务维持生意的公司，这几个小时意味着真金白银的损失。很多企业会考虑多云部署、备用方案来分散风险，但那需要额外成本和运维力量，小公司很难承受。基础设施越集中，连锁反应越明显，这一点短期内难有根本解法。

社交平台上的反应很快分成两类：技术派和段子手。技术派在分析日志、讨论 ClickHouse、聊如何改配置流程；段子手则把这事编成段子，比方把这次和上个月 AWS 的大规模宕机拉一起说：上次 AWS 影响了 60 个国家、1700 多万用户，上千家公司业务中断，损失也不少。也有人发图说“Cloudflare 崩了后我的世界变得安静”，大家笑着嘲讽这类故障带来的荒诞感。

事情慢慢收尾后，Cloudflare 在事故说明里承认了错误，列出要改的方向：加强配置变更审查、完善去重和限流机制、给自动生成文件加额外校验。这类承诺每次大厂出事后都会出现，工程师们也会在内部复盘，想想哪里能再加一层保险。对普通人来说，等系统恢复，日常就回到了原样。我的投票也终于被允许提交——Product Hunt 的那页终于能点通，我把票投完，还拿到折扣。