IT服务连续性简介
实施IT服务连续性管理的目标是确保发生灾难时，IT服务的可用性(可用性介绍，参见“DevOps运维系列：可用性管理”)和性能保持在足够的水平。其实连续性管理就是目前的灾备管理(IT方）。
定义：灾难 （ITIL 4）
对组织造成重大损失或重大损失的突发性意外事件。要将事件归类为灾难，该事件必须符合组织预定义的某些业务影响标准。
现在很多企业都在做连续性管理，尤其是金融行业，包括银行、证券、保险、消金等等。企业首先要应对监管的要求。无论国际还是国内的标准组织和监控机构，针对连续性，都出台了一系列的管理规范，见下（只是一部分）：
| 国际标准 | ISO 22301:2012业务连续性管理 |
| 国家标准 | GB/T30146-2013 公共安全业务连续性管理体系要求 |
| 国家标准 | GB/T20988-2007 信息安全技术信息系统灾难恢复规范 |
| 行业标准 | 保险业信息系统灾难恢复管理指引（保监发[2008]20号） |
| 行业标准 | 银行业重要信息系统突发事件应急管理规范 |
| 行业标准 | JR/T 0044—2008 银行业信息系统灾难恢复管理规范 |
其次，确保服务连续性变得越来越重要和困难。尤其在数字化转型的背景下，很多企业的业务都严重依赖于IT系统，使得IT服务连续性的作用也越来越大。严重的服务中断可能会给企业带来灾难性的影响。
在ITIL 2中，服务连续性管理流程是服务交付其中的一个流程。在ITIL 3中，连续性管理是做为服务设计中的一个流程，流程活动与ITIL2相比，没有大变化，不过针对风险管理的方法进行了详细的解释。那么在ITIL 4中，IT服务连续性管理有哪些新亮点呢？
IT服务连续性的术语
定义：服务连续性
在发生灾难事件或中断性事件后，服务提供商在可接受的预定义级别上继续服务运行的能力。
在这个定义中，我们需要界定连续性管理的范畴是灾难，连续性管理是针对灾难性事件而制定的计划和响应措施。非灾难性事件的管理，一般不包括在IT服务连续性管理实践中，如
●小故障。根据业务影响，应将故障视为轻微或重大故障。重要的是要考虑诸如受影响的维修行动、故障规模、故障时间等因素。
●战略、政治、市场或行业事件
定义：服务连续性计划
服务连续性计划指导服务提供商在服务中断后响应、恢复和恢复到正常水平.
服务连续性计划通常包括：
●响应计划：服务提供商最初如何应对破坏性事件，以防止损坏，例如在火灾或网络***情况下。
●恢复计划：服务提供者如何恢复服务以实现RTO和RPO。
●恢复正常的操作计划：服务提供商在恢复后如何恢复正常操作。
指标：RTO和RPO
定义：RTO 恢复时间目标
在服务中断后，业务功能的缺乏严重影响组织之前，可以经过的最长时间。这表示必须恢复产品或活动或必须恢复资源的最长商定时间。
定义：RPO 恢复点目标
为了使活动在恢复时能够有效地运行，必须将活动使用的信息恢复到该点。
RTO 规定了业务可以中断的时间。RPO规定了可接受数据丢失的时间段。通常，RTO和RPO都是作为连续性管理的衡量指标，写入SLA中。
服务连续性管理的流程
服务连续性管理活动分为以下五个过程：
●服务连续性管理的治理
●业务影响分析
●制定和维护服务连续性计划
●测试服务连续性计划
●响应和恢复。
1. 服务连续性管理的治理
服务连续性治理主要包括三个活动，定义范围、策略选择和意识与演练计划的开发。一般做连续性的企业，主营业务都非庞大，IT系统更是错综复杂，交互繁多。出于经济效益的考虑，企业不可能保证所有的应用和基础设施组件都有备份，所以首先根据BIA（业务需求分析），确定关键业务和组件。然后根据不同的级别，选择不同的灾备方式和演练计划。
2. 业务影响分析 BIA
业务影响分析包括以下活动：
●VBF识别
●中断后果分析
●VBF相互依赖性识别
●确定服务连续性要求
ITIL 4中对于这些活动并未给出具体的实施方法。后面我会专门写一篇，如何开展BIA。BIA的难点在于技术实施层面，必须有系统架构师参与，进行风险评估也需要技术人员。
3. 制定和维护服务连续性计划
这个过程包括的步骤是：
●服务连续性策略制定
●服务连续性计划制定
●服务连续性计划初步测试
服务连续性策略可以包括连续性的等级，对应的RTO和RPO的目标，可用性目标，演练的等级。如：
金融领域的云计算平台容灾能力等级要求
影响范围 |
危害程度 |
||
较小影响 |
一般影响 |
严重影响 |
|
内部辅助管理 |
1级 |
2级 |
3级 |
内部运营管理 |
2级 |
3级 |
4级 |
公民、法人和其他组织的金融权益 |
3级 |
4级 |
5级 |
国家金融稳定、金融秩序 |
4级 |
5级 |
6级 |
关键指标：
容灾等级 |
RTO |
RPO |
可用性 |
３级 |
＜＝24小时 |
＜＝24小时 |
|
４级 |
＜＝4小时 |
＜＝1小时 |
|
５级 |
＜＝30分钟 |
约等于0 |
|
６级 |
＜＝2分钟 |
0 |
演练等级在《保险业信息系统灾难恢复管理指引（保监发[2008]20号）》规定为：桌面演练、模拟演练、实战演练、部分演练和全面演练。
4. 测试连续性计划
这个过程包括执行演练和连续性评审两个活动。
5. 响应和恢复
响应包括对应供应商服务连续性计划的调用。
IT服务连续性和可用性的关联和区别
先说区别。
从目标来看，服务连续性管理不包括对没有严重影响的小故障或短期故障的处理。它侧重于与重大损害相关的风险，而不管其发生的可能性或可能性有多大。通常，这些都是紧急情况：火灾、洪水、停电、数据中心故障等等。可用性管理实践并没有忽略故障对服务提供者和使用者的负面影响，但是在这个过程中也会考虑到单个组件的轻微中断。
从衡量指标看，服务连续性是RTO和RPO，可用性的指标是MTTR，MIBF，Availability%。
再说联系。
服务连续性和可用性在实施方法上，都会用到VBFs和风险评估，需要对服务失败进行BIA分析。所以实施过程中形成的文档和输出内容，都可用于这两个实践。由此可以看出，系统拓扑图，VBF，风险评估，对于IT服务运维管理，是多么的重要，这些都是基础信息，除了用于这两个实践，还可以用于配置管理。可惜的是，很多企业在这个基础层面都是缺失的。很多人提了一堆高大上的方法论和技术，但是基础却做不到位，导致运维管理就是一团散沙，无据可依。
总结
我们如果去做灾备，只看ITIL讲解的IT服务连续性管理其实是远远不够的，还需要结合行业标准和管理规范，来解读监管要求。主要原因是ITIL中所讲解的IT服务连续性管理实践主要是从IT层面来讲解的，但是从企业运维的角度，应该实行的是“业务连续性管理”。可惜的是，ITIL４对于这个层面有一些解释，但是解释的不够全面。关于业务连续性管理的监管解读，后面我会再写一篇。
连续性管理无论是从方法论还是技术实施方案，都是非常复杂的，尤其是很多企业目前在应用云架构和微服务的新技术。如何做灾备，其技术方案是目前讨论的热点。当前市场上出现了不少专门做服务连续性管理的公司，企业也可以选择将连续性管理外包，不过效果如何，还不得而知。