我們從未想過需要寫下這篇文章：在我們的一個主要資料中心發生停電事件後不到五個月，同一資料中心再次發生了這種情況。這很糟糕，也許您心裡在想：「為什麼他們還要繼續使用這個設施呢？」，這沒有關係，因為我們也在想著同樣的事情。但是，事情是這樣的，雖然資料中心可能沒有發生很多變化，但 Cloudflare 在這五個月裡發生了很多變化。因此，雖然在五個月前，一個大型資料中心離線確實令人痛苦，但這次的痛苦要小得多。
本文簡要介紹了一個高可用性資料中心如何在五個月內第二次發生斷電情況。但更重要的是，這篇文章講述了我們的團隊如何努力工作，確保即使我們的其中一個關鍵資料中心斷電也不會影響我們的客戶。
2023 年 11 月 2 日，我們位於俄勒岡州波特蘭的一個關鍵設施長時間斷電。發生這種情況的原因是出現了一系列級聯故障，這些故障似乎是由電網提供者的維護引起的，最終導致設施接地故障，並且由於一系列不幸事件導致設施無法恢復正常運作，情況變得更糟。
如果您想閱讀所有細節，請在此處查看。
無論什麼時候，資料中心完全斷電都是一件令人痛苦的事情，但這是我們應該預料到的。不幸的是，儘管我們知道這種事情可能發生，我們並沒有對我們的產品強制執行一些要求，以確保它們在發生重大故障時能夠繼續執行。
我們絕不允許這樣的錯誤再次發生。
橙色警報
這起事件非常令人痛心，因此我們宣布了「橙色警報」。我們借鑒了 Google 的想法，當他們的業務發生重大威脅時，他們會發出「黃色警報」或「紅色警報」。我們的標誌是橙色的，因此我們對此進行了一些修改。
我們對「橙色警報」的構想是，領導該事件的人（在本次事件中是我們的技術營運資深副總裁 Jeremy Hartman）將有權要求我們團隊中的任何工程師從事他認為最優先的專案。（除非我們宣布「紅色警報」，實際上，因為一起駭客事件，我們最終確實宣布了「紅色警報」，並獲得了更高的優先順序。如果您有興趣，您可以在此處閱讀更多相關資訊。）
在瞭解當前的事件後，Jeremy 迅速對需要完成的最重要的工作進行了分類，以確保即使另一個主要資料中心設施發生災難性故障，我們也能保持高可用性。團隊開始行動。
我們的表現如何？
我們沒有想到這麼快就能進行如此廣泛的現實世界測試，但世間之事就是如此不可預測。2024 年 3 月 26 日（星期二），距離最初的事件發生僅不到五個月的時間，同一設施再次發生重大停電事件。下面我們就來探討一下這次停電的原因，但最重要的是，它為我們團隊在宣布「紅色警報」的情況下所做的工作提供了完美的測試。那麼，結果如何呢？
首先，讓我們回顧一下 Cloudflare 的波特蘭資料中心提供哪些功能。正如 2023 年 11 月 2 日的貼文中所述，Cloudflare 的控制平面主要由面向客戶的介面組成，用於我們的所有服務，包括我們的網站和 API。此外，提供分析和日誌記錄管道的底層服務主要由這些設施提供。
就像 2023 年 11 月一樣，我們立即收到警報，表示我們已失去與 PDX01 資料中心的連線。與 11 月不同的是，我們很快就確定我們再次失去了所有電力，使我們處於與五個月前完全相同的境地。根據二月成功的內部切割測試，我們也知道我們的系統應該如何反應。我們花了幾個月的時間準備、更新無數的系統並啟動大量的網路和伺服器容量，最終透過測試證明工作達到了預期的效果，在這次事件中的體現是——自動容錯移轉到備援設施。
我們的控制平面包含數百個內部服務，我們的期望是，當我們失去波特蘭的三個關鍵資料中心之一時，這些服務繼續在其餘兩個設施中正常運作，而我們繼續主要在波特蘭營運。如果我們的波特蘭中心完全不可用，我們有能力容錯移轉到我們的歐洲資料中心。然而，這是次要選擇，而不是我們立即追求的目標。
2024 年 3 月 26 日，世界標準時間 14:58，PDX01 斷電，我們的系統開始做出反應。到世界標準時間 15:05，我們的 API 和儀表板已正常運作，無需人工幹預。過去幾個月，我們的主要重點是確保我們的客戶在發生類似中斷時仍然能夠設定和操作其 Cloudflare 服務。有一些特定服務需要人工幹預，因此需要更長的時間才能恢復，但主要介面機制如預期運作。
更具體地說，在 2023 年 11 月 2 日的事件中，以下服務的控制平面停機時間至少為 6 小時，其中一些服務的功能下降了數天。
API 和儀表板
Zero Trust
Magic Transit
SSL
SSL for SaaS
Workers
KV
Waiting Room
Load Balancing
Zero Trust Gateway
Access
Pages
Stream
Images
在 2024 年 3 月 26 日的事件中，所有這些服務都在斷電後幾分鐘內啟動並執行，其中許多服務在容錯移轉期間根本沒有受到任何影響。
資料平面（用於處理 Cloudflare 客戶在我們位於全球 300 多個城市的資料中心中傳遞的流量）並沒有受到影響。
我們提供客戶流量檢視的分析平台受到了影響，直到當天晚些時候才完全恢復。這是意料之中的情況，因為分析平台依賴 PDX01 資料中心。就像控制平面一樣，我們在 2023 年 11 月 2 日事件發生後立即開始建立新的分析能力。不過，由於工作規模較大，需要更多時間才能完成。我們一直在努力，力圖盡快消除這種依賴性，並預計在不久的將來完成這項工作。
在驗證控制平面服務的功能後，我們再次面臨一個非常大的資料中心的冷啟動。這項活動在 2023 年 11 月花費了約 72 小時，但這次我們在大約 10 小時內完成了這一過程。在將來，我們將繼續努力以加快速度，我們將繼續完善我們的程序，以防將來發生類似事件。
我們是如何實現當前狀態的？
如上所述，去年 11 月的停電事件導致我們引入了「橙色警報」，即在發生重大事件或危機時，我們會將大部分或全部工程資源用來解決手頭的問題。在過去的五個月裡，我們不再進行所有非關鍵工程功能的開發，轉向專注於確保控制平面的高可靠性。
我們工程部門的團隊齊心協力，確保我們的系統在未來遇到類似故障時更具彈性。儘管 2024 年 3 月 26 日發生的事件出乎意料，但我們一直在為這樣的事件做準備。
最明顯的區別是控制平面和 API 恢復服務的速度。在沒有人工幹預的情況下，在 PDX01 失去連線七分鐘後就可以登入並變更 Cloudflare 設定。這是由於我們努力將所有設定資料庫遷移到高可用 (HA) 拓撲，並預先佈建足夠的容量以承擔容量損失。在受影響的設施中，20 多個不同資料庫叢集中的 100 多個資料庫同時發生故障並自動復原服務。這實際上是一年多以來工作的頂峰，我們每週進行測試，來證明我們擁有正確進行容錯移轉的能力。
另一個重大改進是我們的 Logpush 基礎架構的更新。2023 年 11 月，PDX01 資料中心失去連線意味著我們無法將記錄推送給客戶。在「橙色警報」期間，我們投資在波特蘭建立了 Logpush 基礎架構 HA，並另外在阿姆斯特丹建立了主動容錯移轉選項。Logpush 利用了我們大規模擴展的 Kubernetes 叢集，該叢集覆蓋了我們在波特蘭的所有設施，並為服務擁有者提供了一種無縫的方式來部署具有彈性的 HA 相容服務。實際上，在二月的混亂演練中，我們在波特蘭 HA 部署中發現了一個缺陷，但客戶沒有受到影響，因為阿姆斯特丹 Logpush 基礎架構成功接手。在這次事件中，我們看到自那時以來所做的修復措施均已生效，並且我們能夠從波特蘭地區推送記錄。
我們的 Stream 和 Zero Trust 產品中的許多其他改進對其操作幾乎沒有影響。我們的 Stream 產品使用大量運算資源來對影片進行轉碼，這些產品能夠無縫地移交給我們的阿姆斯特丹設施以繼續營運。我們為團隊提供了服務的具體可用性目標，並提供了實現這些目標的多種選項。Stream 是一個很好的服務範例，它選擇了不同的彈性架構，但能夠在這次中斷期間無縫地提供服務。Zero Trust 在 2023 年 11 月的事件中也受到了影響，之後，我們將其絕大多數功能轉移到我們的數百個資料中心，這些資料中心在這次事件期間保持無縫運作。這將是我們推動所有 Cloudflare 產品所採取的最終策略，因為我們位於全球 300 多個城市的資料中心提供了盡可能高水準的可用性。
資料中心的電源發生了什麼？
2024 年 3 月 26 日，世界標準時間 14:58，PDX01 的 Cloudflare 實體基礎架構完全斷電，據報道，服務於 Cloudflare 所有機櫃的四台 Flexential 擁有和營運的交換機同時發生故障。這意味著整個環境中的主電源路徑和備援電源路徑都被停用。在 Flexential 調查期間，工程師重點研究了一組稱為電路交換板 (CSB) 的設備。CSB 類似於電氣面板，由主輸入斷路器和一系列較小的輸出斷路器組成。Flexential 工程師報告稱，CSB 上游的基礎架構（供電、發電機、UPS 和 PDU/變壓器）沒有受到影響，並繼續正常運作。同樣，CSB 下游的基礎架構（例如遠端電源板和連接的開關設備）也沒有受到影響，這意味著停電與 CSB 本身無關。
對 Flexential CSB 故障根本原因的初步評估表明，四個 CSB 內的斷路器協調設定不正確是一個促成因素。限製過多的跳脫設定值可能會導致過流保護過於敏感，並可能導致裝置誤跳閘。在這次事件中，據報道，Flexential 在四個 CSB 內的斷路器設定相對於下游佈建的電力容量來說太低。當其中一個或多個斷路器跳閘時，剩餘的作用中 CSB 板會發生級聯故障，導致 Cloudflare 機櫃和共用基礎架構上的其他設備完全斷電。在事件分類過程中，我們被告知 Flexential 設施團隊注意到了不正確的跳脫設定，重設了 CSB 並將其調整為預期值，使我們的團隊能夠以分階段和受控的方式啟動我們的伺服器。我們不知道這些設定是何時建立的——通常，在安裝客戶關鍵負載之前，應在資料中心試運轉過程和/或斷路器協調研究過程中對這些設定進行配置/調整。
接下來是什麼？
我們的首要任務是完成分析平台的彈性計畫。分析不僅僅是儀表板中漂亮的圖表。當您想要查看攻擊的狀態、防火牆封鎖的活動，甚至 Cloudflare Tunnel 的狀態時，您都需要分析。我們有證據表明我們正在採用的彈性模式符合預期，因此這仍然是我們的主要關注點，我們將盡快取得進展。
有些服務仍然需要手動介入才能正確恢復，我們已經為每個服務收集了資料和動作項，以確保不需要進一步的手動動作。我們將繼續使用小範圍生產測試來證明所有這些變更和增強功能能夠提供客戶期望的彈性。
我們將繼續與 Flexential 合作開展後續活動，以最大程度地擴大我們對其營運和審核程序的瞭解。雖然此事件僅限於單一設施，但我們將把這次活動變成一個流程，確保對所有關鍵資料中心設施都保持一致的態度。
我們再次對受影響客戶深表歉意，特別是那些依賴 Analytics Engine 的客戶，他們在事件期間無法存取該產品功能。過去四個月的工作取得了預期的成果，我們將繼續專注於完成剩餘的工作。