Cloudflare 11-18 斷網(wǎng)故障復(fù)盤報(bào)告

就在昨天，有 “賽博佛祖” 之稱的 Cloudflare 遭遇自 2019 年以來的最嚴(yán)重故障 —— 正常的核心網(wǎng)絡(luò)流量無(wú)法傳輸，長(zhǎng)達(dá)六個(gè)小時(shí)。 ChatGPT、X（前 Twitter）、Spotify、Uber 等知名服務(wù)悉數(shù)中招。 故障的根因是修改了 ClickHouse 的權(quán)限，導(dǎo)致生成的反爬特征太大，撐爆了路由網(wǎng)絡(luò)流量的軟件的限制。

Cloudflare 團(tuán)隊(duì)今天早上在其博客發(fā)布了故障復(fù)盤文章[1]，老馮將其翻譯為中文，并附上點(diǎn)評(píng)。

Cloudflare 2025年11月18日服務(wù)中斷

https://blog.cloudflare.com/18-november-2025-outage/[2]

2025年11月18日11:20 UTC（本文所有時(shí)間均為 UTC），Cloudflare 的網(wǎng)絡(luò)開始出現(xiàn)核心網(wǎng)絡(luò)流量傳輸?shù)膰?yán)重故障。 對(duì)于嘗試訪問我們客戶網(wǎng)站的 Internet 用戶而言，這種故障表現(xiàn)為一個(gè)錯(cuò)誤頁(yè)面，提示 Cloudflare 網(wǎng)絡(luò)內(nèi)部發(fā)生了故障。

此次問題并非由任何形式的網(wǎng)絡(luò)攻擊或惡意活動(dòng)直接或間接導(dǎo)致。相反，起因是我們一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)的權(quán)限更改， 導(dǎo)致該數(shù)據(jù)庫(kù)將多個(gè)條目輸出到了我們的 Bot 管理系統(tǒng)所使用的一個(gè)“特征文件”中。 該特征文件的大小因此翻了一倍。這個(gè)超出預(yù)期大小的特征文件隨后被分發(fā)到構(gòu)成我們網(wǎng)絡(luò)的所有服務(wù)器上。

運(yùn)行在這些服務(wù)器上的軟件（用于在我們的網(wǎng)絡(luò)中路由流量）會(huì)讀取這個(gè)特征文件，以使我們的 Bot 管理系統(tǒng)能夠應(yīng)對(duì)不斷變化的威脅。 該軟件對(duì)特征文件的大小設(shè)有一個(gè)上限，而這個(gè)上限低于特征文件翻倍后的大小，導(dǎo)致軟件發(fā)生了故障。

最初，我們誤以為所觀察到的癥狀是一場(chǎng)超大規(guī)模 DDoS 攻擊所致。 后來，我們正確地識(shí)別出了問題的核心原因，并阻止了那個(gè)超出預(yù)期大小的特征文件繼續(xù)傳播， 將其替換為之前的一個(gè)版本。 到 14:30 時(shí)，我們的大部分核心流量已經(jīng)基本恢復(fù)正常。此后幾小時(shí)里，隨著流量回升，我們團(tuán)隊(duì)持續(xù)努力減輕網(wǎng)絡(luò)各部分面臨的過載問題。 截至 17:06，Cloudflare 的所有系統(tǒng)均已恢復(fù)正常。

我們對(duì)本次事件給客戶和整個(gè) Internet 帶來的影響深表歉意。 鑒于 Cloudflare 在互聯(lián)網(wǎng)生態(tài)系統(tǒng)中的重要性，我們的任何系統(tǒng)發(fā)生中斷都是不可接受的。 而我們的網(wǎng)絡(luò)有一段時(shí)間無(wú)法路由流量，這讓我們團(tuán)隊(duì)的每一名成員都深感痛心。我們知道，今天我們讓大家失望了。

本文將深入詳述事件的經(jīng)過，以及哪些系統(tǒng)和流程出現(xiàn)了故障。 這也是我們開始著手采取行動(dòng)以確保類似中斷不再發(fā)生的起點(diǎn)（但絕非結(jié)束）。

故障概況

下圖顯示了 Cloudflare 網(wǎng)絡(luò)返回的 HTTP 5xx 錯(cuò)誤狀態(tài)碼數(shù)量。正常情況下，這個(gè)值應(yīng)當(dāng)非常低，事實(shí)在故障開始前也是如此。

在 11:20 之前，5xx 錯(cuò)誤數(shù)量保持在我們預(yù)期的基線水平。之后的激增及隨后的波動(dòng)表明，由于加載了錯(cuò)誤的特征文件，我們的系統(tǒng)發(fā)生了故障。 有一點(diǎn)值得注意：我們的系統(tǒng)隨后一度自行恢復(fù)正常過一段時(shí)間——對(duì)于內(nèi)部錯(cuò)誤而言，這種現(xiàn)象非常不尋常。

原因在于，這個(gè)文件每隔五分鐘由一個(gè)在 ClickHouse 數(shù)據(jù)庫(kù)集群上運(yùn)行的查詢生成，而該集群當(dāng)時(shí)正在逐步更新以改進(jìn)權(quán)限管理。 只有當(dāng)查詢?cè)谝迅碌募汗?jié)點(diǎn)上運(yùn)行時(shí)，才會(huì)生成錯(cuò)誤數(shù)據(jù)。因此，每隔五分鐘，就有可能生成一套正確的或錯(cuò)誤的配置文件，并迅速傳播到整個(gè)網(wǎng)絡(luò)。

這種波動(dòng)使我們難以及時(shí)判斷發(fā)生了什么，因?yàn)檎麄€(gè)系統(tǒng)會(huì)先恢復(fù)正常，然后在下一次分發(fā)配置文件時(shí)（有時(shí)文件正確、有時(shí)文件錯(cuò)誤）再次發(fā)生故障。 起初，這讓我們認(rèn)為故障可能是由攻擊造成的。最終，當(dāng)每個(gè) ClickHouse 節(jié)點(diǎn)都開始生成錯(cuò)誤的配置文件后，系統(tǒng)波動(dòng)停止并穩(wěn)定地處于故障狀態(tài)。

錯(cuò)誤一直持續(xù)到 14:30，我們才找到根本原因并著手解決問題。 我們通過停止生成和傳播錯(cuò)誤的特征文件，并手動(dòng)將一份已知良好的文件插入特征文件分發(fā)隊(duì)列來解決問題，隨后強(qiáng)制重啟了我們的核心代理。 上圖中后面拖長(zhǎng)的尾部曲線，代表我們的團(tuán)隊(duì)在逐步重啟那些進(jìn)入異常狀態(tài)的服務(wù)；到 17:06 時(shí)，5xx 錯(cuò)誤數(shù)量已恢復(fù)正常。

以下服務(wù)受到了影響：

?核心CDN與安全服務(wù)：返回 HTTP 5xx 狀態(tài)碼。（本文開頭的截圖展示了終端用戶看到的典型錯(cuò)誤頁(yè)面。）?Turnstile：無(wú)法加載。?Workers KV：出現(xiàn)了顯著升高的 HTTP 5xx 錯(cuò)誤率，因?yàn)閷?duì) Workers KV “前端”網(wǎng)關(guān)的請(qǐng)求由于核心代理故障而失敗。?Dashboard：儀表盤基本保持可用，但由于登錄頁(yè)面上的 Turnstile 無(wú)法使用，大多數(shù)用戶無(wú)法登錄。?Email安全：雖然郵件處理和傳遞未受影響，但我們觀察到一度無(wú)法訪問某個(gè) IP 信譽(yù)數(shù)據(jù)源，導(dǎo)致垃圾郵件檢測(cè)準(zhǔn)確性降低，并使一些基于域名注冊(cè)時(shí)長(zhǎng)的檢測(cè)未能觸發(fā)（未發(fā)現(xiàn)嚴(yán)重的客戶影響）。我們還觀察到部分自動(dòng)移動(dòng)操作（Auto Move）失敗；所有受影響的郵件均已過審查并得到處理。?Access：從故障開始到 13:05 回滾期間，大多數(shù)用戶的身份驗(yàn)證嘗試都失敗了（已有的 Access 會(huì)話不受影響）。所有這些失敗的身份驗(yàn)證嘗試都會(huì)出現(xiàn)錯(cuò)誤頁(yè)面，這意味著故障期間這些用戶無(wú)法訪問其目標(biāo)應(yīng)用。而在此期間成功的登錄嘗試都已被正確記錄。嘗試在故障期間進(jìn)行的任何 Access 配置更新要么完全失敗，要么傳播非常緩慢；目前所有配置更新均已恢復(fù)正常。

除了返回 HTTP 5xx 錯(cuò)誤，我們還觀察到在故障影響期間 CDN 響應(yīng)的延遲顯著增加。 這是因?yàn)槲覀兊恼{(diào)試和可觀測(cè)性系統(tǒng)消耗了大量 CPU 資源——它們會(huì)在未捕獲的錯(cuò)誤中自動(dòng)附加額外的調(diào)試信息。

Cloudflare 請(qǐng)求處理流程及本次故障原因

每個(gè)發(fā)往 Cloudflare 的請(qǐng)求都會(huì)沿著我們網(wǎng)絡(luò)中一條明確的路徑進(jìn)行處理。 請(qǐng)求可能來自加載網(wǎng)頁(yè)的瀏覽器、調(diào)用 API 的移動(dòng)應(yīng)用，或者來自其他服務(wù)的自動(dòng)化流量。 這些請(qǐng)求首先終止于我們的 HTTP 和 TLS 層，然后流入我們的核心代理系統(tǒng)（我們稱之為 FL，即 “Frontline”）， 最后經(jīng)由 Pingora 執(zhí)行緩存查找，或在需要時(shí)從源站獲取數(shù)據(jù)。

我們?cè)谶@里更詳細(xì)地介紹過 核心代理的工作原理[3]。

當(dāng)請(qǐng)求通過核心代理時(shí)，我們會(huì)運(yùn)行網(wǎng)絡(luò)中提供的各種安全和性能產(chǎn)品。 核心代理根據(jù)每個(gè)客戶的特定配置和設(shè)置處理流量，從執(zhí)行 WAF 規(guī)則、防御 DDoS 攻擊，到將流量路由到開發(fā)者平臺(tái)和 R2 等。 這一過程通過一系列特定領(lǐng)域的模塊實(shí)現(xiàn)，這些模塊對(duì)經(jīng)過代理的流量應(yīng)用相應(yīng)的配置和策略規(guī)則。

這些模塊中的一個(gè) —— Bot 管理模塊，正是此次故障的源頭。

Cloudflare 的 Bot管理系統(tǒng)[4] 包含多個(gè)子系統(tǒng)， 其中包括一個(gè)機(jī)器學(xué)習(xí)模型，我們用它為經(jīng)過我們網(wǎng)絡(luò)的每個(gè)請(qǐng)求生成“機(jī)器人分?jǐn)?shù)”。 客戶可以使用這個(gè)分?jǐn)?shù)來控制哪些機(jī)器人被允許訪問他們的網(wǎng)站，哪些則不被允許。

該模型使用一個(gè)“特征”配置文件作為輸入。在這里，“特征”是指機(jī)器學(xué)習(xí)模型用來判斷請(qǐng)求是否由自動(dòng)程序發(fā)出的單個(gè)屬性。特征配置文件是由各個(gè)獨(dú)立的特征組合而成的集合。

這個(gè)特征文件每隔幾分鐘就會(huì)刷新并發(fā)布到我們整個(gè)網(wǎng)絡(luò)上，使我們能夠?qū)?Internet 上不斷變化的流量模式作出響應(yīng)。 它讓我們能夠應(yīng)對(duì)新型的機(jī)器人以及新的機(jī)器人攻擊。因此，需要頻繁且快速地發(fā)布該文件，因?yàn)閻阂庑袨檎咄芸旄淖儾呗浴?/p>

在生成該文件的底層 ClickHouse 查詢行為發(fā)生變化（詳見下文）后，文件中出現(xiàn)了大量重復(fù)的“特征”行。 這使得原本固定大小的特征配置文件變得比預(yù)期更大，導(dǎo)致 Bot 模塊觸發(fā)了錯(cuò)誤。

結(jié)果是，核心代理在處理任何依賴 Bot 模塊的流量時(shí)都會(huì)返回 HTTP 5xx 錯(cuò)誤。 這也影響到了依賴核心代理的 Workers KV 和 Access。

需要指出的是，我們當(dāng)時(shí)正在將客戶流量遷移到新版代理服務(wù)（內(nèi)部稱為 FL2[5]）。 舊版和新版代理引擎都受到了這一問題的影響，盡管表現(xiàn)出的影響有所不同。

使用新 FL2 代理引擎的客戶遇到了 HTTP 5xx 錯(cuò)誤。而使用舊版代理（FL）的客戶雖然沒有看到錯(cuò)誤，但機(jī)器人分?jǐn)?shù)未能正確生成，所有流量的機(jī)器人分?jǐn)?shù)都變成了零。 那些基于機(jī)器人分?jǐn)?shù)設(shè)置了封禁規(guī)則的客戶會(huì)遇到大量誤判；未在規(guī)則中使用機(jī)器人分?jǐn)?shù)的客戶則沒有受到影響。

還有一個(gè)現(xiàn)象最初使我們誤以為遇到了攻擊：Cloudflare 的狀態(tài)頁(yè)也發(fā)生了故障。 狀態(tài)頁(yè)完全托管在 Cloudflare 基礎(chǔ)設(shè)施之外，與 Cloudflare 系統(tǒng)沒有任何依賴關(guān)系。 雖然事后證明這只是一個(gè)巧合，但它使得部分診斷團(tuán)隊(duì)成員一度認(rèn)為攻擊者可能同時(shí)針對(duì)了我們的系統(tǒng)和狀態(tài)頁(yè)。 在那段時(shí)間訪問狀態(tài)頁(yè)的用戶會(huì)看到如下的錯(cuò)誤信息：

在內(nèi)部事故聊天頻道中，我們擔(dān)心這可能是最近一系列高流量 Aisuru DDoS 攻擊[6] 的延續(xù)：

查詢行為的變化

正如前文提到的，底層查詢行為的更改導(dǎo)致特征文件中包含了大量重復(fù)行。此處涉及的數(shù)據(jù)庫(kù)系統(tǒng)使用的是 ClickHouse 軟件。

這里有必要說明一下 ClickHouse 分布式查詢是如何工作的：一個(gè) ClickHouse 集群由許多分片組成。 為了從所有分片查詢數(shù)據(jù)，我們?cè)诿麨?default 的數(shù)據(jù)庫(kù)中使用所謂的分布式表（由 Distributed 表引擎提供支持）。 Distributed 引擎會(huì)查詢名為 r0 的數(shù)據(jù)庫(kù)中的底層表；這些底層表是每個(gè)分片上實(shí)際存儲(chǔ)數(shù)據(jù)的地方。

對(duì)分布式表的查詢是通過一個(gè)共享的系統(tǒng)賬戶執(zhí)行的。作為提高分布式查詢安全性和可靠性工作的其中一環(huán)，我們正在努力使這些查詢改為在初始用戶賬戶下運(yùn)行。

在今天之前，當(dāng)從 ClickHouse 的系統(tǒng)表（如 system.tables 或 system.columns）查詢表的元數(shù)據(jù)時(shí)，用戶只能看到 default 數(shù)據(jù)庫(kù)中的表。

由于用戶已經(jīng)隱含擁有對(duì) r0 數(shù)據(jù)庫(kù)中底層表的訪問權(quán)限，我們?cè)?11:05 進(jìn)行了改動(dòng)，將這種訪問權(quán)限顯式化，以便用戶也能看到這些表的元數(shù)據(jù)。 通過確保所有分布式子查詢都在初始用戶上下文中運(yùn)行，我們可以更細(xì)粒度地評(píng)估查詢限制和訪問授權(quán)，從而避免某個(gè)用戶的異常子查詢影響到其他用戶。

上述改動(dòng)使得所有用戶都可以獲取到其有權(quán)限訪問的表的準(zhǔn)確元數(shù)據(jù)。 不幸的是，此前有些代碼假定這類查詢返回的列列表只會(huì)包含 “default” 數(shù)據(jù)庫(kù)下的內(nèi)容。例如下面的查詢并沒有按數(shù)據(jù)庫(kù)名過濾：

SELECT name, type
FROM system.columns
WHERE table = 'http_requests_features'
ORDER BY name;

注意，上述查詢并未按數(shù)據(jù)庫(kù)名稱進(jìn)行過濾。隨著我們逐步在該 ClickHouse 集群上推出顯式授權(quán)， 上述查詢?cè)?11:05 的改動(dòng)后開始返回列的“重復(fù)”，因?yàn)榻Y(jié)果中包含了存儲(chǔ)在 r0 數(shù)據(jù)庫(kù)中底層表的列。

不巧的是，Bot 管理特征文件的生成邏輯執(zhí)行的正是上述類型的查詢來構(gòu)建文件中的每一個(gè)“特征”。

上述查詢會(huì)返回一個(gè)類似下表所示的列清單（示例經(jīng)過簡(jiǎn)化）：

然而，由于給用戶授予了額外的權(quán)限，查詢結(jié)果現(xiàn)在包含了 r0 模式下的所有相關(guān)元數(shù)據(jù)，有效地使響應(yīng)行數(shù)增加了一倍多，最終導(dǎo)致輸出文件中的特征數(shù)量大大超出正常范圍。

內(nèi)存預(yù)分配

我們的核心代理服務(wù)中的每個(gè)模塊都設(shè)置了一些上限，以防止內(nèi)存無(wú)限增長(zhǎng)，并通過預(yù)分配內(nèi)存來優(yōu)化性能。在本例中，Bot 管理系統(tǒng)限定了運(yùn)行時(shí)可使用的機(jī)器學(xué)習(xí)特征數(shù)量。 目前該上限設(shè)置為 200，遠(yuǎn)高于我們當(dāng)前大約 60 個(gè)特征的使用量。再次強(qiáng)調(diào)，這個(gè)限制存在是出于性能考慮，我們會(huì)預(yù)先為這些特征分配內(nèi)存空間。

當(dāng)包含超過 200 個(gè)特征的錯(cuò)誤文件被傳播到我們的服務(wù)器時(shí)，這一限制被觸發(fā)——系統(tǒng)因此發(fā)生了 panic。下面的 FL2（Rust）代碼片段顯示了執(zhí)行該檢查并導(dǎo)致未處理錯(cuò)誤的部分：

由此產(chǎn)生了如下所示的 panic 日志，進(jìn)而導(dǎo)致了 5xx 錯(cuò)誤：

thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

故障期間的其他影響

在此次事故中，其他依賴我們核心代理的系統(tǒng)也受到了影響，包括 Workers KV 和 Cloudflare Access。 在 13:04，我們對(duì) Workers KV 實(shí)施了補(bǔ)丁以使其繞過核心代理，從而降低了這些系統(tǒng)所受的影響。 此后，所有依賴 Workers KV 的下游系統(tǒng)（例如 Access 本身）的錯(cuò)誤率都降低了。

Cloudflare 儀表盤（Dashboard）也受到了影響，因?yàn)閮x表盤內(nèi)部使用了 Workers KV，且我們的登錄流程中部署了 Cloudflare Turnstile。

這次中斷也影響了 Turnstile：對(duì)于沒有活躍儀表盤會(huì)話的用戶，他們?cè)谑鹿势陂g無(wú)法登錄。 儀表盤的可用性在兩個(gè)時(shí)間段內(nèi)下降：11:30 至 13:10，以及 14:40 至 15:30（如下圖所示）。

第一個(gè)時(shí)間段（11:30 至 13:10）的可用性下降是由于 Workers KV 受到了影響——一些控制平面和儀表盤功能依賴于 Workers KV。 在 13:10，當(dāng) Workers KV 繞過核心代理系統(tǒng)后，這些功能恢復(fù)了正常。 第二個(gè)時(shí)間段的儀表盤可用性問題發(fā)生在恢復(fù)特征配置數(shù)據(jù)之后。 大量積壓的登錄嘗試開始讓儀表盤不堪重負(fù)。這些積壓的請(qǐng)求結(jié)合用戶重試操作，導(dǎo)致了高延遲，儀表盤可用性下降。 通過提升控制平面的并發(fā)處理能力，我們?cè)诖蠹s 15:30 恢復(fù)了儀表盤的可用性。

補(bǔ)救措施和后續(xù)步驟

現(xiàn)在，我們的系統(tǒng)已經(jīng)恢復(fù)正常運(yùn)行，我們已經(jīng)開始著手研究如何在未來加強(qiáng)系統(tǒng)抵御類似故障的能力。具體來說，我們將：

?像對(duì)待用戶生成的輸入那樣，強(qiáng)化對(duì) Cloudflare 內(nèi)部生成的配置文件的攝取和校驗(yàn)；?為功能啟用更多全局性的緊急開關(guān)；?消除核心轉(zhuǎn)儲(chǔ)或其他錯(cuò)誤報(bào)告占用過多系統(tǒng)資源的可能性；?審查所有核心代理模塊在錯(cuò)誤情況下的失效模式。

今天的事故是 Cloudflare 自 2019 年以來最嚴(yán)重的一次中斷。我們過去也出現(xiàn)過讓儀表盤無(wú)法使用的停機(jī)，還有一些導(dǎo)致較新功能暫時(shí)不可用的故障。但在過去超過 6 年的時(shí)間里，我們沒有再出現(xiàn)過讓大部分核心流量停止的中斷。

像今天這樣的中斷是不可接受的。我們?cè)诩軜?gòu)設(shè)計(jì)上讓系統(tǒng)具備高度的容錯(cuò)能力，以確保流量始終可以繼續(xù)傳輸。 每次過去發(fā)生故障后，我們都會(huì)據(jù)此構(gòu)建新的、更可靠的系統(tǒng)。

我謹(jǐn)代表 Cloudflare 全體團(tuán)隊(duì)，對(duì)我們今天給互聯(lián)網(wǎng)帶來的影響表示誠(chéng)摯的歉意。

時(shí)間

狀態(tài)

描述

11:05

正常

數(shù)據(jù)庫(kù)訪問控制更改已部署。

11:28

故障開始

新配置部署到客戶環(huán)境，在客戶的 HTTP 流量中首次觀察到錯(cuò)誤。

11:32–13:05

調(diào)查進(jìn)行中

團(tuán)隊(duì)調(diào)查了 Workers KV 服務(wù)流量和錯(cuò)誤率升高的問題。初始癥狀表現(xiàn)為 Workers KV 響應(yīng)速度下降，導(dǎo)致 Cloudflare 其他服務(wù)受到下游影響。團(tuán)隊(duì)嘗試通過流量調(diào)整和賬戶限制等措施使 Workers KV 恢復(fù)正常。11:31 自動(dòng)測(cè)試首次檢測(cè)到問題，11:32 開始人工調(diào)查，并在 11:35 發(fā)起了事故會(huì)議。

13:05

影響減輕

針對(duì) Workers KV 和 Cloudflare Access 啟用了內(nèi)部繞過，使它們回退到較早版本的核心代理。雖然舊版核心代理也存在該問題，但其影響較小（如上文所述）。

13:37

準(zhǔn)備回滾

我們確認(rèn) Bot 管理配置文件是事故的觸發(fā)因素。各團(tuán)隊(duì)以多種途徑著手修復(fù)服務(wù)，其中最快的方案是恢復(fù)該配置文件之前已知的良好版本。

14:24

停止發(fā)布

停止生成和傳播新的 Bot 管理配置文件。

14:24

測(cè)試完成

使用舊版本配置文件進(jìn)行的恢復(fù)測(cè)試取得成功，我們隨即開始加速在全球范圍內(nèi)部署修復(fù)。

14:30

主要故障解除

部署了正確的 Bot 管理配置文件，大多數(shù)服務(wù)開始恢復(fù)正常。

17:06

全部恢復(fù)

所有下游服務(wù)均已重啟，全部業(yè)務(wù)功能已完全恢復(fù)。

老馮評(píng)論

昨天在群里看到 Cloudflare 大故障的消息，老馮一看，自己托管在 Cloudflare 上的 pigsty.io 站點(diǎn)也趴窩了，還好老馮還有一個(gè)中國(guó)區(qū)域的并行站點(diǎn) pigsty.cc 能用。 就在上周，老馮剛把 Cloudflare Free 計(jì)劃升級(jí)成 240 美元一年的計(jì)劃，成為 “付費(fèi)客戶” ，就遇上這種戲劇效果，著實(shí)讓人感到遺憾。

老馮是比較激進(jìn)的下云派，但是對(duì)于 CDN 這樣的服務(wù)，我還是依然心安理得的使用云 —— 主要是 Cloudflare，因?yàn)檫@玩意自建確實(shí)比較麻煩。 不幸的是，最近這幾年 Cloudflare 的大型故障并不罕見。而且一出現(xiàn)就是帶崩百分之幾十互聯(lián)網(wǎng)的全局性大故障，這很難說是互聯(lián)網(wǎng)出現(xiàn)的初衷。

又一次多米諾骨牌事件

這份故障復(fù)盤報(bào)告揭示了一些有趣的細(xì)節(jié) —— 這是又一次多米諾骨牌級(jí)聯(lián)故障 —— 從 ClickHouse 權(quán)限變更，傳導(dǎo)到 Bot管理模塊，再傳導(dǎo)到核心流量分發(fā)功能上。

ClickHouse 權(quán)限變更，導(dǎo)致查詢得到的特征數(shù)據(jù)從 < 60 行 變?yōu)?200 行。 然后 CF 因?yàn)槌鲇谛阅芸紤]（well，也許是成本，省內(nèi)存就是省錢，它們還特意強(qiáng)調(diào)下是出于性能的考慮）， 靜態(tài)分配了 Bot 管理軟件使用的內(nèi)存，指定了一個(gè)上限，而兩百行特征數(shù)據(jù)打爆了這個(gè)上限，Rust 寫的 Bot 管理工具就趴窩了。

于是，分?jǐn)?shù)未能正確生成，所有流量的機(jī)器人分?jǐn)?shù)都變成了零。（“大致意味著 —— 所有流量都是機(jī)器人流量”） 那些基于機(jī)器人分?jǐn)?shù)設(shè)置了封禁規(guī)則的客戶會(huì)遇到大量誤判；未在規(guī)則中使用機(jī)器人分?jǐn)?shù)的客戶則沒有受到影響。 （比如，網(wǎng)站設(shè)置了 —— “不允許爬蟲訪問” 的規(guī)則，結(jié)果現(xiàn)在所有的流量包括正常流量都被當(dāng)成爬蟲機(jī)器人流量了）

行業(yè)通病：AWS、Azure、Google、阿里云無(wú)一幸免

一個(gè)看上去不起眼的改動(dòng)，在復(fù)雜度的迷宮中不斷推倒多米諾骨牌，最終變成一場(chǎng)大災(zāi)難。 實(shí)際上，這并非 Cloudflare 獨(dú)有的問題，所有主要云廠商都有過類似的翻車記錄：

1. DNS 配置失誤2.微軟 Azure 門戶癱瘓（2025 年 10 月） 配置更改失誤3.：誤操作4. – IAM OSS 循環(huán)依賴

老馮認(rèn)為這些大故障的背后，有著共性的問題 —— 云計(jì)算規(guī)模效應(yīng)帶來的收益正在被相應(yīng)復(fù)雜度帶來的風(fēng)險(xiǎn)所吞噬。

復(fù)雜度的詛咒

正如老馮在 《》中提到的，復(fù)雜度是一種成本。 現(xiàn)代云服務(wù)為了追求彈性和功能，堆疊了極其龐雜的組件：微服務(wù)拆得四分五裂、Kubernetes 集群一套接一套、各種模塊千絲萬(wàn)縷依賴……

這些復(fù)雜度在平時(shí)潛伏不顯山露水，一旦出事，就會(huì)極大加劇排查和恢復(fù)的難度。 當(dāng)系統(tǒng)出現(xiàn)故障時(shí)，系統(tǒng)越復(fù)雜，修復(fù)就越困難，要做的 “功” 就越多。 而故障處理需要的是智力功率難以在空間上疊加。因此當(dāng)系統(tǒng)復(fù)雜度膨脹到核心團(tuán)隊(duì)無(wú)法及時(shí)響應(yīng)時(shí)，大規(guī)模，長(zhǎng)時(shí)間的故障就會(huì)開始頻繁出現(xiàn)。

以 AWS 10-20 史詩(shī)大故障為例，因?yàn)榉植际降?DNS 修改器 BUG，帶癱了半個(gè)互聯(lián)網(wǎng)。 對(duì)于一家普通規(guī)模公司來說，修改或者修復(fù) DNS 問題可能也就是ansible/puppet 下發(fā)簡(jiǎn)單一行命令甚至手改就好了。 然而對(duì)于 AWS 這樣的規(guī)模來說，完整這樣一件事就需要用到如同雜耍一般的專用分布式組件，而修復(fù)問題的過程也表現(xiàn)的笨拙/業(yè)余的令人發(fā)指。

更嚴(yán)峻的是，整個(gè)互聯(lián)網(wǎng)越來越集中到少數(shù)幾家頭部云計(jì)算廠商上。一家云廠商的小小配置錯(cuò)誤，就有可能帶崩大半個(gè)互聯(lián)網(wǎng)。 這套系統(tǒng)的爆炸半徑實(shí)在是太大了，已經(jīng)形成了系統(tǒng)性風(fēng)險(xiǎn)。如今的互聯(lián)網(wǎng)架構(gòu)，正在重復(fù)“所有雞蛋放在一個(gè)籃子里”的錯(cuò)誤。

出路會(huì)在哪里

老馮覺得要解決這個(gè)問題，也許還是要借鑒其他行業(yè)的經(jīng)驗(yàn) —— 電力，航空，金融這類關(guān)乎國(guó)計(jì)民生的基礎(chǔ)設(shè)施行業(yè)，最終的結(jié)局就是監(jiān)管介入。 我的老對(duì)手瑞典馬工寫了一篇 ，討論了這個(gè)問題。

云計(jì)算的愿景是讓算力成為像水與電一樣的公共基礎(chǔ)設(shè)施，那么最終的結(jié)局也會(huì)大概率和水利與電力一樣，受到公共監(jiān)管。 當(dāng)前的云服務(wù)巨頭往往既壟斷基礎(chǔ)資源 (IaaS)，又掌控各種平臺(tái)服務(wù) (PaaS)、軟件服務(wù) (SaaS)。 這種垂直一體化模式帶來了強(qiáng)大的技術(shù)生態(tài)，但也積聚了過多權(quán)力和風(fēng)險(xiǎn)。或許，將 IaaS 和 PaaS 適度“分拆”，分別走向不同的發(fā)展路徑，是化解當(dāng)前困局的出路。

IaaS 層（基礎(chǔ)設(shè)施即服務(wù)）可以類比為電力、自來水這類“資源供給行業(yè)”。它提供的是算力、存儲(chǔ)、帶寬等基礎(chǔ)算網(wǎng)資源，本質(zhì)上偏向公用事業(yè)屬性。 隨著云計(jì)算的深入普及，可以預(yù)見 IaaS 資源部分終將被「剝離、整合、招安」**，演變成國(guó)家主導(dǎo)下的算力/存儲(chǔ)“電網(wǎng)。

另一方面，PaaS/SaaS 層（平臺(tái)和軟件服務(wù)）則應(yīng)充分市場(chǎng)化競(jìng)爭(zhēng)，猶如家電行業(yè)百花齊放，保留云計(jì)算行業(yè)的創(chuàng)新活力。 用戶也不必被綁死在一家云商生態(tài)里，可以自由組合基礎(chǔ)設(shè)施和上層服務(wù)，形成更加健康的云計(jì)算市場(chǎng)格局。

最終，希望這個(gè)云計(jì)算行業(yè)能 像基建那樣穩(wěn)健，像高鐵電網(wǎng)那樣讓人放心。要達(dá)成這個(gè)目標(biāo)，技術(shù)優(yōu)化是一方面，體制與監(jiān)管的創(chuàng)新同樣關(guān)鍵。 屆時(shí)，無(wú)論是老馮的 pigsty.io 這樣的小站點(diǎn)，還是承載億萬(wàn)人生活的在線服務(wù)， 都能建立在更可靠、更健壯的云服務(wù)之上，不用再提心吊膽等待下一次“云崩塌”的驚魂時(shí)刻了。

References

[1] 故障復(fù)盤文章:https://blog.cloudflare.com/18-november-2025-outage/
[2]:https://blog.cloudflare.com/18-november-2025-outage/
[3]核心代理的工作原理:https://blog.cloudflare.com/20-percent-internet-upgrade/
[4]Bot管理系統(tǒng):https://www.cloudflare.com/application-services/products/bot-management/
[5]FL2:https://blog.cloudflare.com/20-percent-internet-upgrade/
[6]Aisuru DDoS 攻擊: https://blog.cloudflare.com/defending-the-internet-how-cloudflare-blocked-a-monumental-7-3-tbps-ddos/

專欄：云計(jì)算泥石流

云故障

云資源

下云記