灾难恢复测试评估业务连续性 （BC）和灾难恢复（DR）计划的有效性，以帮助企业避开环境、人类或技术的威胁。测试灾难恢复的过程或进程允许组织在真正灾难发生之前，评估是否需要额外的工作人员，培训或者系统维护。

　　TechTarget最近在社交媒体Twitter上发起关于灾难恢复计划的讨论，很多从业人员以及专家们，包括特别专家Paul Kirvan（他是一位拥有超过20年业务连续性和灾难恢复经验的独立顾问和审计师），一起分享了他们的建议和想法，比如如何安排灾难恢复（DR）测试。

　　接下来来看看他们都提出了哪几个建议。

　　灾难恢复（DR）测试计划，没做计划，那就为失败做好计划

　　灾难恢复（DR）以及和业务连续性（BC）专家Paul Kirvan认为，没做计划，那就为失败做好计划。

　　DR和BC策略取决于IT和业务进行合作，以测试DR流程，确保最关键的系统能尽快启动并运行。DR测试可以根据手头的系统或流程，提前几周、几个月甚至一年进行计划。Kirvan强调DR测试计划的主要错误是缺乏准备和不引入相关人员。

　　虽然组织不能精准预测他们可能会被迫面对的灾难，但一定要确保关键人员都了解灾难恢复测试的运行，则可以给他们机会去记录其执行情况是好是坏。Kirvan补充道：

　　还有一条，没有让正确的人员参与进来，例如错误的DBA，错误的网络管理员。#

　　不要武断臆测服务中断原因

　　移动行业研究和企业咨询公司Sepharim集团创始人兼首席执行官Bob Egan警告说：不要武断臆测已知或未知的服务中断原因，因为这样做你会吃亏的。

　　有一长串的潜在中断原因，从基本的人为失误，到技术故障，以及低劣的编码校对和环境危机。在讨论里， Egan表明，如果没有证据明确的服务中断原因，企业是不能改善DR测试的。例如，上个月黑客中断了服务器，这并不意味着黑客也是本月中断的原因。

　　测试将不会100%顺利运行。重要的是组织能够准确定位是谁，如何，何时，何地，为什么会服务中断，然后去计划重新测试。

　　避免在业务灾难恢复计划中的测试计划堆积

　　讨论者认为，准备对运行一个商业灾难恢复计划的合适测试至关重要。灾难恢复专家Paul Kirvan警告说，如果IT没做计划，也准备好失败，并随后强调细致DR测试计划安排的需要。

　　“准备和提交一个测试计划给管理层，这样可以为未来一系列的测试活动预先分配资源。然后， 要为未来12个月内的每个测试事件各自进行计划，“专家Jon Toigo最近在一篇专栏文章中解释到。“基于时间表，以非线性方式进行的复苏任务和程序，执行每个测试事件来优化测试时间。”

　　Kirvan和Toigo都推荐分别测试相互依赖的任务以避免一个测试过程的失败影响到整个事件。有意识或无意识地，未能提前调整测试安排——重叠测试可能是徒劳的、并得出错误的结果。

　　别忘了对DR测试结果归档和事后回顾

　　以事后回顾的方式记录测试灾难恢复（DR）计划不仅会提升未来的测试，而且可以让您的组织在真正的灾难发生时立于不败之地。

　　其中一位参与者Forrester Rachel Dines，是现任的Riverbed Technology产品营销经理，他倡导事后回顾的重要性。Dines很快得到其他同意这一点的推特讨论者的支持，不回顾的话，组织未来灾难恢复的障碍的可能性就会增加：

　　@AndiMann：可以说不回顾并记录失败方案的话。就太难了，这么多可能的陷阱。

　　@AndiMann： 太多的人考虑“修复”；但也需要归档以及制度化事后回顾。

　　@DDubie： DR/BC 测试将显示结果，或好或坏，需要对其归档以避免有下次类似问题。

　　Andi Mann还建议，将归档纳入制度化标准，这将确保您的组织在其DR计划中学到什么可行，什么不可行。为了获取合适的归档、关键人员必须参与DR测试并把它像一场真正的灾难那样对待。

　　使用基于真实场景而不是猜测的灾难恢复案例

　　另一位参与者Antstanley认为， 进行灾难恢复（DR）测试时要避免的头号陷阱是缺乏紧迫感和全面性。其他的SearchCIO推特话题参与者同意基于真实场景的灾难恢复案例的重要性：

　　@IamStan：（我）看到很多不幸的事件。 对复选框依赖盛行，导致弱操作弹性. .

　　@AndiMann：真的。如果设定为必须通过，那为什么还要运行测试呢。可以更好的使用那些时间或者金钱。

　　@mthiele10：如果它是一个完整的测试，你必须做两件事1）涉及业务代表2）用现实世界的例子计划测试。

　　备战真正的攻击，企业和他们的CIO必须像对那样待一场真正的攻击那样去对待DR测试。此次讨论中还有一些其他建议：做好失败计划，提前安排测试和从头到尾记录一切——这些都应指导你的DR策略。