Wiki source code of 服务管理实践 - 02 事件

Last modified by superadmin on 2024/12/25, 15:38
Show last authors
1 {{info}}
2
3 {{/info}}
4
5
6 **申明：**
7
8 本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注微信公众号：**ITILXF**，并回复“**事件管理**”或“**事件**”即可。
9
10
11 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
12
13
14 本文档翻译工作参与人员：
15
16 翻译：秦佩君
17
18 审校：马军
19
20
21 总审： 长河
22
23 审核： 李锐
24
25 统筹： 常宏
26
27
28
29 ----
30
31 {{box cssClass="floatinginfobox" title="**Contents**"}}
32 {{toc/}}
33 {{/box}}
34
35 = **1 关于本文件** =
36
37 本文档提供事件管理实践实用指南。分为五个主要部分，内容包括：
38
39 * 本实践的一般信息
40 * 实践的流程和活动及其在服务价值链中的作用
41 * 参与实践的组织和人员
42 * 支持实践的信息和技术
43 * 对实践的合作伙伴和供应商的考虑。
44
45 == **1.1 ITIL®4 认证方案** ==
46
47 本文档的部分内容可以作为以下教学大纲的一部分以供检查：
48
49 * ITIL专家：创建、交付和支持
50 * ITIL专家：高速IT
51
52 详情请参考各部分教学大纲。
53
54
55
56
57 ----
58
59 = **2 一般信息** =
60
61
62 == **2.1** **目的和描述** ==
63
64 |(((
65 **关键信息**
66 )))
67 |事件管理实践的目的是尽快恢复正常的服务运作，以尽量减少事件的负面影响。
68
69 规范的服务运维通常是在服务级别协议（SLA）定义，或在服务质量规范的其他形式中定义的，因为这可以是服务提供者在内部达成的协议。规范可以包含比最初与客户达成的协议更多的质量准则。因此，事件管理实践包括恢复服务和资源的正常运行，即使服务使用者看不到它们的失效或偏差。在这种情况下，日常运维操作在配置项（CI）或服务技术规范中定义。但是，如果没有日常运维的书面规范，则可以使用专家意见来评估资源和服务的状况。如果需要，可以使用事件管理实践来纠正有故障的资源或服务。
70
71 事件管理实践是服务管理的基本元素。服务的快速恢复是用户和客户满意、服务提供者的信誉，以及组织在服务关系中创建价值的关键因素。
72
73
74 == **​​​​​​​2.2** **术语和概念** ==
75
76 |**事件**
77 |服务的计划外中断或服务质量的降低。
78
79 事件管理实践确保将计划外的服务不可用或降级的时间减至最少，从而减少对用户的负面影响。有两个主要因素可以实现这一点：早期的事件检测和快速恢复正常的运维。
80
81 借助有效、高效的流程，自动化工具和供应商关系以及技术精湛且积极进取的专家团队，可以快速检测和解决事件。服务管理四维模型的资源被整合以形成事件管理实践。
82
83 一些系统和服务给出了包括所谓典型事件在内的操作范例。这些可能与已知的错误相关，例如缺乏兼容性或不正确的用户行为方式。服务提供者通常定义事件模型以优化处理和解决重复事件或类似事件，这些事件模型有助于快速、高效地解决事件，由于采用了经过验证和测试的解决方案，通常会产生更好的结果。
84
85
86 事件模型的创建和使用对于事件管理实践中的活动很重要。这将在第3节中进一步描述。
87
88 尽管有些事件在服务运营和消费方面的影响相对较低，但其他事件却给服务消费者和服务提供者带来了严重后果，这些被称为重大事件，需要特别注意。
89
90
91 |(((
92 **定义：重大事件**
93 )))
94 |具有重要业务影响的事件，需要立即协调解决。
95
96 重要的业务影响并不是重大事件的唯一特征。例如，当有多个为高可用性设计的系统和服务时，单个故障不太可能导致严重的业务影响。故障将迅速且通常是自动检测并修复。重大事件通常与更高级别的复杂性相关。例如，如果多个看似微不足道的事件同时发生，则可能会升级并对服务使用者产生影响。诸如此类的复杂事件需要一些特殊的管理和解决方法。实施一个模型来管理所有事件将是有益的，尽管重大事件很少发生且通常具有不同的性质。重大事件的模型可能包括：
97
98 * 清晰的准则，以区分重大事件与灾难及其他事件
99 * 特别负责的协调员，有时也称为重大事件经理（MIM）
100 * 创建了一个专门的临时团队来调查和解决重大事件
101 * 其他专用资源（包括预算），例如，与第三方专家进行紧急咨询或采购组件
102 * 特殊的调查方法（例如，全功能团队）
103 * 与用户，客户，监管机构，媒体和其他利益相关者进行沟通的机制
104 * 达成一致的评审与后续活动的规程。
105
106 |(((
107 **定义：变通方案**
108 )))
109 |当事件或者问题无法彻底解决，而采取减少或消除事件或问题影响的变通解决方案。一些变通方案还可以降低事件发生的可能性。
110
111 有时，可能找不到事件的系统性解决方案。在这些情况下，服务提供者可以应用变通方案。
112
113 变通方案可以立即将服务恢复到可接受的质量。但是，变通方案可能会增加技术债务，并可能在将来导致新的事件。问题管理实践可用于减少事件解决方法创建的技术债务。在许多情况下，了解事件的原因可以帮助找到最佳解决方案。
114
115
116 |(((
117 **定义：技术债务**
118 )))
119 |因选择变通方案而非系统性解决方案（需要花费更长时间），而累计的返工总量
120
121 == **​​​​​​​2.3 范围** ==
122
123 事件管理实践的范围包括：
124
125 * 发现和登记事件
126 * 诊断和调查事件
127 * 将受影响的服务和配置项还原到约定的质量
128 * 管理事件记录
129 * 在事件的全生命周期中与利益相关者进行沟通
130 * 在事件解决之后，进行事件故并发起服务改进和事件管理实践优化
131
132 尽管许多活动和责任领域仍与事件紧密相关，但它们并没有包含在事件管理实践中。表2.1中列出了这些活动，以及对实践指南的引用。重要的是要记住，ITIL实践指南仅仅是价值流中使用的工具集合，应根据情况的需求而组合。
133
134
135 表2.1 其他实践中描述的与事件管理实践相关的活动
136
137 (% style="width:364px" %)
138 |(% style="width:204px" %)**活动**|(% style="width:157px" %)**实践指南**
139 |(% style="width:204px" %)调查事件原因|(% style="width:157px" %)问题管理
140 |(% style="width:204px" %)与用户沟通|(% style="width:157px" %)服务台
141 |(% style="width:204px" %)实施产品和服务的变更|(% style="width:157px" %)变更支持
142 |(% style="width:204px" %) |(% style="width:157px" %)(((
143 部署管理
144
145 基础设施和平台管理
146
147 项目管理
148
149 发布管理
150
151 软件开发和管理
152 )))
153 |(% style="width:204px" %)监控技术，团队和供应商绩效|(% style="width:157px" %)监控和事态管理
154 |(% style="width:204px" %)改进计划的管理|(% style="width:157px" %)持续改进
155 |(% style="width:204px" %)服务请求的管理和执行|(% style="width:157px" %)服务请求管理
156 |(% style="width:204px" %)灾难情况下，恢复正常操作|(% style="width:157px" %)服务连续性管理
157
158 == **​​​​​​​2.4** **实践成功因素** ==
159
160 |(((
161 **实践成功因素**
162 )))
163 |相关联的一组事务的协同工作机制，是实践活动实现其目的所必需的。
164
165 实践的成功因素（PSF）不仅仅是一项任务或活动，它包括服务管理四维模型的所有功能组件。在一项实践中，PSFs活动和资源的性质可能不同，但这些资源和活动共同确保实践有效。
166
167 事件管理实践包括以下PSFs：
168
169 * 及早发现事件
170 * 快速有效地解决事件
171 * 不断改进事件管理方法。
172
173 === **2.4.1 尽早发现事件** ===
174
175 以前，实践通常是根据最终用户和IT专家的信息来报告大多数事件的。这种获取信息的方法仍被广泛使用，但是现在一个好的实践建议是自动发现和报告事件。可以在事件发生后和开始影响用户之前立即被发现。这种方法具有多种好处，其中包括：
176
177 * 事件较早发现缩短了服务不可用或降级的时间。
178 * 更高质量的初始数据支持事件正确的响应和解决，包括自动解决，也称为故障自愈。
179 * 某些事件对用户来说是不可见的，从而改进了用户满意度和客户满意度。
180 * 一些事件可能在影响与顾客约定的服务质量之前得到解决，从而提高感知服务和正式报告的服务质量。
181 * 与事件相关的成本可能会降低。
182
183 通过监控和事态管理实践可以发现事件。这包括用于事态分类的工具和流程，用于区分事件、信息事态和告警。
184
185 自动发现的事件可以自动，手动或部分自动地分类。部分自动分类是手动进行的，但会基于系统提出的建议。自动事件发现和分类可能受益于机器学习解决方案，使用从过去事件、事件、已知错误和其他来源获得的数据。
186
187 当无法自动发现事件时，通常会在事件已经影响到用户及其工作时发现事件。即使这样，事件的报告和报告越早越好。这可以通过在用户中推广负责任的服务的文化来实现，包括鼓励报告可疑事件和行为，并在合理范围内容忍误报。
188
189
190 === **2.4.2 快速有效地解决事件** ===
191
192 该PSF对于事件管理实践和通用服务质量的成功至关重要。考虑到环境的复杂性，在检测到事件之后，应该有效地进行处理：
193
194 * 在简单的情况下，例如重复发生的事件和众所周知的事件，预设的解决程序可能是有效的。这些可能包括自动解决或标准化的分派和处理（根据适当的预先约定的事件模型）。
195 * 在复杂的情况下，事件的确切性质未知，但支持团队熟悉系统和组件，并且组织可以获取专家知识，因此通常会将事件分派到一个或多个专家组进行诊断和解决。有时，这可以帮助识别模式，并产生一个模型和/或解决方案，可以应用于未来的类似事件。
196 * 在非常复杂的情况下，很难或不可能确定专家区域和专家组，或者已确定的专家组找不到解决方案时，采用集体方法可能会有用。此技术称为“全功能团队”。
197
198 |**全功能团队**
199 |解决各种复杂任务的技术方法。在全功能团队中，具有不同专业知识领域的多个人员一起完成一项任务，直到明确哪些能力最相关和最需要。
200
201 通常，全功能团队有助于降低复杂度，使其可以切换到低复杂性环境中使用的技术。但是，全功能团队通常适用于性质未知的重大事件。在这种情况下，与仍未解决的事件造成的损失相比，将大量专用资源集中在一起更具有成本效益。
202
203 全功能团队不需要举行实际会议。建立计划后，专家可能会独自工作以完成实验，设计脚本，并使用其他工具来发现正在发生的事情。为了应对这一事件，全功能团队使用正确的人员，而不是大量的人员。
204
205 在复杂情况下可以使用其他技术。例如，可以将专家分析替换或与一系列旨在提高对事件性质理解的安全失效实验相结合：
206
207 基于复杂度的决策框架[[1 >>path:#_bookmark2]]对于在高度变化的复杂环境中处理事件很有用。
208
209 无论复杂性如何，从事件处理的第一步开始，都要确认事件数据的质量是否较高。这在以下方面具有强大的影响力：
210
211 * 决策的正确性
212 * 服务的恢复速度
213 * 有效利用资源
214 * 找到并纠正根本原因的能力
215 * 机器学习的可能性和质量。
216
217 ==== **2.4.2.1 事件的优先级** ====
218
219 事件应尽快解决。但是，参与事件解决的团队的资源是有限的，并且这些团队通常同时参与其他类型的工作。应该优先处理某些事件，以最大程度地减少对用户的负面影响。
220
221 * 任务优先级是任务相对于其他任务的重要性。具有更高优先级的任务应首先处理。优先级在待办项中所有任务的背景中定义。
222 * 当无法在待办项中为所有任务分配资源时，优先选择首先要处理的任务。
223
224 事件优先级划分有许多简单准则：
225
226 * 评估事件的影响和紧急程度（以及调查和解决的时间限制）是不分优先顺序的。但是，这种评估可用于确定优先级和其他重要的考虑因素，例如估计执行工作所需的时间。
227 * 仅当存在资源冲突时才需要确定优先级。如果在时间限制内有足够的资源用于流程的每个任务，则无需进行优先级排序。
228 * 事件应在单个待办项中与其他任务（计划内的和计划外的）一起等待处理。
229 * 优先级排序是一种工具，用于在团队中分配人员执行任务。如果事件由多个团队处理，则将根据资源可用性、目标解决时间和估算的处理时间在各团队中确定优先级。
230 * 资源可用性和估算的处理时间由团队确定。此外，对于重复性操作可以将处理时间标准化。目标解决时间可以由SLA和/或服务提供方的内部服务规范定义。随着支持团队发现新信息，原来的影响度评估结果和完成（解决）时间可能会有变化。
231 * 可视化工具（如看板）和精益原则（如对在建工程的限制）对于提高优先级排序的有效性是有用的。
232
233 这些规则适用于服务提供方的专业团队执行的，无论是计划内还是计划外的所有类型的工作。在所有实践中，参与组织服务管理活动的每个人都必须同意并遵循这些原则，这一点很重要。
234
235
236 === **2.4.3 持续改进事件管理方法** ===
237
238 应当定期对事件进行评审，以提高事件管理实践的有效性和效率。对于重大事件、新类型的事件以及未及时解决的事件通常需要在解决后进行单独评审。大多数事件除了确认成功解决外，不需要单独进行评审。尽管如此，在一定的时间间隔内对事件管理记录进行回顾有助于总结成功经验、识别改进点，有助于在专业团队间实现知识共享、识别新的事件类型，有助于改进或引入事件模型。
239
240 定期评审提供一个机会来分析利益相关方对事件管理实践的满意度。定期事件评审也是机构和组织持续改进产品及服务的关键。
241
242
243 |**关键信息**
244 |(((
245 //数据的重要性//
246
247 有效的评审一定需要数据支撑，认同记录数据的要求很重要。数据应该是：
248
249 * 在持续改进中，要求利益相关方在事件处置过程中（而不是事后）更新事件记录，以保证所有人同时且准确地知道什么时间做了什么事非常有用。同样，准确的时间表有助于调查问题。
250 * 在一个简单的描述中可能隐藏着大量的具体活动。例如，“我们重新启动集群并在45分钟后观察到功能正常”之类的语句可能隐藏了有用的细节。这可能意味着：“我们先重启服务器1，然后重启2，然后再重启3，然后发现原来正常运行的服务器4停机了。我们查阅了手册，重新启动了服务器2和4，之后是服务器1和3。所有服务器在10分钟后都能正确处理数据。
251
252 全面描述采取行动的原因与描述行动本身同样重要。
253 )))
254
255 == **​​​​​​​2.5 关键指标** ==
256
257 应该基于每个实践对价值流的贡献来评估ITIL实践的有效性和绩效。与任何工具的绩效一样，实践的绩效只能在其应用情境中评估。工具在设计和质量上可能会有很大差异，按照工具的用途使用时，这些差异定义了工具有效性的潜力或能力。关于度量标准，关键绩效指标（KPI）和其它技术的进一步指导，请参见度量和报告实践指南。
258
259 事件管理实践的关键指标已映射到其PSF。它们可以用作价值流情景下的KPIs，来评估实践对这些价值流的效能和效率的贡献。表2.2中给出了一些关键指标的例子。
260
261 在实践中，应将指标应用于特定的场景，例如事件的类型，服务，专家组或时间区间。将度量标准正确地聚合到复杂的指标中，将使数据更容易用于价值流的持续管理，以及事件管理实践的定期评估和持续改进。并没有唯一的最佳解决方案，度量标准将基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。
262
263
264 表2.2 实践成功因素的关键指标示例
265
266 (% style="width:458px" %)
267 |(% style="width:182px" %)**实践成功因素**|(% style="width:273px" %)**指标示例**
268 |(% style="width:182px" %)尽早发现事件|(% style="width:273px" %)(((
269 事件发生到发现之间的时间
270
271 通过监控和事态管理发现的事件百分比
272 )))
273 |(% style="width:182px" %)快速有效地解决事件|(% style="width:273px" %)(((
274 从事件发现到接受诊断之间的时间
275
276 派单次数
277
278 等待时间占事件总处理时间的百分比
279
280 首次解决比率
281
282 按时解决率
283
284 用户对事件处理和解决的满意度
285
286 自动解决事件的百分比
287
288 用户报告之前已解决的事件的百分比
289 )))
290 |(% style="width:182px" %)不断改进事件管理方法|(% style="width:273px" %)(((
291 使用先前确定和记录的解决方案的事件解决率
292
293 使用事件模型解决的事件的百分比
294
295 超时关键实践指标的改善
296
297 事件解决的速度和有效性指标之间的平衡
298 )))
299
300 ----
301
302 = **3 价值流和流程** =
303
304
305 == ​​​​​​​**3.1** **价值流贡献** ==
306
307 像任何其他ITIL管理实践一样，事件管理实践对多条价值流有帮助。重要的是要记住，价值流不是由单一实践形成的。例如，即使当价值流专注于事件解决时，也会涉及其他实践，例如服务台、监控和事态管理、服务配置管理、变更支持、供应商管理、基础设施和平台管理以及软件开发和管理。
308
309 事件管理实践主要与在各种工作环境中恢复正常系统或服务运营有关。实践贡献的主要价值链活动是：
310
311 * 契动
312 * 交付和支持
313 * 设计和转换
314 * 改进
315 * 获取或构建。
316
317 事件管理实践对服务价值链的贡献如图3.1所示。
318
319 (% style="text-align:center" %)
320 [[image:1639666274571-239.png]]
321
322 图3.1 事件管理实践对价值链活动的贡献热力图
323
324
325 == **3.2 流程** ==
326
327 每个实践可以包含一个或多个过程和活动，这是实现这一实践目的所必需的。
328
329
330 |(((
331 **流程**
332 )))
333 |将输入转换为输出的一组相互关联或相互作用的活动。过程接受一个或多个已定义的输入，并将其转换为已定义的输出。过程定义操作的顺序及依赖关系。
334
335 事件管理活动分为两个流程：
336
337 * **事件的处理和解决**。该流程的重点是从发现到关闭的单个事件的处理和解决。
338 * **定期事件评审**。该流程确保从事件处理和解决的过程中吸取教训，并确保持续改进事件管理的方法。
339
340 === **3.2.1 事件处理和解决** ===
341
342 该过程包括表3.1中列出的活动，并将输入转换为输出。
343
344 表3.1 事件处理和解决过程的输入，活动和输出
345
346 (% style="width:552px" %)
347 |(% style="width:254px" %)**关键输入**|(% style="width:119px" %)**活动**|(% style="width:177px" %)**关键输出**
348 |(% style="width:254px" %)监控和事件数据|(% style="width:119px" %)事件发现|(% style="width:177px" %)事件记录
349 |(% style="width:254px" %)用户查询|(% style="width:119px" %)事件登记|(% style="width:177px" %)事件状态沟通
350 |(% style="width:254px" %)配置信息|(% style="width:119px" %)事件分类|(% style="width:177px" %)问题调查请求
351 |(% style="width:254px" %)IT资产信息|(% style="width:119px" %)事件诊断|(% style="width:177px" %)变更请求
352 |(% style="width:254px" %)服务目录|(% style="width:119px" %)事件解决|(% style="width:177px" %)事件报告
353 |(% style="width:254px" %)与消费者和供应商/合作伙伴的SLA|(% style="width:119px" %)事件关闭|(% style="width:177px" %)知识库更新
354 |(% style="width:254px" %)容量和性能信息|(% style="width:119px" %) |(% style="width:177px" %)恢复CI和服务
355 |(% style="width:254px" %)连续性策略和计划|(% style="width:119px" %) |(% style="width:177px" %)
356 |(% style="width:254px" %)信息安全策略和计划|(% style="width:119px" %) |(% style="width:177px" %)
357 |(% style="width:254px" %)问题记录|(% style="width:119px" %) |(% style="width:177px" %)
358 |(% style="width:254px" %)知识库|(% style="width:119px" %) |(% style="width:177px" %)
359
360 图3.2展示事件处理和解决的工作流程图。
361
362
363 (% style="text-align:center" %)
364 [[image:1639666329840-902.png]]
365
366 图3.2 事件处理和解决流程的工作流
367
368
369 在整个过程中，应明确每个事件的所有权。在处理和解决过程中，所有权有可能会转移，但是每个事件应在任意时间都有人负责。另外，只要事件状态发生变化，就应与利益相关者沟通。
370
371 基于不同的事件模型，流程可能会有较大差异。表3.2提供了两种事件模型（手动和自动）的活动示例，它们只是许多可选项中的两个，用来说明事件模型之间的差异。
372
373
374 表3.2 事件处理和事件解决过程的活动
375
376 [[image:1642222461983-817.png]]
377
378 [[image:1642222484248-277.png]]
379
380
381 === **3.2.2 定期事件评审** ===
382
383 该流程的重点是持续改进事件管理实践，事件模型和事件处理程序。它可以定期执行，也可以由事件报告触发，该报告突显低效率和其他改进点机会。根据现有模型和程序的效果，每两到三个月或更短时间进行一次定期检查。
384
385 该流程包括表3.3中列出的活动，并将输入转换为输出。
386
387
388 表3.3定期事件评审的输入、输出和活动
389
390 (% style="width:406px" %)
391 |(% style="width:139px" %)**关键输入**|(% style="width:146px" %)**活动**|(% style="width:117px" %)**关键输出**
392 |(% style="width:139px" %)当前事件的模型和程序|(% style="width:146px" %)事件评审和事件记录分析|(% style="width:117px" %)更新的事件模型
393 |(% style="width:139px" %)事件记录|(% style="width:146px" %)事件模型优化的启动|(% style="width:117px" %)更新的事件处理程序
394 |(% style="width:139px" %)事件报告|(% style="width:146px" %) |(% style="width:117px" %)事件记录
395 |(% style="width:139px" %)策略和法规要求|(% style="width:146px" %)事件模型更新的沟通|(% style="width:117px" %)更新的事件模型和过程的沟通
396 |(% style="width:139px" %)配置信息|(% style="width:146px" %) |(% style="width:117px" %)
397 |(% style="width:139px" %)IT资产信息|(% style="width:146px" %) |(% style="width:117px" %)变更请求
398 |(% style="width:139px" %)与消费者和供应商/合作伙伴的SLA|(% style="width:146px" %) |(% style="width:117px" %)(((
399 改进计划
400
401 事件评审报告
402 )))
403 |(% style="width:139px" %)容量和性能信息|(% style="width:146px" %) |(% style="width:117px" %)
404 |(% style="width:139px" %)连续性策略和计划|(% style="width:146px" %) |(% style="width:117px" %)
405 |(% style="width:139px" %)安全策略和计划|(% style="width:146px" %) |(% style="width:117px" %)
406
407 图3.3 展示事件评审的工作流程图。
408
409
410 (% style="text-align:center" %)
411 [[image:1639666373428-469.png]]
412
413 图3.3定期事件评审流程的工作流
414
415
416 表3.4提供了定期评审流程活动的示例。
417
418
419 表3.4 定期事件评审流程的活动
420
421 (% style="width:434px" %)
422 |(% style="width:106px" %)**活动**|(% style="width:326px" %)**示例**
423 |(% style="width:106px" %)事件评审和事件记录分析|(% style="width:326px" %)事件经理与服务所有者和其他相关的利益相关者一起，对选定的事件（例如重大事件，未及时解决的事件或特定时期内的所有事件）实施评审，确定事件模型和事件处理程序的改进机会，包括事件处理和解决方案的自动化。
424 |(% style="width:106px" %)事件模型优化的启动|(% style="width:326px" %)事件经理记录优化方案，它将通过持续改进实践或启动变更请求开始。（如果事件模型、程序和自动化包含在变更支持实践的范围内）。
425 |(% style="width:106px" %)(((
426 事件模型
427
428 变更的沟通
429 )))|(% style="width:326px" %)如果事件模型成功地完成优化，这一事实将会传达给相关的利益相关者。这通常由事件经理和/或服务或资源所有者通过沟通过程完成。
430
431 ----
432
433 = **4 组织和人员** =
434
435
436 == ​​​​​​​**4.1 角色，能力和责任** ==
437
438 实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定于每个实践的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住，角色并非职位头衔。一个人可担任多个角色，一个角色也可以分配给多个人员。
439
440 在过程和活动的情景中描述角色。每个角色都有一个基于表4.1所示模型的能力类型。
441
442
443 表4.1能力代码和类型
444
445 |**能力代码**|**能力类型（活动和技能）**
446 |L|**领导**决策、授权、监督其他活动，提供激励和动力，并评估结果
447 |А|**管理员**分配任务并确定优先级，保持记录，持续报告，并启动基本改进
448 |C|**协调者/沟通者**协调多方，维护利益相关者之间的沟通，并开展宣传活动
449 |М|**方法和技巧专家 **设计和实施技术、文件化步骤、流程咨询、工作分析和持续改进
450 |Т|**技术专家**提供技术（IT）专业知识并执行基于专家经验的作业
451
452 === **4.1.1 事件经理角色** ===
453
454 在许多组织中，事件经理角色由专人担任，有时授予事件经理的职衔。在其他组织中，事件经理的责任由负责与事件关联的配置项，服务或产品的人员或团队承担；他可能是资源所有者，服务负责人或产品负责人。
455
456
457 该角色通常负责：
458
459 * 根据组织设计，协调在组织或特定区域（例如管区，产品和技术）内的事件处理
460 * 在事件中协调人工操作事宜，尤其是涉及多个团队的事件
461 * 监控并检查负责处理和解决事件的团队的工作情况
462 * 确保在组织层面对事件及其状况有足够的认知
463 * 组织定期的事件评审，对事件管理实践，事件模型和事件处理程序持续改进
464 * 发展组织在流程和事件管理实践方法上的专业知识。
465
466 在某些情况下，组织可能会设置重大事件经理（MIM）角色。该角色的职责与事件经理的职责相似，但只关注重大事件。该角色负责重大事件期间主要的联系和协调。MIM通常具有更广泛的权限，且可能有用于重大事件管理的专用资源。
467
468 尽管每种能力的重要性因活动而异，但这些角色的能力类型是LCTA。
469
470
471 === **4.1.2 事件管理活动中涉及的其他角色** ===
472
473 表4.2中列出了事件管理活动中可能涉及的其他角色示例，以及相关的能力类型和特定技能。
474
475
476 表4.2负责事件管理活动的角色示例
477
478 [[image:1642222648578-782.png]]
479
480 [[image:1642222669993-827.png]]
481
482
483 == **​​​​​​​4.2** **组织结构和团队** ==
484
485 事件管理实践不推荐任何特定的组织模型。但是，组织结构会影响实践的执行方式，因为它涉及具有不同领域和专业水平的专家。专家分组的典型方法包括：
486
487 * 技术领域
488 * 生产/服务
489 * 管区
490 * 消费者类型。
491
492 依据组织的需求和资源，组织的构建方式会有所不同。事件管理实践应采取灵活的构建方式，必要时包括来自不同内部和外部团队的资源。
493
494
495 === **4.2.1 分层型与扁平型团队结构** ===
496
497 历史上，处理事件的团队具有分层或分级的结构，其中能力，专业知识和专业技能随级别的增加而增加。为了降低成本，尽可能用最低的层级人员解决大多数事件。如果无法在当前级别解决事件，则将事件转移到高一层级或升级。在这样的团队中，事件升级的级别和程序均有明确的界限。缺点是，这样的结构会抑制协作和信息流动，导致解决时间延长。因此，对于高优先级事件，通过团队协作来促进快速解决。
498
499 敏捷方法的扩展应用和IT系统质量提升（如自愈系统），要求更广泛地使用扁平型团队结构，而不是分层型团队结构。更扁平的结构和相应的协作方法（如全功能团队）代替了分层结构，以促进合作和信息的自有流动。这种变化的主要驱动力是摒弃了刚性分层，取而代之的是更具活力的、自组织的协作。
500
501
502 |(((
503 **范例**
504 )))
505 |(((
506 三层（L1，L2，L3）团队中的典型升级流程可以替换为以下内容：
507
508 * 用扁平的配对系统（或类似的系统）代替L1到L2的升级以快速的解决事件，和尽快将剩余的未决问题流转到L3，
509 * L3团队间协作，以取代多次重新分配和/或对专家和顶级人才的过度依赖。
510 )))
511
512 === **4.2.2 团队动力** ===
513
514 事件管理实践是团队动力的基础，它们影响着运维支持团队的职责履行。经常出现以下问题：
515
516 * 事件在团队之间重定向
517 * 团队成员缺乏自主性，报告被他人拖延
518 * 事件解决后，“个人英雄主义”的文化盛行。
519
520 这导致事件管理实践不同步，解决方案执行缓慢或根本不执行，士气下降，缺乏动力以及不健康的工作氛围，甚至导致团队成员间的信任关系破裂。尽管DevOps和全功能团队等方法表现出鼓励积极团队文化所需的一些特征，但是实现正确的团队动力也不是必须遵循这些方法。主要解决以下三个问题：
521
522
523 ==== **4.2.2.1 集体责任** ====
524
525 如果解决事件是首要责任，那么团队中的每个人都将聚焦于此。团队动力仅次于实现SLA或按时完成。改变这一点的第一步是建立一种给团队成员共享成功和失败的文化。责任分担的团队可能只有一个人负责事件发现到解决，但是应该鼓励他在这个过程中与其他有经验的人合作。此时，组织将从快速恢复政策服务和知识共享中受益。
526
527
528 ==== **4.2.2.2 不责备文化** ====
529
530 团队中应建立不责备文化；否则，会导致个人，团队和供应商之间的信任度下降。事件诊断和事件评审应关注事件解决和服务恢复过程。如果事件团队的设想失败，必须鼓励他们采取行动，而不必担心受到责罚。
531
532
533 ==== **4.2.2.3 持续学习** ====
534
535 团队成员需要分享他们从实验中学到的经验和教训，以便他们可以学习改进。事实证明，这在许多环境中都是一个重大的文化飞跃，尤其是外包比例较高的环境中。
536
537
538
539
540 ----
541
542 = **5 信息和技术** =
543
544
545 == **​​​​​​​5.1** **信息沟通** ==
546
547 事件管理实践的有效性取决于所用信息的质量。这包括但不限于以下信息：
548
549 * 客户和用户
550 * 服务的架构和设计
551 * 合作伙伴和供应商，包括其提供的服务合同和SLA信息
552 * 规范服务提供的政策和要求
553 * 利益相关者对实践的满意度。
554
555 信息可采用多种形式，具体取决于所使用的事件模型。实践的关键输入和输出在第3节中列出。
556
557 事件的细节是最重要的信息。这些通常包括：
558
559 * 信息来源
560 * 对失效的或未达标的产品、服务或配置项的说明
561 * 受影响的用户或服务
562 * 性能下降的状况
563 * 观察到性能下降的时间
564 * 症状前最近一次已知的正常运行的时间点
565 * 是否应用了自动修复（如果没有，原因）
566 * 地理位置和虚拟位置
567 * 影响正常运行的性质和程度
568 * 可能受不良性能或绩效影响且当前运行正常的类似系统
569 * 导致观察到症状的一系列事件。
570
571 事件管理实践中将交换和记录的其他信息应包括以下细节：
572
573 * 诊断（如果有）
574 * 每个采取的行动，包括结果。
575
576 为形成准确的时间表，任何采取的措施都应记录在案。如果实时记录操作不现实，则应记录启动和完成的记录，以避免创建错误的历史日志。但是，如果客户可以通过门户查看信息，则最好捕获实时操作。如果可能，应自动化记录操作。
577
578 应提供遵循支持客服或专家的工作流程的事件记录，并应包括表5.1中所示的数据。
579
580
581 表5.1 事件记录中包含的数据
582
583 [[image:1642222734298-342.png]]
584
585
586 == **​​​​​​​5.2** **自动化和工具** ==
587
588 事件管理实践应该是自动化的。在可行且有效的情况下，可能涉及表5.2中概述的解决方案。
589
590 在某些情况下，事件处理和解决过程中特定活动之后的所有活动都可以使用针对特定类型事件的预定义脚本和场景实现完全自动化。
591
592 请注意，事件管理实践中使用的自动化工具不仅包括对所有事件都有效的组织范围内的工具，还包括一些本地自定制化工具和脚本，这些工具和脚本是在定期事件评审过程中为特定事件模型创建的。两者都应该用来推动自动化工作。
593
594
595 表5.2 事件管理活动的自动化解决方案
596
597 [[image:1642222873598-155.png]]
598
599 [[image:1642222893312-806.png]]
600
601
602
603 ----
604
605 = **6 合作伙伴和供应商** =
606
607 很少的服务是仅用组织自身资源就能交付的。大部分（即使不是全部）依赖于组织外的第三方提供的服务（参见ITIL Foundation：ITIL 4出版物第2.4节，服务关系模型）。支持服务引入的关系和依赖关系在《ITIL供应商管理和服务级别管理实践指南》中有相关叙述。
608
609 事件模型应定义第三方如何参与事件解决，以及组织如何确保有效协作。这取决于产品、服务和价值流的架构和设计解决方案。尽管如此，支持这些解决方案的事件模型的优化将涉及到事件管理实践。通常，为事件选择正确的模型后，在事件诊断、解决和评审期间需要进一步考虑第三方依赖关系。
610
611 为了使供应商成为组织生态系统的一部分，定义标准界面可能是沟通状况和要求的简便方法。这种界面描述可能包括在多供应商环境中，创建使用通用语言描述的数据交换规则、工具和过程。
612
613 当组织的目标是确保快速有效的事件解决时，他们通常会尝试与合作伙伴和供应商达成紧密合作，消除沟通、协作和决策制定中形式化的官僚壁垒。（有关这方面的更多信息，请参阅《供应商管理实践指南》）。
614
615
616
617
618 ----
619
620 = **7 重要提醒** =
621
622 实践指南的大部分内容应作为组织在建立和培养自身实践时相关领域可考虑的建议。实践指南是组织可以考虑的主题目录，而非答案列表。在使用ITIL实践指南的内容时，组织应始终遵循ITIL指导原则：
623
624 * 聚焦价值
625 * 从你所处的地方开始
626 * 基于反馈迭代推进
627 * 协作和提升可视化程度
628 * 通盘思考和工作
629 * 保持简单实用
630 * 优化和自动化。
631
632 ----
633
634 = **8 致谢** =
635
636 AXELOS有限公司感谢所有为本指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
637
638
639
640 == **8.1 作者** ==
641
642 Barry Corless, Roman Jouravlev, Andrew Vermes.
643
644
645
646 == **8.2 审稿人** ==
647
648 Akshay Anand, Sofi Fahlberg, Michael G. Hall, Steve Harrop, Piia Karvonen, Anton Lykov, Paula Määttänen, Christian F. Nissen, Mark O’Loughlin, Tatiana Orlova, Elina Pirjanti, Stuart Rance.
深圳市艾拓先锋企业管理咨询有限公司