实施IT服务连续性管理的目标是确保发生灾难时，IT服务的可用性(可用性介绍，参见“DevOps运维系列：可用性管理”)和性能保持在足够的水平。其实连续性管理就是目前的灾备管理(IT方）。安全
定义：灾难 （ITIL 4）网络
对组织形成重大损失或重大损失的突发性意外事件。要将事件归类为灾难，该事件必须符合组织预约义的某些业务影响标准。架构
如今不少企业都在作连续性管理，尤为是金融行业，包括银行、证券、保险、消金等等。企业首先要应对监管的要求。不管国际仍是国内的标准组织和监控机构，针对连续性，都出台了一系列的管理规范，见下（只是一部分）：运维
| 国际标准 | ISO 22301:2012业务连续性管理 |
| 国家标准 | GB/T30146-2013 公共安全业务连续性管理体系要求 |
| 国家标准 | GB/T20988-2007 信息安全技术信息系统灾难恢复规范 |
| 行业标准 | 保险业信息系统灾难恢复管理指引（保监发[2008]20号） |
| 行业标准 | 银行业重要信息系统突发事件应急管理规范 |
| 行业标准 | JR/T 0044—2008 银行业信息系统灾难恢复管理规范 |
其次，确保服务连续性变得愈来愈重要和困难。尤为在数字化转型的背景下，不少企业的业务都严重依赖于IT系统，使得IT服务连续性的做用也愈来愈大。严重的服务中断可能会给企业带来灾难性的影响。ide
在ITIL 2中，服务连续性管理流程是服务交付其中的一个流程。在ITIL 3中，连续性管理是作为服务设计中的一个流程，流程活动与ITIL2相比，没有大变化，不过针对风险管理的方法进行了详细的解释。那么在ITIL 4中，IT服务连续性管理有哪些新亮点呢？微服务
定义：服务连续性性能
在发生灾难事件或中断性事件后，服务提供商在可接受的预约义级别上继续服务运行的能力。测试
在这个定义中，咱们须要界定连续性管理的范畴是灾难，连续性管理是针对灾难性事件而制定的计划和响应措施。非灾难性事件的管理，通常不包括在IT服务连续性管理实践中，如云计算
●小故障。根据业务影响，应将故障视为轻微或重大故障。重要的是要考虑诸如受影响的维修行动、故障规模、故障时间等因素。spa
●战略、政治、市场或行业事件
定义：服务连续性计划
服务连续性计划指导服务提供商在服务中断后响应、恢复和恢复到正常水平.
服务连续性计划一般包括：
●响应计划：服务提供商最初如何应对破坏性事件，以防止损坏，例如在火灾或网络***状况下。
●恢复计划：服务提供者如何恢复服务以实现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. 响应和恢复
响应包括对应供应商服务连续性计划的调用。
先说区别。
从目标来看，服务连续性管理不包括对没有严重影响的小故障或短时间故障的处理。它侧重于与重大损害相关的风险，而无论其发生的可能性或可能性有多大。一般，这些都是紧急状况：火灾、洪水、停电、数据中心故障等等。可用性管理实践并无忽略故障对服务提供者和使用者的负面影响，可是在这个过程当中也会考虑到单个组件的轻微中断。
从衡量指标看，服务连续性是RTO和RPO，可用性的指标是MTTR，MIBF，Availability%。
再说联系。
服务连续性和可用性在实施方法上，都会用到VBFs和风险评估，须要对服务失败进行BIA分析。因此实施过程当中造成的文档和输出内容，均可用于这两个实践。由此能够看出，系统拓扑图，VBF，风险评估，对于IT服务运维管理，是多么的重要，这些都是基础信息，除了用于这两个实践，还能够用于配置管理。惋惜的是，不少企业在这个基础层面都是缺失的。不少人提了一堆高大上的方法论和技术，可是基础却作不到位，致使运维管理就是一团散沙，无据可依。
咱们若是去作灾备，只看ITIL讲解的IT服务连续性管理实际上是远远不够的，还须要结合行业标准和管理规范，来解读监管要求。主要缘由是ITIL中所讲解的IT服务连续性管理实践主要是从IT层面来说解的，可是从企业运维的角度，应该实行的是“业务连续性管理”。惋惜的是，ITIL４对于这个层面有一些解释，可是解释的不够全面。关于业务连续性管理的监管解读，后面我会再写一篇。
连续性管理不管是从方法论仍是技术实施方案，都是很是复杂的，尤为是不少企业目前在应用云架构和微服务的新技术。如何作灾备，其技术方案是目前讨论的热点。当前市场上出现了很多专门作服务连续性管理的公司，企业也能够选择将连续性管理外包，不过效果如何，还不得而知。