对还没准备DR/BC计划的企业感到悲哀。适当的测试会弥补差距，消除IT和业务很多的不幸。

多年来，我在一定程度上自大的发表很多意见，以接近建立灾难恢复/业务持续性计划。我的建议包括，认清技术的修复和持续性仅仅是DR/BC计划应该包含的一部分。重要的是，在业务风险基础上排列计划里元素的优先级，以及只聚焦于没了它哪怕一小段时间你都没法生存的系统和过程。

因为我确定我的建议言之有理，你肯定做了所有的事。但现在，是时候测试你的DR/BC计划了。如何能用有意义的方式——帮你鉴别和解决差距，但又不会损伤企业（或你的名誉），测试该计划呢？

依我的经验，有4种可能的方法来测试一份DR/BC计划。如下：

1.考虑紧急情况，精神上想像一下你的响应。

2.意外引起紧急情况，在你从错误中恢复时触发该计划。

3.推迟你的测试，直到有真正紧急情况出现。用该紧急情况立即测试你的计划。

4.提出实际的、分阶段的方法，来测试你的DR/BC计划，而无需破坏企业（或你的名誉）。

经过一段艰辛的路程，我才了解前3条方法还有待改进。

方法#1有点像消防演习，但是告诉演习参加人员去想象逃离着火建筑并在指定地点集合——所有的一切在面临真实火灾时变得毫无意义。

方法#2有效，却在恢复时留下相当多的破坏。多年前，我们的数据库被完全锁死，只好关闭业务。我们死水一潭，只好启动DR/BC计划以修复系统。我们从中吸取了教训，知道了计划的差距，但却失去了很多信任——对所有企业做相似的测试，针对所有类型风险，我本应该有很多意外的故障时间。我人生的目标是意外停工为零。

方法#3有非常高的风险，因为我们的DR/BC计划经常有差距——有时是很重要的差距，所以等着一场真实的紧急情况来测试我们的计划，让我们公开面对暴露差距所带来的影响

接下来是方法#4

该方法要花费一些时间思考，因为我们想按逻辑步骤测试。那些步骤需要对齐整体的DR/BC计划和企业的需求。该方法也需要与企业非IT部门高水平的协调，因为你会测试人们每天使用的具体子系统和流程。

举个例子，测试电话系统运行中断的恢复，你需要包含客户支持、销售和后勤——即利用电话系统处理公司关键业务的任何人。

接着讲测试电话系统运行中断的例子，按步骤执行的测试计划也许与一些电话系统的计划保养一致----为何要中断系统超过所需要的次数？在你计划维护时段，涉及企业的其余人员以便参与的每人触发系统，然后启用DR/BC计划。随着电话打进来，你如何能查找出员工的身份？你的顾客如何联系你？你如何跟踪发货？为了测试，创建某种“战争房间”来跟踪DR/BC计划子集的执行情况，问题和差距，以及你发现的所有有意思的和令人不安的事物。充分利用每次可能的计划保养时段来测试你的计划。

然而，如果系统和流程不会中断（或者不允许中断），即便是计划保养的时候，那又该怎么办？如果系统和流程是关键任务，很可能这些系统是有某种形式的冗余备份。既然那样，测试就使用系统的冗余备份版本。分割出系统支持企业的一部分，比如，呼叫中心的10%，把他们连接到你准备测试的冗余备份系统上。

记住，你要测试的是DR/BC计划，因此你需要一直创建整个系统流程的点到点使用的复制品。使用一部分业务以实现测试目标，而无需关掉整个企业系统。

最后一件事：你执行分阶段测试的开始几次，可能会有混乱、失调、恐慌和挫败。因此，我最后建议，为最糟的情况做好准备，然后当你观察企业的一部分从紧急情况中恢复时，带一些爆米花来吃——Keystone Kops电影与接下来要发生的古怪动作相比都显苍白。