Version 16.1 by superadmin on 2021/02/20, 15:00
Show last authors
1 {{box cssClass="floatinginfobox" title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
4
5 (((
6
7 )))
8
9 需要下载 **ITIL 4 服务连续性管理实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“服务连续性”即可。
10
11 ​[[image:微信截图_20210206234644.png]]
12
13 **申明：**
14
15 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
16
17
18 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
19
20
21 翻译：李天池  审校：张宏伟  审核：谢帅
22
23
24
25 ----
26
27 = **1 关于本文档** =
28
29 本文档提供服务连续性实践实用指南，分为五个主要部分，涵盖：
30
31 * 本实践的一般信息
32 * 本实践相关的流程和活动及其在服务价值链中的作用
33 * 参与本实践的组织和人员
34 * 支持本实践的信息和技术
35 * 对本实践的合作伙伴和供应商的考虑
36
37
38 == **1.1 ITIL 4资格认证计划** ==
39
40 本文档中的部分内容可作为以下教学大纲的一部分以供检查：
41
42 * ITIL专家创建、交付和支持
43 * ITIL专家交付利益干系人价值
44
45 详情请参考各部分教学大纲。
46
47
48
49 ----
50
51 = **2 一般信息** =
52
53
54 == **2.1 目的和描述** ==
55
56 * **关键信息**
57
58 服务连续性管理实践的目的是确保灾难发生时，服务的可用性和性能能够保持在足够的水平。本实践提供了一个框架机制，利用产生有效响应的能力来构建组织的弹性，以保障关键利益相关者的利益，还有组织的声誉、品牌和创造价值的活动。
59
60 * **定义：灾难**
61
62 一个突发的意外事态，会对组织造成巨大损坏或严重损失。要被归类为灾难，这一事态必须与组织预定义的特定业务影响准则相匹配。服务连续性管理实践有助于确保服务提供者做好应对高影响事件的准备，这些事件会破坏组织的核心活动和/或信誉。在数字化转型的背景下，服务连续性管理实践变得越来越重要，因为在各个行业，数字化服务的作用越来越大。对于在过去专注于非技术灾难的组织而言，重大服务中断可能产生灾难性的影响。
63
64 云解决方案的广泛使用，以及与合作伙伴和服务消费者的数字化服务的广泛整合，正在产生更加难以控制的新的关键依赖关系。合作伙伴和服务消费者通常会投资于高可用性和高连续性解决方案上，但是组织之间缺乏整合和一致性会产生新的脆弱性，这一点需要被了解并解决。
65
66 服务连续性管理实践与其他实践（包括可用性管理、容量和性能管理、信息安全管理、风险管理、服务设计、关系管理、架构管理和供应商管理实践）相结合，可以确保组织的服务具有弹性并为灾难性事件做好准备。
67
68 风险的概念是服务连续性管理实践的核心。该实践通常可以减轻无法被完全避免的高影响、低概率风险（因为某些风险因素不在组织的控制之下，例如自然灾害）。
69
70 简单来说，此实践与事件管理实践非常相似，不同之处在于其潜在的损害要大得多，并且它可能威胁到服务提供者创造价值的能力。
71
72 服务连续性管理实践与服务价值系统（SVS）中的可用性管理实践密切相关，并且在某些情况下可以合二为一。它也与公司背景下的业务连续性管理实践紧密相关，并可以纳入其中。
73
74 服务经济时代，每个组织的业务都是由服务驱动和数字化的。由于这样的紧密联系，业务连续性管理实践可能会与数字化服务连续性与服务管理进行全面整合。如果数字化转型导致消除了“ IT 管理”和“业务管理”之间的界限，则这种整合可能是可行且有用的（有关该主题的更多信息，请参见ITIL4：高速IT）。
75
76
77 == **2.2  术语和概念** ==
78
79 * **定义：服务连续性**
80
81 在灾难事态或破坏性事件发生后，服务提供者以可接受的预定义级别继续服务运营的能力。
82
83 对于内部服务提供商，服务连续性管理实践的主要目的是通过管理可能影响IT服务的风险来确保服务提供者能够始终提供相关的议定服务级别，从而支持整个业务连续性管理实践。
84
85 对于外部服务提供商，服务连续性管理等同于业务连续性管理。
86
87 业务连续性专业人员也有兴趣处理业务危机，如负面媒体关注或破坏性市场事件。但是，在本实践指南中，服务连续性管理实践的范围仅限于运营风险。
88
89
90 === **2.2.1  灾难（或破坏性事件或危机）** ===
91
92 ISO将灾难定义为“一种具有高度不确定性的情况，这种情况会破坏核心业务和/或组织的信誉，并需要紧急行动”
93
94 明确定义被认为是灾难的事态列表通常是一个好主意。这样做有助于制定一套适当的服务连续性计划，从而确保组织做好应对破坏性事件的准备。灾难清单通常包括：
95
96 * 网络攻击
97 * 停电
98 * 战略合作伙伴的失败
99 * 火灾
100 * 洪水
101 * 关键人员不可用
102 * 大规模IT基础设施故障（例如数据中心故障）
103 * 自然灾害
104 * 界定那些不是灾难的事态同样重要。通常，服务连续性管理实践不涵盖：
105 * 轻度故障 故障被视为轻度或重度取决于其对业务的影响程度。重要的是要考虑诸如受影响的服务行动，故障的规模，故障的时间等因素。
106 * 战略，政治，市场或行业事件
107
108 为了从灾难中成功恢复，服务提供者应该定义服务的连续性要求。服务的连续性要求包括：
109
110 * 恢复时间目标(RTO)
111 * 恢复点目标(RPO)
112
113 最低服务连续性级别（请参阅图2.1）
114
115 (% style="text-align:center" %)
116 [[image:1613802480933-588.png]]
117
118 图2.1 服务的连续性要求：RTO，RPO，最低目标服务级别
119
120
121 === **2.2.2  恢复时间目标** ===
122
123 |(((
124 **定义：恢复时间目标**
125
126 由于业务功能缺失导致对组织产生严重影响之前，服务中断持续的最长时间。这就意味着在这个最大约定时间内必须重新开始生产或业务活动，或者必须恢复资源。
127 )))
128
129 估算RTO时应考虑的主要因素是：
130
131 * 服务提供者提供服务的能力下降以及与此下降相关的成本
132 * 服务级别协议罚款和监管判决
133 * 与竞争优势和声誉减弱相关的损失
134
135 业务连续性专业人员还使用术语“最大容忍中断时间/最大可接受中断（MAO）”，并将其与RTO区分开。
136
137 ISO 22301：2012提供以下定义：
138
139 * MAO因没有提供生产/服务或执行活动而产生的，为不良影响所花费的变得不可接受的时长
140 * RTO 事件之后的时间段，在此期间生产或业务活动必须重新开始，或者资源必须恢复
141
142 按照此逻辑，RTO应当比MAO在数量上少一些，这足以说明组织的风险偏好.MAO应该在业务影响分析中确定。RTO应该在服务连续性计划的开发中定义。
143
144
145 === **2.2.3  恢复点目标** ===
146
147 |(((
148 **定义：恢复点目标**
149
150 活动所使用的必须恢复的信息所指向的点，以使活动在重新开始后能够有效运行。
151 )))
152
153 RPO定义了可容许的数据损失的时间段。如果RPO为30分钟，则在破坏性事态之前30分钟应至少有一个备份，在服务恢复后的服务交付重新开始时，距离破坏性事态之前30分钟或更短时间内的数据是可用的。
154
155 估算RPO时应考虑的主要因素是：
156
157 * 使用数据的服务的重要性
158 * 数据的重要性
159 * 数据的生产率。
160
161 例如，一家网上商店每小时接收100个订单。高管们说，丢失200个订单将是不可接受的。因此，RPO为2小时。
162
163 RPO定义了备份频率的要求。在灾难发生时，备份管理必须确保最近的备份副本的可用性。
164
165
166 === **2.2.4  最低目标服务级别** ===
167
168 |**定义：最低目标服务级别**服务提供者可接受的服务级别，可以在中断期间实现其目标。
169
170 灾难恢复期间，服务提供者通常应以最低目标服务级别提供服务。即使客户没有特殊要求，但达到最低服务级别也有助于尽量减小损失。
171
172 最低目标服务级别通常根据以下方面进行定义：
173
174 * 中断期间用户可以使用的特定服务操作和功能点的列表
175 * 中断期间应能够访问服务的有限的用户数量或特定用户组
176 * 中断期间用户应能够处理的单位时间段内有限的交易数量。
177
178
179
180 === **2.2.5  业务影响分析** ===
181
182 |(((
183 **定义：业务影响分析**
184
185 服务连续性管理实践中的关键活动，用于标识重要的业务功能（VBF）及其依赖关系。这些依赖关系可能包括供应商，人员，其他业务流程和IT服务。业务影响分析定义了IT服务的恢复要求。这些要求包括RTO，RPO和每个IT服务的最低目标服务级别。
186 )))
187
188 业务影响分析（BIA）是一个流程，用于分析活动以及中断可能对其产生的影响
189
190 根据ISO 22301，业务影响分析应包括：
191
192 * 识别支持产品和服务提供的活动
193 * 评估不执行这些活动，随着时间流逝而造成的影响
194 * 设置优先级时间范围以在明确规定的最低可接受水平上恢复这些活动，考虑到在这时间内不恢复它们，带来的影响将变得不可接受
195 * 确定这些活动的依赖关系和支持资源，包括供应商，外包合作伙伴，以及其他相关利益方。
196
197
198
199 === **2.2.6  服务连续性/ 灾难恢复计划** ===
200
201 |(((
202 **定义：服务连续性**
203
204 一套明确定义的考虑到服务管理四维模型的计划，有关组织如何从灾难恢复并返回到灾难之前的状态。
205 )))
206
207 服务连续性计划用于指导服务提供者在中断后响应，恢复服务并将其还原到正常水平。
208
209 服务连续性计划通常包括：
210
211 * 响应计划 明确了服务提供者最初如何对破坏性的事态做出反应，以防止损坏，例如火灾或网络攻击。
212 * 恢复计划 明确了服务提供者如何恢复服务以实现RTO和RPO。
213 * 计划恢复正常操作明确了服务提供者在恢复之后如何重新开始正常。例如，如果已使用备用数据中心，则此阶段将使主数据中心重新投入运行，并修复再次调用IT服务连续性计划的能力。
214
215 在许多情况下也会有制定业务连续性计划的需求。业务连续性计划可能包括：
216
217 * 紧急响应 对接所有紧急服务和活动
218 * 疏散计划以确保人员安全
219 * 危机管理和公众关系计划为不同危机的指挥和控制，以及媒体和公众关系的管理做出计划
220 * 安全计划展示了所有主站点和恢复站点上的安全的各个方面是如何被管理的
221 * 沟通计划展示了在重大事件期间，与所有相关领域和当事人沟通的各个方面是如何处理和管理的。
222
223 这些计划通常在制定时被当做业务连续性管理实践的一部分。
224
225
226 == **2.3 范围** ==
227
228 服务连续性管理实践包括以下领域：
229
230 * 执行BIA来量化服务不可用带给服务提供者和服务消费者的影响
231 * 开发服务连续性策略（并将它们整合到相关的业务连续性管理策略中）。这应该包括的要素有风险缓解措施，以及适当的、全面的恢复选项的选择
232 * 制定和管理服务连续性计划（并为相关的业务连续性计划提供清晰的接口）
233 * 进行练习，并测试如果发生灾难情况下，服务连续性计划的启用
234 * 有一些活动和责任领域尽管仍与服务连续性管理密切相关，但不包含在服务连续性管理实践中。表2.1中列出了这些内容，以及涉及到的包含这些内容的实践。重要的是要记住，ITIL实践只是在价值流的背景中使用的工具的集合；它们应当根据情况在必要时组合在一起。
235
236
237 |活动|实践指南
238 |与客户沟通以使客户的业务连续性策略和计划与服务提供者的服务连续性策略和计划保持一致|关系管理
239 |协商并与客户服务连续性要求达成一致|服务级别管理
240 |将服务连续性解决方案设计为服务模型的一部分|服务设计
241 |使服务连续性解决方案与业务架构保持一致|架构管理
242 |识别与服务连续性相关的风险|风险管理
243 |与供应商和合作伙伴建立和管理合同|供应商管理
244 |监控服务的可用性|监控和事态管理
245 |证明新的服务连续性解决方案|组合管理
246 |实施风险缓解措施并更改IT基础设施，以确保弹性|项目管理, 变更控制
247 |管理并实施持续改进|持续改进
248
249
250
251 === **2.3.1  可用性与连续性之间的界线** ===
252
253 服务的连续性和可用性管理的实践之间的界限是不明显的。两种做法都涉及风险的概念，并致力于识别和准备应对可能威胁并导致服务不能运转的事件。对于这两种实践，都需要了解VBF和风险评估或服务故障的BIA。最终，两种做法都确保了组织的抗故障能力。
254
255 一些组织不希望将可用性的管理和连续性分开。但是，表2.2中概述了这两种做法之间的一些差异，在设计服务管理系统时应考虑这些差异。
256
257 |可用性管理|服务连续性管理
258 |专注于高概率的风险|专注于高影响风险（紧急情况，灾难）
259 |更主动|更被动
260 |减少意外的可能性|减少意外的影响
261 |关注技术解决方案|关注组织措施
262 |优化|创建冗余
263 |不属于公司职能|通常是公司职能的一部分
264 |日常业务|特殊情况下
265 |MTRS, MTBF, MTBSI|RTO, RPO
266
267 表2.2 可用性管理和服务连续性管理之间的区别
268
269
270 服务连续性管理实践不包含那些不会严重影响组织的轻度或短期故障。它关注与重大损害相关的风险，无论它们发生的可能性或不可能性有多大。通常，这些是紧急情况：火灾，洪水，断电，数据中心故障等。虽然可用性管理实践并未忽略故障对服务提供者和消费者造成的负面影响，但是单个组件的轻度中断也在流程中有所考虑。
271
272 这些实践的目标之间存在对立。可用性管理实践处理统计数据并分析趋势；连续性管理关心如何应对破坏性事件。
273
274 可用性规划致力于满足当前和将来的商定要求，并避免出现偏差。可用性管理实践发现并消除单点失效；所采取的对策通常是积极主动的，以减少意外事态发生的可能性。服务连续性管理实践专注于规划，以管理破坏性事件的严重后果。备份站点，服务提供的替代方案的过渡，还有恢复程序，都可以减少损坏，但是通常不影响事件发生的可能性。
275
276
277 === **2.3.2 事件管理** ===
278
279 事件管理实践的活动与服务连续性管理实践的非常相似。但是，事件管理实践专注于不会威胁组织的弹性的故障，而服务连续性管理实践专注于可能会阻碍组织恢复服务交付的高影响故障。
280
281 同样，这两个实践之间的界线是不明显的，应根据对务提供者和服务使用者的影响来明确定义。同时，在某些情况下（通常在小的，单站点服务提供者中），服务连续性活动可作为重大事件管理的一部分来执行。
282
283 当服务连续性计划到位并与事件管理活动分开管理时，应该有一个清晰的标准来触发服务连续性程序。在评估事件的业务影响时，支持专家应确定重大事件是否可能导致灾难，并通知危机管理组，以便他们能够做出有关启用的决定。
284
285 |(((
286 **定义：启用**
287
288 服务提供者必须承诺服务连续性计划，以便继续服务的交付。
289 )))
290
291
292
293 === **2.3.3 服务连续性实践在管理风险时的角色** ===
294
295 风险的概念是服务连续性管理实践的核心。该实践通常关注于减轻无法完全防止的高影响，低概率风险。
296
297 为了降低风险，此实践致力于使预期损失减小到最低程度，以便在灾难发生时不会造成重大损失。
298
299 为确保准备好应对破坏性事件，服务连续性管理实践需要有关风险的信息，这些信息可以通过风险管理实践获得。
300
301 有效的服务连续性管理实践可以为组织的风险管理做出显著贡献。大量风险缓解措施在某种程度上与服务连续性选项相关。
302
303
304 == **2.4 实践成功因素** ==
305
306 |(((
307 **定义：实践成功因素**
308
309 实践的一个复杂的功能性的组件，是实践实现其目的所必需的。
310 )))
311
312 实践的成功因素（PSF）不仅仅是一项任务或活动，因为它包括全部服务管理四维模型的组件。活动的性质和实践中PSF的资源可能有所不同，但它们共同确保实践有效。
313
314 服务连续性管理实践包括以下PSF：
315
316 * 制定和管理服务连续性计划
317 * 降低服务的连续性风险
318 * 确保认知和准备就绪
319 * 制定和管理服务连续性计划
320
321 为了有效地应对灾难并从中恢复，服务提供者需要服务连续性计划，该计划应反映所选的服务连续性策略。应该根据在BIA期间确定的服务连续性要求选择服务连续性策略。
322
323 因此，为了制定和管理服务连续性计划，服务提供者应该首先完成BIA，然后选择适当的一组服务连续性要求，进而定义服务连续性策略。
324
325 业务连续性研究所（BCI）定义了以下连续性策略:
326
327 * 多样化
328 * 复制
329 * 备用
330 * 事件之后的采集
331 * 什么都不作
332 * 分包
333
334 只要服务的连续性要求和服务提供者的背景有所变化，它们就不是一次性的活动。例如，当服务提供者开始将其服务交付给新的消费者时。该事态是重新执行BIA和更新服务连续性策略的触发器。如果长期没有明显变化，则通常每年进行一次或两次BIA，并与风险评估周期同步。有关BIA的更多详细信息，请参见[[3.2.2>>path:#_bookmark10]].
335
336
337 === **2.4.1 连续性计划** ===
338
339 BCI在响应和恢复规划结构中引入了三个层次：战略层、战术层和操作层，如表2.3所示。
340
341 表2.3响应和恢复规划结构中的层次
342
343 |层次|描述
344 |战略层|高管如何做出有关恢复流程的决策，如何与外部各方（包括相关媒体）进行沟通以及处理服务连续性计划中未涉及的任何情况
345 |战术层|管理层如何协调恢复流程，以确保根据优先级（当前业务优先级，季节性变化等）适当分配资源并管理规划团队和恢复团队之间的冲突
346 |操作层|团队如何执行恢复活动，包括响应破坏性事件，恢复到服务的预定义级别，和/或提供替代设施以继续运行
347
348 根据组织的规模以及服务提供者是内部的还是外部的，可能会有不同的解决方案来构建计划。责任主体也可能有所不同。
349
350 服务连续性计划根据服务提供者的类型和组织的规模，其结构的复杂度可能会或多或少。表2.4 概述了一些常见的结构。
351
352 | |小型组织|大型组织
353 |内部服务提供商|(((
354 在小型组织的IT部门中，可能没有任何服务连续性计划。所有连续性安排都可以作为业务连续性管理的一部分进行管理。
355
356 特定的IT服务连续性活动可以作为事件管理实践的一部分执行。
357 )))|(((
358 战略层：由高管执行的危机管理计划。它通常是业务连续性计划的一部分。
359
360 战术层：大量计划，每个计划都涵盖一个产品，服务，业务单元，站点或位置，每个计划都拥有自己的恢复团队。战术的IT部门活动可以包含在业务连续性计划中，但通常将它们设计为单独的相关计划。
361
362 操作层：大量的用于特定恢复活动的详细步骤（例如，从备份中恢复应用程序数据）。其他部门可能会有自己的特定操作说明，作为连续性计划的一部分。
363 )))
364 |外部服务提供商|所有层次（战略，战术，运行的）都可以作为一个计划实施，而一个团队则负责响应和恢复的各个方面。|连续性计划级别的描述与上面类似，但是服务提供者对所有级别负责。
365
366 表2.4 连续性计划的结构选项
367
368
369 服务连续性计划应涵盖表2.5中概述的灾难发生之后的各个阶段。
370
371 |阶段|响应|恢复|复原
372 |计划|响应计划|恢复计划|恢复正常运行计划
373 |内容|(((
374 应触发服务连续性计划的事件和场景
375
376 危机管理组联系人
377
378 初始响应并最小化潜在损失的规程。通常会有针对特定场景的程序（例如火灾或停电）
379
380 用于挑选恢复选项的文档化准则（如果有）
381
382 沟通程序，包括与客户，合作伙伴和员工的沟通
383
384 用于启用的文件化的触发器
385 )))|(((
386 恢复团队成员联系方式
387
388 恢复团队的协调指南
389
390 恢复程序的详细说明
391
392 整个组织的监控和共享信息的指南
393
394 升级程序
395 )))|(((
396 恢复正常运行的文件化准则
397
398 恢复正常运行程序的详细说明
399
400 复原恢复站点的说明（如果有）
401 )))
402
403 表2.5 响应阶段和恢复阶段
404
405
406 计划应清晰，简洁且以行动为导向。通常，计划中应排除掉那些对于使用计划的恢复团队不直接应用的信息。程序应基于时间，并应包含可能的延迟以及计划与团队之间的交互信息。
407
408 有关响应和恢复的组织结构的详细信息，请参见[[4.2>>path:#_bookmark14]].
409
410
411 === **2.4.2 减轻服务连续性风险** ===
412
413 服务连续性管理实践包括管理各种风险的控制项的定义和管理。为此，它与风险管理实践和其他以风险为中心的实践（例如容量和性能管理，可用性管理和信息安全管理实践）结合使用。商定的可用性控件应通过服务设计，软件开发和管理，以及基础设施和平台管理实践来实施。
414
415 表2.6 中概述的服务连续性选项可以作为总体风险缓解计划的一部分来设计和实现。
416
417 |服务管理维度|服务连续性措施
418 |组织和人员|(((
419 1. 在灾难期间的人员管理
420 1. 使用替代站点和设施
421 )))
422 |信息和技术|(((
423 1. 物理安全
424 1. 弹性电信网络
425 1. 运维中的数据保护：使用RAID阵列，SAN等来确保数据的可用性
426 1. 数据备份
427 1. 容错应用程序
428 1. 监控以提供及时告警
429 )))
430 |合作伙伴和供应商|(((
431 1. 互惠协议
432 1. 将服务外包给多个提供商
433 1. 作为服务的火灾探测系统或灭火系统
434 )))
435 |流程和价值流|(((
436 1. 服务交付的手动操作和替代方法
437 1. 响应和恢复的计划与程序（服务连续性计划）
438 )))
439
440 表2.6 服务连续性管理实践的四个维度
441
442
443 如果服务的BIA表明了有更早和更高的影响发生，则需要采取更多的预防措施。如果初始影响较低且发展缓慢，则投资于连续性和恢复对策是更经济有效的方法。
444
445 选择服务连续性措施时，每个选项的效果和效率应得到评估。同样重要的是持续控制并验证其持续效果和效率。
446
447 * 效果根据风险管理原则，应评估服务连续性措施的效果，并将其与破坏性事态的预期损失进行比较。
448 * 效率服务连续性度量的成本应该进行评估，并与收益进行比较。通过估算实施该措施后破坏性事态发生概率的降低，并乘以发生事态会对服务提供者和客户造成的预期的影响，可以计算出收益。就成本而言，应将此价值与该措施实施的成本进行比较。这里可以使用成本效益分析。
449
450
451
452 === **2.4.3 确保认知和就绪状态** ===
453
454 未经测试的恢复计划通常根本无法按预期工作。因此，测试是服务连续性管理的关键组成部分，并且是确保所选策略，已实施措施和计划切实可行的唯一方法。
455
456 测试服务连续性计划是检查和提高准备状态的一种手段。通过定期修改计划和程序，恢复团队发现缺陷和低效率，然后更新服务连续性计划以反映他们的发现。
457
458 BCI定义以下演练类型:
459
460 * 走查
461 * 桌上演练
462 * 指挥所演练
463 * 现场
464 * 测试。
465
466 根据BCI良好实践指南，每种类型的关键特征和目的。
467
468 表2.7 概述了2013年。
469
470 |(% style="width:92px" %)演练类型|(% style="width:426px" %)关键特征|目的
471 |(% style="width:92px" %)走查|(% style="width:426px" %)(((
472 * 基于讨论的演练
473 * 未加压的环境
474 * 通常专注于某一特定区域进行改进
475 )))|(((
476 用于恢复团队成员首次见面
477
478 利用改进机会
479 )))
480 |(% style="width:92px" %)桌上演练|(% style="width:426px" %)(((
481 * 基于一个给定场景的讨论
482 * 通常实时运行，但可以包含“时间跳跃”以使得场景的不同阶段都受到演练
483 )))|提高对计划的了解
484 |(% style="width:92px" %)指挥所演练|(% style="width:426px" %)(((
485 * 以模拟真实事件的方式为恢复团队成员提供信息，并邀请他们做出回应
486 )))|测试沟通，决策和协调
487 |(% style="width:92px" %)现场|(% style="width:426px" %)(((
488 * 测试计划的最逼真的方法
489 * 范围可以从一个组件的恢复的小型排练，到整个服务或组织的恢复的全面排练
490 * 通常包括参与的利益相关方
491 )))|测试在发生破坏性事态时，达到RTO，RPO和最低目标服务水平的能力
492 |(% style="width:92px" %)测试|(% style="width:426px" %)(((
493 * 它通常应用于特定的硬件或软件，例如从备份恢复应用程序数据。
494 * 依照ISO 22301，测试是一种独特类型的演练，它包含了一个期望，就是：演练的（一个或多个）目标的成功或失败要素正在计划中
495 )))|当故障的风险较高时，测试服务组件的恢复
496
497 表2.7 锻炼类型
498
499
500 演练应该按计划的时间间隔，以及发生可能影响恢复的显著变更时实施。服务中断的可能造成的影响程度越高，演练的频率就应该越高。
501
502 演练不仅是确保准备就绪的一种方法，而且是一个改进机会。因此，通常的好主意是，分析测试期间的发现以及整个恢复团队表现，然后生成包括发现和正式建议的演练报告。
503
504
505 == **2.5 关键指标** ==
506
507 每个实践所做的贡献应该在价值流的背景下评估ITIL实践的效果和绩效。与任何工具的性能/绩效一样，只能在应用程序的背景下评估实践的绩效。然而，工具在设计和质量方面会有很大差异，这些差异被定义为一种工具在根据其用途使用时的有效潜力或能力。更多的有关指标，关键绩效指标（KPIs），和有助于此目的的其他工具的进一步指导，能够在度量和报告实践指南中找到。
508
509 服务连续性管理实践的关键指标已映射到其PSF。它们可以用作价值流的背景中的KPI，以评估实践对这些价值流的效果和效率的贡献。表2.8给出了一些关键指标的示例。
510
511 |实践成功因素|指标示例
512 |制定和管理服务连续性计划|(((
513 * 具有清晰地文件化连续性要求的产品和服务的百分比
514 * 文件化的服务连续性计划中（关键）产品和服务的百分比
515 * 及时更新服务连续性计划
516 )))
517 |降低服务的连续性风险|(((
518 * RTO达成情况（实际灾难和演练）
519 * RPO达成情况（实际灾难和演练）
520 * 有效连续性措施的百分比
521 * 实际损失与预期损失之比
522 )))
523 |确保认知和就绪状态|(((
524 * 按计划进行的演练和认知活动的百分比
525 * 在给定时间段内（通常为过去6个月）对其连续性计划进行测试的服务所占的百分比
526 )))
527
528 表2.8 实践成功因素的指标示例
529
530 将指标正确汇总到复杂指标中，将使数据更易于用于价值流的日常管理，以及用于服务连续性管理实践的定期评估和持续改进。没有单一的最佳解决方案。指标将基于总体的服务战略和组织的优先级，以及实践有助于的价值流目标。
531
532
533
534 ----
535
536
537 = **3  价值流和流程** =
538
539
540 == **3.1  价值流贡献** ==
541
542 像任何其他ITIL 管理实践一样，服务连续性管理也有助于多个价值流。重要的是要记住，价值流永远不会由单个实践形成。服务连续性管理实践与其他实践相结合，可以为消费者提供高质量服务。实践贡献的主要价值链活动是：
543
544 * 交付和支持
545 * 设计和转换
546 * 改进
547 * 获取或构建
548 * 计划
549
550 服务连续性管理实践对服务价值链的贡献如图3.1 所示。
551
552 (% style="text-align:center" %)
553 [[image:1613802652783-527.png]]
554
555 图3.1 服务连续性管理实践对价值链活动贡献的热力图
556
557
558 == **3.2  流程** ==
559
560 每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必需的。
561
562 |(((
563 **定义：流程**
564
565 一组相互关联或交互的活动，可将输入转换为输出。流程接受一个或多个定义的输入，并将其转换为定义的输出。流程定义活动的顺序及它们的依赖关系。
566 )))
567
568 服务连续性管理活动形成五个流程：
569
570 * 服务连续性管理的治理
571 * 业务影响分析
572 * 制定和维护服务连续性计划
573 * 测试服务连续性计划
574 * 响应和恢复
575
576
577
578 === **3.2.1  服务连续性管理的治理** ===
579
580 该流程包括表3.1中列出的活动，并将输入转换为输出。
581
582 |关键输入|活动|关键输出
583 |(((
584 1. 业务影响分析报告
585 1. 风险登记册
586 1. 客户要求
587 1. 法规要求
588 1. 风险偏好
589 1. 标准
590 )))|(((
591 1. 范围的定义
592 1. 策略设置
593 1. 认知和演练方案制定
594 )))|(((
595 1. 服务连续性策略
596 1. 文件化的角色和职责
597 1. 认知和演练方案
598 )))
599
600 表3.1 服务连续性管理的治理的输入，活动和输出
601
602
603 图3.2显示了流程的工作流程图。
604
605 (% style="text-align:center" %)
606 [[image:1613802681329-660.png]]
607
608 图3.2 服务连续性管理的治理的工作流程
609
610
611 这些活动可能由组织中的许多人以不同程度的正式方式来执行。表3.2进一步描述了这些活动。
612
613 |(% style="width:106px" %)活动|(% style="width:662px" %)描述
614 |(% style="width:106px" %)范围的定义|(% style="width:662px" %)(((
615 定义服务连续性管理实践的范围，确保它所涵盖的组织的环境和地域清晰。
616
617 组织范围可能受到产品和服务，站点和位置，客户等的限制。那些已停产的或即将终止的产品和服务通常被排除在范围之外，非关键和低利润的产品和服务也一样。
618
619 实施服务连续性管理实践的成本可能很高。因此，如果服务提供者启动服务连续性管理方案，则某些服务，产品或站点最初可能会作为分阶段实施的一部分而被排除在外。
620
621 许多不同的技术被用来定义实践的范围，包括成本效益分析，SWOT分析，PESTLE分析等。
622
623 定义范围时，组织应考虑：
624
625 * 以前的业务影响分析报告
626 * 现有风险登记册
627 * 客户要求
628 * 监管要求
629
630 根据灾难定义实践的范围也很重要。
631 )))
632 |(% style="width:106px" %)策略设置|(% style="width:662px" %)(((
633 策略的设置包括：
634
635 * 记录范围。
636 * 分配角色和职责。如果服务提供者仅启动服务连续性方案，则将没有组织结构来支持任何服务连续性计划。在其他情况下，响应和恢复团队的组织结构通常是服务连续性策略的一部分。
637 * 定义服务连续性管理的一般方法。服务连续性策略应阐明在BIA期间应考虑的可用资源和限制。
638 * 应尽快建立并传达政策，以便所有参与服务连续性管理实践或受其影响的利益相关者都知道范围，限制及其职责。
639 * 范围和政策应定期修订（通常每年一次）。修订被触发，可能是由于破坏性事态（尤其是计划未涵盖的），一个新的服务，一个新的客户或者是与合作伙伴的一个新关系。
640 )))
641 |(% style="width:106px" %)认知和演练方案制定|(% style="width:662px" %)(((
642 测试是整个服务连续性管理实践的关键部分：这是确保所选策略，措施和计划有效的唯一方法。
643
644 应该制定教育，认知培训和演练计划，以确保实践的所有部分（站点，团队成员，服务或CI）每年至少进行一次测试。
645
646 演练方案应确保测试整个的服务管理四维模型：
647
648 * 组织和人员
649
650 * 具有适当技能的适当人员
651 * 恢复团队成员的知识和经验
652 * 工作人员了解服务连续性计划
653
654 * 信息和技术:
655
656 * 所需的设备正常工作
657 * 所需的数据可用
658
659 * 合作伙伴和供应商:
660 * 参与响应和恢复的第三方准备就绪，以满足服务连续性要求
661
662 * 流程和价值流：
663
664 * 程序是正确的，一致的，可管理的
665 )))
666
667 表3.2 服务连续性管理的活动
668
669
670 === **3.2.2 业务影响分析** ===
671
672 该流程包括表3.3中列出的活动，并将输入转换为输出。
673
674 |关键输入|活动|关键输出
675 |(((
676 * 服务文档
677 * 风险评估报告
678 * VBF损失的财务数据
679 * 重大事件报告
680 * 服务模型
681 * 风险管理策略
682 * 风险偏好
683 * 监管要求
684 )))|(((
685 * VBF识别
686 * 中断后果分析
687 * VBF相互依赖关系识别
688 * 服务连续性要求的确定
689 )))|(((
690 * VBF的优先级列表
691 * 文件化的VBF损失产生的影响
692 * 文件化的VBF相互依赖关系
693 * 业务影响分析报告
694 )))
695
696 表3.3 业务影响分析流程的输入、活动和输出
697
698
699 图3.3 业务影响分析流程的工作流程
700
701 (% style="text-align:center" %)
702 [[image:1613802733108-253.png]]
703
704 图3.3 显示了流程的工作流程图
705
706
707 这些活动可以由组织中的许多人以不同程度的正式方式来执行。表3.4进一步概述了这些活动。
708
709 |(% style="width:110px" %)活动|(% style="width:657px" %)描述
710 |(% style="width:110px" %)VBF识别|(% style="width:657px" %)(((
711 VBF涉及到服务中对于服务提供者和/或客户的成功至关重要的一部分。识别和文件化这些VBF，以提供适当的焦点和资源分配非常重要。
712
713 可以使用许多不同的技术来识别风险，包括头脑风暴，与利益相关者（包括客户和用户）的访谈，对服务文档的分析等等。
714
715 如果服务提供者具有已建立的风险管理实践，则有关风险评估的信息可能有助于理解最关键的区域。
716 )))
717 |(% style="width:110px" %)中断后果分析|(% style="width:657px" %)(((
718 当确定了VBF时，应确定中断的影响。该影响可能是可以准确识别的“硬” 影响，例如财务损失，也可以是“软” 影响，例如声誉受损或失去竞争优势。
719
720 可以考虑FAIR提出的以下形式的损失：
721
722 * 生产效率：服务提供者提供服务的能力下降
723 * 响应：与管理损失事态有关的费用
724 * 替换：资产的固有价值，与替换丢失或损坏的资产相关的费用（例如，购买替换服务器）
725 * SLA罚款和监管判决：针对服务提供者的法律或监管行动
726 * 竞争优势：与竞争优势减弱相关的损失。
727 * 声誉：与外部对服务提供者的看法的相关损耗
728
729 影响可能会随时间推移产生变化。服务提供者和客户也许可以在短时间内不使用特定的服务或VBF而正常工作，但是随着时间的流逝，影响可能会增加，直到服务提供者或客户不能再操作。
730
731 BIA演练的主要输出之一是一项IT服务或特定VBF随时间推移的预期损失图。使用此图以驱动服务连续性策略和计划。
732
733 服务中断造成的损失通常会随着时间呈指数增长。除了与组织产生其主要价值主张的能力下降的有关损失之外，还存在罚款，判决和声誉受损的威胁。
734 )))
735 |(% style="width:110px" %)(((
736 VBF
737
738 相互依赖关系识别
739 )))|(% style="width:657px" %)(((
740 VBF和服务组件以及关键的内部和外部资源之间的相互依赖关系应予以识别和文件化。
741
742 为此，如果已安装配置管理数据库，则服务提供者可以使用服务和配置模型。组件故障影响分析（CFIA）也可能是有用的技术。CFIA可用于识别失效的单个点，现有的冗余等。
743 )))
744 |(% style="width:110px" %)服务连续性要求的确定|(% style="width:657px" %)(((
745 基于对中断后果和识别的相互依赖关系的分析，服务提供者应为服务连续性管理范围中的每个服务或VBF确定服务连续性要求，包括：
746
747 * 恢复时间目标
748 * 恢复点目标
749 * 最低目标服务级别
750 )))
751
752 表3.4 业务影响分析流程的活动
753
754
755 === **3.3.2  制定和维护服务连续性计划** ===
756
757 该流程包括表3.5 中列出的活动，并将输入转换为输出。
758
759 |关键输入|活动|关键输出
760 |(((
761 * 业务影响分析报告
762 * 现有控件
763 * 有关可用资源的信息
764 * 消费者的连续性计划
765 * 服务连续性策略
766 )))|(((
767 * 服务连续性策略制定
768 * 服务连续性计划制定
769 * 服务连续性计划的初始测试
770 )))|(((
771 * 新的和更新的控件
772 * 服务连续性策略
773 * 服务连续性计划
774 )))
775
776 表3.5 制定和维护服务连续性计划流程的输入，活动和输出
777
778
779 图3.4 显示了该流程的工作流程图。
780
781 (% style="text-align:center" %)
782 [[image:1613803200091-580.png]]
783
784 图3.4 制定和维护服务连续性计划流程的工作流程
785
786
787 这些活动可以由组织中的许多人以不同程度的正式方式来执行。
788
789 表3.6 进一步概述了这些活动。
790
791 |(% style="width:147px" %)活动|(% style="width:621px" %)描述
792 |(% style="width:147px" %)服务连续性策略制定|(% style="width:621px" %)(((
793 基于BIA 报告，服务提供者应该确定一套适当的且具有成本效益的服务连续性策略集。
794
795 对于影响更早，影响更大的流程和服务，应采取更多的预防措施。对于影响较低且需要较长时间开发的流程和服务，应更加重视恢复措施。
796 )))
797 |(% style="width:147px" %)服务连续性计划制定|(% style="width:621px" %)(((
798 基于服务连续性政策和策略，服务提供者应该制定和维护服务连续性计划。
799
800 如果服务或恢复团队成员发生变化，则必须更新计划。计划也可以在演练或实际恢复之后更新。
801 )))
802 |(% style="width:147px" %)服务连续性计划的初始测试|(% style="width:621px" %)发布之前，应测试服务连续性计划。初始测试的方法类似于正在进行的演练。
803
804 表3.6 制定和维护服务连续性计划流程的活动
805
806
807 === **3.3.3  测试服务连续性计划** ===
808
809 该流程包括表3.7 中列出的活动，并将输入转换为输出。
810
811 |关键输入|活动|关键输出
812 |(((
813 * 认知和演练方案
814 * 服务连续性计划
815 )))|(((
816 * 进行演练
817 * 服务连续性审计
818 )))|(((
819 * 演练报告
820 * 新的和更新的控件的要求
821 * 策略或计划的变更请求
822 * 审计报告
823 )))
824
825 表3.7 测试服务连续性计划流程的输入、活动和输出
826
827
828 图3.5 显示了该流程的工作流程图。
829
830 (% style="text-align:center" %)
831 [[image:1613803224419-995.png]]
832
833 图3.5 测试服务连续性计划流程的工作流程
834
835
836 这些活动可能由组织中的许多人以不同程度的正式方式来执行。表3.8进一步概述了这些活动。
837
838 |(% style="width:131px" %)活动|(% style="width:636px" %)描述
839 |(% style="width:131px" %)进行演练|(% style="width:636px" %)(((
840 演练应按计划的时间间隔，和当出现可能影响恢复的显著变化时进行。服务中断的可能影响越高，演练的频率就应该越高。
841
842 演练和测试不仅是确保准备就绪的方法；它们也是改进机会。这通常是一个好主意，用来分析测试结果以及整个恢复团队绩效，然后生成包括结果和建议的演练报告。
843
844 练习报告可能包括对新的或更新的现存的要求，或对服务连续性计划变更的请求。
845
846 如果演练失败，则会更新后续演练时间表以便尽快重新执行失败的演练。
847 )))
848 |(% style="width:131px" %)服务连续性审计|(% style="width:636px" %)(((
849 服务连续性审计可确保在环境更改时，BIA，服务连续性策略和计划保持适当和相关。审计通常是按计划进行的，但是可能由于演练失败或恢复失败而触发。
850
851 审核可以在内部进行，也可以由第三方进行。审计的输出可能会确定一个实施新的或更新的控件的需求，也可以是调整服务连续性策略或计划的需求。
852 )))
853
854 表3.8测试服务连续性计划流程的活动
855
856
857 === **3.3.4  响应和恢复** ===
858
859 该流程包括表3.9 中所述的活动，并将输入转换为输出。
860
861 |关键输入|活动|关键输出
862 |(((
863 * 服务连续性计划
864 * 事件记录
865 )))|(((
866 * 调用
867 * 执行服务连续性计划
868 )))|(((
869 * 恢复报告
870 * 新的和更新的控件的要求
871 * 变更计划的请求
872 )))
873
874 表3.9 响应和恢复流程的输入、活动和输出
875
876
877 图3.6 显示了该流程的工作流程图。
878
879 (% style="text-align:center" %)
880 [[image:1613803263520-830.png]]
881
882 图3.6 响应的工作流程和恢复流程
883
884
885 这些活动可以由组织中的许多人以不同程度的正式方式来执行。
886
887 表3.10 进一步概述了这些活动。
888
889 |(% style="width:152px" %)实现价值|(% style="width:615px" %)描述
890 |(% style="width:152px" %)启动|(% style="width:615px" %)(((
891 启动是一项声明行为，组织的连续性安排需要实施，以便继续提供关键产品和服务[[12>>path:#_bookmark12]].
892
893 启动的决定通常是由“ 危机管理”团队（在组织结构的战略层面上）做出的。[[13>>path:#_bookmark13]]），用于核算：
894
895 * 服务中断的潜在影响
896 * 服务中断的可能持续时间
897 * 每天/每月/每年的时间
898 )))
899 |(% colspan="2" %)(((
900 |(% style="width:143px" %)启动|(% style="width:607px" %)(((
901 如果风险较低，则危机管理团队可以决定不调用服务连续性计划。
902
903 如果启动，危机管理团队还应该：
904
905 * 确定服务提供者要使用的哪些恢复选项（如果有几个选项可用）
906 * 定义启动的范围（服务，产品，站点，位置等）
907
908 启动是服务连续性计划的最终测试。如果准备工作已经完成并且计划已经制定和经过测试，那么启动应该很简单。如果计划未经测试，则可能会失败。
909 )))
910 |(% style="width:143px" %)执行服务连续性计划|(% style="width:607px" %)(((
911 一旦发生启动，所有参与的恢复团队都应执行服务连续性程序。恢复可能是一段时间的高级活动，需要许多人花费长时间。在战术层面上，恢复团队调度员必须对此进行识别和管理。
912
913 任何时候都可能发生中断，因此对于办公室内外的关键人员而言，容易获得启动流程的指南是非常必要的。
914
915 恢复流程通常包括以下阶段：
916
917 * 响应：为防止损坏对破坏性的事态做出响应，例如在火灾或网络攻击情况下。
918 * 恢复：根据RTO，RPO和最低要求目标服务级别，恢复服务的交付。
919 * 返回正常操作。
920 )))
921 )))
922
923 表3.10 活动的响应和恢复流程
924
925
926
927 ----
928
929 = **4  组织和人员** =
930
931
932 == **4.1  角色，能力和责任** ==
933
934 ITIL 实践指南没有描述实践管理的角色，例如实践所有者，实践负责人或实践教练。相反，他们专注于每个实践特有的专门角色。每个角色的结构和命名都可能因组织而异，因此ITIL中定义的任何角色都不应被视为强制性的，只是推荐性的。
935
936 请记住，角色不是职位。一个人可以担任多个角色，一个角色可以分配给多个人。
937
938 角色是在流程和活动的背景中描述的。每个角色都具有基于表4.1中所示模型的一个能力简介的特征。
939
940
941 表4.1 能力代码和简介
942
943 |能力代码|能力类型（活动和技能）
944 |L|**领导者 **决策，委派，监督其他活动，提供激励和动机以及评估结果
945 |A|**管理员 **分配任务并确定优先级，保留记录，进行中的报告并启动基本改进
946 |C|**协调员/沟通者 **协调多方，维护利益相关者之间的沟通，并开展宣传活动
947 |M|**方法和技术专家 **设计和实施工作技术，记录程序，咨询流程，工作分析和持续改进
948 |T|**技术专家 **提供技术（IT）专业知识并实施基于专业知识的任务
949
950
951
952 表4.2 中列出了服务连续性管理实践涉及的角色示例，以及相关的能力简介和特定技能。
953
954 |流程活动|(% colspan="2" %)负责角色|(% colspan="2" %)能力类型|具体技能
955 |(% colspan="6" %)服务连续性管理流程的治理
956 |范围的定义|(% colspan="2" %)指导委员会|(% colspan="2" %)MC|对各种影响组织的PESTLE因素的能见度
957 |策略设置|(% colspan="2" %)指导委员会|(% colspan="2" %)MCL|(((
958 意识到组织特定的文档要求
959
960 确保管理人员的持续参与，以确保服务连续性策略的清晰性和持续实现
961 )))
962 |认知和演练方案开发|(% colspan="2" %)连续性管理员|(% colspan="2" %)ACM|(((
963 演练类型和恢复团队结构的知识
964
965 启用沟通渠道
966 )))
967 |(% colspan="6" %)业务影响分析流程
968 |VBF识别|(% colspan="2" %)(((
969 服务或产品所有者
970
971 关系经理
972
973 服务设计者
974
975 客户
976 )))|(% colspan="2" %)CM|(((
977 业务分析
978
979 很好的了解服务消费者的业务
980
981 熟悉产品，包括其架构和配置
982 )))
983 |中断后果分析|(% colspan="2" %)(((
984 服务或产品所有者
985
986 关系经理
987
988 客户
989 )))|(% colspan="2" %)MC|(((
990 能够系统地应用定性和定量风险分析工具
991
992 专业能力和对影响服务的PESTLE因素的能见度
993 )))
994 |VBF相互依赖关系识别|(% colspan="2" %)(((
995 服务或产品所有者
996
997 服务设计者
998
999 技术专家
1000
1001 架构管理专家
1002 )))|(% colspan="2" %)MT|熟悉产品，包括其架构和配置
1003 |服务连续性要求的确定|(% colspan="2" %)(((
1004 服务或产品所有者
1005
1006 连续性管理员
1007 )))|(% colspan="2" %)MTC|(((
1008 对恢复流程的深入了解
1009
1010 了解服务的连续性策略
1011 )))
1012 |(% colspan="6" %)制定和维护服务连续性计划流程
1013 |服务连续性策略开发|(% colspan="2" %)(((
1014 连续性管理员
1015
1016 服务设计者
1017
1018 技术专家
1019 )))|(% colspan="2" %)TM|(((
1020 对服务连续性选项有很好的了解
1021
1022 认知现有控件
1023
1024 认知市场上可用的技术
1025 )))
1026 |服务连续性计划开发|(% colspan="2" %)(((
1027 连续性管理员
1028
1029 技术专家
1030 )))|(% colspan="2" %)MTA|(((
1031 优秀的文档编制能力
1032
1033 优秀的逻辑能力
1034
1035 很好地了解服务组件的相互依赖关系
1036
1037 对技术有很好的了解
1038 )))
1039 |服务连续性计划的初始测试|(% colspan="2" %)(((
1040 连续性管理员
1041
1042 响应和恢复协调员及团队成员
1043 )))|(% colspan="2" %)CATL|(((
1044 协调与沟通
1045
1046 对服务连续性计划有深入的了解
1047
1048 了解作为服务连续性策略组成部分的技术
1049 )))
1050 |(% colspan="6" %)测试服务连续性计划流程
1051 |(% colspan="2" %)进行演练|(((
1052 连续性管理员
1053
1054 响应和恢复协调员及团队成员
1055 )))|CATL|(% colspan="2" %)(((
1056 协调与沟通
1057
1058 对服务连续性计划有深入的了解
1059
1060 了解作为服务连续性策略组成部分的技术
1061 )))
1062 |(% colspan="2" %)服务连续性审计|内部或外部审计师（根据授权并代表董事会）|CAMT|(% colspan="2" %)(((
1063 审计管理技术
1064
1065 常见的审计实践命令
1066
1067 确保审核员公正性，客观性和独立性
1068 )))
1069 |(% colspan="6" %)响应和恢复流程
1070 |(% colspan="2" %)调用|危机管理组|LC|(% colspan="2" %)(((
1071 对服务提供者和消费者风险有深入的了解
1072
1073 了解对消费者的背景
1074
1075 协调与沟通
1076 )))
1077 |(% colspan="2" %)执行服务连续性计划|(((
1078 危机管理组
1079
1080 连续性管理员
1081
1082 响应和恢复协调员及团队成员
1083 )))|CATL|(% colspan="2" %)(((
1084 协调与沟通
1085
1086 对服务连续性计划有深入的了解
1087
1088 了解作为服务连续性策略组成部分的技术
1089 )))
1090
1091 表4.2 负责服务连续性管理活动的角色示例
1092
1093
1094
1095 == **4.2  组织结构和团队** ==
1096
1097 灾难是影响重大的事件，因此响应必须非常快。协调响应和恢复活动需要灵活性。因此，常规业务的组织结构与灾难无关。
1098
1099 在恢复过程中，组织结构通常基于连续性计划的级别。表4.3概述了用于响应和恢复的组织结构级别。
1100
1101 |连续性计划的层次|(% style="width:77px" %)组织层次|(% style="width:602px" %)描述
1102 |战略|(% style="width:77px" %)行政级别|(% style="width:602px" %)这包括高级管理/主管人员，他们具有组织内的总体权限和控制，并负责危机管理，联络其他部门，事业部，组织，媒体，监管机构，紧急服务等。
1103 |战术|(% style="width:77px" %)协调级别|(% style="width:602px" %)通常，该级别比主管组低一级，该组负责协调组织内的整体恢复工作。
1104 |运行|(% style="width:77px" %)专家级|(% style="width:602px" %)一系列服务恢复团队，负责在各自区域内执行计划并与员工，客户和第三方保持联系。在IT内部，恢复团队应按服务和产品分组。
1105
1106 表4.3 用于响应和恢复的组织结构
1107
1108
1109
1110 ----
1111
1112 = **5  信息和技术** =
1113
1114
1115 == **5.1  信息交换，输入/输出** ==
1116
1117 服务连续性管理实践的效果基于所使用信息的质量。该信息可以包括：
1118
1119 * 消费者的业务流程
1120 * 服务及其架构和设计
1121 * 合作伙伴和供应商及其提供的服务信息
1122 * 有关服务连续性的法规要求
1123 * 与服务连续性安排有关的市场上可用的技术和服务
1124
1125 实践的关键输入和输出在第3节中列出。
1126
1127 服务连续性计划是该实践的核心。它们应该是最新的，并可供所有相关方使用。
1128
1129
1130 == **5.2 自动化和工具** ==
1131
1132 尤其是在大型组织中，服务连续性实践应该是自动化的。在可行且有效的地方，可能涉及表5.1中概述的解决方案。
1133
1134 |(% style="width:89px" %)流程活动|(% colspan="4" style="width:293px" %)自动化手段|(% colspan="3" style="width:442px" %)关键功能|(% colspan="3" style="width:132px" %)对实践有效性的影响
1135 |(% colspan="11" %)服务连续性管理流程的治理
1136 |(% style="width:89px" %)(((
1137 范围的定义
1138
1139 策略设置
1140 )))|(% colspan="4" style="width:293px" %)知识管理工具和文档存储库|(% colspan="3" style="width:442px" %)服务提供者的员工，监管机构和外部利益相关者（例如客户代表）必须容易访问服务的连续性策略，包括方案的范围，指南，角色和职责。|(% colspan="3" style="width:132px" %)低
1141 |(% style="width:89px" %)认知和演练方案开发|(% colspan="4" style="width:293px" %)业务连续性计划工具|(% colspan="3" style="width:442px" %)服务连续性管理员，服务所有者和恢复团队成员们应有权访问演练时间表，以及他们参与的演练范围的信息。|(% colspan="3" style="width:132px" %)中
1142 |(% colspan="11" %)业务影响分析流程
1143 |(% colspan="3" style="width:105px" %)VBF识别|(% colspan="3" style="width:164px" %)服务目录，CMDB，BPM工具|(% colspan="3" style="width:470px" %)为了识别VBF，服务分析人员应有权访问有关服务组件和操作的信息。BPM工具可以提供消费者的流程以及服务支持的操作的有关信息|(% colspan="2" %)高
1144 |(% colspan="3" style="width:105px" %)中断后果分析|(% colspan="3" style="width:164px" %)(((
1145 业务连续性计划工具
1146
1147 分析工具，
1148
1149 风险评估工具，事件管理工具
1150 )))|(% colspan="3" style="width:470px" %)各种管理系统数据都可以支持分析，例如事件报告和有关已经意识到的风险的信息。在服务或特定的VBF中断的情况下，分析师还可以使用建模工具预测预期的损失。|(% colspan="2" %)高
1151 |(% colspan="3" style="width:105px" %)(((
1152 VBF
1153
1154 相互依赖关系识别
1155 )))|(% colspan="3" style="width:164px" %)业务连续性计划工具，CMDB，分析工具|(% colspan="3" style="width:470px" %)分析师可以使用服务和配置模型来识别关键的服务和VBF相互依赖关系。|(% colspan="2" %)高
1156 |(% colspan="3" style="width:105px" %)服务连续性要求的确定|(% colspan="3" style="width:164px" %)业务连续性计划工具，服务目录|(% colspan="3" style="width:470px" %)连续性管理员，服务所有者和恢复团队成员应有权访问服务的连续性要求。|(% colspan="2" %)低
1157 |(% colspan="11" %)开发和维护服务连续性计划流程
1158 |(% colspan="3" style="width:105px" %)服务连续性策略开发|(% colspan="3" style="width:164px" %)业务连续性计划工具，CMDB，变更初始化和控制工具|(% colspan="3" style="width:470px" %)(((
1159 确定现有控件和弹性措施
1160
1161 发起应作为服务连续性策略实现的一部分实施的变更
1162 )))|(% colspan="2" %)中
1163 |(% colspan="3" style="width:105px" %)服务连续性计划开发|(% colspan="3" style="width:164px" %)业务连续性计划工具，文档控制工具|(% colspan="3" style="width:470px" %)失效日期控制，版本控制和文档的归档|(% colspan="2" %)从低到高，取决于要管理的文档量
1164 |(% colspan="2" style="width:138px" %)服务连续性计划的初始测试|(% colspan="9" style="width:877px" %)参见“进行演练”
1165 |(% colspan="11" %)测试服务连续性计划流程
1166 |(% colspan="4" %)进行演练|(% colspan="3" %)会议工具，监控工具，技术管理和系统管理工具|(% colspan="3" %)所有相关方应该能够进行沟通和协作，持续了解当前状况并管理服务组件，以执行服务连续性计划。|高
1167 |(% colspan="4" %)服务连续性审计|(% colspan="3" %)知识管理工具和文档存储库|(% colspan="3" %)审核员应该可以访问服务连续性文档资料，包括计划，练习程序，练习报告和恢复报告。|中
1168 |(% colspan="11" %)响应和恢复流程
1169 |(% colspan="4" %)启用|(% colspan="3" %)监控工具，紧急通知，会议工具，事件管理工具|(% colspan="3" %)危机管理组必须能够获得有关事态的信息，并立即直接响应和恢复流程。|高
1170 |(% colspan="4" %)执行服务连续性计划|(% colspan="3" %)会议工具，紧急管理工具，监控工具，技术管理和系统管理工具，事件管理工具|(% colspan="3" %)所有相关方应能够进行沟通和协作，对当前情况有持续的了解，并管理服务组件，以执行服务连续性计划|高
1171
1172 表5.1 服务连续性管理活动的自动化解决方案
1173
1174
1175
1176 ----
1177
1178 = **6  合作伙伴和供应商** =
1179
1180 很少有服务仅使用组织自己的资源来交付的。大多数（如果不是全部）依赖于其他服务，这些服务通常由组织之外的第三方提供（请参阅ITIL Foundation的2.4节：ITIL 4 Edition 服务关系模型）。在服务设计，架构管理和供应商管理的实践指南中描述了由支持服务引入的关系和依赖。
1181
1182 合作伙伴和供应商可以提供关键产品和服务组件。服务提供者需要与合作伙伴和供应商协商，并就服务的连续性要求达成一致，以便满足服务的连续性要求。
1183
1184 合作伙伴和供应商也可以提供连续性服务和解决方案，例如备份站点，按需计算，灾难恢复的服务等。在这些情况下，它们也应参与服务连续性计划的开发，测试和执行。
1185
1186
1187
1188 ----
1189
1190 = **7  重要提醒** =
1191
1192 该实践指南的大部分内容都应作为组织在建立和培养自己的实践时可能考虑的领域的建议。实践指南是组织可能考虑的主题目录，而不是答案列表。使用实践指南的内容时，组织应始终遵循ITIL 指导原则：
1193
1194 * 聚焦价值
1195 * 此时此刻
1196 * 基于反馈迭代推进
1197 * 协作和提升可视化程度
1198 * 通盘思考和工作
1199 * 保持简单实用
1200 * 优化和自动化
1201
1202 有关指导原则及其应用的更多信息，请参见ITIL ® Foundation: ITIL 4 Edition的第4.3节。
1203
1204
1205
1206 ----
1207
1208 = **8  致谢** =
1209
1210 AXELOS有限公司非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
1211
1212
1213 == **8.1  作者** ==
1214
1215 Pavel Demin
1216
1217
1218 == **8.2 审稿人** ==
1219
1220 ​
1221
1222 (% class="row" %)
1223 (((
1224 (% class="col-xs-12 col-sm-4" %)
1225 (((
1226
1227 )))
1228 )))
深圳市艾拓先锋企业管理咨询有限公司