活動(dòng)推薦：阿里云雙11活動(dòng)上線 2核2G3M服務(wù)器99元/年 原價(jià)續(xù)費(fèi)不限新老用戶

“總不能讓我這個(gè)上班才 1 周的中斷周新人來背鍋吧？”

CloudFlare 作為全球最為知名的網(wǎng)絡(luò)服務(wù)提供商之一，偶爾出現(xiàn)中斷是超過很常見的事情，一般來說 CloudFlare 有多種不同的時(shí)機(jī)上班冗余策略，即便掛了影響范圍也比較小。房夜

但是班竟前兩天 CloudFlare 出現(xiàn)的技術(shù)故障竟然持續(xù)了 40 個(gè)小時(shí)，這應(yīng)該是有名 CloudFlare 中斷時(shí)間最長的一次事故，所以現(xiàn)在恢復(fù)后 CloudFlare 火速發(fā)布博客分析此事件的新人前因后果。

故障時(shí)間是藍(lán)點(diǎn)從 2023 年 11 月 2 日 11:44 到 11 月 4 日 04:25，時(shí)間均為 UTC 時(shí)間，中斷周與中國時(shí)間有 + 08:00 時(shí)差，超過下面提到的時(shí)機(jī)上班所有時(shí)間都是 UTC 時(shí)間。

直接原因：機(jī)房供電故障、高壓線接地故障

時(shí)間說明：11:44 UTC 換成太平洋時(shí)間 (下面提到的班竟這個(gè)數(shù)據(jù)中心位于美國俄勒岡州，使用太平洋時(shí)間) 是有名夜里四點(diǎn)前后。

本次中斷事故影響了 CloudFlare 的新人很多產(chǎn)品，不過最嚴(yán)重的是 CloudFlare 控制臺(tái)和分析服務(wù)，其中控制臺(tái)就是客戶登錄 CloudFlare 后用來操作的地方，分析服務(wù)則是提供日志和分析報(bào)告之類的。

盡管 CloudFlare 已經(jīng)考慮到核心數(shù)據(jù)中心可能會(huì)掛掉因此做了冗余，但隨著時(shí)間的推移，系統(tǒng)會(huì)變得越來越復(fù)雜，因此冗余也不一定能生效。

根據(jù) CloudFlare 說明，最直接的原因是 CloudFlare 租用的 Flexential 數(shù)據(jù)中心出現(xiàn)了一起計(jì)劃外的供電維護(hù)，這導(dǎo)致數(shù)據(jù)中心的市電供應(yīng)中斷，但數(shù)據(jù)中心都有備用發(fā)電機(jī)，即便備用發(fā)電機(jī)沒用那還有 UPS 不間斷電源呢。

盡管 Flexential 的數(shù)據(jù)中心已經(jīng)通過 Tier III 認(rèn)證，不過在通用電氣進(jìn)行計(jì)劃外的市電維護(hù)后，這個(gè)數(shù)據(jù)中心還是出現(xiàn)了一大堆問題。

當(dāng)出現(xiàn)供電問題后 Flexential 啟動(dòng)了備用發(fā)電機(jī)進(jìn)行供電，但并沒有通知他們的客戶，包括 CloudFlare，因此 CloudFlare 是不知道核心數(shù)據(jù)中心出現(xiàn)了電力問題。

與最佳實(shí)踐不同的是，F(xiàn)lexential 同時(shí)運(yùn)行僅剩的一個(gè)市電設(shè)施以及內(nèi)部的發(fā)電機(jī)進(jìn)行供電，一般來說遇到這種情況應(yīng)該直接切換為備用發(fā)電機(jī)供電，因?yàn)樵谑须姽?yīng)問題出現(xiàn)后，僅剩的這個(gè)市電設(shè)施也可能會(huì)被切斷，而 Flexential 既沒有通知客戶也不知道為什么還要使用剩余的一個(gè)市電設(shè)施。

但這個(gè)市電設(shè)施就這么巧出現(xiàn)了問題，到 11:40，也就是 CloudFlare 故障幾分鐘前 (這時(shí)候還沒故障，因?yàn)閭溆冒l(fā)電機(jī)還在干活中)，剩余的這個(gè)市電設(shè)施的前置變壓器出現(xiàn)了接地故障，前置變壓器的電源是 12kV 的高壓電，高壓電出現(xiàn)了接地是很嚴(yán)重的問題。

出現(xiàn)了高壓電接地后電氣系統(tǒng)為了確保電氣設(shè)施的安全立即自動(dòng)啟動(dòng)停機(jī)保護(hù)，不巧的是這種停機(jī)保護(hù)也把所有發(fā)電機(jī)都給停了，于是這個(gè)數(shù)據(jù)中心的市電和備用發(fā)電機(jī)供電全部停掉。

萬幸的是還有一組 UPS 電池，大約可以供電 10 分鐘，如果在 10 分鐘內(nèi)市電或者發(fā)電機(jī)能恢復(fù)工作，那么 UPS 會(huì)停機(jī)，這樣整個(gè)系統(tǒng)基本都不會(huì)出現(xiàn)大問題。

然而這組 UPS 電池工作 4 分鐘后就出現(xiàn)了故障，此時(shí) Flexential 還沒修好發(fā)電機(jī)，于是數(shù)據(jù)中心徹底斷電了。

三件事阻礙發(fā)電機(jī)重新工作：

第一，由于高壓線接地故障導(dǎo)致電路跳閘，必須物理訪問并手動(dòng)重啟各個(gè)設(shè)施；

第二，Flexential 的門禁系統(tǒng)也沒有備用電池供電，因此出于離線模式，壓根進(jìn)不去(那最后估計(jì)是暴力方式進(jìn)去的)；

第三，Flexential 數(shù)據(jù)中心夜班只有保安和一名工作僅一周的技術(shù)人員，沒有經(jīng)驗(yàn)豐富的操作或電氣專家。

由于發(fā)電機(jī)遲遲沒有恢復(fù)，UPS 電源在 12:01 徹底歇菜，此時(shí)整個(gè)數(shù)據(jù)中心都歇菜了，但 Flexential 仍然沒有通知他們的任何客戶表示數(shù)據(jù)中心已經(jīng)掛了。

CloudFlare 在 11:44 收到了第一個(gè)報(bào)警通知，這就是 UPS 電源工作 4 分鐘后出現(xiàn)故障的時(shí)間，這時(shí)候 CloudFlare 意識(shí)到問題了，開始主動(dòng)聯(lián)系 Flexential 并希望派遣 CloudFlare 自己在當(dāng)?shù)氐墓こ處熯M(jìn)入數(shù)據(jù)中心。

到 12:28 Flexential 終于向客戶發(fā)出了第一條通知 (此時(shí)當(dāng)?shù)貢r(shí)間是凌晨 5 點(diǎn)前后)，表示數(shù)據(jù)中心遇到了故障，工程師正在積極努力解決問題。

12:48 Flexential 終于重啟了發(fā)電機(jī)，部分設(shè)施開始恢復(fù)供電，但是更巧合的是 CloudFlare 所屬的電源線路的斷路器又損壞了，不知道這是由于接地故障還是浪涌導(dǎo)致的，亦或者說之前就已經(jīng)壞了，現(xiàn)在發(fā)現(xiàn)發(fā)電機(jī)重新上線后沒法恢復(fù)供電才發(fā)現(xiàn)斷路器壞了。

Flexential 于是又開始嘗試更換新的斷路器，但由于損壞的斷路器太多，他們還需要去采購，不知道這會(huì)兒 Flexential 有沒有打電話讓正在睡覺的電氣工程師進(jìn)入了現(xiàn)場。但這個(gè)點(diǎn)去采購斷路器估計(jì)有點(diǎn)難度。

由于 Flexential 無法告知恢復(fù)時(shí)間，CloudFlare 決定在 13:40 啟用位于歐洲的災(zāi)備站點(diǎn)，讓服務(wù)先恢復(fù)。

龐大的系統(tǒng)能夠快速通過冗余站點(diǎn)恢復(fù)那是不可能的，前提是你已經(jīng)經(jīng)過完完全全的測試，否則真正進(jìn)行切換時(shí)肯定會(huì)遇到問題。

所以接下來就是 CloudFlare 自己的問題了。

CloudFlare 自己的問題：

直接原因是數(shù)據(jù)中心問題，但還有間接原因，那就是為了快速迭代 CloudFlare 允許團(tuán)隊(duì)快速創(chuàng)新，這意味著有一些新東西可能沒有經(jīng)過嚴(yán)格測試就上線了。

在故障轉(zhuǎn)移過程中失敗的 API 調(diào)用直接起飛了，由于失敗的 API 調(diào)用太多，CloudFlare 不得不開始限制請求速率，直到 17:57 后災(zāi)備站點(diǎn)基本恢復(fù)運(yùn)行。

但還有些產(chǎn)品 – 一些較新的產(chǎn)品并沒有完全進(jìn)行災(zāi)備測試，所以部分服務(wù)仍然不可用。

到 11 月 2 日 22:48 Flexential 那邊終于換好了斷路器并開始使用市電進(jìn)行供電，此時(shí)忙得暈頭轉(zhuǎn)向的 CloudFlare 團(tuán)隊(duì)決定歇會(huì)兒，畢竟災(zāi)備站點(diǎn)現(xiàn)在能應(yīng)對大部分服務(wù)的運(yùn)行。

到 11 月 3 日開始 CloudFlare 著手恢復(fù) Flexential 數(shù)據(jù)中心，首先是物理啟動(dòng)網(wǎng)絡(luò)設(shè)備，然后啟動(dòng)數(shù)千臺(tái)服務(wù)器并恢復(fù)服務(wù)，但這些服務(wù)器也需要重新配置，而重建管理配置服務(wù)器就花了 3 個(gè)小時(shí)。有些服務(wù)之間存在依賴，必須上游服務(wù)恢復(fù)了才能使用，所以必須按照順序進(jìn)行操作。

配置服務(wù)器能用后工程師開始操作其他服務(wù)器，每臺(tái)服務(wù)器重建時(shí)間在 10 分鐘～2 小時(shí)之間，直到 11 月 4 日 04:25 整個(gè)服務(wù)才被恢復(fù)。

對運(yùn)維有興趣的用戶建議閱讀 CloudFlare 原文看看總結(jié)出來的教訓(xùn)：https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/