从业时间较长的“老兵”们都知道，在IT行业理想与现实是有很大差距的。大家总是在谈论一些理想化的最佳实践，但在实践过程中却总会受到这样那样的限制。只能说，在运行较好的IT工作站，这种差距要相对小一些。

　　然而，谈到灾难恢复（DR），这种差距显得更加明显。灾难恢复更像是防范灾难的一种方案，如果你有精心策划的灾难恢复方案，在灾难发生时就可以及时通过远程操控将业务恢复上线，满足其恢复时间目标（RTO）和恢复点目标（RPO）。但是，这对许多公司而言太过理想化。实际上，如果灾难真的发生了，即使是所有的IT员工一同上阵，最终的业务恢复时间也要比RTO要长的多。因此，是时候该想想办法解决这一问题了。这里是可能导致你的灾难恢复计划失败的几个原因：

　　业务部门和IT部门沟通不够

　　灾难恢复是大型业务恢复计划的一部分，为了使其能够成功，你有必要去了解业务需求、驱动因素、相关动态、附属关系以及其它部门容易发生的事故和易犯的错误。然而，Veritas公司的调查显示，有76%的企业是IT部门单独制定灾难恢复计划。尽管说灾难恢复主要涉及IT部门，但它也要有其它部门的合作。因此，灾难恢复计划的制定与整个企业的持续性努力密不可分，这样才能从业务的角度来保证人力和设备能够随时可用。

　　缺乏灾难恢复计划

　　如果问哪项IT业务最需要团队协作？灾难恢复应该首当其冲。在灾难发生时或发生后，灾难恢复计划的实施应该由IT部门牵头，围绕应用、数据库、网络、服务器、客户端和存储等领域，由其它部门通力协作来完成。所有这些都需要专人负责，一步步地进行处理。但是，大多数企业都不能做到这点。很多情况下，灾难恢复过程中相关业务的负责人都对自己的职责不是很熟悉，这很有可能会导致情况向更糟的方向发展。缺乏综合完整的灾难恢复计划对灾难而言具有“火上浇油”的效果——甚至说这是一种更大的灾难。

　　灾难恢复计划不够现实

　　这里要提到一个词——变更管理。灾难恢复计划很容易变得“OUT”。对于灾难恢复计划的管理必须要与变更管理流程紧密结合。如果有新的应用上线，你必须要去考虑它的业务优先性和对于灾难恢复的影响。如果你在灾难恢复计划的制定方面投入了足够的精力，而又能将服务器、应用及其彼此的附属关系和文档说明都包含进去，那在有新元素加入进来时就很好处理——更新一下相关部分并通知有关部门即可。

　　缺乏对灾难恢复计划的测试（或是没有正确测试）

　　对于大多数IT工作站而言，灾难恢复测试都是一件头疼的事情。这意味着企业的主要业务要在一年内要中断一到两次。

　　许多灾难恢复测试计划都不是真正的端到端的测试。真正的灾难恢复和测试应该基于应用层面，而不仅仅是服务器。复杂的应用通常会涉及运行在多台服务器上的多个部件。操作系统和数据的恢复只是第一步，接下来还需要对应用进行恢复和测试。尽管说这有些不太现实，但最终的灾难恢复测试的确需要涉及生产领域。正确的做法是，先在灾难恢复站点将生产设备运行一段时间，然后再逐步迁回本部。

　　另一个关于灾难恢复测试的问题是大家通常都把它当做是一次考试，而不是提高业务质量的一次实践。这就会导致测试质量缩水，有些企业会把测试限制在“安全”的组件上，因为这基本不会出错。事实上，发现Bug是好事，我们可以及时对其进行更正，以免将来出现更大的问题。

　　恢复目标不够现实

　　通常，企业都会设定RTO和RPO目标，然后再依此来排定服务器和应用的优先顺序。但是，在对灾难恢复能力进行客观的测试时，发现这根本没法实现。例如，如果你的恢复目标时间是一天，而恢复设备位于“冷站点”，用的还是磁带备份，那估计就很难实现了。正确的做法是，对服务器的恢复时间做出理性的预判并综合考虑存储和备份环境，来制定恢复的目标和指标。

　　对灾难恢复角色、职责和所有权的划分不够明确。灾难恢复工作要求组织缜密，执行明确。每个参与者必须明确自己的职责和所搭档的人群，更重要的是，还要备有合适的指挥系统。好的灾难恢复计划应该对这些组织架构有明确的划分，并制定一套行之有效的执行体系。这其中需要考虑的因素有：灾难的通告方式、相关人员到达灾难恢复站点的时间、设备后勤支持和恢复流程的执行。

　　在《企业灾难恢复失败的十大诱因（下）》中，我们将继续为大家分析导致企业灾难恢复计划失败的原因，并提供相应的解决建议。