Cloudflare 在 2025 年 11 月 19 日發布詳細的事後檢討報告（post-mortem），揭露 11 月 18 日全球大規模當機的完整技術細節。這起始於 UTC 時間 11:20 的故障，源於 ClickHouse 資料庫系統的權限變更，導致 Bot Management 模組設定檔異常，最終觸發 Rust 程式 panic，造成 X（前 Twitter）、ChatGPT、Spotify、Discord 等數千個網站與應用程式癱瘓超過 4 小時。Cloudflare CEO Matthew Prince 稱這是自 2019 年以來最嚴重的服務中斷。
事件時間軸：4 小時的網際網路噩夢
故障發生與影響
11 月 18 日 11:20 UTC：Cloudflare 網路開始經歷重大流量傳遞故障
影響範圍：
- 持續時間：主要影響期約 3 小時（11:20-14:30 UTC）
- 完全恢復：17:06 UTC 所有系統完全恢復
- 受影響網站：數千個依賴 Cloudflare 的網站與服務
知名受影響服務：
- X（Twitter）：社群媒體平台完全無法存取
- ChatGPT：OpenAI 的 AI 助理服務中斷
- Spotify：音樂串流服務受影響
- Discord：通訊平台部分功能故障
- Canva：設計工具無法使用
- 加密貨幣交易所前端：多個交易平台受影響
使用者體驗
錯誤訊息： 使用者嘗試存取受影響網站時，看到 Cloudflare 錯誤頁面，顯示「Cloudflare 網路內部故障」。
社群媒體反應： 由於 X（Twitter）本身也當機，使用者湧向其他平台如 Reddit、Telegram 討論這起大規模網路中斷事件，許多人以為遭受大規模 DDoS 攻擊。
技術根本原因：ClickHouse 資料庫權限變更
Cloudflare 的詳細技術報告揭露故障的連鎖反應機制。
第一步：資料庫權限變更
時間點：UTC 11:05（故障前 15 分鐘）
變更內容： Cloudflare 工程師正在改進 ClickHouse 分散式資料庫叢集的權限管理方式，應用了一項權限變更。
ClickHouse 簡介： ClickHouse 是一個開源的列式資料庫管理系統（OLAP），專為即時分析查詢設計，Cloudflare 使用它進行大規模資料分析。
變更目的： 改善 ClickHouse 中分散式查詢的執行方式，原本是例行性的系統優化。
第二步：查詢未過濾資料庫名稱
問題出現： 權限變更後，一個用於產生 Bot Management 設定檔的 ClickHouse 查詢開始出現異常行為。
技術細節：
- 底層資料庫結構：ClickHouse 查詢存取底層 “r0” 資料庫的 metadata
- 查詢缺陷：查詢語句沒有根據資料庫名稱進行過濾
- 重複資料：新的權限讓查詢同時看到兩個位置的 metadata
- 資料重複：查詢結果包含重複的欄位與特徵
結果： 原本正常的查詢結果因為沒有過濾資料庫名稱，從兩個來源提取資料，導致輸出包含重複記錄。
第三步：Bot Management 設定檔膨脹
設定檔生成： 這個有問題的查詢每 5 分鐘執行一次，用於生成 Bot Management 模組的「特徵檔案」（feature file）。
檔案大小異常：
- 正常大小：包含最多 200 個特徵項目
- 異常大小：因重複資料，檔案大小翻倍，超過 200 個特徵
Bot Management 簡介： Bot Management 是 Cloudflare 用於偵測與管理機器人流量的系統，依賴機器學習模型與特徵檔案來識別惡意機器人。
檔案傳播： 異常的設定檔在 11:20 UTC 被傳播到 Cloudflare 全球所有資料中心的機器上。
第四步：Rust Panic 與系統崩潰
記憶體預配置機制： Bot Management 模組使用 Rust 程式語言撰寫，系統在啟動時根據嚴格的特徵數量限制（200 個）預先分配記憶體。
觸發 Panic： 當系統嘗試載入超過 200 個特徵的異常設定檔時：
- 超出預期大小：檔案包含超過 200 個特徵
- 記憶體溢出風險：預分配的記憶體無法容納
- Rust Panic：Rust 的記憶體安全機制觸發 panic（類似其他語言的 crash）
- Proxy 系統崩潰：執行 Bot Management 的 proxy 程序終止
連鎖反應：
- 全球同步故障：異常設定檔傳播至全球資料中心
- 大規模服務中斷：所有使用 Bot Management 的流量無法處理
- 重複崩潰：系統自動重啟但持續因相同檔案而 panic
故障檢測與修復過程
Cloudflare 工程團隊的應變過程。
初期檢測（11:20-13:37）
告警觸發： Cloudflare 監控系統立即偵測到流量處理異常，觸發多個告警。
初步調查： 工程師起初懷疑可能是：
- DDoS 攻擊：大規模分散式阻斷服務攻擊
- 網路基礎設施故障：路由或交換設備問題
- 外部攻擊：駭客針對性攻擊
排除錯誤方向： Cloudflare CEO Matthew Prince 在早期聲明中提到「觀察到流量激增」，這導致外界猜測是遭受攻擊，但實際上是誤判。
根因識別（13:37）
突破點： 工程師在 UTC 13:37 識別出 ClickHouse 查詢與 Bot Management 設定檔的關聯。
關鍵發現：
- 時間關聯：故障時間與設定檔更新時間吻合
- 檔案異常：設定檔大小異常且包含重複資料
- 權限變更追溯：回溯發現 11:05 的資料庫權限變更
診斷方法：
- 日誌分析：檢視 ClickHouse 查詢日誌
- 設定檔檢查：對比正常與異常設定檔
- Rust panic 日誌：分析 proxy 系統崩潰原因
緊急修復（13:37-14:30）
修復步驟：
1. 停止產生新設定檔（14:24 UTC）
- 停止執行有問題的 ClickHouse 查詢
- 防止繼續產生異常設定檔
2. 部署已知良好版本
- 手動部署先前正常的 Bot Management 設定檔
- 確保檔案符合 200 個特徵限制
3. 強制重啟 Proxy 系統
- 在所有資料中心強制重啟 proxy 程序
- 載入正確的設定檔
4. 核心流量恢復（14:30 UTC）
- 大部分流量恢復正常處理
- 網站開始可以存取
完全恢復（14:30-17:06）
後續工作：
- 監控驗證：確認所有資料中心恢復正常
- 邊緣案例處理：解決少數持續問題的節點
- 系統健康檢查：全面檢視所有相關系統
17:06 UTC：Cloudflare 宣布所有系統完全恢復正常。
技術深度分析
ClickHouse 查詢設計缺陷
SQL 查詢問題：
正常的資料庫查詢應該包含明確的資料庫名稱過濾：
-- 正確的查詢（簡化示例）
SELECT features FROM database1.table WHERE database_name = 'production'
-- 有問題的查詢（簡化示例）
SELECT features FROM database1.table -- 缺少 WHERE 過濾條件未過濾的後果： 權限變更後，查詢可以存取多個資料庫的 metadata，但沒有過濾邏輯，導致：
- 從 “r0” 資料庫提取資料
- 從其他資料庫也提取資料
- 結果合併產生重複記錄
Rust 記憶體安全機制
Rust 的設計哲學： Rust 程式語言強調記憶體安全，透過編譯時檢查與執行時 panic 防止記憶體錯誤。
Panic 機制： 當程式遇到無法處理的情況（如記憶體溢出風險），Rust 會：
- 停止執行：立即終止當前執行緒或程序
- 展開堆疊：清理資源（可選）
- 防止未定義行為：避免記憶體損壞或安全漏洞
在此案例中：
- 預期：最多 200 個特徵，記憶體已預配置
- 實際：超過 200 個特徵，預配置記憶體不足
- 反應：Rust panic 終止 proxy 程序
優缺點：
- 優點：防止潛在的記憶體安全問題或安全漏洞
- 缺點：無法優雅降級，直接崩潰導致服務中斷
分散式系統的連鎖反應
設定檔分發機制： Cloudflare 使用自動化系統將設定檔推送到全球數百個資料中心。
同步故障風險：
- 快速傳播：異常設定檔在數分鐘內傳播至全球
- 統一觸發：所有資料中心幾乎同時遇到問題
- 全球影響：不是單一區域故障，而是全球性中斷
缺乏分階段部署： 設定檔似乎沒有採用「金絲雀部署」（canary deployment）策略：
- 金絲雀部署：先部署到少數節點測試，確認無誤後再全面推廣
- 此次故障：一次性全球部署，沒有早期預警機會
對使用者與企業的影響
受影響的使用者體驗
社群媒體用戶：
- X（Twitter）無法存取：數億用戶無法使用
- 轉移至其他平台：Reddit、Telegram 流量激增
- 資訊真空：主要新聞傳播管道中斷
工作與生產力：
- 企業通訊中斷：Discord、Slack 等工具受影響
- 雲端服務不可用：依賴 Cloudflare 的 SaaS 服務停擺
- 遠端工作受阻：無法存取必要的線上工具
娛樂與休閒：
- 串流服務中斷：Spotify 等音樂服務受影響
- 遊戲服務故障：部分線上遊戲無法連線
- 內容創作受阻：Canva 等設計工具無法使用
企業與商業影響
電商與交易：
- 交易中斷：加密貨幣交易所前端無法存取
- 銷售損失：電商網站無法運作，損失營收
- 支付系統影響：依賴 Cloudflare 的支付閘道受影響
品牌與信任：
- 服務等級協議（SLA）違反：企業客戶可能要求賠償
- 品牌形象受損：使用者對依賴 Cloudflare 的網站信心下降
- 多元化壓力：企業重新評估單一 CDN 供應商風險
估算損失： 雖然 Cloudflare 未公布具體數字，但依據：
- 受影響網站數量：數千個
- 中斷時間：4 小時
- 流量規模：Cloudflare 處理全球 20% 以上網路流量
估計全球經濟損失可能達數億美元。
Cloudflare 的回應與改進計畫
CEO 公開道歉
Matthew Prince 聲明： Cloudflare CEO Matthew Prince 代表整個團隊公開道歉，承認這起事件對網際網路造成的痛苦。
坦誠溝通： Cloudflare 快速發布詳細的技術事後檢討報告，展現透明度與技術誠信。
歷史對比： Prince 稱這是自 2019 年以來最嚴重的服務中斷，顯示 Cloudflare 過去幾年的穩定記錄。
系統改進措施
Cloudflare 在報告中承諾多項改進措施：
1. 查詢審查與測試
措施：
- 強制資料庫名稱過濾：所有 ClickHouse 查詢必須明確過濾資料庫
- 查詢審查流程：新增查詢審查機制，防止類似缺陷
- 自動化測試：建立測試套件驗證查詢結果正確性
2. 設定檔驗證
措施：
- 檔案大小檢查：產生設定檔時檢查大小是否在預期範圍
- 內容驗證：檢查重複項目與異常資料
- 拒絕異常檔案：自動拒絕不符合規格的設定檔
3. 分階段部署
金絲雀部署：
- 測試節點：先部署到少數資料中心
- 監控指標：觀察效能與錯誤率
- 逐步推廣：確認無誤後才全面部署
回滾機制：
- 快速回滾：發現問題立即回滾至穩定版本
- 自動化回滾：建立自動偵測與回滾機制
4. 錯誤處理改進
Graceful Degradation：
- 不完全 panic：考慮讓系統在遇到異常設定時降級運作，而非完全崩潰
- 備用邏輯：當主要功能失效時，啟用備用簡化邏輯
- 部分服務：盡可能維持部分功能可用
5. 監控與告警強化
早期偵測：
- 設定檔異常告警：檔案大小或內容異常立即告警
- 查詢效能監控：ClickHouse 查詢效能異常告警
- 相關性分析：自動關聯不同系統的異常事件
6. 變更管理流程
權限變更審查：
- 影響評估：變更前評估潛在影響範圍
- 測試環境驗證：在測試環境完整驗證變更
- 逐步上線：生產環境分階段應用變更
產業啟示與教訓
這起事件對整個網際網路基礎設施產業的啟示。
單點故障風險
Cloudflare 的關鍵地位： Cloudflare 處理全球超過 20% 的網路流量，其故障影響：
- 數千個網站：直接依賴 Cloudflare 的客戶
- 數億用戶：無法存取這些網站的終端使用者
- 經濟活動：電商、金融、通訊等領域
過度集中化風險： 少數幾家 CDN 與雲端服務商（Cloudflare、Akamai、Fastly、AWS CloudFront）掌控大部分網路流量，單一故障影響巨大。
分散式系統的脆弱性
連鎖反應： 一個看似微小的資料庫權限變更，透過連鎖反應導致全球性服務中斷：
- 微小變更 → 資料庫權限調整
- 查詢缺陷 → 未過濾資料庫名稱
- 資料異常 → 設定檔包含重複資料
- 記憶體問題 → 超出預分配大小
- 系統崩潰 → Rust panic 終止程序
- 全球故障 → 所有資料中心同步崩潰
複雜性詛咒： 現代分散式系統極度複雜，跨越多個層次（資料庫、應用邏輯、網路、配置管理），任何環節的小失誤都可能放大成重大故障。
自動化的雙面刃
自動化優點：
- 快速部署：設定變更迅速推廣至全球
- 一致性：所有節點使用相同配置
- 效率：減少人工操作錯誤
自動化風險：
- 快速傳播錯誤：異常設定也快速推廣
- 缺乏人工干預：自動化系統無法識別異常
- 同步故障：所有節點同時失效
平衡之道： 需要在自動化效率與安全性之間找到平衡，如金絲雀部署、自動回滾等機制。
記憶體安全語言的取捨
Rust 的選擇： Cloudflare 選擇 Rust 是為了記憶體安全與效能，但這次 Rust 的嚴格 panic 機制也導致系統無法優雅降級。
設計權衡：
- 安全性優先：Rust panic 防止記憶體損壞或安全漏洞
- 可用性考量：部分功能失效是否優於完全停止？
- 行業標準：不同語言在錯誤處理上的哲學差異
透明度與信任
Cloudflare 的回應： Cloudflare 快速發布詳細技術報告，展現高度透明度：
- 詳細根因分析：不隱瞞技術細節
- 承認錯誤：CEO 公開道歉
- 改進計畫：明確列出防止未來故障的措施
產業最佳實踐： 這種透明溝通建立信任，相較於試圖隱瞞或含糊其辭，誠實溝通更能維護客戶關係。
企業應對策略
企業如何降低對單一 CDN 供應商的依賴風險？
多雲與多 CDN 策略
Multi-CDN 架構： 使用多個 CDN 供應商分散風險：
- 主要 CDN：如 Cloudflare 處理大部分流量
- 備用 CDN：如 Akamai、Fastly 作為備援
- 自動切換：偵測主要 CDN 故障時自動切換
成本與複雜性：
- 成本增加：維持多個 CDN 服務
- 管理複雜：協調多個供應商
- 效益：降低單點故障風險
故障轉移與備援計畫
DNS 層級故障轉移：
- 健康檢查：持續監控 CDN 可用性
- 快速切換：DNS TTL 設定較短，加速切換
- 地理分散：不同區域使用不同 CDN
應用層備援：
- 直連原站：CDN 故障時直接連接源伺服器
- 降級服務：提供基本功能，暫時犧牲效能
- 靜態備份：關鍵頁面的靜態版本
監控與告警系統
端到端監控：
- 合成監控：模擬用戶存取，持續檢查可用性
- 真實用戶監控（RUM）：收集實際用戶體驗數據
- 多區域監控：從全球多個地點監控
快速響應：
- 自動告警：故障立即通知團隊
- Runbook：預先準備故障應對手冊
- 定期演練：模擬故障測試應對能力
結論
Cloudflare 2025 年 11 月 18 日的全球大當機，是近年來最嚴重的網際網路基礎設施故障之一。一個看似例行的 ClickHouse 資料庫權限變更，因查詢缺少資料庫名稱過濾，導致 Bot Management 設定檔異常，最終觸發 Rust panic 造成全球性服務中斷，影響 X、ChatGPT、Spotify 等數千個網站長達 4 小時。
關鍵教訓
- 微小變更可能引發巨大影響：資料庫權限調整導致全球故障
- 查詢必須嚴格驗證：未過濾資料庫名稱是根本缺陷
- 分階段部署至關重要：金絲雀部署可避免全球同步故障
- 自動化需要安全機制：快速傳播也意味著快速失敗
- 透明溝通建立信任：Cloudflare 的詳細報告展現業界典範
對產業的意義
基礎設施脆弱性： 這起事件再次提醒，現代網際網路高度依賴少數基礎設施提供商，單點故障風險巨大。
技術債與複雜性： 分散式系統的複雜性持續增加，任何環節的小疏失都可能放大成重大故障，需要更嚴格的變更管理與測試流程。
多元化必要性： 企業應認真考慮多 CDN 策略與故障轉移計畫，不應過度依賴單一供應商。
展望未來
Cloudflare 承諾的改進措施若確實執行，將大幅降低類似故障再次發生的機率。然而，完全消除故障是不可能的，關鍵在於：
- 快速檢測：盡早發現異常
- 快速修復：縮短故障時間
- 透明溝通：誠實面對客戶
- 持續改進：從每次事件學習
對於依賴 Cloudflare 或其他 CDN 的企業與開發者，這次事件是重要提醒：備援計畫不是可選項，而是必需品。網際網路的可靠性不僅取決於供應商的技術實力，也取決於整個生態系統的韌性設計。
Cloudflare 從 2019 年以來保持良好穩定記錄，這次 4 小時的全球故障雖然嚴重,但若能從中學習並切實改進，反而可能讓其系統變得更加穩健。時間將證明 Cloudflare 是否能兌現改進承諾，維護其作為全球關鍵網際網路基礎設施提供商的信任。
