Version 5.1 by superadmin on 2021/12/16, 19:50
Show last authors
1 **申明：**
2
3 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众
4 多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信
5 公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
6
7
8 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
9
10
11 本文档翻译工作参与人员：
12
13 翻译：张泽翰
14
15 审校：陈一梦
16
17
18 项目总负责：长河
19
20 审核：王庆
21
22 统筹：常宏
23
24
25
26 ----
27 {{box cssClass="floatinginfobox" title="**Contents**"}}
28 {{toc/}}
29 {{/box}}
30 = **1 关于本文档** =
31
32 本文档为可用性管理实践提供了实用指南。它分为五个主要部分，内容包括：
33
34 * 有关实践的一般信息
35 * 实践的流程和活动以及它们在服务价值链中的作用
36 * 实践中涉及的组织和人员
37 * 支持实践的信息和技术
38 * 实践中关于合作伙伴和供应商的注意事项。
39
40
41 == **1.1 ITIL 4资格认证计划** ==
42
43 本文的选定内容可以作为下列教学大纲的一部分加以考察：
44
45 * ITIL专家 - 高速IT
46
47 有关详细信息，请参考相应的教学大纲文档。
48
49
50
51 ----
52
53 = **2 一般信息** =
54
55
56 == **2.1目的和描述** ==
57
58 **​​​​​​​关键信息**
59
60 **可用性管理实践的目的是为了确保服务达到约定的可用性级别，以满足客户和用户的需求。**
61
62 可用性管理实践确保了服务和资源的可用性需求得到有效的理解和满足，并符合组织的战略和承诺。为了实现这一点，此实践应贯穿于组织产品从构思到运营的整个服务生命周期。
63
64 在产品的计划和设计过程中，此实践极为重要。在此阶段做出的决定将影响可用性的级别和相关约束，以及组织监控和管理等方面的能力。
65
66 从消费者的角度来看，可用性是服务的重要特性，因此它受到谈判、协议、监控和报告的制约。这些活动涉及多种实践（包括业务分析，关系管理，服务设计，服务级别管理（SLM）以及度量和报告实践等），当可用性管理实践与这些实践结合使用，可以确保可用性得到充分、一致的解决。
67
68 **​​​​​​​​​​​​​​定义**
69
70 **可用性：IT服务或其它配置项在需要时执行其约定功能的能力。**
71
72 从理论上讲，可用性易于度量和理解。这取决于服务发生故障的频率，以及故障恢复的速度。这些特性通常表示为平均故障间隔时间（MTBF）和平均恢复服务时间（MTRS）：
73
74 * MTBF 度量服务发生故障的频率。例如，平均而言，MTBF为4周的服务每年会发生13次故障。
75 * MTRS 度量故障后服务恢复的速度。例如，平均而言，MTRS为四个小时的服务将在四个小时内从故障完全恢复。
76
77 在实践中，可用性是一个复杂的特性。要被度量和理解，多次度量和通过服务上下文中理解这些度量的协议是必需的。可用性取决于服务体系结构、服务组件或服务操作的重要性、不可用性标准、服务时间以及其他参数。
78
79 从单个用户或群体用户的角度来看，用户理解的可用性可能与提供者或客户角度衡量的可用性不同。例如，在有200个用户的组中，有5个用户无法使用某个服务。这将被五个用户视为中断，但仍可以满足该组其它用户约定的可用性目标。
80
81 可用性管理实践应确保所有相关方对可用性（预期的、约定的、计划的和实际的）的理解透明、一致、实际。
82
83 当服务提供给数千甚至数百万人时，通常不会与客户签订单个通用可用性协议，但总体服务可用性对服务提供者来说是至关重要。这种服务通常是为高可用性设计的，其中可靠性（高MTBF）与快速恢复（短MTRS）保持平衡。
84
85 可用性与服务性能、容量、连续性和信息安全密切相关。ITIL 管理实践指南在论述这些领域时通常涉及配置项和服务的相同特征，但着重于质量的不同方面。这些实践可以从共享所有服务管理四维模型的资源中受益匪浅；但是，在某些情况下，尤其是在服务连续性和信息安全等严格监管的领域中，需要明确区分责任。
86
87
88 == **2.2术语和概念** ==
89
90 服务可用性是业务成功的关键，服务可用性与客户和用户满意度直接相关。然而，当服务失败时，也是有可能达到客户满意的。服务提供者在故障情况下的反应方式对客户感知有很大的影响。
91
92 如果不了解服务如何支持使用者，就很难提高可用性。
93
94
95 === **2.2.1关键业务功能** ===
96
97 ··························关键业务功能（VBF）是一个术语，用于反映服务中对组织的成功至关重要的部分。服务还可能支持许多不是至关重要的业务功能。
98
99 例如，电子邮件服务的VBF是发送和接收电子邮件，并访问已归档的消息。访问日历的能力可能不是至关重要的。
100
101 关键功能和非关键功能之间的区别非常重要，它将会影响可用性设计和相关成本。通常，业务功能越重要，它就需要越有弹性和可用性。
102
103
104 === **2.2.2 不同类型服务的可用性** ===
105
106 对于不同类型的服务产品，可以定义不同的可用性。例如，如果服务提供：
107
108 * 保障业务运营（例如贷款审批流程或财务报告流程），可用性通常是根据业务操作的执行情况来定义的。
109 * 提供对资源的访问（例如网络，打印或电子邮件服务），可用性是根据资源的可用性来定义和度量的。
110 * 各种执行类操作（例如用户支持），可用性通常不是适用的措施。相反，重点应该放在及时完成请求上。
111
112
113 === **2.2.3 可用性标准** ===
114
115 定义服务的可用性需求通常很复杂。一个服务可能有多个功能和客户，每个客户可能对每个功能有不同的可用性需求。
116
117 通常，对于非功能性需求，性能低下(服务缓慢、不安全、不兼容，等等)和不可用性之间的界限很难确定。
118
119 在定义服务可用性时，必须考虑以下几点：
120
121 * 服务保障业务功能可用的临界状态
122 * 各种形式的性能不佳和不可用的阈值；例如，在达到约定的阈值之前，发送或接收电子邮件的延迟可以视为服务级别降级，而不是服务不可用
123 * 受影响的用户、业务单元或网站的数量；例如，只有在超过一定比例的用户受到影响时，才会认为该服务不可用
124 * 某些重要用户、业务单元、网站等是否受到影响；例如，对于电子邮件服务，如果需要直接与客户和合作伙伴通信的用户能够使用服务，则认为服务可用
125 * 服务的交付时间表和高峰时间：仅在夜间或周末出现中断的服务可能不会被视为不可用。
126
127 这些因素反映了服务提供者和客户如何定义不可用性。在服务级别协议中记录约定的服务可用性标准是一种好的做法。
128
129
130 === **2.2.4可用性指标** ===
131
132 可用性是服务质量的最重要指标之一，因此服务提供者必须能够度量、评估和报告可用性。普遍接受的做法是报告可用性的百分比，可用一个简单的公式计算:
133
134 可用性= (约定的服务时间-停机时间) / 约定的服务时间
135
136 该公式可能很有用，特别是对于资源提供服务，但它不能反映复杂的服务中断场景对业务的影响。
137
138 理想的可用性指标是度量（由于服务不可用而造成的财务）损失。不幸的是，通常很难或不可能度量或估计这样的指标。因此，服务提供者和客户应该定义一组可接受的度量标准，以反映客户如何因服务中断而损失财物，即使这些度量标准可能不太准确。
139
140 应考虑以下因素：
141
142 累计服务中断时间越长，损失越大。
143
144 单次服务中断时间越长，损失越大。在大多数情况下，停机期间的经济损失成倍增长。服务提供者可能会面临罚款、监管惩罚、竞争优势减弱、声誉受损等问题。
145
146 故障越频繁，损失就越大，因为管理损失事件和重新启动业务运营相关的费用很高。
147
148 可用性可以通过各种方式进行测量，评估和报告。这些包括但不限于以下指标：
149
150 * 平均故障时间
151 * 两次故障之间的最短时间
152 * 服务中断次数
153 * 周期内总计停机时间
154 * 最大单次中断时长
155 * 平均修复时间
156
157 在定义度量可用性的指标时，反映服务中断的业务影响而不是服务组件的技术可用性是至关重要的。
158
159
160 === **2.2.5可用性度量** ===
161
162 可用性度量基于精确跟踪的停机时间。因此，可用性管理实践最重要的目标之一是设计和管理可用性监视工具，并将结果数据转换为有意义的服务可用性信息。
163
164 事件管理记录是服务中断数据的一个来源。然而，基于事件日志的可用性数据通常不可靠，并且很难与约定的服务可用性指标相一致。
165
166 基础设施监控工具是可用性数据的常见来源。然而，尽管来自这些工具的信息在度量资源提供服务的可用性时很有用，但是在度量支持业务运营服务的可用性时就不那么有用了。诸如真实用户监控和业务交易监控之类的工具对这些服务更有用。
167
168 表2.1进一步概述了可用性度量方法。
169
170 **表2.1 可用性度量方法**
171
172
173 |可用性度量方法|描述
174 |事件记录|(((
175 事件记录通常包含识别和解决事件时的时间戳，以便可以计算中断时间。但是，此方法有局限性，例如：
176
177 * 事件可能无法在服务不可用的同时被识别和记录。
178 * 在恢复服务可用性的同时，可能无法解决该事件，也可能无法记录其解决情况。
179 * 并非所有事件都是可用性事件（有关可用性标准的详细信息，请参见第2.2.3节）。
180 * 应将相关的事件记录进行关联，并考虑到事件随时间的可能重叠，以便准确估计停机时间。
181
182 在小规模的服务提供者中，这种度量可用性的方法可能效果很好，但是在大规模的组织中，由于服务和事件的数量较多，这种方法就不那么有用了。
183 )))
184 |IT基础设施监控|(((
185 基础设施监控工具也是可用性数据的来源。然而，这些工具度量的是CI可用性，而不是服务可用性。服务和配置模型可用于理解基于组件可用性数据的服务可用性。
186
187 然而，这种方法也有它的局限性：
188
189 * 服务组件中断可能不会导致服务中断。
190 * 服务的不可用可能是由于组件的性能不佳以及故障造成的。
191 * 可以通过开发服务健康模型来克服这些问题; 服务健康模型是确定一个组件的性能不佳或中断如何影响服务模型中的其他组件的模型。
192 * 开发服务健康状况模型是一项耗时的工作，在大多数情况下，由于IT基础设施的变化很快，因此这并不是最佳的一种方式。
193 )))
194 |业务交易监控/真实用户监控|(((
195 业务交易监视是从业务操作/交易的角度度量IT服务的可用性和性能的一种方法。为此，可以使用多种数据的收集方法，包括网络包嗅探、日志解析、基于代理的中间件协议嗅探、读取数据库记录等。
196
197 业务交易监控的两种特定方法是：
198
199 * 综合监控是一种通过模拟用户活动来监控应用程序的方法。综合监控来自机器人客户机的模拟交易，这些事务模拟典型的用户操作。
200 * 实际用户监控（RUM）RUM可以捕获服务器端数据，以重建终端用户体验，或者直接监控用户与应用程序的交互，以及用户在使用服务时的体验。
201 )))
202
203
204
205 == **2.3 适用范围** ==
206
207 可用性管理实践确保服务交付约定的可用性级别，以满足客户和用户的成本效益需求。为了实现这一点，实践包括可用性的定义、度量、分析和改进，并为可用性事件提供一个知识库，以支持其他服务管理实践。
208
209 可用性管理实践的适用范围非常广泛。几乎每一个ITIL实践都直接或间接地对服务可用性做出了贡献。表2.2中列出了与可用性管理实践密切相关的其他实践的活动。重要的是要记住，ITIL实践只是在价值流环境中的一个工具的集合；根据情况，应将它们结合起来使用。
210
211 **表2.2与其他实践指南中描述的可用性管理实践相关的活动**
212
213 (% style="width:608px" %)
214 |(% style="width:389px" %)**活动**|(% style="width:217px" %)**实践指南**
215 |(% style="width:389px" %)协商并同意客户的可用性要求|(% style="width:217px" %)SLM
216 |(% style="width:389px" %)将可用性控件设计为服务模型的一部分|(% style="width:217px" %)服务设计
217 |(% style="width:389px" %)将可用性控件与业务体系结构保持一致|(% style="width:217px" %)架构管理
218 |(% style="width:389px" %)识别与可用性相关的风险|(% style="width:217px" %)风险管理
219 |(% style="width:389px" %)分析变更对可用性目标的影响|(% style="width:217px" %)变更支持
220 |(% style="width:389px" %)监控服务的可用性|(% style="width:217px" %)监控和事态管理
221 |(% style="width:389px" %)验证新的可用性控件|(% style="width:217px" %)组合管理
222 |(% style="width:389px" %)(((
223 实施风险缓解措施
224
225 变更IT基础设施以提高可用性
226 )))|(% style="width:217px" %)项目管理、变更支持
227 |(% style="width:389px" %)在服务转换期间测试可用性控件|(% style="width:217px" %)服务验证和测试
228 |(% style="width:389px" %)(((
229 对可能影响组织达到可用性目标能力的事件做出反应
230
231 管理可用性事件
232 )))|(% style="width:217px" %)事件管理、监控和事态管理
233 |(% style="width:389px" %)持续管理和实施改进|(% style="width:217px" %)持续改进
234
235
236 === **2.3.1可用性与连续性之间的界线** ===
237
238 服务连续性和可用性管理之间的界限很细微。这两种做法都涉及对可能导致服务失效的事件的风险、识别和准备的概念。在这两种情况下，都需要了解VBFs、风险评估和服务故障的业务影响分析（BIA）。最终，这两种实践都确保了组织的抗故障能力。
239
240 一些组织更倾向于不区分可用性和连续性管理。但是，两者之间还是存在些差异，如表2.3所示。
241
242 **表2.3 可用性管理和服务连续性管理之间的区别**
243
244 |**可用性管理**|**服务连续性管理**
245 |专注于高概率风险|重点关注高影响的风险（突发事件，灾难）
246 |更主动|更被动
247 |减少不必要事件的可能性|减少不必要事件的影响
248 |专注于技术解决方案|注重组织措施
249 |专注于优化|专注于创建冗余
250 |不是公司职能的一部分|通常是公司职能的一部分
251 |常态|不可抗力
252 |MTRS、MTBF、平均服务事件时间|恢复时间目标、恢复点目标
253
254 服务连续性管理实践对轻度或对组织没有严重影响的短期故障不感兴趣。它关注与重大损害相关的风险，而不考虑其发生的可能性。这些通常是紧急情况；火灾、洪水、停电、数据中心或站点故障等灾难。尽管可用性管理实践没有忽略故障对服务提供者和使用者的负面影响，但是在此过程中也会考虑单个组件的轻微中断。
255
256 可用性规划专注于满足当前和未来已约定的客户要求，并避免出现偏差。可用性管理实践通常是通过实现主动的对策和减少不需要的事件的可能性来发现和消除单点故障。服务连续性管理实践侧重于计划管理破坏性事件的严重后果。服务连续性管理活动通常不会影响事件发生的概率。
257
258 可用性管理实践的目的是：通过合理的成本确保所提供服务的可用性，以满足客户当前和将来已约定的需求。通过优化，从业人员试图利用可用资源来达到最大程度的可用性。连续性管理活动几乎总是在发生紧急情况时创建冗余（例如备份站点，更换设备资金，外部协议等）。这两种做法的目标之间存在着矛盾。
259
260 最后，可用性管理实践使用统计数据并分析趋势，而连续性管理实践关注的是如何响应破坏性事件。
261
262
263
264 === **2.3.2可用性管理在服务风险管理中的作用** ===
265
266 风险的概念是可用性管理实践的核心。为了达到服务可用性目标，实践需要关于风险的信息，这些信息可以由风险管理实践提供。
267
268 因此，有效的可用性管理实践可以为风险管理做出重要贡献。大部分风险缓解措施在某种程度上与可用性控件相关。
269
270 可用性管理通常侧重于在成本允许的范围内识别和消除单点故障或不可靠或脆弱的组件。（详细信息见2.4.3）。
271
272
273
274 == **2.4实践成功因素** ==
275
276 **​​​​​​​​​​​​​​定义**
277
278 实践成功因素：实践的复杂功能型组件，是实践实现其目的所必需的。
279
280 实践的成功因素（PSF）不仅仅是一项任务或活动，因为它包括所有服务管理四维模型的组件。活动的性质和实践中PSF的资源可能有所不同，但它们共同确保实践有效。
281
282 可用性管理实践包含以下PSF：
283
284 * 识别服务可用性需求
285 * 度量、评估和报告服务可用性
286 * 处理服务可用性风险。
287
288
289 === **2.4.1确认服务可用性需求** ===
290
291 为了有效管理可用性，服务提供者应该识别服务可用性的需求。这些需求应反映服务客户可能如何受到服务中断的影响。
292
293 确认服务的可用性需求可能是单独的实现价值，但它通常是SLM实践中服务级别协商的一部分，或者与服务连续性管理实践共同执行的更广泛的BIA。
294
295 确认服务可用性的需求包括：
296
297 * 了解客户对服务可用性的需求
298 * 确定可用性标准
299 * 确定可用性指标并设置目标
300
301
302 ==== **2.4.1.1了解客户对服务可用性的需求** ====
303
304 业务分析和SLM实践通常涉及与客户进行沟通，以了解他们对IT服务的可用性需求，并协商服务级别需求。可用性管理实践为SLM、业务分析、服务设计实践提供了重要的支持和输入。可用性要求总是需要平衡成本和质量之间的关系；可用性管理实践可以在优化服务的可用性，满足不断增长的可用性需求，延迟成本增长这三方面发挥关键作用。
305
306
307 ==== **2.4.1.2确定可用性标准** ====
308
309 可用性和不可用性之间的界限应明确定义。确定服务可用性标准时应考虑以下因素：
310
311 * 服务支持的业务功能可用的临界状态
312 * 性能不佳和完全不可用的阈值（可能存在可接受的延迟，不应将其视为服务不可用）
313 * 规模因素（用户数量，业务单元，受影响的站点）
314 * 必然会被影响到的用户，业务单元，站点等
315 * 服务的交付时间表和高峰时间。
316
317 更多细节见第2.2.3节
318
319
320 ==== **2.4.1.3确定可用性指标并设置目标** ====
321
322 可用性是最关键的服务质量指标，因为服务客户通常会因为服务中断而蒙受损失。可用性指标和目标应该准确地反映消费者如何受到服务不可用性的影响(有关详细信息，请参阅第2.2.4节)。
323
324
325 === **2.4.2测量、评估和报告服务可用性** ===
326
327 服务提供者必须能够正确地测量，评估和报告可用性。以百分比报告可用性是一种被广泛接受的实践，可以基于正常运行时间和停机时间的简单公式计算可用性。尽管它适用于许多情况(特别是资源提供服务)，但是这种方法缺乏对复杂服务中断场景的业务影响的可见性。
328
329 重要的是要考虑各种度量、评估和报告可用性的方法，包括但不限于以下度量（请参阅2.2.4 有关详细信息）：
330
331 * 平均故障时间
332 * 最短故障时间
333 * 服务中断次数
334 * 服务周期内总计停机时间
335 * 最大单次中断时间
336 * 平均恢复时间
337
338 无论哪种度量标准都适合服务，重要的是要反映服务中断的业务影响，而不是服务组件的技术可用性。
339
340 可用性管理实践的最重要目标之一是设计并确保有充分的可用性监控。然后，将监控数据转换为有意义的服务可用性信息。
341
342 事件记录是服务中断数据的一个直接来源。但是，通常很难基于事件记录获得可靠的可用性数据，尤其是对于用户报告的事件。数据也很难与商定的服务可用性指标进行匹配。
343
344 基础设施监控工具是更可靠的可用性数据来源。然而，尽管它们可以很好地度量资源提供类服务，但是很难度量基于基础架构监控数据正确支持业务运营的服务的可用性。诸如真实的用户监控，业务交易监控之类的工具可以对此提供帮助（请参阅第2.2.5节）。
345
346
347 === **2.4.3服务可用性风险处理** ===
348
349 可用性管理实践不仅与规划和监控有关，该实践还包含控件的定义和管理，以管理可能对影响服务可用性造成的一系列风险。为此，它与风险管理实践和其他关注风险的实践（包括服务连续性管理、容量和性能管理以及信息安全管理实践）结合使用。有效的可用性管理实践可以为风险管理做出重大贡献.
350
351 表2.4中概述的措施可以作为整体风险缓解计划的一部分来设计和实施。
352
353 **表2.4 可用性管理的四个维度**
354
355 |**服务管理维度**|**可用性风险对策**
356 |组织和人员|通过培训提高人们的能力
357 |信息和技术|(((
358 利用容灾技术避免计划内或计划外组件停机对服务可用性的影响
359
360 提供冗余机制或提供备用IT基础设施组件，以允许一个组件接管另一个组件的工作
361
362 通过优化测试方法来改进组件可靠性
363
364 改进软件设计和开发过程
365
366 引入弹性通讯网络
367
368 运维中的数据保护：局域网服务器的RAID阵列和磁盘镜像可以避免数据丢失以确保数据的可用性持续有效
369
370 监控（提供提示告警）
371 )))
372 |合作伙伴和供应商|改进外部提供的服务，合同或协议
373 |价值流和流程|(((
374 改进事件管理
375
376 改进测试
377 )))
378
379 选择可用性控件时应评估每个选件的效果和效率。持续控制和验证可用性部署的效果和效率也很重要。
380
381 * **效果**：根据风险管理原则，应评估可用性控件的效果，并将其与事件造成的预期损失进行比较。
382 * **效率**：还应评估可用性控件的成本，并将其与效益进行比较。效益是通过估计控制实施后事件降低的可能性，然后乘以事件发生后可能产生的影响的严重程度来计算的。应将价值的成本与实施该措施的成本进行比较（此处可以使用成本效益分析）。
383
384 从一开始就将正确的服务可用性级别设计到服务中，而不是试错后添加服务，这样做的成本通常较低。而且，一旦服务被大家认为是不可靠的，重新获得大家的认可则变得非常困难。
385
386 以下是FAIR3提出的损失形式，在评估服务可用性风险时可能很有用：
387
388 * **生产力：**服务提供者提供服务能力的降低
389 * **响应：**与管理损失事件相关的费用
390 * **替换：**资产的固有价值，或者与替换被丢失或被损坏的资产相关的费用(例如购买替换服务器)
391 * **SLA：**罚款和监管判罚 对服务提供者采取的法律或监管措施
392 * **竞争优势：**与竞争优势减弱相关的损失
393 * **声誉：**与服务提供者的外部评价相关的损失。
394
395 了解影响如何随时间变化也很重要。服务中断造成的损失往往随时间呈指数增长。随着组织产生其主要价值主张的能力下降而造成的损失，声誉风险和财务制裁的威胁也随之产生。
396
397 商定的可用性控制是通过服务设计、软件开发和管理以及基础设施和平台管理实践来实现的。
398
399
400 == **2.5关键指标** ==
401
402 ITIL实践的有效性和性能应该在每个实践所贡献的价值流背景中进行评估。与任何工具的效果一样，实践的效果只能在其应用的范围内进行评估。然而，工具在设计和质量上可能有很大的差异，这些差异定义了工具的潜力或能力，当根据它们的目的使用时，它们是有效的。在度量和报告实践指南中可以找到关于度量、关键性能指标(KPI)和其他有助于实现这一点的工具的进一步指导。
403
404 可用性管理实践的关键指标已被映射到其PSF。它们可以用作价值流背景中的KPI，以评估实践对这些价值流的效果和效率的贡献。表2.5中给出了一些关键指标的示例。
405
406 **表2.5 实践成功因素的示例指标**
407
408 (% style="width:715px" %)
409 |(% style="width:289px" %)**实践成功因素**|(% style="width:424px" %)**关键指标**
410 |(% style="width:289px" %)识别服务可用性需求|(% style="width:424px" %)(((
411 产品和服务具有清晰的可用性标准的百分比
412
413 SLA中包含可用性需求的(关键的)产品和服务的百分比
414
415 在服务变更时及时更新服务可用性需求
416 )))
417 |(% style="width:289px" %)度量、评估和报告服务可用性|(% style="width:424px" %)(((
418 具有确定的可用性指标的产品和服务的百分比
419
420 可用性和性能或绩效监控涵盖的产品和服务的百分比
421
422 服务可用性报告中包含的产品和服务的百分比
423 )))
424 |(% style="width:289px" %)应对服务可用性风险|(% style="width:424px" %)(((
425 MTBF
426
427 两次故障之间的最短时间
428
429 服务中断次数
430
431 服务期内停机时间
432
433 最大服务中断时间
434
435 MTRS
436
437 有效可用性控件的百分比
438
439 实际损失与预期损失之间的比率
440 )))
441
442 将度量指标正确汇总到复杂的标准中，将使数据更易用于价值流的持续管理，以及用于可用性管理实践的定期评估和持续改进。没有单一的最佳解决方案。度量指标将基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。
443
444
445 = **3 价值流和流程** =
446
447
448 == **3.1 价值流贡献** ==
449
450 像任何其他ITIL 管理实践一样，可用性管理实践贡献了多个价值流。重要的是要记住，价值流绝不是由一个单独的实践形成的。可用性管理实践与其他实践相结合，可以为消费者提供高质量服务。可用性管理贡献的主要价值链活动有：
451
452 * 计划
453 * 交付和支持
454 * 设计和转换
455 * 获取或构建
456 * 改进
457
458 **图片3.1 可用性管理实践对价值链的贡献的热图活动**
459
460 (% style="text-align:center" %)
461 [[image:1639655058520-328.png]]
462
463
464 == **3.2 流程** ==
465
466 每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必需的。
467
468 ​​​​​​​**定义**
469
470 流程是将输入转换为输出的一组相互关联或相互作用的活动。流程接受一个或多个已定义的输入，并将其转换为已定义的输出。流程定义操作的顺序及其依赖项。
471
472 可用性管理活动包括两个流程：
473
474 * 建立服务可用性控制
475 * 分析和改进服务可用性
476
477
478 === **3.2.1建立服务可用性控制** ===
479
480 该流程包括表3.1中列出的活动，并将输入转换为输出。
481
482 **表3.1 建立服务可用性控制过程的输入、活动和输出**
483
484 |**关键输入**|**活动**|**关键输出**
485 |(((
486 客户需求
487
488 SLR草案
489
490 有关可用资源的信息
491 )))|(((
492 识别服务可用性需求
493
494 商定服务可用性需求
495
496 确定可用性需求指标
497
498 设计可用性指标和报告
499 )))|(((
500 约定的服务可用性的要求
501
502 可用性需求指标
503
504 可用性报告模板
505 )))
506
507 **图片3.2 建立服务可用性控制流程的工作流程**
508
509
510 (% style="text-align:center" %)
511 [[image:1639655132244-616.png]]
512
513
514 这些活动可以由组织中的许多人以不同层次的形式执行。表3.2进一步描述了这些活动。
515
516 **表3.2建立服务可用性控制流程的活动**
517
518 (% style="width:776px" %)
519 |(% style="width:154px" %)**活动**|(% style="width:620px" %)**描述**
520 |(% style="width:154px" %)识别服务可用性需求|(% style="width:620px" %)(((
521 组织可能具有SLR草案和服务可用性需求，但是它们很少以可度量和可管理的方式定义。客户根据他们的业务需求传达出对服务可用性的需求。
522
523 可用性管理实践应该与SLM 实践一起使用，以澄清服务可用性标准和可用性指标，这些标准和指标应该准确地反映服务中断对客户的影响(详细信息请参阅第2.2.3和2.4.1节)。
524
525 来自面向客户的团队或业务分析团队，或产品和服务负责人通常参与记录服务可用性需求。
526 )))
527 |(% style="width:154px" %)商定服务可用性要求|(% style="width:620px" %)(((
528 对可能需要的资源需求进行分析，以确定满足可用性需求是否可能且负担得起。主要输出是一个带有评估成本的报价和实现的时间表。
529
530 此分析应包括与服务提供者的供应商以及合作伙伴的协议，以确保他们将支持所需要的服务水平。
531 )))
532 |(% style="width:154px" %)确定可用性|(% style="width:620px" %)(((
533 为了分析、报告和改进服务可用性，服务提供者必须对其进行度量。
534
535 可用性监控方法应该基于服务可用性需求、报告策略、
536 )))
537 |(% style="width:154px" %)度量的需求|(% style="width:620px" %)(((
538 客户报告要求、服务客户报告需求、服务类型和可用的监控工具。
539
540 主要任务是定义如何跟踪服务中断
541 )))
542 |(% style="width:154px" %)(((
543 设计可用性指标
544
545 和报告
546 )))|(% style="width:620px" %)(((
547 度量指标应该基于服务可用性需求来确定。应该考虑以下可用性指标:
548
549 * 可用性百分比
550 * 平均故障时间
551 * 最短故障间隔
552 * 服务中断次数
553 * 总停机时长
554 * 最大停机时长
555 * 平均恢复时间
556
557 无论哪一组度量指标适合于服务，最重要的都是要反映服务中断的业务影响而不是服务组件的技术可用性(请参阅2.4.2了解详细信息)。
558
559 选择指标之后，应该设计一个报告或仪表盘模板来显示结果。
560 )))
561
562
563
564 === **3.2.2分析和改进服务可用性** ===
565
566 该流程包括表3.3中列出的活动，并将输入转换为输出。
567
568 **表3.3分析和改进服务可用性流程的输入、活动和输出**
569
570
571 (% style="width:747px" %)
572 |(% style="width:311px" %)**关键输入**|(% style="width:250px" %)**活动**|(% style="width:184px" %)**关键输出**
573 |(% style="width:311px" %)(((
574 监控数据
575
576 事件记录
577
578 服务模型
579
580 可用性报告模板
581
582 约定的服务可用性的要求
583
584 风险登记
585
586 服务规范
587 )))|(% style="width:250px" %)(((
588 服务可用性分析
589
590 报告服务可用性
591
592 规划和设计服务可用性
593 )))|(% style="width:184px" %)(((
594 服务可用性报告
595
596 问题记录
597
598 可用性管理计划
599
600 新增和更新的控件
601 )))
602
603 这些活动可能由组织中的许多人以不同层次的形式进行。
604
605 图片3.3显示了该流程的工作流程图。
606
607 **图片3.3分析和改进服务可用性流程的工作流程**
608
609
610 (% style="text-align:center" %)
611 [[image:1639655215428-788.png]]
612
613 表3.4进一步描述了这些活动。
614
615 **表3.4 分析和改进服务可用性过程的活动**
616
617 |**活动**|**描述**
618 |服务可用性分析|(((
619 必须确认服务可用性需求的实现。所有与预定义级别的偏差都必须接受调查，如果发现错误，必须采取纠正措施。
620
621 可用性管理实践使用监控数据（例如事件记录）作为服务可用性审查和分析的输入。这种分析可以在不同的层次上进行：
622
623 * 服务组件/ IT基础设施级别：由可用性经理、系统管理员和工程师执行
624 * 服务级别：由可用性经理，服务负责人和SLM 经理执行。
625
626 应该执行趋势分析来检测尚未引起事件的缺陷。问题或风险应该被记录下来。
627
628 因为业务需求和客户需求可能会发生变化，所以服务的可用性的级别可能需要修改。此类审查应成为SLM 实践的常规服务审查的一部分。还应定期考虑来自服务连续性管理实践的输入，特别是来自BIA和风险评估的输入。
629
630 不断地考虑优化IT基础设施和服务可用性的机会是很重要的。这种定期评审方法的好处是，可以以非常低的代价提高可用性水平。
631 )))
632 |报告服务可用性|(((
633 服务提供者生成报告或仪表盘，以展示服务可用性的成就。这些通过商定的渠道进行沟通。
634
635 通过SLM实践[[4>>path:#_bookmark8]]，服务可用性报告通常是总体服务质量报告的一部分。
636 )))
637 |规划和设计服务可用性|(((
638 服务提供者应该确定一组合适的，成本效益高的服务连续性策略。需要对那些较早产生和较大影响的流程和服务采取更多的预防措施。至于影响较低及需要较长时间开发的服务，应更重视恢复措施（请参阅[[2.4.3 >>path:#_bookmark4]]有关详细信息）。
639
640 可用性管理实践确保新的或更改的服务满足客户的可用性需求。这项工作包括为新的和变更的服务提出有关设计指南的建议、计划和文件。在某些情况下，可能会编制一个可用性计划，其中包括以下内容：
641
642 * 当前的可用性水平
643 * 关键服务组件
644 * 预期的客户需求变化
645 * 新需求的可用性影响
646 * 可用性控件的建议
647 )))
648
649
650
651
652 ----
653
654 = **4 组织和人员** =
655
656
657 == **4.1角色、能力和责任** ==
658
659 ITIL 实践指南没有描述实践管理的角色，例如实践负责人，实践领导或实践教练。相反，它们关注于特定于每个实践的专家角色。每个角色的构成和命名可能因组织而异，因此ITIL中定义的任何角色都不应视为强制性的，甚至不应该被推荐。请记住，角色不是职务。一个人可以担任多个角色，一个角色可以分配给多个人。
660
661 角色是在过程和活动的背景中描述的。每个角色都有一个基于表4.1所示模型的能力概述。
662
663 **表4.1能力代码和资料**
664
665 |**能力代码**|**能力概述（活动和技能）**
666 |L|领袖 决策，授权，监督其他活动，提供激励和动机，并评估结果
667 |A|管理员 分配和确定任务的优先级，记录，持续的报告，并开始基本的改进
668 |C|协调/沟通 协调多方，维护利益相关者之间的沟通，并开展宣传活动
669 |M|方法与技术专家 设计和实施工作技术，记录程序，过程咨询，工作分析，持续改进
670 |T|技术专家 提供技术(IT)专业知识并执行基于专业知识的任务
671
672 表4.2中列出了可用性管理活动涉及的角色示例，以及相关的能力概述和特定技能。
673
674 **表4.2 可用性管理活动角色的示例**
675
676 (% style="width:829px" %)
677 |(% style="width:197px" %)**活动**|(% style="width:174px" %)**负责角色**|(% style="width:133px" %)**能力概述**|(% style="width:324px" %)**特定技能**
678 |(% colspan="4" style="width:826px" %)建立服务可用性控制
679 |(% style="width:197px" %)识别服务可用性需求|(% style="width:174px" %)(((
680 服务/产品负责人
681
682 关系经理
683
684 服务设计者
685
686 客户
687 )))|(% style="width:133px" %)CTA|(% style="width:324px" %)(((
688 业务分析
689
690 熟悉服务消费者的业务
691
692 良好的产品知识，包括架构和配置
693
694 沟通和协调
695 )))
696 |(% style="width:197px" %)商定服务可用性需求|(% style="width:174px" %)(((
697 服务负责人
698
699 关系经理
700
701 客户
702 )))|(% style="width:133px" %)CA|(% style="width:324px" %)(((
703 沟通和谈判
704
705 良好的产品知识，包括架构和配置
706 )))
707 |(% style="width:197px" %)确定可用性指标需求|(% style="width:174px" %)(((
708 可用性经理
709
710 监控工具
711
712 管理员
713
714 监控和事件
715
716 管理服务
717
718 设计者
719
720 技术专家
721 )))|(% style="width:133px" %)TM|(% style="width:324px" %)(((
722 对监控工具和技术有良好的理解
723
724 对市场上可用的监控和事件管理技术的认识
725 )))
726 |(% style="width:197px" %)设计可用性指标和报告|(% style="width:174px" %)(((
727 可用性经理
728
729 服务负责人
730
731 关系经理
732
733 IT质量经理
734 )))|(% style="width:133px" %)CM|(% style="width:324px" %)(((
735 沟通和谈判
736
737 报告和仪表盘设计技能
738 )))
739 |(% colspan="4" style="width:826px" %)服务可用性分析和改进点
740 |(% style="width:197px" %)服务可用性分析|(% style="width:174px" %)(((
741 可用性经理
742
743 服务负责人
744
745 技术专家
746
747 IT质量经理
748 )))|(% style="width:133px" %)MT|(% style="width:324px" %)(((
749 优秀的分析能力
750
751 具备故障树分析、部件失效影响分析等方法和技术知识
752
753 熟悉分析工具
754
755 充分了解由于服务中断而可能对业务造成的影响
756 )))
757 |(% style="width:197px" %)报告服务可用性|(% style="width:174px" %)(((
758 服务负责人
759
760 关系经理
761
762 客户
763 )))|(% style="width:133px" %)CA|(% style="width:324px" %)(((
764 了解协议和期望
765
766 了解消费者背景
767
768 沟通与谈判
769 )))
770 |(% style="width:197px" %)规划和设计服务可用性|(% style="width:174px" %)(((
771 可用性经理
772
773 服务设计师
774
775 技术专家
776
777 架构经理
778 )))|(% style="width:133px" %)TM|(% style="width:324px" %)(((
779 对弹性设置有很好的了解
780
781 对现有控件的认识
782
783 对市场上现有技术的了解
784
785 充分了解由于服务中断而可能对业务造成的影响
786 )))
787
788
789 == **4.2组织结构和团队** ==
790
791 尽管可用性经理的角色可能具有正式的职位和职务说明，但是在可用性管理实践中很少看到专用的组织结构。服务可用性由其他实践和组织职能进行管理。
792
793 表4.3概述了这些功能。
794
795 **表4.3 与其他实践和组织职能相关的可用性管理活动示例**
796
797 (% style="width:743px" %)
798 |**流程**|**活动**|(% style="width:449px" %)**常见执行场景**
799 |(% rowspan="4" %)建立服务可用性控制|识别服务可用性需求|(% rowspan="2" style="width:449px" %)(((
800 服务/产品的负责人
801
802 可以作为SLM 实践的一部分执行
803 )))
804 |商定服务可用性需求
805 |确定可用性标准需求|(% style="width:449px" %)(((
806 监控工具管理员
807
808 可以作为监控和事件管理实践的一部分执行
809 )))
810 |设计可用性指标和报告|(% style="width:449px" %)(((
811 服务/产品的负责人
812
813 可以作为SLM或度量和报告实践的一部分执行
814 )))
815 |(% rowspan="3" %)服务可用性分析和改进|服务可用性分析|(% style="width:449px" %)(((
816 对于服务组件/ IT基础设施：系统和基础架构管理员
817
818 对于服务级别：服务/ 产品负责人
819 )))
820 |报告服务可用性|(% style="width:449px" %)(((
821 服务/ 产品负责人
822
823 可以作为SLM 实践中总体服务级别报告的一部分执行
824 )))
825 |规划和设计服务可用性|(% style="width:449px" %)与风险经理和业务连续性管理员一起执行。根据服务生命周期阶段和组织环境，可能涉及业务分析人员、体系结构管理人员、信息安全管理人员和/或系统管理员
826
827 因为可用性几乎受所有ITIL 实践的影响，所以最好任命一个可用性经理，对确保成本高效的可用性管理负责。该角色可以与服务连续性管理员或IT风险经理的角色结合使用。
828
829
830
831
832 ----
833
834 = **5 信息和技术** =
835
836
837 == **5.1信息交换，输入/输出** ==
838
839 可用性管理实践的效果基于所使用信息的质量。该信息包括但不限于以下信息：
840
841 * 消费者的业务流程
842 * 服务及其体系架构和设计
843 * 合作伙伴和供应商及其提供的服务信息
844 * 关于服务可用性的法规要求
845 * 市场上可能与服务可用性部署相关的技术和服务
846 * 有关监控工具和技术的信息
847
848 该信息可以采用各种形式。实践的关键输入和输出在第3节中列出。
849
850
851 == **5.2自动化和工具** ==
852
853 在某些情况下，可用性管理实践可以从自动化中受益匪浅（有关详细信息，请参阅第3节）。在可行且有效的地方，可能涉及表5.1中概述的解决方案。
854
855 **表5.1 可用性管理活动的自动化解决方案**
856
857 |**流程活动**|**自动化手段**|**关键功能**|**对实践效果的影响**
858 |(% colspan="4" %)建立服务可用性控制
859 |识别服务可用性需求|服务目录，CMDB，BPM工具，CMDB，服务模型，可用性和容量，监控和管理工具以及资产管理工具|为了识别服务的VBF和可用性需求，分析人员应该能够访问有关服务组件和服务操作的信息。BPM工具可能会提供有关消费者的流程以及服务支持的操作的信息。|很高
860 |商定服务可用性需求|订约工具，服务门户|(((
861 备选方案的选择
862
863 与服务客户的沟通
864 )))|低
865 |确定可用性指标需求|(% rowspan="2" %)报告和仪表盘工具，服务门户和应用|(% rowspan="2" %)报告和仪表盘模板设计|(% rowspan="2" %)从低到高，取决于必须接收报告的服务和利益相关者数量
866 |设计可用性指标和报告
867 |(% colspan="4" %)服务可用性分析和改进
868 |服务可用性分析|基础架构、应用程序监控和报告工具，内置用户行为监控工具，仪表盘和报告工具，高级分析工具|系统和服务健康状况数据的收集、处理和分析，仪表盘和报告设计以及展示|高
869 |报告服务可用性|报告和仪表盘工具、服务门户和应用程序、电子邮件、其他通信工具以及社交媒体|报告展示|从低到高，取决于必须接收报告的服务和利益相关者数量
870 |规划和设计服务可用性|架构管理工具，CMDB，变更初始化和控制工具|确定现有的控件和弹性措施。初始化变更应作为可用性管理计划实现的一部分来实现。|中等
871
872
873
874 ----
875
876 = **6 合作伙伴和供应商** =
877
878 很少有服务是仅使用组织自己的资源交付的。大部分(如果不是全部的话)依赖于其他服务，这些服务通常是由组织外的第三方提供的(参见ITIL Foundation: ITIL 4 Edition的第2.4节了解服务关系的模型)。服务设计、架构管理和供应商管理的实践指南中描述了由支持服务引入的关系和依赖性。
879
880 合作伙伴和供应商可能提供关键产品和服务组件。服务提供者需要与合作伙伴和供应商协商并就可用性需求达成一致，以满足服务可用性的需求。
881
882 合作伙伴和供应商还可以提供服务和解决方案来确保弹性，例如容灾和群集技术、负载平衡、多层备份系统、监控工具等。在这些情况下，他们应该在设计和规划服务提供时考虑服务可用性。
883
884
885
886
887 ----
888
889 = **7 重要提醒** =
890
891 实践指南的大部分内容应视为组织在建立和培育自身实践相关领域时可考虑的建议。实践指南是组织可以考虑的主题目录而非答案列表。在使用ITIL实践指南的内容时，各组织应始终遵循ITIL指导原则：
892
893 * 聚焦价值
894 * 从你所处的地方开始
895 * 基于反馈迭代推进
896 * 协作和提升可视化程度
897 * 通盘思考和工作
898 * 保持简单实用
899 * 优化和自动化
900
901 关于指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4出版物第4.3节。
902
903
904
905
906 ----
907
908 = **8 致谢** =
909
910 AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：
911
912
913 == **8.1 作者** ==
914
915 帕维尔·德明（Pavel Demin）
916
917
918 == **8.2审阅者** ==
919
920 罗马·朱拉夫列夫（Roman Jouravlev）
深圳市艾拓先锋企业管理咨询有限公司