完整的災難恢復計劃測試不是許多企業可以經常進行的。計劃和執行災難恢復測試需要兩個寶貴的資源：時間和金錢，僅出于這一原因，災難恢復團隊必須現實地確定他們每年可以執行的測試數量。大多數主要應用程序一年最多只進行一次端到端測試，有些應用程序可以每三年測試一次，這取決于災難恢復團隊的要求。
這將災難恢復團隊置于兩難境地：如果他們不能足夠頻繁地進行測試，關鍵應用程序或進程可能會錯過必要的更新，然而，如果他們用無關的測試分散太多，他們就有可能耗盡前面提到的寶貴資源，測試戰略必須幾乎和恢復本身一樣徹底，這將確保災難恢復團隊不會錯過任何必要的更改，并可以最大限度地利用有限的資源。
要最大限度地利用災難恢復測試策略，請考慮納入這些最佳實踐。
確定測試類型并制定相應的計劃
災難恢復測試分為兩種類型：完全災難恢復測試和組件測試，不同之處在于，組件測試本質上較小，并且測試應用程序的子集，大多數組件測試實際上是冒煙測試，以在投入大量資源進行全面災難恢復測試之前，幫助確保整個應用程序的較小部分正常工作。
在討論測試的技術方面之前，了解正在測試的內容至關重要，這是否是一個完整的交互式災難恢復測試，要求用戶登錄，在危機情況下執行，并測試應用程序是否按預期工作，或者，是否足以驗證系統和軟件是否可用？根據企業災難恢復計劃中的工具或流程，可能需要對該計劃執行一次全面檢查，以測試該計劃在危機中將如何運行。
確保一切及早就位——并反復檢查
這可能看起來微不足道，但在運行完整測試之前沒有檢查關鍵組件是企業最常見和可以預防的錯誤之一。災難恢復測試的重點是確保事情按預期運行，但如果有一個修復可以在完整測試之外完成，那么就值得檢查一下是否一切都預先設置好了，這是組件測試可以派上用場的一個領域。
一個常見的例子是，IT團隊發現所需的防火墻端口未打開，這是他們在完整的災難恢復測試中可能會發現的，但為了節省時間和資源，提前檢查仍然更容易。修復防火墻問題可能是一個令人沮喪的過程，而且這可能不是安全和網絡工作人員在運行端到端災難恢復測試期間想要處理的事情。
好的文檔始終是重要事項
良好文檔的重要性至高無上，如果災難恢復測試是由經驗較少的員工進行的，他們可能會在測試過程中面臨并解決幾個問題，然而，如果他們不記錄這些問題和補救措施，重要信息的丟失可能會顯著影響災難恢復測試或實際恢復的速度。
災難恢復團隊必須具備四種類型的文檔，才能制定強大的測試策略：
1.當前的災難恢復計劃是書面的，有離散的步驟和時間表。
2.關于測試過程中出現的任何問題以及如何修復這些問題的說明，如果有臨時解決方法，請概述它是什么。
3.測試過程的詳細文檔，這應該包括正在測試什么以及由誰測試。
4.測試完成時管理員簽字。
不要繞過全面的總結和報告
這看起來可能很簡單，但測試后報告是許多災難恢復團隊的不足之處，不幸的是，這是對管理層影響最大、影響最大的任務。
管理層通常對IT的具體細節不感興趣，但在高層次上傳遞成功或失敗是一項復雜的任務，在關閉生產系統以測試災難恢復方案時尤其如此，就像處理真正的災難一樣，IT團隊應該在整個過程中創建全面的文檔，以告知管理層測試是如何進行的，以及他們必須解決的任何領域。
為避免在總結過程中因技術細節而使管理負擔過重，在測試過程中及時溝通高級狀態至關重要，請記住，某些災難恢復測試的執行時間可能相當長，跨越24小時或更長時間，確保這些關鍵的利益相關者隨時了解正在發生的事情，這讓他們感到高興，并顯示出良好的溝通。
企業網D1net(hfnxjk.com)：
國內主流的to B IT門戶，同時在運營國內最大的甲方CIO專家庫和智力輸出及社交平臺-信眾智(www.cioall.com)。同時運營19個IT行業公眾號(微信搜索D1net即可關注)。
版權聲明：本文為企業網D1Net編譯，轉載需在文章開頭注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號