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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　本文为澎湃号作者或机构在澎湃新闻上传并发布，仅代表该作者或机构观点，不代表澎湃新闻的观点或立场，澎湃新闻仅提供信息发布平台。申请澎湃号请用电脑访问。