CIO如何測試你的DR/BC計劃

對還沒準備DR/BC計劃的企業感到悲哀。适當的測試會彌補差距，消除IT和業務很多的不幸。

多年來，我在一定程度上自大的發表很多意見，以接近建立災難恢複/業務持續性計劃。我的建議包括，認清技術的修複和持續性僅僅是DR/BC計劃應該包含的一部分。重要的是，在業務風險基礎上排列計劃裡元素的優先級，以及隻聚焦于沒了它哪怕一小段時間你都沒法生存的系統和過程。

因為我确定我的建議言之有理，你肯定做了所有的事。但現在，是時候測試你的DR/BC計劃了。如何能用有意義的方式——幫你鑒别和解決差距，但又不會損傷企業（或你的名譽），測試該計劃呢？

依我的經驗，有4種可能的方法來測試一份DR/BC計劃。如下：

1.考慮緊急情況，精神上想像一下你的響應。

2.意外引起緊急情況，在你從錯誤中恢複時觸發該計劃。

3.推遲你的測試，直到有真正緊急情況出現。用該緊急情況立即測試你的計劃。

4.提出實際的、分階段的方法，來測試你的DR/BC計劃，而無需破壞企業（或你的名譽）。

經過一段艱辛的路程，我才了解前3條方法還有待改進。

方法#1有點像消防演習，但是告訴演習參加人員去想象逃離着火建築并在指定地點集合——所有的一切在面臨真實火災時變得毫無意義。

方法#2有效，卻在恢複時留下相當多的破壞。多年前，我們的資料庫被完全鎖死，隻好關閉業務。我們死水一潭，隻好啟動DR/BC計劃以修複系統。我們從中吸取了教訓，知道了計劃的差距，但卻失去了很多信任——對所有企業做相似的測試，針對所有類型風險，我本應該有很多意外的故障時間。我人生的目标是意外停工為零。

方法#3有非常高的風險，因為我們的DR/BC計劃經常有差距——有時是很重要的差距，是以等着一場真實的緊急情況來測試我們的計劃，讓我們公開面對暴露差距所帶來的影響

DR/BC計劃測試與日常維護看齊

接下來是方法#4

該方法要花費一些時間思考，因為我們想按邏輯步驟測試。那些步驟需要對齊整體的DR/BC計劃和企業的需求。該方法也需要與企業非IT部門高水準的協調，因為你會測試人們每天使用的具體子系統和流程。

舉個例子，測試電話系統運作中斷的恢複，你需要包含客戶支援、銷售和後勤——即利用電話系統處理公司關鍵業務的任何人。

接着講測試電話系統運作中斷的例子，按步驟執行的測試計劃也許與一些電話系統的計劃保養一緻----為何要中斷系統超過所需要的次數？在你計劃維護時段，涉及企業的其餘人員以便參與的每人觸發系統，然後啟用DR/BC計劃。随着電話打進來，你如何能查找出員工的身份？你的顧客如何聯系你？你如何跟蹤發貨？為了測試，建立某種“戰争房間”來跟蹤DR/BC計劃子集的執行情況，問題和差距，以及你發現的所有有意思的和令人不安的事物。充分利用每次可能的計劃保養時段來測試你的計劃。

為關鍵任務系統測試DR/BC計劃

然而，如果系統和流程不會中斷（或者不允許中斷），即便是計劃保養的時候，那又該怎麼辦？如果系統和流程是關鍵任務，很可能這些系統是有某種形式的備援備份。既然那樣，測試就使用系統的備援備份版本。分割出系統支援企業的一部分，比如，呼叫中心的10%，把他們連接配接到你準備測試的備援備份系統上。

記住，你要測試的是DR/BC計劃，是以你需要一直建立整個系統流程的點到點使用的複制品。使用一部分業務以實作測試目标，而無需關掉整個企業系統。

最後一件事：你執行分階段測試的開始幾次，可能會有混亂、失調、恐慌和挫敗。是以，我最後建議，為最糟的情況做好準備，然後當你觀察企業的一部分從緊急情況中恢複時，帶一些爆米花來吃——Keystone Kops電影與接下來要發生的古怪動作相比都顯蒼白。

本文轉自d1net（轉載）