利用虚拟基础架构应对业务灾难

对于严重依赖于信息系统的业务运营而言，应用程序停运即使时间很短，也会造成严重的影响。 如果发生数据丢失，影响将更加巨大。 IDC 估计：在发生灾难的情况下，平均每次事故将损失 $3,000,000，而每小时将损失 $381,000。

    要建立一套高效的业务连续性策略，企业必须对其 IT 应用程序进行评估，并确定各个应用程序对业务运营的重要性。一套全面的业务连续性策略由多项内容组成，其中包括：向不同应用程序提供的从灾难预防到热站点和数据备份等灾难保护方法，灾难发生时的人员配备计划，文档完备的行动计划，以及审核和测试流程。要测算将特定应用程序或系统包括在灾难保护计划（从属于大的业务连续性计划）中的成本，就应该从此应用程序潜在的风险程度和它停止工作可能造成的影响两方面来测算。 对应用程序实施灾难恢复的解决方案的成本应低于停机造成的影响。

    对于一家成功的企业而言，业务连续性和灾难恢复 (DR) 计划是管理风险的关键。 如果没有建立起主动式灾难恢复计划，在遭受一次严重的灾难后，大约有 60% 到 90% 的公司会在两年内停业。 但是，如果希望在短时间内实施一套可靠的恢复策略，费用会非常昂贵，原因是这需要负担用于镜像主数据中心设备的恢复设备。 对主目标设备和恢复目标设备的升级必须同步进行，因此很多公司只得放弃这一流程。有些公司采用了一种折衷的灾难恢复策略，例如：仅对最关键的应用程序进行灾难恢复、对不同的设备采用人工流程，或采取外包的方式，以降低因 DR 中心灾难保护能力不足而在应用程序支持范围、可接受的停机时间和恢复的可靠性等方面存在的风险。这种方法同样很被动。实际上，越来越多的企业在使用虚拟基础架构实现经济高效的灾难恢复。

商业上可行的业务连续性策略

    灾难补救计划过程中有几种常用的标准。 其中最常用的两种标准是恢复点目标 (RPO) 和恢复时间目标 (RTO)。RPO 指的是在发生灾难时，恢复的数据未与生产数据同步的时间长度。 RTO 指的是恢复操作所需的时间。其他需要考虑的问题就是，如果只是部分恢复 IT 系统，能否在灾难发生后恢复业务运营。

    问题的补救措施与问题本身一样五花八门。让我们看几个可能用于业务连续性的信息系统 (IS) 设计。

• 连续可用性。 在该体系结构中，工作负载平衡加载到多个平台上（通常分布于不同的地理位置）。 并为每个平台调配了备用能力。 一个平台发生故障后，就会将它的工作负载分配给剩余的平台。 这种方法的优点在于即使是在发生灾难后，公司仍能维持业务运营。

• 在线和近线站点备份。 这种策略假设故障切换站点可用，它配备了、冷却设备、连接、物理保护，以及所有其他关键要求。 如果发生灾难，故障切换站点有足够的设备可用于恢复业务运营。 这种方法的优点在于它不像连续可用性方法一样需要完整的系统检查。

• 备份到。 最广为人知的方法，使用一种流行的备份管理包将数据备份到磁带上。 这种方法执行的是文件对文件的备份。 然后异地这些磁带，以备发生灾难时进行补救。这种方法最经济，而且在发生重大灾难时，还可以使用相同的方法应对需要谨慎处理的数据问题（即，意外删除文件）并执行恢复。 但是，这使得业务运营的恢复时间变得很难预测。

    商业上可行的业务连续性策略在实施业务连续性计划的成本和潜在停机造成的影响及其可能性之间取得了良好的平衡。 这些更加经济高效的方法允许 IT 专业人士在更广泛的应用程序支持范围内实施连续性计划，实现几乎不中断的运营。借助虚拟基础架构，中型企业也具备了实现业务连续性的商业可行性，而且它的支持范围大于最关键 IT 应用程序中的前 5%。