Cloudflare中斷超過40個小時機房夜班竟然只有1名上班1週的新人
「總不能讓我這個上班才1 週的新人來背鍋吧？」CloudFlare 作為全球最知名的網路服務供應商之一，偶爾出現中斷是很常見的事情，一般來說CloudFlare 有多種不同的冗餘餘策略，即便掛了影響範圍也比較小。
但前兩天CloudFlare 出現的技術故障竟然持續了40 個小時，這應該是CloudFlare 中斷時間最長的一次事故，所以現在恢復後CloudFlare 火速發布博客分析此事件的前因後果。
故障時間是從2023 年11 月2 日11:44 到11 月4 日04:25，時間均為UTC 時間，與中國時間有+ 08:00 時差，下面提到的所有時間都是UTC 時間。
直接原因：機房供電故障、高壓線接地故障
時間說明：11:44 UTC 換成太平洋時間(下面提到的這個資料中心位於美國俄勒岡州，使用太平洋時間) 是夜里四點前後。
這次中斷事故影響了CloudFlare 的許多產品，不過最嚴重的是CloudFlare 控制台和分析服務，其中控制台就是客戶登入CloudFlare 後用來操作的地方，分析服務則是提供日誌和分析報告之類的。
儘管CloudFlare 已經考慮到核心資料中心可能會掛掉因此做了冗餘，但隨著時間的推移，系統會變得越來越複雜，因此冗餘也不一定能生效。
根據CloudFlare 說明，最直接的原因是CloudFlare 租用的Flexential 資料中心出現了一起計劃外的供電維護，這導致資料中心的市電供應中斷，但資料中心都有備用發電機，即便備用發電機沒用那還有UPS 不間斷電源呢。
儘管Flexential 的資料中心已經通過Tier III 認證，不過在通用電氣進行計劃外的市電維護後，這個資料中心還是出現了一大堆問題。
當出現供電問題後Flexential 啟動了備用發電機進行供電，但並沒有通知他們的客戶，包括CloudFlare，因此CloudFlare 是不知道核心資料中心出現了電力問題。
與最佳實踐不同的是，Flexential 同時運行僅剩的一個市電設施以及內部的發電機進行供電，一般來說遇到這種情況應該直接切換為備用發電機供電，因為在市電供應問題出現後，僅剩的這個市電設施也可能會被切斷，而Flexential 既沒有通知客戶也不知道為什麼還要使用剩餘的一個市電設施。
但這市電設施就這麼巧出現了問題，到11:40，也就是CloudFlare 故障幾分鐘前(這時候還沒故障，因為備用發電機還在幹活中)，剩餘的這個市電設施的前置變壓器出現了接地故障，前置變壓器的電源是12kV 的高壓電，高壓電出現了接地是很嚴重的問題。
出現了高壓電接地後電氣系統為了確保電氣設施的安全立即自動啟動停機保護，不巧的是這種停機保護也把所有發電機都給停了，於是這個資料中心的市電和備用發電機供電全部停掉。
萬幸的是還有一組UPS 電池，大約可以供電10 分鐘，如果在10 分鐘內市電或發電機能恢復工作，那麼UPS 會停機，這樣整個系統基本上都不會出現大問題。
然而這組UPS 電池工作4 分鐘後就出現了故障，此時Flexential 還沒修好發電機，於是資料中心徹底斷電了。
三件事阻礙發電機重新工作：
第一，由於高壓電線接地故障導致電路跳閘，必須物理存取並手動重啟各個設施；
第二，Flexential 的門禁系統也沒有備用電池供電，因此出於離線模式，壓根進不去(那最後估計是暴力方式進去的)；
第三，Flexential 資料中心夜班只有保全和一名工作僅一週的技術人員，沒有經驗豐富的操作或電氣專家。
由於發電機遲遲沒有恢復，UPS 電源在12:01 徹底歇菜，此時整個資料中心都歇菜了，但Flexential 仍然沒有通知他們的任何客戶表示資料中心已經掛了。
CloudFlare 在11:44 收到了第一個警報通知，這就是UPS 電源工作4 分鐘後出現故障的時間，這時候CloudFlare 意識到問題了，開始主動聯繫Flexential 並希望派遣CloudFlare 自己在當地的工程師進入資料中心。
到12:28 Flexential 終於向客戶發出了第一條通知(此時當地時間是凌晨5 點前後)，表示資料中心遇到了故障，工程師正在積極努力解決問題。
12:48 Flexential 終於重啟了發電機，部分設施開始恢復供電，但是更巧合的是CloudFlare 所屬的電源線路的斷路器又損壞了，不知道這是由於接地故障還是浪湧導致的，亦或者說之前就已經壞了，現在發現發電機重新上線後沒辦法恢復供電才發現斷路器壞了。
Flexential 於是又開始嘗試更換新的斷路器，但由於損壞的斷路器太多，他們還需要去採購，不知道這會兒Flexential 有沒有打電話讓正在睡覺的電氣工程師進入了現場。但這個點去採購斷路器估計有點難度。
由於Flexential 無法告知復原時間，CloudFlare 決定在13:40 啟用位於歐洲的災備站點，讓服務先復原。
龐大的系統能夠快速通過冗餘站點恢復那是不可能的，前提是你已經經過完完全全的測試，否則真正進行切換時肯定會遇到問題。
所以接下來就是CloudFlare 自己的問題了。
CloudFlare 自己的問題：
直接原因是資料中心問題，但還有間接原因，那就是為了快速迭代CloudFlare 允許團隊快速創新，這意味著有一些新東西可能沒有經過嚴格測試就上線了。
在故障轉移過程中失敗的API 呼叫直接起飛了，由於失敗的API 呼叫太多，CloudFlare 不得不開始限制請求速率，直到17:57 後災備站點基本恢復運行。
但還有些產品- 一些較新的產品並沒有完全進行災備測試，所以部分服務仍然不可用。
到11 月2 日22:48 Flexential 那邊終於換好了斷路器並開始使用市電進行供電，此時忙得暈頭轉向的CloudFlare 團隊決定歇會兒，畢竟災備站點現在能應對大部分服務的運行。
到11 月3 日開始CloudFlare 著手恢復Flexential 資料中心，首先是實體啟動網路設備，然後啟動數千台伺服器並恢復服務，但這些伺服器也需要重新配置，而重建管理配置伺服器就花了3 個小時。有些服務之間存在依賴，必須上游服務恢復了才能使用，所以必須按照順序進行操作。
設定伺服器能用後工程師開始操作其他伺服器，每台伺服器重建時間在10 分鐘～2 小時之間，直到11 月4 日04:25 整個服務才恢復。
對維運有興趣的用戶建議閱讀CloudFlare 原文看看總結出來的教訓：https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/