说到服务连续性和灾备计划，基本上当前大多数企业都或多或少的有所涉及。就像我们小时候常听到的《狼来了》的故事一样。如果狼总是不来，喊多了也就没有意思了。但是上升到理论层面，套用时间管理的术语来说，连续性和容备其实属于“重要但不紧急”的事情。我们不得不花时间和精力去“以大博小”，来体现我们那“高瞻远瞩”的忧患意识。

对于一般企业IT服务的连续性设计，我们可以从如下三个方面进行考虑：

· 识别服务与资产，对其进行分级和估值，并完成业务影响分析（BIA）。

· 通过关键服务的各种测试，包括：功能测试、性能测试、压力测试、渗透测试以及恢复测试，制定出效率和精度平衡的策略来备份应用程序、配置和业务数据等。

· 从业务和用户角度出发，制定相应的应急预案和灾难恢复措施，加强日常演练，从而将业务中断的风险降到企业及用户的可接受范围内（可参照上次我们聊到的服务级别约定）。

· 选用软/硬件的瞬间切换和容错/互备技术来保证系统高可用性。

而在编制系统灾难恢复的流程时，可以参考如下通用步骤，具体系统与特殊服务可在此基础上增删。

· 恢复硬件或相关设施。

· 利用技术手段恢复操作系统。

· 根据配置管理数据库里的相关文档描述，重新配置该系统，包括驱动程序设置、用户参数、文件修改与增删等。

· 应用软件或程序的加载与定制。

· 应用数据的导入与测试。

· 对整个系统进行重新全量备份。

那么除了上述传统的连续性和灾备要点之外，对于正在使用云系统或服务的企业来说，和以前完全自行管控的不同之处在于，现在由于使用的是云平台，在网络资源、硬件配置和软服务上各种服务，基本上是以平台提供商为单位整体展现出的一体化的打包模式。所以原始的细粒度的BIA已经不一定适用了。反而，及时、准确的向云服务提供商更新自己系统的各项配置，保持顺畅沟通，并时常与之联动，进行事件（事故）的响应与恢复演练，就显得更为重要的。我的经验是：乘着现在还是“买方市场”的格局，这些条款或事项完全可以追加到与他们的SLA中。

另外，因为在云端，对于IT部门来说，某种程度上已经是“摸不着”了，那么就要做得任何时候都能“看得见”，就需要加强监控。监控的内容可以包括：对服务页面（网站）的监控、服务器（虚拟主机）的监控、各项服务性能的监控、甚至是各种API调用的监控等。通过主动发现、准确定位、快速响应的方式来减少云端业务中断所给企业带来的运营风险。

同时，我也注意到自己身边有一些企业会另辟蹊径，他们把云服务作为自己当前系统的一种备份方式。通过运用云计算技术中的虚拟化，实现重要数据资源以多样、安全和快捷的方式进行备份和迁移，从而利用云计算带来的“红利”，实现了自身业务的弹性变更，也达到了系统灾备和恢复能力的提升。

深入来看，云备份镜像可以实现对主站点的完全备份。当服务流量负载从主站点切换到云端的热镜像后，利用云端资源的弹性优势，服务性能基本上不受影响。大幅缩短恢复点目标和恢复时间目标。当然镜像同样需要IT人员进行日常维护，灾难恢复的各种演练可以在镜像上反复模拟。根据云服务的本质特点，镜像的运营成本相对另建备用站点的软硬件成本要低廉许多。另外，双方也可事先确认SLA，说明系统将以何种速度启动，需要哪些资源，才能将业务恢复到正常工作的水准。