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