如果在一個晴朗的夏日，您的設備所在的資料中心看起來是這個樣子，您會有什麼感覺？
大家好！我叫 Dmitry Samsonov，我在以下公司擔任首席系統管理員」照片顯示的是我們專案所需的設備安裝在四個資料中心之一。在這些牆後面，有大約4台設備：伺服器、資料儲存系統、網路設備等——幾乎占我們所有設備的三分之一。
大多數伺服器都是Linux。還有幾十台 Windows（MS SQL）伺服器 - 我們的遺留系統，我們已經系統地放棄了多年。
因此，5 年 2019 月 14 日下午 35:XNUMX，我們其中一個資料中心的工程師報告了火警。
否定
14:45。資料中心發生輕微煙霧事件的頻率比您想像的要高。大廳內的指標正常，所以我們的第一反應比較平靜：我們禁止從事生產相關的工作，即禁止對配置進行任何更改、禁止推出新版本等，除非是與修復某些東西相關的工作。
憤怒
您是否曾嘗試向消防員詢問火災究竟發生在屋頂的哪個位置，或是親自爬上燃燒的屋頂查看情況？透過五個人收到的訊息的信任度如何？
14：50。 收到的訊息顯示，火勢正在逼近冷卻系統。。但它會實現這一目標嗎？值班系統管理員從該資料中心的前端移除外部流量。
目前，我們所有服務的前端都複製到三個資料中心，在 DNS 層級使用平衡，這使我們能夠從 DNS 中刪除資料中心的位址，從而保護使用者免受存取服務的潛在問題的影響。如果資料中心已經出現問題，它將自動退出輪換。您可以在此處閱讀更多內容：
火災尚未對我們造成任何影響—使用者和設備均未受到損壞。這是意外嗎？文件的第一部分「事故行動計畫」對「事故」一詞進行了定義，並以以下內容結束該部分：
«如果對這是否是意外還有任何疑問，那麼這絕對是個意外！»
14:53。已任命一名緊急協調員。
協調員負責控制所有參與者之間的溝通、評估事故規模、使用「事故行動計畫」、吸引必要的人員、監督修復完成情況，最重要的是委派任何任務。換句話說，這是管理事故排除整個過程的人。
便宜貨
15:01。我們開始關閉與生產無關的伺服器。
15:03。我們正確地禁用了所有保留的服務。
這不僅包括前端（此時用戶不再存取）及其輔助服務（業務邏輯、快取等），還包括複製因子為 2 或更多的各種資料庫（, , , 等等）。
15：06。 收到消息稱，一場火災正威脅著資料中心的一個大廳。 我們在這個大廳裡沒有設備，但火勢可能從屋頂蔓延到大廳這一事實極大地改變了正在發生的事情的畫面。
（後來發現，由於大廳與屋頂完全密封，因此沒有受到任何物理威脅。威脅只針對大廳的冷卻系統。）
15:07。我們允許在加速模式下在伺服器上執行命令，無需進行額外檢查（).
15:08。大廳內的溫度在正常範圍內。
15：12。 大廳裡的溫度有所上升。
15:13。資料中心內超過一半的伺服器處於離線狀態。我們繼續吧。
15:16。我們決定關閉所有設備。
15:21。我們開始關閉無狀態伺服器的電源，而沒有正確關閉應用程式和作業系統。
15:23。分配了一組負責 MS SQL 的人員（他們人數不多，服務對他們的依賴程度不高，但恢復功能的過程比 Cassandra 等需要更多時間並且更複雜）。
Депрессия
15：25。 收到16個展廳中6個（7、8、9、XNUMX號）停電的訊息。 我們的設備位於7號和8號展廳，目前沒有關於我們另外兩個展廳（1號和3號）的資訊。
通常發生火災時，電源會立即關閉，但這次由於消防員和資料中心技術人員的協同工作，並不是全部關閉，也不是立即關閉，而是根據需要關閉。
（後來發現8號館和9號館的電源並未關閉。）
15:28。我們開始從其他資料中心的備份中部署 MS SQL 資料庫。
它需要多長時間？整個路線的網路容量是否足夠？
15：37。 據報道，部分網路部分已停止服務。
管理網路和生產網路在物理上是相互隔離的。如果生產網路可用，您可以登入伺服器，停止應用程式並關閉作業系統。如果不可用，您可以透過 IPMI 登錄，停止應用程式並關閉作業系統。如果沒有任何網絡，那麼您就什麼也做不了。 「謝謝，隊長！」你可能會想。
您可能還會想，“總的來說，這太麻煩了。”
事實是，即使沒有火災，伺服器也會產生大量熱量。更準確地說，當有冷卻時，它們會產生熱量，而當沒有冷卻時，它們會製造出地獄般的大火，在最好的情況下，會融化一些設備並關閉其他部分，而在最壞的情況下......會導致大廳內發生火災，幾乎可以肯定會摧毀一切。
15:39。我們正在修復 conf 基礎的問題。
conf 庫是同名服務的後端，所有生產應用程式都會使用它來快速更改設定。沒有這個基礎我們就無法管理門戶的運行，但門戶本身仍然可以工作。
15:41。核心網路設備上的溫度感測器記錄的讀數接近最大允許值。它是一個佔據整個機架並為資料中心內的所有網路供電的盒子。
15:42。問題追蹤器和 wiki 不可用，切換到待機狀態。
這不是生產，但一旦發生事故，任何知識庫的可用性都至關重要。
15:50。其中一個監控系統已停用。
他們有好幾個人，負責服務的不同面向。其中一些配置為在每個資料中心內自主運作（即，它們僅監視自己的資料中心），其他一些則由分散式元件組成，這些元件可以透明地承受任何資料中心的損失。
在這種情況下它停止工作 ，以主備模式運作。已切換至待機狀態。
採用
15:51。透過 IPMI，我們關閉了除 MS SQL 之外的所有伺服器，但沒有正確關閉它們。
您準備好在需要時透過 IPMI 進行大規模伺服器管理了嗎？
此時正是現階段資料中心設備搶救工作完成的時刻。能做的事都已經做了。有些同事可以休息一下。
16：13。 據悉，屋頂空調的氟利昂管道已爆裂，火災撲滅後，資料中心的啟動將延遲。
16:19。根據資料中心技術人員提供的數據，大廳內的溫度上升已經停止。
17:10。恢復conf資料庫的操作。現在我們可以更改應用程式設定。
如果一切都具有容錯能力並且即使沒有單一資料中心也能正常運作，那麼這為什麼如此重要？
首先，並非所有事物都具有容錯能力。有各種輔助服務尚無法很好地承受資料中心故障，且資料庫處於主備模式。管理設定的能力使您能夠採取一切必要措施，即使在困難的條件下也能最大限度地減少事故對使用者的影響。
其次，很明顯資料中心在未來幾個小時內不會完全恢復，因此有必要採取措施確保副本的長期不可用不會導致其餘資料中心出現磁碟溢出等其他問題。
17:29。披薩時間到了！我們僱用的是人，而不是機器人。
復原
18:02。 8 號廳（我們的）、9 號廳、10 號廳和 11 號廳的溫度已經穩定下來。其中一個尚未通電的廳（7 號廳）內有我們的設備，那裡的溫度持續上升。
18:31。批准1號、3號展廳設備開機；火災並未影響這些大廳。
目前，1、3、8號館伺服器正在陸續上線，先從最核心的幾個館開始。檢查所有正在執行的服務是否正常運作。 7號房間仍有問題。
18:44。資料中心的技術人員發現，在7號大廳（只有我們的設備所在的地方）許多伺服器沒有關閉。根據我們的數據，26 台伺服器仍然在線。經過重新檢查，我們發現有 58 台伺服器。
20:18。資料中心技術人員透過穿過走廊的移動風管將空氣吹入未調節的房間。
23:08。第一位管理員被遣送回家。有些人今晚必須睡覺，以便明天能夠繼續工作。接下來，我們將發布更多管理員和開發人員。
02:56。我們發射了所有可以發射的東西。我們正在使用自動測試對所有服務進行重大檢查。
03:02。最後一個大廳（第 7 個大廳）的空調已經恢復。
03:36。我們已經開始在 DNS 的資料中心中旋轉前端。從此刻起，用戶流量開始到達。
我們將讓大部分管理團隊成員回家。但我們還留下了一些人。
一個小常見問題：
問：18:31 到 02:56 之間發生了什麼事？
答：按照“災難行動計劃”，我們將啟動所有服務，先從最重要的服務開始。同時，聊天中的協調員將服務發佈給空閒的管理員，由管理員檢查OS和應用程式是否啟動，是否有錯誤，各項指標是否正常。啟動完成後，他在聊天中報告說他有空，並從協調員那裡獲得了新的服務。
硬體故障進一步減慢了該過程的速度。即使作業系統關閉和伺服器關閉正確，某些伺服器也會因為磁碟、記憶體或機箱突然發生故障而無法復原。當斷電時，故障率就會增加。
Q：為什麼我們不能一次運行所有內容，然後再修復監控中出現的問題？
A：一切都需要逐步進行，因為服務之間存在依賴關係。並且一切都應立即檢查，而不必等待監控——因為最好立即處理問題，而不是等待問題惡化。
7:40。最後一位管理員（協調員）去睡覺了。第一天的工作已經完成。
8:09。第一批開發人員、資料中心工程師和管理員（包括新的協調員）開始恢復工作。
09:37。我們已經開始建造 7 號大廳（最後一個大廳）。
同時，我們繼續修復其他房間未修復的部分：更換磁碟/內存/伺服器，修復監控中「燒壞」的所有東西，在主備方案中切換角色，以及其他一些小事，儘管如此，這些事情還是很多的。
17:08。我們允許所有常規生產工作。
21:45。第二天的工作完成了。
09:45。今天是星期五。監控方面仍然存在不少小問題。週末到了，大家都想放鬆一下。我們將繼續大規模修復一切可以修復的地方。可以推遲的日常管理任務已被推遲。協調員是新來的。
15:40。另一個資料中心的一半核心網路堆疊突然重新啟動。為了將風險降至最低，鋒線被從輪換中移除。對用戶沒有影響。後來發現是底盤故障。協調員同時負責修復兩起事故。
17:17。另一個資料中心的網路運作已經恢復，一切都已檢查完畢。該資料中心已投入輪調。
18:29。第三天的工作以及總體而言事故恢復工作已經完成。
後記
04.04.2013年XNUMX月XNUMX日， 、“同學們” — 入口網站三天內完全或部分不可用。在此期間，來自不同城市、不同公司的 100 多人（再次感謝！）透過遠端方式直接在資料中心手動和自動修復了數千台伺服器。
我們已經得出結論。為了防止類似事件再次發生，我們已經開展並將繼續進行大量工作。
本次事故與404事故主要有哪些差異？
- 我們現在有一份「事故行動計畫」。我們每季進行一次演習——我們模擬一種緊急情況，一組管理員（輪流）必須使用「緊急行動計畫」來解決。主要係統管理員輪流擔任協調員的角色。
- 每個季度，在測試模式下，我們透過 LAN 和 WAN 網路隔離資料中心（依序），這使我們能夠及時發現瓶頸。
- 損壞的磁碟更少，因為我們提高了標準：更少的運行時間，更嚴格的 SMART 閾值，
- 我們徹底放棄了 BerkeleyDB，這是一個老舊且不穩定的資料庫，伺服器重新啟動後需要很長時間才能恢復。
- 減少了使用 MS SQL 的伺服器數量並降低了對其餘伺服器的依賴。
- 我們有自己的 ，兩年來我們一直在積極遷移所有服務。雲端大大簡化了應用程式的整個工作週期，並且在發生事故時，它提供了以下獨特的工具：
- 只需單擊即可正確停止所有應用程式；
- 輕鬆從故障伺服器遷移應用程式；
- 自動、依服務優先排序啟動整個資料中心。
本文描述的事故是第404天以來最大的一次事故。當然，並不是一切都進展順利。例如，在因火災受損的資料中心不可用期間，另一個資料中心的一台伺服器上的磁碟崩潰，這意味著 Cassandra 叢集中的三個副本中只有一個仍然可用，這就是 4,2% 的行動應用程式使用者無法登入的原因。同時，已經連接的用戶繼續工作。總體而言，事故導致超過 30 個問題，包括從普通的錯誤到服務架構的缺陷。
但這次事故和 404 號事故的主要區別在於，當我們在消除火災後果時，用戶仍然在用手機發送簡訊和打視訊電話。 玩遊戲、聽音樂、互贈禮物、觀賞影片、電視節目和電視頻道 ，並流入 .
你的事故進度如何？
來源： www.habr.com
