完整的灾难恢复计划测试不是许多企业可以经常进行的。计划和执行灾难恢复测试需要两个宝贵的资源：时间和金钱，仅出于这一原因，灾难恢复团队必须现实地确定他们每年可以执行的测试数量。大多数主要应用程序一年最多只进行一次端到端测试，有些应用程序可以每三年测试一次，这取决于灾难恢复团队的要求。
这将灾难恢复团队置于两难境地：如果他们不能足够频繁地进行测试，关键应用程序或进程可能会错过必要的更新，然而，如果他们用无关的测试分散太多，他们就有可能耗尽前面提到的宝贵资源，测试战略必须几乎和恢复本身一样彻底，这将确保灾难恢复团队不会错过任何必要的更改，并可以最大限度地利用有限的资源。
要最大限度地利用灾难恢复测试策略，请考虑纳入这些最佳实践。
确定测试类型并制定相应的计划
灾难恢复测试分为两种类型：完全灾难恢复测试和组件测试，不同之处在于，组件测试本质上较小，并且测试应用程序的子集，大多数组件测试实际上是冒烟测试，以在投入大量资源进行全面灾难恢复测试之前，帮助确保整个应用程序的较小部分正常工作。
在讨论测试的技术方面之前，了解正在测试的内容至关重要，这是否是一个完整的交互式灾难恢复测试，要求用户登录，在危机情况下执行，并测试应用程序是否按预期工作，或者，是否足以验证系统和软件是否可用？根据企业灾难恢复计划中的工具或流程，可能需要对该计划执行一次全面检查，以测试该计划在危机中将如何运行。
确保一切及早就位——并反复检查
这可能看起来微不足道，但在运行完整测试之前没有检查关键组件是企业最常见和可以预防的错误之一。灾难恢复测试的重点是确保事情按预期运行，但如果有一个修复可以在完整测试之外完成，那么就值得检查一下是否一切都预先设置好了，这是组件测试可以派上用场的一个领域。
一个常见的例子是，it团队发现所需的防火墙端口未打开，这是他们在完整的灾难恢复测试中可能会发现的，但为了节省时间和资源，提前检查仍然更容易。修复防火墙问题可能是一个令人沮丧的过程，而且这可能不是安全和网络工作人员在运行端到端灾难恢复测试期间想要处理的事情。
好的文档始终是重要事项
良好文档的重要性至高无上，如果灾难恢复测试是由经验较少的员工进行的，他们可能会在测试过程中面临并解决几个问题，然而，如果他们不记录这些问题和补救措施，重要信息的丢失可能会显著影响灾难恢复测试或实际恢复的速度。
灾难恢复团队必须具备四种类型的文档，才能制定强大的测试策略：
1.当前的灾难恢复计划是书面的，有离散的步骤和时间表。
2.关于测试过程中出现的任何问题以及如何修复这些问题的说明，如果有临时解决方法，请概述它是什么。
3.测试过程的详细文档，这应该包括正在测试什么以及由谁测试。
4.测试完成时管理员签字。
不要绕过全面的总结和报告
这看起来可能很简单，但测试后报告是许多灾难恢复团队的不足之处，不幸的是，这是对管理层影响最大、影响最大的任务。
管理层通常对it的具体细节不感兴趣，但在高层次上传递成功或失败是一项复杂的任务，在关闭生产系统以测试灾难恢复方案时尤其如此，就像处理真正的灾难一样，it团队应该在整个过程中创建全面的文档，以告知管理层测试是如何进行的，以及他们必须解决的任何领域。
为避免在总结过程中因技术细节而使管理负担过重，在测试过程中及时沟通高级状态至关重要，请记住，某些灾难恢复测试的执行时间可能相当长，跨越24小时或更长时间，确保这些关键的利益相关者随时了解正在发生的事情，这让他们感到高兴，并显示出良好的沟通。
企业网d1net(www.d1net.com)：
国内主流的to b it门户，同时在运营国内最大的甲方cio专家库和智力输出及社交平台-信众智(www.cioall.com)。同时运营19个it行业公众号(微信搜索d1net即可关注)。
凯发在线的版权声明：本文为企业网d1net编译，转载需在文章开头注明出处为：企业网d1net，如果不注明出处，企业网d1net将保留追究其法律责任的权利。