即使在災難期間，也總有時間喝杯茶。
DRP （災難恢復計劃）是理想情況下永遠不需要的東西。 但是，如果在交配季節遷徙的海狸突然咬斷了主光纖，或者初級管理員放棄了生產基地，那麼您肯定要確保自己有一個預先制定的計劃來處理所有這些恥辱。
當驚慌失措的客戶開始致電技術支持時，一名初級人員正在尋找氰化物，您明智地打開紅包並開始整理一切。
在這篇文章中，我想分享有關如何編寫 DRP 及其應包含的內容的建議。 我們還將研究以下內容：
- 學會像惡棍一樣思考。
- 我們來分析一下末世時期喝一杯茶的好處。
- 考慮一個方便的 DRP 結構
- 讓我們看看如何測試它
哪些公司可能會從中受益？
當 IT 部門開始需要這些東西時，很難劃清界限。 我想說，如果滿足以下條件，您肯定需要 DRP：
- 停止服務器、應用程序或丟失某些數據庫將給整個業務帶來重大損失。
- 您擁有完善的 IT 部門。 我的意思是，一個部門作為公司的一個成熟的單位，有自己的預算，而不僅僅是幾個疲憊的員工鋪設網絡、清除病毒和重新填充打印機。
- 您有一個現實的預算，可以在緊急情況下至少進行部分裁員。
當 IT 部門幾個月來一直在為舊服務器請求至少幾個 HDD 進行備份時，您不太可能組織對已停止服務的全面遷移以備用容量。 儘管這裡的文檔也不是多餘的。
文檔很重要
從文檔開始。 假設您的服務運行在三代管理員之前編寫的 Perl 腳本上，但沒有人知道它是如何工作的。 積累的技術債務和缺乏文檔將不可避免地不僅射中你的膝蓋，而且射中你的其他四肢，這只是時間問題。
一旦您對現有的服務組件有了很好的描述，就可以提高崩潰統計數據。 幾乎可以肯定，它們將是完全典型的。 例如，您有時會出現磁盤滿的情況，這會導致節點出現故障，直到手動清理為止。 或者由於有人再次忘記續訂證書而導致客戶端服務不可用，而 Let's Encrypt 無法配置或不想配置。
像破壞者一樣的想法
最困難的部分是預測那些以前從未發生過但可能完全破壞您的服務的事故。 在這裡我們通常和同事一起扮演小人。 喝很多咖啡和一些美味的東西，然後把自己鎖在會議室裡。 只需確保在同一次會議中，您鎖定了那些自己提出目標服務或定期使用該服務的工程師。 然後，無論是在黑板上還是在紙上，您開始畫出您的服務可能發生的所有可能的恐怖情況。 沒有必要詳細到特定的清潔女工和拔掉電纜，考慮“破壞本地網絡完整性”的場景就足夠了。
通常，最典型的緊急情況分為以下類型：
- 網絡故障
- 操作系統服務故障
- 應用失敗
- 鐵故障
- 虛擬化失敗
只需瀏覽每個視圖，看看哪些內容適用於您的服務。 例如，Nginx 守護進程可能會崩潰並且無法正常運行 - 這是操作系統方面的故障。 導致 Web 應用程序進入非工作狀態的一種罕見情況是軟件故障。 在這個階段的發展過程中，做好問題的診斷非常重要。 例如，如何區分虛擬化上掛起的接口與思科故障和網絡崩潰。 這對於快速找到責任人並開始追究責任直到事故得到解決非常重要。
寫下典型問題後，我們倒了更多咖啡，並開始考慮最奇怪的場景，即某些參數開始超出正常範圍。 例如：
- 如果活動節點上的時間相對於集群中其他節點的時間向後移動一分鐘，會發生什麼情況？
- 如果時間向前推進，如果向前推進 10 年呢？
- 如果集群節點在同步過程中突然斷網怎麼辦？
- 如果兩個節點由於網絡上彼此暫時隔離而無法共享領導權，會發生什麼情況？
在這個階段，相反的方法有很大幫助。 找一個團隊中最頑固、想像力最差的成員，讓他在最短的時間內安排改道，這會降低服務質量。 如果很難診斷，那就更好了。 你不會相信工程師在提出破壞某些東西的想法時會想出奇怪而酷的想法。 如果你答應他們為此提供一個測試台，那就非常好。
你的這個DRP是什麼？！
您已經定義了威脅模型。 他們還考慮到當地居民為了尋找銅而切斷光纖電纜，以及嚴格在周五 16:46 斷開無線電中繼線的軍用雷達。 現在我們需要弄清楚如何處理這一切。
你的任務是寫出在緊急情況下會打開的同樣的紅包。 立即預料到，當（不是如果！）一切都搞砸了時，只有最沒有經驗的學員才會在附近，他們的手會因所發生的事情的恐怖而劇烈顫抖。 了解醫療辦公室如何實施緊急標誌。 例如，過敏性休克該怎麼辦。 醫務人員熟記所有的治療方案，但當附近的一個人開始死亡時，很多時候每個人都無能為力地抓住一切。 為此，牆上掛著清晰的說明，上面寫著“打開某某的包裝”和“靜脈注射這麼多單位的藥物”等內容。
緊急情況下很難思考！ 應該有簡單的脊柱解析說明。
一個好的 DRP 由幾個簡單的塊組成：
- 事故開始時應通知誰。 為了盡可能並行化消除過程，這一點很重要。
- 如何正確診斷 - 我們跟踪、查看 systemctl status servicename 等等。
- 每個階段可以花多少時間。 如果您沒有時間在 SLA 時間內親手修復它，虛擬機將被終止並從昨天的備份中回滾。
- 如何確保崩潰已經結束。
請記住，DRP 在服務完全失敗時啟動，並通過恢復完成，即使效率有所降低。 僅僅丟失預訂不應激活 DRP。 您還可以在 DRP 中開一杯茶。 嚴重地。 據統計，許多事故從不愉快變成災難性的，都是因為工作人員倉促地趕去修復某些東西，同時殺死了唯一有數據的存活節點，或者最終結束了集群。 一般來說，5 分鐘的時間喝杯茶可以讓你有一點時間冷靜下來並分析正在發生的事情。
不要混淆 DRP 和系統通行證！ 不要讓不必要的數據超載。 只需提供通過超鏈接快速方便地轉到文檔的所需部分並以擴展格式閱讀有關服務架構的必要部分的機會即可。 在 DRP 本身中，只有關於在何處以及如何連接複製粘貼特定命令的直接說明。
如何正確測試
確保任何負責的員工都能夠完成所有項目。 在最關鍵的時刻，工程師可能沒有所需系統的訪問權限，所需帳戶沒有密碼，或者不知道什麼是“通過代理連接到服務管理控制台”總公司”的意思。 每個項目都應該盡可能簡單。
錯 - “進入虛擬化並重新啟動死節點”
正確地 - “通過 Web 界面連接到 virt.example.com，在節點部分中，重新加載導致錯誤的節點。”
避免歧義。 還記得那個受驚的實習生嗎？
請務必測試 DRP。 這不僅僅是一個表演計劃——它可以讓您和您的客戶快速擺脫危急情況。 最好多次執行此操作：
- 一名專家和幾名實習生在盡可能模仿真實服務的測試台上工作。 專家以各種方式中斷服務，並讓學員根據DRP 恢復服務。 記錄文檔中的所有問題、含糊之處和錯誤。 對學員進行培訓後，對DRP進行了一些不起眼的地方的補充和簡化。
- 在真實服務上進行測試。 事實上，您永遠無法創建真實服務的完美副本。 因此，每年有幾次需要有計劃地關閉部分服務器、斷開連接並從威脅列表中安排其他事故，以便評估恢復順序。 半夜計劃內 10 分鐘的停機比高峰負載下突然發生幾個小時的故障並導致數據丟失要好。
- 真正杜絕事故發生。 是的，這也是測試的一部分。 如果發生不在威脅清單中的事故，則有必要根據調查結果補充並最終確定DRP。
關鍵點
- 如果胡說八道可能發生，它不僅不會發生，而且會在最災難性的情況下發生。
- 確保您擁有用於故障轉移的資源。
- 確保您有備份，它們會自動創建並定期檢查一致性。
- 考慮典型的威脅場景。
- 讓工程師有機會提出非標準選項來提供服務。
- DRP 應該是簡單而愚蠢的指令。 所有復雜的診斷僅在客戶恢復服務後進行。 即使處於待機狀態。
- 列出 DRP 中的關鍵電話號碼和聯繫人。
- 定期測試員工對 DRP 的理解。
- 安排產品上有計劃的事故。 支架不能代替一切。
來源： www.habr.com