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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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