如果在一個晴朗的夏日，配備您的設備的數據中心看起來像這樣，您會有什麼感覺？
大家好！ 我叫德米特里·薩姆索諾夫 (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 或更高的各種數據庫（, , , ETC。）。
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。 除 MS SQL 之外的所有服務器均通過 IPMI 關閉，但未正確關閉。
如果需要，您準備好通過 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。 最後一個第七大廳的空調已恢復。
03:36。 我們將數據中心的前端引入 DNS 中進行輪換。 從這一刻起，用戶流量開始到來。
我們將把大部分行政團隊遣送回家。 但我們留下了一些人。
小常見問題解答：
問：18:31 到 02:56 發生了什麼？
答：按照“災難行動計劃”，我們推出所有服務，從最重要的服務開始。 在這種情況下，聊天中的協調員將服務發布給免費管理員，由管理員檢查操作系統和應用程序是否已啟動，是否有任何錯誤，以及指標是否正常。 啟動完成後，他向聊天室報告他有空，並從協調員那裡收到新服務。
硬件故障會進一步減慢該過程。 即使正確停止操作系統和關閉服務器，某些服務器也會因磁盤、內存和機箱突然出現故障而無法恢復。 當斷電時，故障率就會增加。
問：為什麼不能一次性運行所有內容，然後修復監控中出現的問題？
A：一切都要循序漸進，因為服務之間存在依賴關係。 一切都應該立即檢查，而不是等待監控——因為最好立即處理問題，而不是等待問題惡化。
7:40。 最後一位管理員（協調員）上床睡覺了。 第一天的工作已經完成。
8:09。 第一批開發人員、數據中心工程師和管理員（包括新協調員）開始了恢復工作。
09:37。 我們開始籌建7號館（最後一個）。
同時，我們繼續修復其他房間沒有修復的問題：更換磁盤/內存/服務器，修復監控中“燒毀”的所有內容，在主備方案中切換角色等等小事情，其中有儘管如此，還是有很多。
17:08。 我們允許所有常規生產工作。
21:45。 第二天的工作就完成了。
09:45。 今天是星期五。 監控中還存在不少小問題。 週末快到了，大家都想放鬆一下。 我們繼續盡我們所能大規模修復一切。 本來可以推遲的常規管理任務被推遲了。 協調員是新的。
15:40。 突然，另一個數據中心的一半核心網絡設備堆棧重新啟動。 戰線不再輪換，以盡量減少風險。 對於用戶來說沒有任何影響。 後來查明是底盤有故障。 協調員正在同時修復兩起事故。
17:17。 另一個數據中心的網絡運行已恢復，一切都已檢查完畢。 數據中心投入旋轉。
18:29。 第三天的工作以及事故後的恢復工作總體已經完成。
後記
04.04.2013 、《同學們》 ——三天來門戶完全或部分不可用。 在整個過程中，來自不同城市、不同公司的 100 多人（再次感謝！）在數據中心遠程、直接、手動和自動修復了數千台服務器。
我們得出了結論。 為了防止這種情況再次發生，我們已經並將繼續開展廣泛的工作至今。
目前的事故與404事故的主要區別是什麼？
- 我們有一個“事故行動計劃”。 我們每季度進行一次演習 - 我們對緊急情況進行角色扮演，一組管理員（依次）必須使用“緊急行動計劃”來消除這種情況。 領導系統管理員輪流扮演協調員的角色。
- 每個季度，在測試模式下，我們都會通過 LAN 和 WAN 網絡隔離數據中心（依次），這使我們能夠及時識別瓶頸。
- 更少的損壞磁盤，因為我們收緊了標準：更少的運行時間，更嚴格的 SMART 閾值，
- 我們完全放棄了 BerkeleyDB，這是一個舊的且不穩定的數據庫，在服務器重新啟動後需要大量時間來恢復。
- 我們減少了使用 MS SQL 的服務器數量，並減少了對其餘服務器的依賴。
- 我們有自己的 ，兩年來我們一直在積極遷移所有服務。 雲極大地簡化了應用程序的整個工作週期，並且在發生事故時它提供了以下獨特的工具：
- 一鍵正確停止所有應用程序；
- 從故障服務器輕鬆遷移應用程序；
- 整個數據中心的自動排名（按服務優先級順序）啟動。
本文描述的事故是自第404天以來最嚴重的一次事故。 當然，並不是一切都很順利。 例如，在另一個數據中心因火災損壞的數據中心不可用期間，其中一台服務器上的磁盤發生故障，即 Cassandra 集群中的三個副本中只有一個仍可訪問，這就是為什麼 4,2% 的移動應用程序用戶無法登錄。 與此同時，已經連接的用戶繼續工作。 此次事故總共發現了 30 多個問題——從平庸的錯誤到服務架構中的缺陷。
但當前事故與第 404 次事故最重要的區別在於，當我們正在消除火災後果時，用戶仍在發短信和視頻通話 、玩遊戲、聽音樂、互贈禮物、觀看視頻、電視劇和電視頻道 ，並且還流入了 .
你的事故進展如何？
來源： www.habr.com