六月的时候，国家台风中心宣布2015年的大西洋台风季应该平静度过。如果这是真的，那确是个好消息。不太好的消息是，错误的预测以及2013和2014年比较平静的台风季结合起来似乎哄骗得很多人对防灾产生了放任心理。我则比任何时候都感觉这像Alfred E. Neuman（那个Mad杂志上说“什么？我会担心？”的家伙）的态度——让人有些不安。

话说，国家海洋气象管理局（NOAA）的预测就只是预测而已，基于过去的天气记录和气候特征。有些人说气候变化正在挑战现有的模型，上部大气层中的粒子能量水平正在发生变化。这可能会削弱周期性事件——例如厄尔尼诺现象，大气压变化和风速，以及其它——对暴风雨发生概率的影响。这也不是说预测暴风雨预测就曾经那么精确过。例如，NOAA预测2013年是台风年，现实是那年没有什么极端天气。还有一些影响很大的暴风雨，例如1992年的台风Andrew就发生在NOAA预测不会有什么动静的季节。然而，我访问的很多公司都没有做任何的灾难恢复计划。

有些业务和IT人士告诉我，技术的进步已经让我们不需要灾难恢复计划了。在很多大型机用户那里，他们在说服自己如果用了IBM的虚拟化引擎（TS7700），就可以让他们在任何宕机情况下跳到最近的RUN（Tape Rewind Unload磁带回退卸载）点来自动恢复环境。他们相信那就像把一个进程回退到故障前的一个点，再从那点重新开始那么简单。当然，阅读产品Redbook（红书——IBM产品手册）能得到非常不同的观点。要重启的话，在RUN点之外还有很多因素需要考虑，要保证你有所有恢复业务所需的东西需要仔细地计划和测试。激进的厂商销售代表和客户的选择性接受可能会在他们需要恢复业务的时候给他们带来很多烦恼。

业务连续性的真实含义

x86的世界里也在发生类似的问题。一些Hypervisor市场言论告诉用户“灾难恢复过时了”HA（高可用性）架构（指切换集群）消灭了其必要性。VMware开始把它们的切换集群配置称作内置“业务连续性”。

当然业务连续性的实际含义不是在一对集群服务器之间切换业务处理。根据ISO标准对“业务连续性”的定义，这个过程不只是在意外中断事件中恢复技术堆栈和数据，还包括恢复业务流程，人员和办公场所。我对那些傻到相信切换服务器集群和ISO里定义的业务连续性是一回事的人表示怜悯——特别是当他们为了满足法律或者监管合规而需要满足ISO标准的时候。

让我把话说得再直接一点。丢掉根据规章（例如HIPAA——Health Insurance Portability andAccountability Act, 医疗保险可以移动性和可靠性法案）需要留存的数据会给一个医疗机构带来双重灾难。首先，运营成本会非常大，因为丢掉数据可能影响对病人的医疗服务。其次，如果该机构声称遵循ISO 22301标准，而这个“合规”仅仅是基于Hypervisor厂家把他们的服务器切换功能标榜为“即时业务连续性”，那就可能会有一堆法律问题了。

为什么灾难恢复很重要

我知道没有人想要做灾难恢复计划。还有，类似台风这样在废墟上升起浓烟的大型灾难只占IT故障时间的5%。最大的一部分下线时间是计划停机时间，软件故障，硬件故障，用户操作错误，恶意软件和病毒。所以某种切换（带有持续的数据复制）可能可以帮助公司在95%的可能引起停机的事件中保持业务持续运行。

但是，那不是业务连续性也不是灾难恢复——这是灾难避免。当然也是一个很重要的能力，不过不是同一回事。灾难恢复和业务连续性计划人员需要考虑不可抗力摧毁业务流程的情况。你需要考虑假如你不能访问你的系统和数据的话，如何在异地重启业务，不管原因是什么。

首先，你要打造一个真正高可用的数据架构——它的可用性可以测试也验证。数据复制加上祈祷是不够的。你要严重你的镜像和副本，保证数据在连续复制而副本存储在一个足够远的地方，不会和主站受到同一个自然灾害的威胁。

很多公司都做不到这点。在一对集群服务器，甚至在一对本地服务器和一个站外远程集群后面的一对直连存储之间镜像数据是远远不够的。你要分析和发现在另一个主机上重启业务所需要的所有数据——包括业务数据和支持文件（还有hypervisor软件，驱动程序，等等）。然后你要确定你的目标恢复集群的物理位置，并理解距离产生的延迟和网络抖动会对你的数据实时性以及可用性有何影响。后一个目标需要你经常性地拆掉镜像并检查本地和远程数据集的一致性。

把头伸进云里

如果你的备份目标是一个“云”， 你需要知道这个服务的物理位置在哪里。一个云可以提供顶级的灾难恢复服务等级协议（SLA），但是距离会很大程度上影响服务商提供服务的能力。


另一方面，如果你的DRaaS（灾难恢复即服务）是通过SONET或者MPLS这样的城域网来访问的，你要自己考量一下距离是不是足够远了，来避免相同的灾难会同时降临到他们那里，不过是一个城市大规模停电或者是一个100千米或者更大规模的飓风。如果DRaaS的服务商就在街对面的话，你的数据是不安全的。

另一方面，如果你的云服务商是通过WAN(广域网)来访问的，它可能就不一定适合作为那些对由延迟的差别比较敏感的事务数据。

每种情况都需要测试。让你的策略就能够通过计划的和临时的测试。很多所谓的“DRaaS”服务其实是“DR灵机一动”——那些主机托管服务商把DR当作他们菜单上的一个新项目，而并没有真
的理解DR的真正含义。有很多软件厂家都在给备份或者镜像软件开发“简单易用”的前端界面，这些软件可以为客户提供云接口。通过网络界面提供一个复杂的数据保护软件不意味着这个厂家了解DR／BC的相关规划原则，或者能够提供有效的业务连续性。

总结一下：DR／BC规划对那些打算应对那些100%引起财务危机的5%宕机的人来说是个挑战。你不能用灾难事件的概率和频率来麻痹自己。准备好应对那5%，你也能轻松应对剩下的95%。