Cloudflare 近 6 小時服務中斷：分散式系統快速傳播機制成故障放大器

全球內容傳遞網路（CDN）巨頭 Cloudflare 在本週二經歷了六年來最嚴重的服務中斷，一個看似例行的資料庫權限更新，竟在短短數分鐘內癱瘓了全球約 20% 的網站服務長達近 6 小時。這起事故不僅影響了 X(前 Twitter)、Uber、Canva、ChatGPT 等重要平台，更暴露出現代分散式雲端架構中令人意外的脆弱環節。

單一配置檔案引發的全球性災難

故障起因於 Cloudflare 對其某個資料庫系統進行了權限變更。該公司執行長 Matthew Prince 在事後發布的技術剖析報告中指出，這次變更導致資料庫在輸出給 Bot Management 系統使用的「特徵檔案」(feature file)時，產生了大量重複條目。

技術細節顯示，資料庫查詢在權限變更後開始回傳重複的欄位元資料(column metadata)，使得特徵檔案的大小從原本約 60 個特徵暴增至超過 200 個。這個數字正好超越了系統設定的 200 個特徵上限，該限制原本是為了防止記憶體無限制消耗而設計的保護機制。

當這個超大配置檔案被傳播到 Cloudflare 全球網路的所有機器上時，Bot Management 模組中的 Rust 程式碼觸發了系統恐慌(system panic)，導致處理流量的核心代理系統(core proxy system)崩潰，並向使用者回傳 5xx 內部伺服器錯誤。

分散式架構成為故障放大器

此次事故最令工程團隊困惑的現象，是系統呈現出反覆失敗再恢復的異常行為。Prince 表示，這種模式「對於內部錯誤來說非常不尋常」，也是為何 Cloudflare 一開始誤判為遭受分散式阻斷服務攻擊(DDoS)的原因。

問題的根本原因來自 Cloudflare 用於改進權限管理的 ClickHouse 資料庫叢集。由於該叢集正處於逐步更新階段，系統每隔 5 分鐘就會執行一次查詢來產生配置檔案。當查詢在已更新的叢集節點上執行時，就會產生錯誤的資料。因此每 5 分鐘就有機會產生正確或錯誤的配置檔案，並迅速傳播到整個網路。

這種設計原本是為了確保全球 120 多個國家、連接超過 13,000 個網路的分散式基礎設施能快速同步最新的威脅情報。然而在這次事故中，這個快速傳播機制反而成為災難的放大器。當所有 ClickHouse 節點都開始產生錯誤配置檔案時，系統的波動最終穩定在故障狀態，造成核心流量停止流動。

從發現到修復的關鍵時刻

Cloudflare 工程團隊首先注意到 5xx 錯誤的 HTTP 狀態碼大幅飆升並劇烈波動。透過追蹤這個異常模式，團隊最終找到了根本原因 ：每隔 5 分鐘執行的資料庫查詢持續產生錯誤配置檔案。

解決方案相對直接但需要謹慎執行。工程團隊停止了錯誤特徵檔案的產生與發送，手動將已知正確的檔案插入分發佇列(distribution queue)，並強制重新啟動核心代理系統。到 14:30 UTC 時，核心流量基本恢復正常；17:06 UTC 時，所有系統完全恢復運作。

對企業的關鍵啟示

這起事故凸顯了現代網際網路生態系統的一個關鍵脆弱性:當企業將關鍵服務委託給少數幾個大型雲端服務提供者時，單一供應商的技術問題就可能造成大規模連鎖效應。對台灣企業而言，這提醒了幾個重要課題：首先是第三方依賴的風險評估。企業在選擇 CDN、雲端安全或其他基礎設施服務時，必須了解自身業務對這些服務的依賴程度，並規劃適當的備援機制。其次是業務持續性計畫(BCP)與災難復原(DR)策略的重要性。即使服務中斷並非源自網路攻擊，其影響仍可能與重大資安事件相當。企業需要建立能應對各種第三方服務中斷情境的應變計畫。

Cloudflare 已承諾採取多項強化措施，包括對配置檔案採用更嚴格的輸入驗證、啟用更多全域功能終止開關(kill switches)、防止核心傾印或錯誤報告耗盡系統資源，以及檢視所有核心代理模組的錯誤處理機制。

Prince 在聲明中坦承:「考慮到 Cloudflare 在網際網路生態系統中的重要性，我們任何系統的任何故障都是不可接受的。」這場六年來最嚴重的故障，不僅是對 Cloudflare 的警示，也是對整個產業關於系統韌性與架構設計的一次深刻提醒。