一、目的和描述
- 关键信息
服务连续性管理实践的目的是确保灾难发生时，服务的可用性和性能能够保持在足够的水平。本实践提供了一个框架机制，利用产生有效响应的能力来构建组织的弹性，以保障关键利益相关者的利益，还有组织的声誉、品牌和创造价值的活动。
- 定义：灾难
一个突发的意外事态，会对组织造成巨大损坏或严重损失。要被归类为灾难，这一事态必须与组织预定义的特定业务影响准则相匹配。服务连续性管理实践有助于确保服务提供者做好应对高影响事件的准备，这些事件会破坏组织的核心活动和/或信誉。在数字化转型的背景下，服务连续性管理实践变得越来越重要，因为在各个行业，数字化服务的作用越来越大。对于在过去专注于非技术灾难的组织而言，重大服务中断可能产生灾难性的影响。
云解决方案的广泛使用，以及与合作伙伴和服务消费者的数字化服务的广泛整合，正在产生更加难以控制的新的关键依赖关系。合作伙伴和服务消费者通常会投资于高可用性和高连续性解决方案上，但是组织之间缺乏整合和一致性会产生新的脆弱性，这一点需要被了解并解决。
服务连续性管理实践与其他实践（包括可用性管理、容量和性能管理、信息安全管理、风险管理、服务设计、关系管理、架构管理和供应商管理实践）相结合，可以确保组织的服务具有弹性并为灾难性事件做好准备。
风险的概念是服务连续性管理实践的核心。该实践通常可以减轻无法被完全避免的高影响、低概率风险（因为某些风险因素不在组织的控制之下，例如自然灾害）。
简单来说，此实践与事件管理实践非常相似，不同之处在于其潜在的损害要大得多，并且它可能威胁到服务提供者创造价值的能力。
服务连续性管理实践与服务价值系统（SVS）中的可用性管理实践密切相关，并且在某些情况下可以合二为一。它也与公司背景下的业务连续性管理实践紧密相关，并可以纳入其中。
服务经济时代，每个组织的业务都是由服务驱动和数字化的。由于这样的紧密联系，业务连续性管理实践可能会与数字化服务连续性与服务管理进行全面整合。如果数字化转型导致消除了“ IT 管理”和“业务管理”之间的界限，则这种整合可能是可行且有用的（有关该主题的更多信息，请参见ITIL4：高速IT）。
二、 术语和概念
- 定义：服务连续性
在灾难事态或破坏性事件发生后，服务提供者以可接受的预定义级别继续服务运营的能力。
对于内部服务提供商，服务连续性管理实践的主要目的是通过管理可能影响IT服务的风险来确保服务提供者能够始终提供相关的议定服务级别，从而支持整个业务连续性管理实践。
对于外部服务提供商，服务连续性管理等同于业务连续性管理。
业务连续性专业人员也有兴趣处理业务危机，如负面媒体关注或破坏性市场事件。但是，在本实践指南中，服务连续性管理实践的范围仅限于运营风险。
1 灾难（或破坏性事件或危机）
ISO将灾难定义为“一种具有高度不确定性的情况，这种情况会破坏核心业务和/或组织的信誉，并需要紧急行动”
明确定义被认为是灾难的事态列表通常是一个好主意。这样做有助于制定一套适当的服务连续性计划，从而确保组织做好应对破坏性事件的准备。灾难清单通常包括：
- 网络攻击
- 停电
- 战略合作伙伴的失败
- 火灾
- 洪水
- 关键人员不可用
- 大规模IT基础设施故障（例如数据中心故障）
- 自然灾害
- 界定那些不是灾难的事态同样重要。通常，服务连续性管理实践不涵盖：
- 轻度故障 故障被视为轻度或重度取决于其对业务的影响程度。重要的是要考虑诸如受影响的服务行动，故障的规模，故障的时间等因素。
- 战略，政治，市场或行业事件
为了从灾难中成功恢复，服务提供者应该定义服务的连续性要求。服务的连续性要求包括：
- 恢复时间目标(RTO)
- 恢复点目标(RPO)
最低服务连续性级别（请参阅图2.1）
图2.1 服务的连续性要求：RTO，RPO，最低目标服务级别
2 恢复时间目标
| 定义：恢复时间目标 由于业务功能缺失导致对组织产生严重影响之前，服务中断持续的最长时间。这就意味着在这个最大约定时间内必须重新开始生产或业务活动，或者必须恢复资源。 |
估算RTO时应考虑的主要因素是：
- 服务提供者提供服务的能力下降以及与此下降相关的成本
- 服务级别协议罚款和监管判决
- 与竞争优势和声誉减弱相关的损失
业务连续性专业人员还使用术语“最大容忍中断时间/最大可接受中断（MAO）”，并将其与RTO区分开。
ISO 22301：2012提供以下定义：
- MAO因没有提供生产/服务或执行活动而产生的，为不良影响所花费的变得不可接受的时长
- RTO 事件之后的时间段，在此期间生产或业务活动必须重新开始，或者资源必须恢复
按照此逻辑，RTO应当比MAO在数量上少一些，这足以说明组织的风险偏好.MAO应该在业务影响分析中确定。RTO应该在服务连续性计划的开发中定义。
3 恢复点目标
| 定义：恢复点目标 活动所使用的必须恢复的信息所指向的点，以使活动在重新开始后能够有效运行。 |
RPO定义了可容许的数据损失的时间段。如果RPO为30分钟，则在破坏性事态之前30分钟应至少有一个备份，在服务恢复后的服务交付重新开始时，距离破坏性事态之前30分钟或更短时间内的数据是可用的。
估算RPO时应考虑的主要因素是：
- 使用数据的服务的重要性
- 数据的重要性
- 数据的生产率。
例如，一家网上商店每小时接收100个订单。高管们说，丢失200个订单将是不可接受的。因此，RPO为2小时。
RPO定义了备份频率的要求。在灾难发生时，备份管理必须确保最近的备份副本的可用性。
4 最低目标服务级别
| 定义：最低目标服务级别服务提供者可接受的服务级别，可以在中断期间实现其目标。 |
灾难恢复期间，服务提供者通常应以最低目标服务级别提供服务。即使客户没有特殊要求，但达到最低服务级别也有助于尽量减小损失。
最低目标服务级别通常根据以下方面进行定义：
- 中断期间用户可以使用的特定服务操作和功能点的列表
- 中断期间应能够访问服务的有限的用户数量或特定用户组
- 中断期间用户应能够处理的单位时间段内有限的交易数量。
5 业务影响分析
| 定义：业务影响分析 服务连续性管理实践中的关键活动，用于标识重要的业务功能（VBF）及其依赖关系。这些依赖关系可能包括供应商，人员，其他业务流程和IT服务。业务影响分析定义了IT服务的恢复要求。这些要求包括RTO，RPO和每个IT服务的最低目标服务级别。 |
业务影响分析（BIA）是一个流程，用于分析活动以及中断可能对其产生的影响
根据ISO 22301，业务影响分析应包括：
- 识别支持产品和服务提供的活动
- 评估不执行这些活动，随着时间流逝而造成的影响
- 设置优先级时间范围以在明确规定的最低可接受水平上恢复这些活动，考虑到在这时间内不恢复它们，带来的影响将变得不可接受
- 确定这些活动的依赖关系和支持资源，包括供应商，外包合作伙伴，以及其他相关利益方。
6 服务连续性/ 灾难恢复计划
| 定义：服务连续性 一套明确定义的考虑到服务管理四维模型的计划，有关组织如何从灾难恢复并返回到灾难之前的状态。 |
服务连续性计划用于指导服务提供者在中断后响应，恢复服务并将其还原到正常水平。
服务连续性计划通常包括：
- 响应计划 明确了服务提供者最初如何对破坏性的事态做出反应，以防止损坏，例如火灾或网络攻击。
- 恢复计划 明确了服务提供者如何恢复服务以实现RTO和RPO。
- 计划恢复正常操作明确了服务提供者在恢复之后如何重新开始正常。例如，如果已使用备用数据中心，则此阶段将使主数据中心重新投入运行，并修复再次调用IT服务连续性计划的能力。
在许多情况下也会有制定业务连续性计划的需求。业务连续性计划可能包括：
- 紧急响应 对接所有紧急服务和活动
- 疏散计划以确保人员安全
- 危机管理和公众关系计划为不同危机的指挥和控制，以及媒体和公众关系的管理做出计划
- 安全计划展示了所有主站点和恢复站点上的安全的各个方面是如何被管理的
- 沟通计划展示了在重大事件期间，与所有相关领域和当事人沟通的各个方面是如何处理和管理的。
这些计划通常在制定时被当做业务连续性管理实践的一部分。
三、 范围
服务连续性管理实践包括以下领域：
- 执行BIA来量化服务不可用带给服务提供者和服务消费者的影响
- 开发服务连续性策略（并将它们整合到相关的业务连续性管理策略中）。这应该包括的要素有风险缓解措施，以及适当的、全面的恢复选项的选择
- 制定和管理服务连续性计划（并为相关的业务连续性计划提供清晰的接口）
- 进行练习，并测试如果发生灾难情况下，服务连续性计划的启用
- 有一些活动和责任领域尽管仍与服务连续性管理密切相关，但不包含在服务连续性管理实践中。表2.1中列出了这些内容，以及涉及到的包含这些内容的实践。重要的是要记住，ITIL实践只是在价值流的背景中使用的工具的集合；它们应当根据情况在必要时组合在一起。
| 活动 | 实践指南 |
| 与客户沟通以使客户的业务连续性策略和计划与服务提供者的服务连续性策略和计划保持一致 | 关系管理 |
| 协商并与客户服务连续性要求达成一致 | 服务级别管理 |
| 将服务连续性解决方案设计为服务模型的一部分 | 服务设计 |
| 使服务连续性解决方案与业务架构保持一致 | 架构管理 |
| 识别与服务连续性相关的风险 | 风险管理 |
| 与供应商和合作伙伴建立和管理合同 | 供应商管理 |
| 监控服务的可用性 | 监控和事态管理 |
| 证明新的服务连续性解决方案 | 组合管理 |
| 实施风险缓解措施并更改IT基础设施，以确保弹性 | 项目管理, 变更控制 |
| 管理并实施持续改进 | 持续改进 |
1 可用性与连续性之间的界线
服务的连续性和可用性管理的实践之间的界限是不明显的。两种做法都涉及风险的概念，并致力于识别和准备应对可能威胁并导致服务不能运转的事件。对于这两种实践，都需要了解VBF和风险评估或服务故障的BIA。最终，两种做法都确保了组织的抗故障能力。
一些组织不希望将可用性的管理和连续性分开。但是，表2.2中概述了这两种做法之间的一些差异，在设计服务管理系统时应考虑这些差异。
| 可用性管理 | 服务连续性管理 |
| 专注于高概率的风险 | 专注于高影响风险（紧急情况，灾难） |
| 更主动 | 更被动 |
| 减少意外的可能性 | 减少意外的影响 |
| 关注技术解决方案 | 关注组织措施 |
| 优化 | 创建冗余 |
| 不属于公司职能 | 通常是公司职能的一部分 |
| 日常业务 | 特殊情况下 |
| MTRS, MTBF, MTBSI | RTO, RPO |
表2.2 可用性管理和服务连续性管理之间的区别
服务连续性管理实践不包含那些不会严重影响组织的轻度或短期故障。它关注与重大损害相关的风险，无论它们发生的可能性或不可能性有多大。通常，这些是紧急情况：火灾，洪水，断电，数据中心故障等。虽然可用性管理实践并未忽略故障对服务提供者和消费者造成的负面影响，但是单个组件的轻度中断也在流程中有所考虑。
这些实践的目标之间存在对立。可用性管理实践处理统计数据并分析趋势；连续性管理关心如何应对破坏性事件。
可用性规划致力于满足当前和将来的商定要求，并避免出现偏差。可用性管理实践发现并消除单点失效；所采取的对策通常是积极主动的，以减少意外事态发生的可能性。服务连续性管理实践专注于规划，以管理破坏性事件的严重后果。备份站点，服务提供的替代方案的过渡，还有恢复程序，都可以减少损坏，但是通常不影响事件发生的可能性。
2 事件管理
事件管理实践的活动与服务连续性管理实践的非常相似。但是，事件管理实践专注于不会威胁组织的弹性的故障，而服务连续性管理实践专注于可能会阻碍组织恢复服务交付的高影响故障。
同样，这两个实践之间的界线是不明显的，应根据对务提供者和服务使用者的影响来明确定义。同时，在某些情况下（通常在小的，单站点服务提供者中），服务连续性活动可作为重大事件管理的一部分来执行。
当服务连续性计划到位并与事件管理活动分开管理时，应该有一个清晰的标准来触发服务连续性程序。在评估事件的业务影响时，支持专家应确定重大事件是否可能导致灾难，并通知危机管理组，以便他们能够做出有关启用的决定。
| 定义：启用 服务提供者必须承诺服务连续性计划，以便继续服务的交付。 |
3 服务连续性实践在管理风险时的角色
风险的概念是服务连续性管理实践的核心。该实践通常关注于减轻无法完全防止的高影响，低概率风险。
为了降低风险，此实践致力于使预期损失减小到最低程度，以便在灾难发生时不会造成重大损失。
为确保准备好应对破坏性事件，服务连续性管理实践需要有关风险的信息，这些信息可以通过风险管理实践获得。
有效的服务连续性管理实践可以为组织的风险管理做出显著贡献。大量风险缓解措施在某种程度上与服务连续性选项相关。
四、实践成功因素
| 定义：实践成功因素 实践的一个复杂的功能性的组件，是实践实现其目的所必需的。 |
实践的成功因素（PSF）不仅仅是一项任务或活动，因为它包括全部服务管理四维模型的组件。活动的性质和实践中PSF的资源可能有所不同，但它们共同确保实践有效。
服务连续性管理实践包括以下PSF：
- 制定和管理服务连续性计划
- 降低服务的连续性风险
- 确保认知和准备就绪
- 制定和管理服务连续性计划
为了有效地应对灾难并从中恢复，服务提供者需要服务连续性计划，该计划应反映所选的服务连续性策略。应该根据在BIA期间确定的服务连续性要求选择服务连续性策略。
因此，为了制定和管理服务连续性计划，服务提供者应该首先完成BIA，然后选择适当的一组服务连续性要求，进而定义服务连续性策略。
业务连续性研究所（BCI）定义了以下连续性策略:
- 多样化
- 复制
- 备用
- 事件之后的采集
- 什么都不作
- 分包
只要服务的连续性要求和服务提供者的背景有所变化，它们就不是一次性的活动。例如，当服务提供者开始将其服务交付给新的消费者时。该事态是重新执行BIA和更新服务连续性策略的触发器。如果长期没有明显变化，则通常每年进行一次或两次BIA，并与风险评估周期同步。有关BIA的更多详细信息，请参见3.2.2.
1 连续性计划
BCI在响应和恢复规划结构中引入了三个层次：战略层、战术层和操作层，如表2.3所示。
表2.3响应和恢复规划结构中的层次
| 层次 | 描述 |
| 战略层 | 高管如何做出有关恢复流程的决策，如何与外部各方（包括相关媒体）进行沟通以及处理服务连续性计划中未涉及的任何情况 |
| 战术层 | 管理层如何协调恢复流程，以确保根据优先级（当前业务优先级，季节性变化等）适当分配资源并管理规划团队和恢复团队之间的冲突 |
| 操作层 | 团队如何执行恢复活动，包括响应破坏性事件，恢复到服务的预定义级别，和/或提供替代设施以继续运行 |
根据组织的规模以及服务提供者是内部的还是外部的，可能会有不同的解决方案来构建计划。责任主体也可能有所不同。
服务连续性计划根据服务提供者的类型和组织的规模，其结构的复杂度可能会或多或少。表2.4 概述了一些常见的结构。
表2.4 连续性计划的结构选项
服务连续性计划应涵盖表2.5中概述的灾难发生之后的各个阶段。
表2.5 响应阶段和恢复阶段
计划应清晰，简洁且以行动为导向。通常，计划中应排除掉那些对于使用计划的恢复团队不直接应用的信息。程序应基于时间，并应包含可能的延迟以及计划与团队之间的交互信息。
有关响应和恢复的组织结构的详细信息，请参见4.2.
2 减轻服务连续性风险
服务连续性管理实践包括管理各种风险的控制项的定义和管理。为此，它与风险管理实践和其他以风险为中心的实践（例如容量和性能管理，可用性管理和信息安全管理实践）结合使用。商定的可用性控件应通过服务设计，软件开发和管理，以及基础设施和平台管理实践来实施。
表2.6 中概述的服务连续性选项可以作为总体风险缓解计划的一部分来设计和实现。
| 服务管理维度 | 服务连续性措施 |
| 组织和人员 |
|
| 信息和技术 |
|
| 合作伙伴和供应商 |
|
| 流程和价值流 |
|
表2.6 服务连续性管理实践的四个维度
如果服务的BIA表明了有更早和更高的影响发生，则需要采取更多的预防措施。如果初始影响较低且发展缓慢，则投资于连续性和恢复对策是更经济有效的方法。
选择服务连续性措施时，每个选项的效果和效率应得到评估。同样重要的是持续控制并验证其持续效果和效率。
- 效果根据风险管理原则，应评估服务连续性措施的效果，并将其与破坏性事态的预期损失进行比较。
- 效率服务连续性度量的成本应该进行评估，并与收益进行比较。通过估算实施该措施后破坏性事态发生概率的降低，并乘以发生事态会对服务提供者和客户造成的预期的影响，可以计算出收益。就成本而言，应将此价值与该措施实施的成本进行比较。这里可以使用成本效益分析。
3 确保认知和就绪状态
未经测试的恢复计划通常根本无法按预期工作。因此，测试是服务连续性管理的关键组成部分，并且是确保所选策略，已实施措施和计划切实可行的唯一方法。
测试服务连续性计划是检查和提高准备状态的一种手段。通过定期修改计划和程序，恢复团队发现缺陷和低效率，然后更新服务连续性计划以反映他们的发现。
BCI定义以下演练类型:
- 走查
- 桌上演练
- 指挥所演练
- 现场
- 测试。
根据BCI良好实践指南，每种类型的关键特征和目的。
表2.7 概述了2013年。
表2.7 锻炼类型
演练应该按计划的时间间隔，以及发生可能影响恢复的显著变更时实施。服务中断的可能造成的影响程度越高，演练的频率就应该越高。
演练不仅是确保准备就绪的一种方法，而且是一个改进机会。因此，通常的好主意是，分析测试期间的发现以及整个恢复团队表现，然后生成包括发现和正式建议的演练报告。
五、 关键指标
每个实践所做的贡献应该在价值流的背景下评估ITIL实践的效果和绩效。与任何工具的性能/绩效一样，只能在应用程序的背景下评估实践的绩效。然而，工具在设计和质量方面会有很大差异，这些差异被定义为一种工具在根据其用途使用时的有效潜力或能力。更多的有关指标，关键绩效指标（KPIs），和有助于此目的的其他工具的进一步指导，能够在度量和报告实践指南中找到。
服务连续性管理实践的关键指标已映射到其PSF。它们可以用作价值流的背景中的KPI，以评估实践对这些价值流的效果和效率的贡献。表2.8给出了一些关键指标的示例。
| 实践成功因素 | 指标示例 |
| 制定和管理服务连续性计划 |
|
| 降低服务的连续性风险 |
|
| 确保认知和就绪状态 |
|
表2.8 实践成功因素的指标示例
将指标正确汇总到复杂指标中，将使数据更易于用于价值流的日常管理，以及用于服务连续性管理实践的定期评估和持续改进。没有单一的最佳解决方案。指标将基于总体的服务战略和组织的优先级，以及实践有助于的价值流目标。
六、 价值流和流程
1 价值流贡献
像任何其他ITIL 管理实践一样，服务连续性管理也有助于多个价值流。重要的是要记住，价值流永远不会由单个实践形成。服务连续性管理实践与其他实践相结合，可以为消费者提供高质量服务。实践贡献的主要价值链活动是：
- 交付和支持
- 设计和转换
- 改进
- 获取或构建
- 计划
服务连续性管理实践对服务价值链的贡献如图3.1 所示。
图3.1 服务连续性管理实践对价值链活动贡献的热力图
2 流程
每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必需的。
| 定义：流程 一组相互关联或交互的活动，可将输入转换为输出。流程接受一个或多个定义的输入，并将其转换为定义的输出。流程定义活动的顺序及它们的依赖关系。 |
服务连续性管理活动形成五个流程：
- 服务连续性管理的治理
- 业务影响分析
- 制定和维护服务连续性计划
- 测试服务连续性计划
- 响应和恢复
2.1 服务连续性管理的治理
该流程包括表3.1中列出的活动，并将输入转换为输出。
| 关键输入 | 活动 | 关键输出 |
|
|
|
表3.1 服务连续性管理的治理的输入，活动和输出
图3.2显示了流程的工作流程图。
图3.2 服务连续性管理的治理的工作流程
这些活动可能由组织中的许多人以不同程度的正式方式来执行。表3.2进一步描述了这些活动。
| 活动 | 描述 |
| 范围的定义 | 定义服务连续性管理实践的范围，确保它所涵盖的组织的环境和地域清晰。 组织范围可能受到产品和服务，站点和位置，客户等的限制。那些已停产的或即将终止的产品和服务通常被排除在范围之外，非关键和低利润的产品和服务也一样。 实施服务连续性管理实践的成本可能很高。因此，如果服务提供者启动服务连续性管理方案，则某些服务，产品或站点最初可能会作为分阶段实施的一部分而被排除在外。 许多不同的技术被用来定义实践的范围，包括成本效益分析，SWOT分析，PESTLE分析等。 定义范围时，组织应考虑：
根据灾难定义实践的范围也很重要。 |
| 策略设置 | 策略的设置包括：
|
| 认知和演练方案制定 | 测试是整个服务连续性管理实践的关键部分：这是确保所选策略，措施和计划有效的唯一方法。 应该制定教育，认知培训和演练计划，以确保实践的所有部分（站点，团队成员，服务或CI）每年至少进行一次测试。 演练方案应确保测试整个的服务管理四维模型：
|
表3.2 服务连续性管理的活动
2.2 业务影响分析
该流程包括表3.3中列出的活动，并将输入转换为输出。
| 关键输入 | 活动 | 关键输出 |
|
|
|
表3.3 业务影响分析流程的输入、活动和输出
图3.3 业务影响分析流程的工作流程
图3.3 显示了流程的工作流程图
这些活动可以由组织中的许多人以不同程度的正式方式来执行。表3.4进一步概述了这些活动。
| 活动 | 描述 |
| VBF识别 | VBF涉及到服务中对于服务提供者和/或客户的成功至关重要的一部分。识别和文件化这些VBF，以提供适当的焦点和资源分配非常重要。 可以使用许多不同的技术来识别风险，包括头脑风暴，与利益相关者（包括客户和用户）的访谈，对服务文档的分析等等。 如果服务提供者具有已建立的风险管理实践，则有关风险评估的信息可能有助于理解最关键的区域。 |
| 中断后果分析 | 当确定了VBF时，应确定中断的影响。该影响可能是可以准确识别的“硬” 影响，例如财务损失，也可以是“软” 影响，例如声誉受损或失去竞争优势。 可以考虑FAIR提出的以下形式的损失：
影响可能会随时间推移产生变化。服务提供者和客户也许可以在短时间内不使用特定的服务或VBF而正常工作，但是随着时间的流逝，影响可能会增加，直到服务提供者或客户不能再操作。 BIA演练的主要输出之一是一项IT服务或特定VBF随时间推移的预期损失图。使用此图以驱动服务连续性策略和计划。 服务中断造成的损失通常会随着时间呈指数增长。除了与组织产生其主要价值主张的能力下降的有关损失之外，还存在罚款，判决和声誉受损的威胁。 |
| VBF 相互依赖关系识别 | VBF和服务组件以及关键的内部和外部资源之间的相互依赖关系应予以识别和文件化。 为此，如果已安装配置管理数据库，则服务提供者可以使用服务和配置模型。组件故障影响分析（CFIA）也可能是有用的技术。CFIA可用于识别失效的单个点，现有的冗余等。 |
| 服务连续性要求的确定 | 基于对中断后果和识别的相互依赖关系的分析，服务提供者应为服务连续性管理范围中的每个服务或VBF确定服务连续性要求，包括：
|
表3.4 业务影响分析流程的活动
2.3 制定和维护服务连续性计划
该流程包括表3.5 中列出的活动，并将输入转换为输出。
| 关键输入 | 活动 | 关键输出 |
|
|
|
表3.5 制定和维护服务连续性计划流程的输入，活动和输出
图3.4 显示了该流程的工作流程图。
图3.4 制定和维护服务连续性计划流程的工作流程
这些活动可以由组织中的许多人以不同程度的正式方式来执行。
表3.6 进一步概述了这些活动。
| 活动 | 描述 |
| 服务连续性策略制定 | 基于BIA 报告，服务提供者应该确定一套适当的且具有成本效益的服务连续性策略集。 对于影响更早，影响更大的流程和服务，应采取更多的预防措施。对于影响较低且需要较长时间开发的流程和服务，应更加重视恢复措施。 |
| 服务连续性计划制定 | 基于服务连续性政策和策略，服务提供者应该制定和维护服务连续性计划。 如果服务或恢复团队成员发生变化，则必须更新计划。计划也可以在演练或实际恢复之后更新。 |
| 服务连续性计划的初始测试 | 发布之前，应测试服务连续性计划。初始测试的方法类似于正在进行的演练。 |
表3.6 制定和维护服务连续性计划流程的活动
2.4 测试服务连续性计划
该流程包括表3.7 中列出的活动，并将输入转换为输出。
| 关键输入 | 活动 | 关键输出 |
|
|
|
表3.7 测试服务连续性计划流程的输入、活动和输出
图3.5 显示了该流程的工作流程图。
图3.5 测试服务连续性计划流程的工作流程
这些活动可能由组织中的许多人以不同程度的正式方式来执行。表3.8进一步概述了这些活动。
| 活动 | 描述 |
| 进行演练 | 演练应按计划的时间间隔，和当出现可能影响恢复的显著变化时进行。服务中断的可能影响越高，演练的频率就应该越高。 演练和测试不仅是确保准备就绪的方法；它们也是改进机会。这通常是一个好主意，用来分析测试结果以及整个恢复团队绩效，然后生成包括结果和建议的演练报告。 练习报告可能包括对新的或更新的现存的要求，或对服务连续性计划变更的请求。 如果演练失败，则会更新后续演练时间表以便尽快重新执行失败的演练。 |
| 服务连续性审计 | 服务连续性审计可确保在环境更改时，BIA，服务连续性策略和计划保持适当和相关。审计通常是按计划进行的，但是可能由于演练失败或恢复失败而触发。 审核可以在内部进行，也可以由第三方进行。审计的输出可能会确定一个实施新的或更新的控件的需求，也可以是调整服务连续性策略或计划的需求。 |
表3.8测试服务连续性计划流程的活动
2.5 响应和恢复
该流程包括表3.9 中所述的活动，并将输入转换为输出。
| 关键输入 | 活动 | 关键输出 |
|
|
|
表3.9 响应和恢复流程的输入、活动和输出
图3.6 显示了该流程的工作流程图。
图3.6 响应的工作流程和恢复流程
这些活动可以由组织中的许多人以不同程度的正式方式来执行。
表3.10 进一步概述了这些活动。
| 实现价值 | 描述 | ||||
| 启动 | 启动是一项声明行为，组织的连续性安排需要实施，以便继续提供关键产品和服务12. 启动的决定通常是由“ 危机管理”团队（在组织结构的战略层面上）做出的。13），用于核算：
| ||||
| |||||
表3.10 活动的响应和恢复流程
七、 组织和人员
1 角色，能力和责任
ITIL 实践指南没有描述实践管理的角色，例如实践所有者，实践负责人或实践教练。相反，他们专注于每个实践特有的专门角色。每个角色的结构和命名都可能因组织而异，因此ITIL中定义的任何角色都不应被视为强制性的，只是推荐性的。
请记住，角色不是职位。一个人可以担任多个角色，一个角色可以分配给多个人。
角色是在流程和活动的背景中描述的。每个角色都具有基于表4.1中所示模型的一个能力简介的特征。
表4.1 能力代码和简介
| 能力代码 | 能力类型（活动和技能） |
| L | 领导者 决策，委派，监督其他活动，提供激励和动机以及评估结果 |
| A | 管理员 分配任务并确定优先级，保留记录，进行中的报告并启动基本改进 |
| C | 协调员/沟通者 协调多方，维护利益相关者之间的沟通，并开展宣传活动 |
| M | 方法和技术专家 设计和实施工作技术，记录程序，咨询流程，工作分析和持续改进 |
| T | 技术专家 提供技术（IT）专业知识并实施基于专业知识的任务 |
表4.2 中列出了服务连续性管理实践涉及的角色示例，以及相关的能力简介和特定技能。
表4.2 负责服务连续性管理活动的角色示例
2 组织结构和团队
灾难是影响重大的事件，因此响应必须非常快。协调响应和恢复活动需要灵活性。因此，常规业务的组织结构与灾难无关。
在恢复过程中，组织结构通常基于连续性计划的级别。表4.3概述了用于响应和恢复的组织结构级别。
| 连续性计划的层次 | 组织层次 | 描述 |
| 战略 | 行政级别 | 这包括高级管理/主管人员，他们具有组织内的总体权限和控制，并负责危机管理，联络其他部门，事业部，组织，媒体，监管机构，紧急服务等。 |
| 战术 | 协调级别 | 通常，该级别比主管组低一级，该组负责协调组织内的整体恢复工作。 |
| 运行 | 专家级 | 一系列服务恢复团队，负责在各自区域内执行计划并与员工，客户和第三方保持联系。在IT内部，恢复团队应按服务和产品分组。 |
表4.3 用于响应和恢复的组织结构
八、 信息和技术
1 信息交换，输入/输出
服务连续性管理实践的效果基于所使用信息的质量。该信息可以包括：
- 消费者的业务流程
- 服务及其架构和设计
- 合作伙伴和供应商及其提供的服务信息
- 有关服务连续性的法规要求
- 与服务连续性安排有关的市场上可用的技术和服务
实践的关键输入和输出在第3节中列出。
服务连续性计划是该实践的核心。它们应该是最新的，并可供所有相关方使用。
2 自动化和工具
尤其是在大型组织中，服务连续性实践应该是自动化的。在可行且有效的地方，可能涉及表5.1中概述的解决方案。
表5.1 服务连续性管理活动的自动化解决方案
九、 合作伙伴和供应商
很少有服务仅使用组织自己的资源来交付的。大多数（如果不是全部）依赖于其他服务，这些服务通常由组织之外的第三方提供（请参阅ITIL Foundation的2.4节：ITIL 4 Edition 服务关系模型）。在服务设计，架构管理和供应商管理的实践指南中描述了由支持服务引入的关系和依赖。
合作伙伴和供应商可以提供关键产品和服务组件。服务提供者需要与合作伙伴和供应商协商，并就服务的连续性要求达成一致，以便满足服务的连续性要求。
合作伙伴和供应商也可以提供连续性服务和解决方案，例如备份站点，按需计算，灾难恢复的服务等。在这些情况下，它们也应参与服务连续性计划的开发，测试和执行。
十、 重要提醒
该实践指南的大部分内容都应作为组织在建立和培养自己的实践时可能考虑的领域的建议。实践指南是组织可能考虑的主题目录，而不是答案列表。使用实践指南的内容时，组织应始终遵循ITIL 指导原则：
- 聚焦价值
- 此时此刻
- 基于反馈迭代推进
- 协作和提升可视化程度
- 通盘思考和工作
- 保持简单实用
- 优化和自动化
