灾难恢复测试识别特征的弱点

两只小蜜蜂

灾难恢复测试识别特征的弱点
灾难恢复的问题是大多数企业被迫面对的问题，如同合规性问题，安全性问题和性能问题。 由于这个操作要求，企业制定了一个全面的灾难恢复计划。 但是，又有多少家企业进行了定期的灾难恢复测试呢？假设可能是在几个月前制定的计划在今天仍然行之有效，这样做真的安全吗？
灾难恢复测试是一项重要的操作流程。它需要做与开发原始DR计划相同的尽职调查。以下是为什么要建立全面灾难恢复测试制度的一些最有说服力的原因。
识别遗留基础设施
运营团队花费大部分时间使得关键业务的基础设施能够顺利运行。他们进行性能调整，执行硬件更改，当然还有运用应用软件补丁。自从配置了灾难恢复环境以来，可能已经实现了大量的小型修复。
将多个硬件/软件修复应用于实时环境的累积效应可能会导致灾难恢复环境淘汰的危险。这些修补程序几乎总是适用于使关键业务应用程序顺利运行的情况。 如果它们没有在DR环境中镜像，那么如果发生灾难，这些应用程序将有执行不良或无法完全执行的危险。
因此，定期进行灾难恢复测试可以让企业在传统基础架构的有效作用下对核心应用进行测试。它使操作团队有机会发现任何潜在的问题，并进行相关修复工作。
有机会开发专长
大多数灾难恢复计划将纳入整体的流程，并由得力的多样化团队来执行。许多这些过程很多都是由个人所有者单独测试的。这并不能证明端到端计划的整体有效性。
只有通过进行全面的灾难恢复测试，才能证明该计划的真正有效性。这种测试需要从管理团队启动灾难恢复计划开始。
这使得端到端灾难恢复过程中参与的所有利益相关者都有机会学习如何执行它的专业知识。 个人或部门可以确定他们自己已经掌握了灾难恢复的流程。 但是他们在全面紧急情况下多久测试一次呢？
应用程序测试和QA团队不会针对灾难恢复环境测试提交代码。DevOps循环仅测试应用程序本身及其功能。该应用程序仅在集成环境下进行测试，然后才能被推送到现场。因此，在破坏性灾难的情况下，应用程序不会在其将要运行的实际环境中进行测试。
管理灾后变更
管理团队考虑到每个业务流程对灾难恢复环境的影响后会变更多少呢？可能很少，这样做的代价是可能会使工作量增加一倍。
经常性的灾难恢复测试可以突出显示操作流程变化所产生的任何问题。灾难恢复计划需要付诸行动。
没有人想要考虑当需要时会发生什么情况的影响，灾难恢复环境便失败了。确保公司最有可能在灾难性技术失败的情况下幸存的唯一方法是定期测试灾难恢复计划和环境。