2025 年 11 月 18 日，Cloudflare 的網路發生重大故障，導致約兩小時十分鐘無法傳輸網路流量。將近三週後，我們的網路在 2025 年 12 月 5 日再次無法為我們網路後方 28% 的應用程式提供流量，持續約 25 分鐘。
在兩起事件發生後，我們發布了詳細的事後檢討部落格文章，但我們深知，要重新贏得各位的信任，我們還需要做出更大努力。今天，我們將分享 Cloudflare 為防止此類服務中斷再次發生，我們所開展的工作詳細資訊。
我們將該方案稱為「橙色警報：小規模故障」，這反映了我們的目標是讓我們的網路在發生錯誤或可能導致重大服務中斷的故障時更具復原能力。「橙色警報」意味著此專案的工作優先順序高於其他所有事項。在此之前，Cloudflare 曾發布過一次「橙色警報」。此後發生另一起重大事件，需要全公司上下高度重視。我們認為，近期的事件需要同樣的重視。「橙色警報」是我們實現這一目標的方式，讓團隊能夠根據需要跨職能工作以完成某項任務，同時暫停任何其他工作。
「橙色警報」工作分為三個主要領域：
要求以受控方式推出任何傳播至網路的設定變更，就像我們如今對軟體二進位版本所做的那樣。
審查、改善和測試所有處理網路流量的系統的故障模式，以確保其在所有條件下都能展現定義完善的行為，包括非預期錯誤狀態。
變更我們的內部「Break Glass」程序，並移除任何循環相依項，以便我們和我們的客戶能夠快速採取行動，並在事件期間毫無問題地存取所有系統。
這些專案將在進行過程中逐步提供迭代式改善，而非在其結束時進行一次「大爆炸」式的變革。每一次個別更新都將有助於提升 Cloudflare 的復原能力。到年底，我們預期 Cloudflare 的網路將更具復原能力，包括應對導致過去兩個月所發生的全球事件等問題。
我們理解，這些事件對我們的客戶和整個網際網路來說是痛點。我們對此感到非常抱歉，因此這項工作是全體 Cloudflare 人員首要任務。
* Cloudflare 的 Break Glass 程序讓某些個人在某些情況下提升其權限，以執行緊急動作來處理高嚴重性情境。
在第一個事件中，造訪 Cloudflare 客戶網站的使用者看到錯誤頁面，指出 Cloudflare 無法回應其要求。在第二個事件中，他們看到的是空白頁。
兩次服務中斷都遵循相似的模式。在每次事件發生之前，我們會在全球數百個城市的資料中心中立即部署設定變更。
11 月的變更是一項 Bot Management 分類器自動更新。我們執行各種人工智慧模型，這些模型可從流經我們網路的流量中學習，以建置可識別機器人的偵測項。我們不斷更新這些系統，以領先試圖逃避我們安全防護的不良行為者，使其無法到達客戶網站。
在 12 月事件中，我們設法保護客戶免遭熱門開放原始碼架構 React 中的漏洞影響時，同時對安全性分析師使用的一種安全性工具做出了變更，以改善我們的簽章。類似於全新 Bot Management 更新的緊迫性，我們需要搶先於想要利用此漏洞的攻擊者。該變更觸發了事件的開始。
這種模式揭露了 Cloudflare 在部署設定變更與發布軟體更新方面存在的嚴重差距。當我們發布軟體版本更新時，我們會以受控且受監管的方式進行。針對每個全新的二進位版本，必須先成功完成多個閘道的部署，才能在全球提供服務。我們先部署至員工流量，然後再謹慎地將變更逐步推廣至全球越來越多的客戶，從免費使用者開始。如果我們在任何階段偵測到異常狀況，我們可在沒有任何人為干預的情況下還原發布。
我們尚未將該方法套用至設定變更。與發布驅動網路的核心軟體不同，我們做出設定變更時，我們將修改軟體行為方式的值，並且我們可立即進行。我們也將這種能力賦予我們的客戶：如果您在 Cloudflare 中變更設定，幾秒鐘內即可將變更傳播至全球。
雖然這種速度有其優勢，但也伴隨著我們需要應對的風險。過去的兩起事件表明，對於套用至網路流量服務方式的任何變更，我們都需要像對待軟體本身變更一樣，以久經考驗的謹慎態度來完成。
我們將變更在 Cloudflare 部署設定更新的部署方式。
我們能夠在幾秒鐘內在全球部署設定變更，這是兩起事件的核心共同點。在這兩起事件中，錯誤的設定在數秒內導致我們的網路癱瘓。
就像我們針對軟體發布已經做的那樣，以受控方式推出設定是我們的「橙色警報」方案中最重要的工作流程。
Cloudflare 的設定變更會非常快速地傳播至網路。當使用者建立新的 DNS 記錄或建立新的安全性規則時，幾秒鐘內即可到達網路上 90% 的伺服器。這是由我們內部稱為 Quicksilver 的軟體元件所驅動。
我們自己的團隊做出任何必要的設定變更也使用 Quicksilver。速度是其中一項特徵：我們能夠快速回應，並在全球範圍內迅速更新網路行為。然而，在這兩起事件中，這項特徵導致重大變更在數秒內傳播至整個網路，而沒有經過閘道進行測試。
雖然在許多情況下，能夠近乎即時地將變更部署至我們的網路非常有用，但很少有這個必要。我們正在努力將 Quicksilver 中的受控部署引入任何設定變更，以便以對待程式碼的方式進行。
我們每天透過我們的 Health Mediated Deployment (HMD) 系統，向我們的網路多次發布軟體更新。在此架構中，每個擁有服務（部署至我們網路中的軟體）的 Cloudflare 團隊，都必須定義可指示部署成功或失敗的指標、推出方案，以及在部署失敗時應採取的步驟。
不同的服務會有略微不同的變數。有些可能需要較長的等待時間，才能繼續前往更多資料中心；而其他則可能對錯誤率的容忍度較低，即使這會導致誤判訊號。
一旦部署，我們的 HMD 工具組會仔細按照該方案逐步執行，同時在監控每個步驟之後再繼續。如果任何步驟失敗，復原程序將會自動開始，並且可根據需要通知團隊。
在「橙色警報」結束時，設定更新將遵循相同的程序。我們期望，這能讓我們在過去兩起事件中發生的問題變成普遍性問題之前，快速發現並解決這些問題。
雖然我們樂觀地認為，更好地控制設定變更能在問題演變成事件之前發現更多問題，但我們知道錯誤在所難免。在兩起事件期間，我們網路某部分的錯誤導致我們大多數的技術堆疊出現問題，包括客戶用來設定 Cloudflare 使用方式時所仰賴的控制平面。
我們需要慎重對待、分級推出，而不僅僅是地理漸進（傳播至我們更多的資料中心）或人數漸進（傳播至員工和客戶類型）方面。我們還需規劃更安全的部署，以遏制服務漸進過程中的故障（從我們的 Bot Management 服務等單一產品傳播至儀表板等不相關產品）。
為此，我們正在審查組成我們網路的每個關鍵產品和服務間的介面合約，以確保 a) 假設每個介面之間會發生故障，並且 b) 以盡可能最合理的方式處理該故障。
回顧我們的 Bot Management 服務故障，至少有兩個關鍵介面，如果我們在設計時就考慮到可能發生的故障，就能從容地處理，從而幾乎不會對任何客戶造成影響。第一個是讀取已損毀設定檔案的介面。本應採用一組經驗證且合理的預設值，以允許流量通過我們的網路；即使發生最糟情況，我們也只會失去輸入至機器人偵測機器學習模型的即時微調，而不是驚慌失措。
第二個介面位於執行我們網路的核心軟體與 Bot Management 模組之間。如果我們的 Bot Management 模組發生故障（如同實際發生的情況），預設情況下我們不應中斷流量。取而代之的是，我們可以再次提出一個更合理的預設方案，從而允許流量以尚可接受的分類通過。
在這些事件期間，我們花了太長時間來解決問題。在這兩種情況下，我們的網路安全系統都會阻止團隊成員存取解決問題所需的工具，在某些情況下，由於一些內部系統亦變得不可用，循環相依項拖慢了我們的速度。
作為一家安全性服務公司，我們所有的工具都受到驗證層的保護，並具有精細的存取控制，以確保客戶資料的安全性並防止未經授權的存取。這是正確的做法，但同時當速度是首要任務時，我們目前的程序和系統拖慢了我們的速度。
循環相依項也影響了我們的客戶體驗。例如，在 11 月 18 日的事件中，我們的無 CAPTCHA 機器人解決方案 Turnstile 無法使用。由於我們在 Cloudflare 儀表板的登入流程中使用 Turnstile，因此無作用中工作階段或 API 服務權杖的客戶，在最需要做出重大變更時，將無法登入 Cloudflare。
我們的團隊將審查並改善所有 Break Glass 程序和技術，以確保我們在必要時能夠盡快存取適當的工具，同時確保我們的安全性要求。這包括檢閱和移除循環相依項，或者在發生事件時能夠快速「繞過」它們。我們亦會增加訓練演練的頻率，以便所有團隊在未來可能發生的任何災難情境之前，充分瞭解相關程序。
在這篇文章中雖然並未涵蓋所有內部正在開展的工作，但上面詳述的工作流程介紹了團隊需要關注的首要任務。這些工作流程皆對應一份詳細的方案，幾乎涵蓋 Cloudflare 的所有產品和工程團隊。我們還有很多工作需要完成。
到第一季末（主要在此之前），我們將：
確保 Health Mediated Deployments (HMD) 涵蓋所有生產系統，以便進行設定管理。
更新我們的系統，以遵守適用於每個產品組的適當故障模式。
確保我們設置了程序，以便適當的人員具有相應的存取權，進而能夠在緊急情況下提供適當的補救措施。
其中一些目標將一直不變。隨著我們發布新的軟體，我們將始終需要更好地處理循環相依項，並且我們的 Break Glass 程序需要更新，以反映我們的安全性技術如何隨時間不斷變更。
在過去的兩次事件中，我們辜負了使用者和整個網際網路。我們需要努力工作來彌補。我們計劃在此工作進行期間分享最新消息，並感謝客戶和合作夥伴提供的問題和意見回饋。