昨天一个网站的更新，让外国人集体掉线数小时

昨晚许多人一觉醒来才发现，常用的网站突然罢工了：社交平台刷不出新内容，聊天机器人没法回答，设计工具打不开，连那种专门查网站状态的 Down Detector 也不争气。大家都傻眼，只能干等着恢复。

查了半天，问题的根源指向 Cloudflare。事情发生在 11 月 18 日上午 11 点（UTC）左右，一次本想调整数据库权限的内部改动，意外触发了连锁反应。工程师原本只是想修改数据库里的某些访问权限，没想到把一个本来单一路径的查询变成了广播式的多路应答。系统每隔五分钟会拉一次“Bot 特征清单”来打分，平常大约只有六十来条，用来判断访问者是不是机器人。改动之后，不只是总部索引在回数据，多个分片都把自己的清单一股脑儿地回来了，六十条瞬间被放大成了几百条。Cloudflare 设了个两百条的上限，一旦超过，上层逻辑就扛不住，结果就是一些请求被拒绝，一些偶尔能通过，用户看到的网络体验变得断断续续、时好时坏。

要把这件事说清楚，需要讲讲他们底层的一个组件，叫 ClickHouse。可以把它想成一个总部加分仓的结构：总部索引先指路，分仓按需去拿数据。正常情况下，总部只让某一个分仓回应。改配置后，查询不再去总仓问，而是让所有分仓都回答同一个请求。于是一样的清单被重复返回，条目倍增，最终超过设定阈值。更麻烦的是，这次改动并非一次性全网生效，而是分批部署——有的节点还是老版本，有的变成了新版本。每次去抓数据就像开盲盒：抽到老版就正常，抽到新版就会触发错误。用户端表现出来的就是网站一会能进一会儿又挂，毫无规律可言。

故障刚开始时，Cloudflare 的工程师也摸不着头脑。由于不久前他们刚抵挡住一次达到数 Tbps 的 DDoS 攻击，团队对流量异常格外敏感。出现流量波动、服务忽断忽续，第一反应是有人在打外部流量冲击。更倒霉的是，他们自己的状态页也出问题，导致排查初期信息不全。工程师试过限流、切换路由、临时规则这些常用手段，但都只是缓兵之计，问题没有被根治。经过逐步追查到数据库交互和配置生成的细节，才发现是权限变更导致的广播式重复响应。下午 14:24，团队决定先停止自动生成新的配置，改为手动回滚到之前一版稳定配置；先在一小部分节点上测试，确认没问题后再逐步推广到全球。到 17:06，绝大多数下游服务恢复正常。整个过程从故障出现到大规模恢复，差不多持续了将近六个小时。

受影响的服务不少。推特一度刷不出内容，ChatGPT 无法回应，设计工具 Canva 无法打开，不少在线游戏的排位赛也被玩家们抢了线。更带感的是，大家跑去 Down Detector 看谁挂了，结果发现 Down Detector 也挂了。社交媒体上各种抱怨和调侃立刻刷屏——有人说由于 Cloudflare，连点餐机都罢工了，笑称“没汉堡吃了”；有人反倒感叹网络断了反而看到蓝天白云。还有那张流传的梗图，配文“第一天上班就把公司搞崩了”，被网友反复拿出来笑。后来有人扒出来，这是旧梗，之前 AWS 出问题时也有人发过类似的图，只是把公司名换掉了。

我自己也被波及了。那会儿正打算在 Product Hunt 上给个产品投票，投了能便宜一点，结果投不了；想刷朋友圈看别人晒的东西，网页加载不到该有的内容。那种想做事却被卡住的感觉，既窝火又无奈。身边朋友也纷纷在群里抱怨，有人说正好在做直播，半小时的带货就白忙活了；小公司的一次部署由于依赖外部服务也被迫暂停，对时间敏感的业务损失立刻就能算出来。

把 Cloudflare 的角色简单说清楚：它既是外勤，也是门卫。许多网站把访客流量先丢给 Cloudflare，由它决定要去哪个服务器拉内容。它提供 CDN、DDoS 防护、WAF、DNS 等服务，在全球布了上百个数据中心，目标是让访问更快、更稳定。但这也带来一个脆弱点：当这个“门卫”系统出事，被它代管的大量网站都会被牵连。就像整个小区都交给同一家物业管理，物业系统一旦罢工，整片小区都出问题。

这类基础设施公司的宕机并非个例。前段时间 AWS 的一次故障也影响了多个国家和企业，带来了大规模业务中断和财务损失。对普通用户来说，症状可能只是一时网页打不开；对依赖在线系统的企业来说，损失可能就是实打实的订单、客户和信任。厂商常说可以做多云备份、容灾演练来减风险，但这些方案意味着更高成本和复杂度，小公司并不必定负担得起。

Cloudflare 在事故说明里承认了这是内部操作失误，并表明会改善配置检查和容错能力，调整自动生成配置的流程。听起来合理，但每次大厂出事后说要改善都挺安慰人的，关键还是能不能把改善落到实处。现场的工程师在那几小时里一直紧张工作，从排查、回滚到逐步恢复，每一步都得小心翼翼，避免二次伤害。社交圈里一边是抱怨，一边是调侃，那张“互联网变蓝天”的图又被转来转去，既是无奈也是自嘲。

在这类事件里，可以看到三点细节：一是小小的配置改动可能带来放大效应，尤其触及到分布式系统的调用路径；二是滚动部署、混合版本会把故障表现成不稳定、难以定位的“抽风”式问题；三是状态页也要有冗余和保护，一旦连自家监测工具都挂了，排查会被拖得更久。许多技术团队在总结时都会把这些点提出来，作为下一次演练的重点。

那天网络恢复后，大家继续日常，有的人还会把这事当段子讲。可对于那些被断线影响到收入的团队，这不是段子。网络世界的稳定看起来透明、自然，实则背后是无数的工程决策和运维细节。一处小小的失误，可能让成千上万的人在几个小时里空转。事情出了，大家抱怨，也只能盼着这些大厂真把流程捋顺，把隐患堵上，让下次故障的概率能更低。