昨天一个网站的更新 让外国人集体断网6小时

差友们，昨晚你们网速足够快的话，应该已经见证了一场互联网大戏——

Cloudflare 崩了。

这可不是一般的崩，是那种能让半个地球互联网一起陪葬的崩。

刚开始大伙儿还一脸懵逼，有人发现推特登不上了，好不容易登上去了吧，啥也刷不出来。

同样的，ChatGPT 也寄了，设计工具 Canva 也打不开，国外兄弟正在打 LOL 和瓦罗兰特的排位呢，直接连不上服务器了。。。

更离谱的是，当所有人想去 Down Detector 查查到底哪个网站崩了的时候，发现 Down Detector 也崩了。

好好好，想看热闹，结果自己成了热闹。

差评君昨天也亲身经历了这场灾难。

我正在 Product Hunt 给个 App 投票呢（因为投了给我打五折），结果死活点不动。后来刷朋友圈吧，又发现之前给大家推荐的网页红警也进不去了。

这一切的始作俑者，就是 Cloudflare。

大部分挂掉的网页都出现了 Error 500，清清楚楚写着 Cloudflare 炸了。

只能说一家公司打个喷嚏，全世界感冒。

眼看社交媒体不能逛，ChatGPT 不能聊，游戏不能打，全球网友开始了集体哀嚎。

有人哭诉：就因为 Cloudflare，我的 AI 女友都联系不上了。。。

——怎么和美国人形容 Cloudflare 崩了有多严重？

——你们没汉堡吃了（*点餐机崩了）

还有人截了一张动图，展示了 Cloudflare 服务中断后的互联网世界。。。

甚至有人发现了新大陆，Cloudflare 崩了之后我的生活全是蓝天白云。

就在这一片哀嚎声中，有个叫 MrShibolet 的用户发的推特，突然火了：

Cloudflare 入职第一天，推送了点更新，下午准备休息咯??

配图里的他站在 Cloudflare 前台前，摆着不太聪明的姿势，双手扶着衣边，倔强的嘴角微微上扬。

这条推特一下传开了，60 万次阅读，所有人都在说：兄弟第一天上班就是最后一天。。。

但其实，这哥们是整活的。

上个月 AWS 崩的时候，他也发过一模一样的推文，这次无非是把名字换成了 Cloudflare。

行了，现在你应该知道昨晚的互联网有多热闹了。。。

到这肯定有人好奇，Cloudflare 到底是个啥？凭啥它崩了，这么多网站都得跟着炸？

简单说，Cloudflare 就像是互联网的物业公司，负责网站的安全、加速、流量管理。

主要业务包括 CDN（内容分发网络）、DDoS 防护、Web 应用防火墙、DNS 服务等等。

正常情况下，你访问一个网站，就是你的浏览器直接连到网站服务器。但如果网站用了 Cloudflare，流程就变成了：

你的浏览器 → Cloudflare → 网站服务器 → Cloudflare → 返回给你。

你说绕这么大圈子图个啥呢？

图的是：又快又稳。

Cloudflare 在全球铺了 330 多个数据中心，当你访问用了 Cloudflare 的网站时，它会自动把你导向离你最近的那个数据中心，这样访问速度会快很多。

这就好比你网购，商家从本地仓发货，当然比外地的总仓要快很多。

除了快，Cloudflare 还给网站当保镖，防 DDoS 攻击、管理机器人爬虫、缓存内容减轻源服务器压力。

说白了，网站用了 Cloudflare，就相当于小区请了一个五星级物业。

有外人来了，他先站在门口验个身份，填个来访记录，把可疑的人拦在外面，确认是正经访客了再给他们套个五速鞋，加速访问。

但问题也来了——

一旦这个物业系统崩了，保安集体脑子宕机，那所有人都进不了小区——

想访问网站的人，全被 Cloudflare 拦在了门外。

按理说，一个搞互联网基础设施的公司，不应该轻易崩掉。

可一旦它崩了，那就是真正的牵一发动全身，崩一屁臭整屋。

所以，什么情况下会崩？

Cloudflare 自己发了个事故报告，我看完了只有一个感觉：这也能崩？

咱简单聊一下。

Cloudflare 有个功能叫 Bot Management（机器人管理），它不光能识别出恶意机器人 bot，还能给每个访问者打分。

网站管理员可以自己定规矩：你这访客素质得到多少分，才配来我家玩。

比如电商网站可能设置 70 分以上才能下单，防止抢购机器人；新闻网站估计 30 分就行，毕竟得让搜索引擎爬虫进来。

这个打分系统需要一个特征文件，里面记录了各种判断标准，一般有 60 种。

访问速度异常快？浏览器信息很奇怪？扣分！

IP 地址很可疑？行为模式像爬虫？扣分！

那这个文件是怎么生成的呢？

其实很简单，系统每隔 5 分钟就会向后台数据库喊一嗓子：“喂，把最新的 Bot 特征清单发我一份！”

这样频繁的更新，可以确保应对最新的威胁。

本来这套一问一答的流程跑得稳稳当当。

但在 11 月 18 号上午 11 点（UTC 时间，下同），工程师对数据库搞了一波权限微调，直接把数据库搞精神分裂了。

首先，咱们要理解一下 Cloudflare 那个名叫 ClickHouse 的数据库架构，它是专门处理海量数据的。

另外 Cloudflare 的数据量是非常大，一台服务器根本塞不下。所以，他们被迫搞了个分店模式（学名叫分片存储）。

你可以把 Cloudflare 的数据库想象成一家连锁书店，在北上广都有仓库。

前台总管（代号 Default）： 它坐在总部办公室，手里只拿一张索引目录。它不存真书，只负责告诉你书在哪儿。平时系统来查数，都是直接问它。

各地分仓库（代号 r0）： 这些是分布在北京、上海、广州等地的仓库，真正的书（数据）都在这儿堆着。

原本的流程非常丝滑。

系统喊一嗓子：“给我一份 Bot 特征清单！” 前台总管（Default） 微微一笑，递出一张单子：“给，一共 60 个特征。”

特征 1: 访问速度

特征 2: IP 地址

特征 3: 浏览器类型

。。。

系统接单，一切正常。

但在 18 号一波权限调整后，把原本指向前台总管的单线电话，改成了一个连接全公司的大喇叭。

这时候，系统再喊那句老话：“给我一份 Bot 特征清单！”，问题就出现了。

因为没指名道姓，对面彻底乱套，所有人都在抢答：

前台总管：“给，这是 60 个特征！”

北京分仓库（r0-分片 1）：“俺也一样！这是 60 个特征！”

上海分仓库（r0-分片 2）：“巧了！我也有一份 60 个特征！”

广州分仓库（r0-分片 3）：“俺也一样！”

一堆分仓库冲上来对着你的耳朵疯狂复读，原本只有 60 行的特征清单，瞬间被复制成了几百行。

尴尬的是，Cloudflare 在设计系统时，为了性能考虑，给特征文件设了个上限：最多 200 个特征。

他们想着平时也就 60 多个，撑死 100 个，200 怎么着也够用了。

谁能想到这帮哥们一复读，数据量原地起飞，瞬间冲破 200 大关。

系统一看到这清单，当场两眼一黑，崩溃不干了。

这还没完，更骚的来了。

这个崩溃它不是一直崩，而是仰卧起坐的崩。

因为 Cloudflare 数据库集群的更新，是分批进行的。有些节点数据库更新了，有的还是老版本。

所以系统每 5 分钟进来抓一个数据库问话，都相当于一次开盲盒。

运气好 → 碰到老版本 → 总管答复 → 60 条特征数据 → 网站恢复了。

运气背 → 碰到新版本 → 一群人答复 → 几百条重复数据 → 网站又崩了。。。

这就是为啥一开始在用户眼里，这些网站时好时坏。

上一秒还在骂娘，下一秒突然刷出来了；刚想上推特学习，看到一半又卡了。

这张 GIF 更传神了

Cloudflare 的工程师一开始也蒙圈，看着流量忽高忽低、网站时好时坏，第一反应是：完了，是不是又被 DDoS 攻击了？

毕竟前段时间才刚挡下一个 7.3Tbps 的超级攻击，这种症状太像攻击流量的波动了。

更巧的是，连他们自己的状态页也崩了（后来发现纯属巧合），搞得工程师们一度怀疑：这是有人连我们的状态页一起攻击啊！

在尝试了限流、切换路由等各种操作后，他们终于发现了是自己人在背刺。

于是 14:24，他们赶紧停止自动生成新配置文件，手动翻出一个之前能正常工作的旧版本，测试确认没问题，然后推送到全球所有服务器，大部分服务开始恢复。

最终 17:06，所有下游服务逐步重启完成，清理掉之前的错误状态，宕机正式结束。

整个过程持续了将近 6 个小时。。。

Cloudflare 在官方事故报告里承认了自己的错误，并承诺会加强配置文件检查、审查所有模块的容错能力，具体细节差评君就不展开了。

这些措施听起来都挺合理，但每次大厂宕机后都会发类似的保证书。

上个月 AWS 崩了，这个月 Cloudflare 崩了，过段时间说不定又轮到谁。

对于大多数普通用户来说，昨天这场宕机可能就是“网站打不开了，等等就好”。但对于那些严重依赖在线服务的企业来说，这是真金白银的损失。

上个月 AWS 的宕机影响了 60 个国家 1700 多万用户 ，导致 3500 多家公司业务中断，经济损失每小时超过 7500 万美元。

这次 Cloudflare 宕机 6 小时，损失恐怕也少不了。

用户们可能什么都做不了，开发者可以考虑多云部署、备用方案，但成本和复杂度都会大大增加，小公司根本玩不起。

咱们就只能期待这些基础设施公司真的能从每次事故中吸取教训。

毕竟整个互联网就是建立在极少数基础设施公司之上，它就像一座空中楼阁，看起来宏伟无比，但地基只有那么几根柱子。

哪根柱子晃一晃，整座楼都得跟着颤。