差友們，昨天站昨晚你們網(wǎng)速足夠快的個網(wǎng)更新國人話，應(yīng)該已經(jīng)見證了一場互聯(lián)網(wǎng)大戲——

Cloudflare 崩了。讓外

這可不是集體一般的崩，是斷網(wǎng)那種能讓半個地球互聯(lián)網(wǎng)一起陪葬的崩。

剛開始大伙兒還一臉懵逼，昨天站有人發(fā)現(xiàn)推特登不上了，個網(wǎng)更新國人好不容易登上去了吧，讓外啥也刷不出來。集體

同樣的斷網(wǎng)，ChatGPT 也寄了，昨天站設(shè)計工具 Canva 也打不開，個網(wǎng)更新國人國外兄弟正在打 LOL 和瓦羅蘭特的讓外排位呢，直接連不上服務(wù)器了。集體。斷網(wǎng)。

更離譜的是，當(dāng)所有人想去 Down Detector 查查到底哪個網(wǎng)站崩了的時候，發(fā)現(xiàn) Down Detector 也崩了。

好好好，想看熱鬧，結(jié)果自己成了熱鬧。

差評君昨天也親身經(jīng)歷了這場災(zāi)難。

我正在 Product Hunt 給個 App 投票呢（因為投了給我打五折），結(jié)果死活點不動。后來刷朋友圈吧，又發(fā)現(xiàn)之前給大家推薦的網(wǎng)頁紅警也進(jìn)不去了。

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

大部分掛掉的網(wǎng)頁都出現(xiàn)了 Error 500，清清楚楚寫著 Cloudflare 炸了。

只能說一家公司打個噴嚏，全世界感冒。

眼看社交媒體不能逛，ChatGPT 不能聊，游戲不能打，全球網(wǎng)友開始了集體哀嚎。

有人哭訴：就因為 Cloudflare，我的 AI 女友都聯(lián)系不上了。。。

——怎么和美國人形容 Cloudflare 崩了有多嚴(yán)重？

——你們沒漢堡吃了（*點餐機(jī)崩了）

還有人截了一張動圖，展示了 Cloudflare 服務(wù)中斷后的互聯(lián)網(wǎng)世界。。。

甚至有人發(fā)現(xiàn)了新大陸，Cloudflare 崩了之后我的生活全是藍(lán)天白云。

就在這一片哀嚎聲中，有個叫 MrShibolet 的用戶發(fā)的推特，突然火了：

Cloudflare 入職第一天，推送了點更新，下午準(zhǔn)備休息咯??

配圖里的他站在 Cloudflare 前臺前，擺著不太聰明的姿勢，雙手扶著衣邊，倔強(qiáng)的嘴角微微上揚(yáng)。

這條推特一下傳開了，60 萬次閱讀，所有人都在說：兄弟第一天上班就是最后一天。。。

但其實，這哥們是整活的。

上個月 AWS 崩的時候，他也發(fā)過一模一樣的推文，這次無非是把名字換成了 Cloudflare。

行了，現(xiàn)在你應(yīng)該知道昨晚的互聯(lián)網(wǎng)有多熱鬧了。。。

到這肯定有人好奇，Cloudflare 到底是個啥？憑啥它崩了，這么多網(wǎng)站都得跟著炸？

簡單說，Cloudflare 就像是互聯(lián)網(wǎng)的物業(yè)公司，負(fù)責(zé)網(wǎng)站的安全、加速、流量管理。

主要業(yè)務(wù)包括 CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）、DDoS 防護(hù)、Web 應(yīng)用防火墻、DNS 服務(wù)等等。

正常情況下，你訪問一個網(wǎng)站，就是你的瀏覽器直接連到網(wǎng)站服務(wù)器。但如果網(wǎng)站用了 Cloudflare，流程就變成了：

你的瀏覽器 → Cloudflare → 網(wǎng)站服務(wù)器 → Cloudflare → 返回給你。

你說繞這么大圈子圖個啥呢？

圖的是：又快又穩(wěn)。

Cloudflare 在全球鋪了 330 多個數(shù)據(jù)中心，當(dāng)你訪問用了 Cloudflare 的網(wǎng)站時，它會自動把你導(dǎo)向離你最近的那個數(shù)據(jù)中心，這樣訪問速度會快很多。

這就好比你網(wǎng)購，商家從本地倉發(fā)貨，當(dāng)然比外地的總倉要快很多。

除了快，Cloudflare 還給網(wǎng)站當(dāng)保鏢，防 DDoS 攻擊、管理機(jī)器人爬蟲、緩存內(nèi)容減輕源服務(wù)器壓力。

說白了，網(wǎng)站用了 Cloudflare，就相當(dāng)于小區(qū)請了一個五星級物業(yè)。

有外人來了，他先站在門口驗個身份，填個來訪記錄，把可疑的人攔在外面，確認(rèn)是正經(jīng)訪客了再給他們套個五速鞋，加速訪問。

但問題也來了——

一旦這個物業(yè)系統(tǒng)崩了，保安集體腦子宕機(jī)，那所有人都進(jìn)不了小區(qū)——

想訪問網(wǎng)站的人，全被 Cloudflare 攔在了門外。

按理說，一個搞互聯(lián)網(wǎng)基礎(chǔ)設(shè)施的公司，不應(yīng)該輕易崩掉。

可一旦它崩了，那就是真正的牽一發(fā)動全身，崩一屁臭整屋。

所以，什么情況下會崩？

Cloudflare 自己發(fā)了個事故報告，我看完了只有一個感覺：這也能崩？

咱簡單聊一下。

Cloudflare 有個功能叫 Bot Management（機(jī)器人管理），它不光能識別出惡意機(jī)器人 bot，還能給每個訪問者打分。

網(wǎng)站管理員可以自己定規(guī)矩：你這訪客素質(zhì)得到多少分，才配來我家玩。

比如電商網(wǎng)站可能設(shè)置 70 分以上才能下單，防止搶購機(jī)器人；新聞網(wǎng)站估計 30 分就行，畢竟得讓搜索引擎爬蟲進(jìn)來。

這個打分系統(tǒng)需要一個特征文件，里面記錄了各種判斷標(biāo)準(zhǔn)，一般有 60 種。

訪問速度異?？?？瀏覽器信息很奇怪？扣分！

IP 地址很可疑？行為模式像爬蟲？扣分！

那這個文件是怎么生成的呢？

其實很簡單，系統(tǒng)每隔 5 分鐘就會向后臺數(shù)據(jù)庫喊一嗓子：“喂，把最新的 Bot 特征清單發(fā)我一份！”

這樣頻繁的更新，可以確保應(yīng)對最新的威脅。

本來這套一問一答的流程跑得穩(wěn)穩(wěn)當(dāng)當(dāng)。

但在 11 月 18 號上午 11 點（UTC 時間，下同），工程師對數(shù)據(jù)庫搞了一波權(quán)限微調(diào)，直接把數(shù)據(jù)庫搞精神分裂了。

首先，咱們要理解一下 Cloudflare 那個名叫 ClickHouse 的數(shù)據(jù)庫架構(gòu)，它是專門處理海量數(shù)據(jù)的。

另外 Cloudflare 的數(shù)據(jù)量是非常大，一臺服務(wù)器根本塞不下。所以，他們被迫搞了個分店模式（學(xué)名叫分片存儲）。

你可以把 Cloudflare 的數(shù)據(jù)庫想象成一家連鎖書店，在北上廣都有倉庫。

前臺總管（代號 Default）： 它坐在總部辦公室，手里只拿一張索引目錄。它不存真書，只負(fù)責(zé)告訴你書在哪兒。平時系統(tǒng)來查數(shù)，都是直接問它。

各地分倉庫（代號 r0）： 這些是分布在北京、上海、廣州等地的倉庫，真正的書（數(shù)據(jù)）都在這兒堆著。

原本的流程非常絲滑。

系統(tǒng)喊一嗓子：“給我一份 Bot 特征清單！” 前臺總管（Default） 微微一笑，遞出一張單子：“給，一共 60 個特征。”

特征 1: 訪問速度

特征 2: IP 地址

特征 3: 瀏覽器類型

。。。

系統(tǒng)接單，一切正常。

但在 18 號一波權(quán)限調(diào)整后，把原本指向前臺總管的單線電話，改成了一個連接全公司的大喇叭。

這時候，系統(tǒng)再喊那句老話：“給我一份 Bot 特征清單！”，問題就出現(xiàn)了。

因為沒指名道姓，對面徹底亂套，所有人都在搶答：

前臺總管：“給，這是 60 個特征！”

北京分倉庫（r0-分片 1）：“俺也一樣！這是 60 個特征！”

上海分倉庫（r0-分片 2）：“巧了！我也有一份 60 個特征！”

廣州分倉庫（r0-分片 3）：“俺也一樣！”

一堆分倉庫沖上來對著你的耳朵瘋狂復(fù)讀，原本只有 60 行的特征清單，瞬間被復(fù)制成了幾百行。

尷尬的是，Cloudflare 在設(shè)計系統(tǒng)時，為了性能考慮，給特征文件設(shè)了個上限：最多 200 個特征。

他們想著平時也就 60 多個，撐死 100 個，200 怎么著也夠用了。

誰能想到這幫哥們一復(fù)讀，數(shù)據(jù)量原地起飛，瞬間沖破 200 大關(guān)。

系統(tǒng)一看到這清單，當(dāng)場兩眼一黑，崩潰不干了。

這還沒完，更騷的來了。

這個崩潰它不是一直崩，而是仰臥起坐的崩。

因為 Cloudflare 數(shù)據(jù)庫集群的更新，是分批進(jìn)行的。有些節(jié)點數(shù)據(jù)庫更新了，有的還是老版本。

所以系統(tǒng)每 5 分鐘進(jìn)來抓一個數(shù)據(jù)庫問話，都相當(dāng)于一次開盲盒。

運(yùn)氣好 → 碰到老版本 → 總管答復(fù) → 60 條特征數(shù)據(jù) → 網(wǎng)站恢復(fù)了。

運(yùn)氣背 → 碰到新版本 → 一群人答復(fù) → 幾百條重復(fù)數(shù)據(jù) → 網(wǎng)站又崩了。。。

這就是為啥一開始在用戶眼里，這些網(wǎng)站時好時壞。

上一秒還在罵娘，下一秒突然刷出來了；剛想上推特學(xué)習(xí)，看到一半又卡了。

這張 GIF 更傳神了

Cloudflare 的工程師一開始也蒙圈，看著流量忽高忽低、網(wǎng)站時好時壞，第一反應(yīng)是：完了，是不是又被 DDoS 攻擊了？

畢竟前段時間才剛擋下一個 7.3Tbps 的超級攻擊，這種癥狀太像攻擊流量的波動了。

更巧的是，連他們自己的狀態(tài)頁也崩了（后來發(fā)現(xiàn)純屬巧合），搞得工程師們一度懷疑：這是有人連我們的狀態(tài)頁一起攻擊??！

在嘗試了限流、切換路由等各種操作后，他們終于發(fā)現(xiàn)了是自己人在背刺。

于是 14:24，他們趕緊停止自動生成新配置文件，手動翻出一個之前能正常工作的舊版本，測試確認(rèn)沒問題，然后推送到全球所有服務(wù)器，大部分服務(wù)開始恢復(fù)。

最終 17:06，所有下游服務(wù)逐步重啟完成，清理掉之前的錯誤狀態(tài)，宕機(jī)正式結(jié)束。

整個過程持續(xù)了將近 6 個小時。。。

Cloudflare 在官方事故報告里承認(rèn)了自己的錯誤，并承諾會加強(qiáng)配置文件檢查、審查所有模塊的容錯能力，具體細(xì)節(jié)差評君就不展開了。

這些措施聽起來都挺合理，但每次大廠宕機(jī)后都會發(fā)類似的保證書。

上個月 AWS 崩了，這個月 Cloudflare 崩了，過段時間說不定又輪到誰。

對于大多數(shù)普通用戶來說，昨天這場宕機(jī)可能就是“網(wǎng)站打不開了，等等就好”。但對于那些嚴(yán)重依賴在線服務(wù)的企業(yè)來說，這是真金白銀的損失。

上個月 AWS 的宕機(jī)影響了 60 個國家 1700 多萬用戶 ，導(dǎo)致 3500 多家公司業(yè)務(wù)中斷，經(jīng)濟(jì)損失每小時超過 7500 萬美元。

這次 Cloudflare 宕機(jī) 6 小時，損失恐怕也少不了。

用戶們可能什么都做不了，開發(fā)者可以考慮多云部署、備用方案，但成本和復(fù)雜度都會大大增加，小公司根本玩不起。

咱們就只能期待這些基礎(chǔ)設(shè)施公司真的能從每次事故中吸取教訓(xùn)。

畢竟整個互聯(lián)網(wǎng)就是建立在極少數(shù)基礎(chǔ)設(shè)施公司之上，它就像一座空中樓閣，看起來宏偉無比，但地基只有那么幾根柱子。

哪根柱子晃一晃，整座樓都得跟著顫。