Version 20.1 by superadmin on 2021/02/17, 17:32
Show last authors
1 {{box cssClass="floatinginfobox" title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
4
5 (((
6 (% class="wikigeneratedid" id="H" %)
7
8 )))
9
10 需要下载 **ITIL 4监控和事态管理实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“监控和事态”即可。
11
12 [[image:微信截图_20210206234644.png]]
13
14
15 **申明：**
16
17 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
18
19
20 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
21
22
23 翻译：刘祥发  审校：冯广成  审核： 徐建中
24
25 (% class="row" %)
26 (((
27 (% class="col-xs-12 col-sm-4" %)
28 (((
29
30 )))
31 )))
32
33 = **1 关于本文件** =
34
35 本文件为监控和事态管理实践提供了实用指南。它分为五个主要部分，内容包括：
36
37 * 有关实践的一般信息
38 * 监控和事态管理的流程和活动及其在服务价值链中的角色
39 * 监控和事态管理中涉及的组织和人员
40 * 支持监控和事态管理的信息和技术
41 * 合作伙伴和供应商对监控和事态管理的思考
42
43
44 == **1.1** **ITIL®4 认证体系** ==
45
46 本文件所选内容可作为以下教学大纲的一部分进行考查：
47
48 * ITIL专业人员：创建、交付和支持
49 * ITIL专业人员：指导、计划和改进
50
51 有关详细信息，请参阅相应的教学大纲文件。
52
53
54
55 ----
56
57 = **2 一般信息** =
58
59
60 == **2.1 目的和描述** ==
61
62
63 监控和事态管理实践的目的是系统地观察服务和服务组件，将其状态变化识别为事态并进行记录和报告。该实践识别基础设施、服务、业务流程和信息安全等事态，确定其优先级，建立对这些事态的适当响应，包括对可能导致潜在故障或事件的条件作出响应。
64
65 |(((
66 **事态**
67
68 对服务或其他配置项（CI）的管理具有重要意义的任何状态变更。
69 )))
70
71 监控和事态管理用于管理整个生命周期中的事态，以了解和优化它们对组织及其服务的影响。监控和事态管理包括识别、聚类或者分析与所有级别的基础设施相关的事态、以及组织及其服务使用者之间的服务交互。监控和事态管理确保对这些事态做出适当及时的响应。
72
73 本实践的监控部分专注于服务和配置项（CIs），以探测潜在的重要情况、跟踪和记录服务和配置项（CIs）的状态，并将此信息提供给相关方。
74
75 本实践的事态管理部分着重于那些由组织定义为事态的被监控的状态变化，确定其重要性，识别并启动对它们的正确响应。有关事态的信息也会被记录、存储并提供给相关方。
76
77 监控和事态管理的数据和信息是许多实践的重要输入，包括：
78
79 * 事件管理
80 * 问题管理
81 * 信息安全管理
82 * 可用性管理
83 * 性能和容量管理
84 * 变更支持
85 * 风险管理
86 * 基础设施和平台管理
87 * 软件开发和管理
88 * 其他
89
90 有一个关键点，监控是事态管理发生所必需的，但并非所有的监控都会检测到事态。阈值和其他准则确定哪些状态更改将被视为事态。同样，另一个重要的关注点就是，并非所有事态具有相同的重要性或需要相同的响应。准则将定义发生的事态属于什么类别。按照重要性增加的顺序，典型的事态类别是信息、警告和异常。
91
92
93 == **2.2 **术语和概念 ==
94
95
96 |(((
97 **监控**
98
99 通过对系统、实践、流程、服务或其他实体的重复观察，探测事态并确保已知其当前状态。
100 )))
101
102 了解服务的状态和服务组件对于管理它们至关重要。有关服务运行状态和性能的信息使组织能够对已发生的对服务造成影响的事态做出适当的响应（响应式监控），或者根据对过去事件的模式分析采取主动行动，以防止将来面临不利事态（预防式监控）。
103
104 监控通过多种不同的方式得以实现。配置项（CIs）可以通过轮询（即响应监控工具收集特定目标数据的请求）或通过在满足某些条件时自动通知监控工具来共享有关其自身的信息。监控工具对服务组件的询问代表着主动监控，而配置项（CIs）向监控工具发送的通知代表着被动监控。
105
106 [[image:图片1.png]]
107
108
109 图2.1 监控的类型
110
111
112 注意事项：当使用主动监控来识别趋势时，它可能有助于比被动监控更早地识别趋势（监控工具在配置项自身发送信息之前先请求信息）。但是，当使用主动监控来检测事态时，它可能比被动监控迟一些：在主动监控中，信息是根据计划收集的，但是，被动监控中，配置项会在事态发生变化之后立即共享它。本注意事项的重要性取决于主动监控是连续的还是基于间隔的。需重要强调的是，从监控工具到服务和配置项的请求之间的间隔时间越长，事态与其注册之间的潜在延迟就越长。
113
114 监控利用了被观察的服务组件的本机监控功能。例如，有关操作系统（OS）的数据（例如磁盘空间，CPU负载，交换使用情况等）已经由OS公开，并指示底层物理资源的使用情况。同样，许多Web服务器，数据库服务器和其他软件都具有内置的监控功能，并将生成度量数据。所有这些数据都可以轻松发送到监控工具。
115
116 除了本机监控功能外，监控还采用了专门设计的监控系统。这些是用于监视Web和云应用程序、基础设施、网络、平台、应用程序和微服务的定制软件功能。对于某些服务组件，尤其是内部开发的应用程序，可能有必要向服务中添加自定义工具，例如，代码或接口，这些代码或接口收集并公开对于组织非常重要的度量数据。
117
118 尽管监控和事态管理传统上专注于服务的技术组件，但对了解其他服务管理资源和活动（包括流程，人员和供应商）的状态也很有用。
119
120 |(((
121 **指标**
122
123 为了管理和改进而监控或报告的度量或计算。
124 )))
125
126 指标是监控和事态管理实践的原始数据的来源。监控系统收集、汇总和分析度量指标数据。指标涵盖多个层次，包括：
127
128 * 低级基础设施指标（主机、服务器、网络和其他）
129 * 应用程序指标（响应时间、错误率、资源使用情况…）
130 * 服务级别指标，包括基于基础设施、连接性、应用程序以及基于服务动作的指标（如果适用）
131 * 第三方服务绩效指标（基于商定的服务级别）
132 * 操作、流程和价值流绩效指标
133
134 |(((
135 **阈值**
136
137 触发预定义响应的指标值。
138 )))
139
140 对阈值的响应各不相同，可能包括：
141
142 * 创建一个警报或其他通知
143 * 创建一个事件
144 * 变更先前记录的警报或通知的状态
145 * 响应各自组件或服务
146
147 阈值是一种初始过滤可通过监控工具收集的大量监控数据的方法。阈值的值应谨慎定义，以防止产生过多的响应，从而超越资源，人力和机器的响应能力。处理度量数据的其他规则通常与阈值结合，例如事态相关规则和引擎。这些可以由组件供应商规定，由组织定义，或由机器学习支持。
148
149
150 监控和事态管理中的一些阈值示例可以是：
151
152 * 一小时内出现X个以上磁盘错误
153 * CPU利用率达到或超过N％三次，任何两个连续事态之间的间隔小于Z秒
154
155 |(((
156 **警报**
157
158 通知已到达阈值、已更改某些内容或已发生故障。
159 )))
160
161 警报由监控工具创建和控制，并在监控和事态管理实践中管理。报警是监控系统的一个非常重要的方面。报警系统必须具有几个特征，包括：
162
163 * 高度可靠
164 * 灵活，并可以通过多种媒体通知操作员
165 * 能够生成详细且可行的通知消息
166
167 对于监控和事态管理，“过度报警”是潜在的危险。出现这样一种情况：即生成的警报数量超出企业的处理能力，真正重要的警报却被遗漏在“警报噪音”中。如今，通过人工智能操作（AIOps）和机器学习（ML）可以对警报进行聚合、关联和过滤，从而为这种潜在的危险提供了补救措施。
168
169 服务和服务组件的状态变更在IT 环境中连续发生。如该实践中所述，通常可以通过IT服务，CI或监控工具创建的通知来识别这些变更。为了正确处理和响应数据流，有必要对传入的信息进行过滤和分类。
170
171 根据事态的影响将事态分为三个事态组，并定义三个相应的响应：信息，警告或异常。
172
173 * 信息类事态在被识别后，不需要进行响应。信息类事态提供设备或服务的状态，或确认某个任务的状态。信息类事态的示例包括：用户登录，操作完成等。信息类事态表示正在执行常规操作，并存储在日志文件中一段时间。组织可以选择在以后分析信息事态，并且可能发现有益于服务的预防措施。信息类事态也可以在状态仪表板上发布给供服务提供者或服务消费者使用。
174 * 警告类事态可以在经历任何负面的影响之前采取行动。警告类事态表示发生了非常规但没有抛出异常的操作。警告类事态通知相应的团队或工具采取必要的措施，以防止发生异常。警告的示例包括：计划备份未运行，或者资源利用率在约定异常阈值的10％之内。
175 * 异常类事态表示已达到服务或组件指标的关键阈值。这一违反服务或组件性能既定规范的行为可能尚未对业务运营产生影响，但是，异常事态也可能表示服务或组件发生故障，性能
176
177 下降或功能丧失，而所有这些都将会影响业务运营。无论哪种情况，异常事态都需要进行响应，因为它们表示常规操作正在发生异常。异常事态的示例包括：计算机扫描显示未授权软件的安装、服务器关闭、备份失败等。这是监控和事态管理实践启用事件检测的方式。
178
179 事态分类将注意力集中在对服务的管理和交付真正重要的事态上。它确保适当地跟踪、评估和管理事态。
180
181 监控和事态管理能够检测事件，将其与信息事态及警告区分开。检测到的事件在事件管理实践中处理。监控和事态管理还通过提供有关影响服务和服务组件的趋势和事态的信息来识别问题。此外，监控和事态管理通过服务和服务组件的监控和汇报机制为已知错误进行错误控制。已识别的问题和已知错误的错误控制在问题管理实践中处理。
182
183
184 == **2.3 范围** ==
185
186 监控和事态管理实践的范围涵盖了组织内需要控制和自动化的服务管理的所有方面。这包括：
187
188 * 识别和优化监控的范围
189 * 实施和维护连续监控
190 * 建立和维护事态的识别，分类和处理规则
191 * 实施流程和自动化工具使已定义的事态管理规则产生作用
192 * 根据议定和实施的规则以及流程对事件进行持续处理
193 * 以商定的形式向利益相关者提供受监控服务和资源的当前和历史状态的信息。
194
195 尽管有些活动和责任领域仍然与监控和事态管理实践密切相关，但它们并没有被包含其中。表2.1中列出了它们以及那些包含了它们的实践的相关引用。重要的是要记住，ITIL实践只是那些在价值流环境中被使用的工具的集合，应根据情况进行必要的组合。
196
197 |活动|实践指南
198 |事件的管理|事件管理
199 |事态和趋势的原因调查|问题管理
200 |响应事态的变更管理|变更支持
201 |与用户沟通|服务台
202 |基于监控数据的决策支持|度量和报告
203 |设置服务质量和性能的目标和阈值|(((
204 服务级别管理
205
206 可用性管理
207
208 性能和容量管理
209
210 信息安全管理
211
212 连续性管理
213 )))
214 |设置基础设施和应用程序组件的阈值|(((
215 基础设施和平台管理
216
217 软件开发和管理
218 )))
219 |设定第三方服务的目标和门槛|供应商管理
220
221 表2.1其他实践指南中描述的与监控和事态管理相关的活动
222
223
224 == **2.4 实践成功因素** ==
225
226
227 实践的成功因素（PSF）不仅仅是一项任务或活动；它包括服务管理四维模型的所有组件。实践成功因素活动和资源的性质可能彼此有所不同，但它们共同确保实践有效。
228
229 监控和事态管理实践包含以下实践成功因素活动(PSF)：
230
231 * 建立和维护描述各类型事态和探测它们所需的监控功能的方法/模型
232 * 确保及时，相关且足够的监控数据提供给相关的利益相关者
233 * 确保发现、解释事态，并在需要时尽快采取措施
234
235 === 2.4.1 建立和维护描述各类事态和探测它们所需的监控功能的方法/模型 ===
236
237 在大多数情况下，现代技术为度量和监控服务以及服务组件操作的各个方面提供了机会，但是从业人员应认真管理监控的范围以及度量指标的频率和数量。现代监控和事态管理实践的主要挑战不是缺少数据，而是监控必须处理的数据的规模。监控和事态管理实践的重点应该是获取有意义的信息，以支持服务的操作与改进，决策和价值的创造。建立或改进监控和事态管理实践时，应考虑以下方面：
238
239 * 识别所监控的服务和服务组件并划分优先级
240
241 实践的关键活动在于确定哪些实体需要监控并划分优先级，这有助于检测状态更改（或缺少所需的状态更改），这些更改对于CI的服务的管理最重要。确定要监视的服务，系统，CI和其他服务组件将基于组织的业务目标。它还需要对组织的服务设计架构有透彻的了解。
242
243 监控和事态管理的从业者将需要了解服务依赖映射关系：哪些顶级业务功能映射到支持那些功能的产品和服务，而哪些产品和服务映射到支持该产品和服务的底层IT基础设施。通过对交付服务所涉及的实体有一个完整的端到端的描述，，监控和事态管理的从业人员将能够正确识别需要监控的关键实体并确定其优先级。
244
245 这里，还应该评估服务组件的“可监控性”，并定义一套有效的标准。所选择的标准应该具有足够的揭示性，并为诊断和决策提供依据。
246
247 * 在监控的信息性，颗粒度和频率之间找到平衡
248
249 建立和维护对服务组件的监控可以视为对资源（监控工具，数据存储，工时等）的投资，并且捕获的数据越多，预期的回报就越少。这是因为监控的规则数量和探测频率越多，用于过滤、分类和分析数据的时间和精力就越多。虽然自动化和基于机器学习的解决方案有助于释放人工和改进数据分析的结果，但从业人员应始终致力于使监控效率最高。
250
251 * 维护数据收集，存储，过滤和关联的能力。监控和事态管理实践很大程度上依赖于服务管理的信息和技术层面。如果没有观察到服务和服务组件的本机监控功能，或没有IT 监控工具（一般广泛通用的商业工具以及定制工具），则几乎不可能检测到对CI或服务管理具有重要意义的状态变化。
252
253 服务元素通过轮询（即响应监控工具的询问来收集特定的目标数据），或者在某些条件被满足时通过自动化的通知发送给监控工具，来传达有关自身的信息。该通信取决于监控工具的可用性和传输事态数据的网络。
254
255 另外，应该特别注意执行数据分类、过滤和关联的工具，以及用于事态响应的自动化工具。
256
257 单个服务的许多服务架构通常由组织集成的第三方产品和服务组成，以向客户和用户提供端到端服务。这些第三方产品和服务的内置监控功能是监控和事态管理实践的关键部分。监控和事态管理从业人员以及服务设计实践中的同行需要能够与他们的设备和服务供应商频繁且良好地合作。这样，监控和事态管理和服务设计可以保护构成组织服务的必要产品和服务，并确保这些服务是可监视和可管理的。
258
259 为事态确定适当的控制动作取决于对检测到的状态变化的过滤和分类。信息和技术服务维度中发生的过滤和分类在很大程度上由组织的事态管理系统（EMS）自动完成，IT 监控工具将检测到的、收集的和传输的信息馈送到其中。但是，EMS用于对数据进行过滤和分类，并确定它们的重要性（确定数据代表信息，警告还是异常事态）的业务规则已建立在服务管理的组织和人员维度中。监控工具和EMS配置的阈值，警报参数，准则都是组织优先级以及那些为服务生态系统的健康运营而工作的有经验的领导者和工作人员的成果。
260
261 需要制定策略来处理不同类型的事态。对事态采取“一刀切”的做法是不合适的，而且浪费资源。不同类型的事态需要针对该事态的类型量身定制对应的响应。应该为每个事态类建立一套通用的控制操作。当适用自动响应时、当适用告警和需要升级为人为干预时、或当事件/问题/变更需要启动处理时，都可以通过制定策略来解决。例如，在某个安全违规的情境中，它可能对运营有潜在的影响，但尚未影响服务的可用性。
262
263 策略在组织和人员维度中定义，并在信息和技术维度中实施。
264
265 为事态（例如信息，警告和异常）使用适当的标准分类方案可以实现通用处理和升级流程。它还允许事态通知仅发送给负责处理与事态有关的进一步动作或决策的人员，通常是在事件，问题或变更管理实践中。避免向未直接参与事态处理的个人发送通知是对资源的有效利用。为此，事态通知将确定需要响应事态的部门，团体或个人。随着新事态的添加或人员职责变更，维护事态路由信息是一项连续不变的任务。
266
267 一个标准的事态分类方案将能够为每一类事态建立一套通用的操作。在价值流中，当对已识别的事态采取行动时，会考虑服务操作和服务级别目标。触发事件和问题通知的事态操作可以与事件和问题管理已建立的现有分类和优先级策略进行绑定。
268
269 许多IT 监控工具和EMS本身很可能由第三方供应商提供，监控和事态管理实践和供应商管理实践将保持稳定的工作关系。
270
271
272 === 2.4.2 确保将及时，相关且足够的监控数据提供给相关的利益相关者 ===
273
274 当根据原始服务设计和与客户达成的服务级别协议（SLA）进行基准校对时，监控和事态管理的报告能够使服务提供者的实际操作性能和行为基本真实。监控和事态管理提供了直接的观察结果、基于事实的经验证据，而不是预期或期望的结果。
275
276 收集监控和事态管理实践中准确及完整的数据对于使用服务时交付高质量服务和高质量客户体验的工作至关重要。服务度量（收集有关服务的数据）取决于监控和事态管理监控和报告。由于监控和事态管理专注于服务和服务组件的效果和效率，因此其对于持续改进的工作至关重要。
277
278 监控和事态管理确定了薄弱区域，因此可以采取补救行动（如果有正当的业务案例），以改进将来的服务质量。监控和事态管理还可以显示客户动作在哪里导致故障，并确定工作效率和/或培训可以在哪些地方得到改善。监控和事态管理还可以同时处理内部和外部供应商，因为他们的绩效必须得到评估和管理。
279
280
281 === 2.4.3 确保探测、解释事件，并在需要时尽快采取措施 ===
282
283 仅仅为监控和事态管理定义规则还不够，事态的实际探测和处理程序才能使这些规则有价值。事态管理的效率和范围在很大程度上取决于服务架构和服务管理自动化水平。在数字化基础设施和现代应用程序中，许多用于监控和事态管理的工具是内置的，实践的重点是事态处理规则的集成和调整。
284
285 与此相反，拥有许多不是为监控设计的遗留系统的组织必须将重点放在专用监控和事态管理工具和附加组件的实现上，或者甚至集中在手动监控和事态管理上。
286
287 技术机会和限制应告知监控和事态管理的范围、决策和日常活动。
288
289 不管组织的监控和事态管理功能有多有限，都应持续改进，以确保实践满足组织的需求。
290
291
292 == **2.5  关键指标** ==
293
294 ITIL实践是产品和服务管理的手段或工具。像任何工具的性能一样，只能在该工具的应用程序的环境中评估实践绩效。但是，不同工具在质量上可能有所不同。这种差异定义了工具根据其用途在使用时的能力或潜力。
295
296 这同样适用于实践：它们的绩效应在价值流的环境里评估，但其潜力由它们的设计和资源的质量来定义的。有关指标，KPI和其他可帮助解决此问题的技术的进一步指南，请参见度量和报告实践指南。
297
298 监控和事态管理实践的关键指标已映射到其实践成功因素（PSF）。它们可以用作价值流环境中的KPI，以评估监控和事态管理实践对那些价值流的效果和效率的贡献。表2.2中给出了一些关键指标的示例。
299
300 |**实践成功因素**|**指标样例**
301 |建立和维护描述各类事态的方法/模型以及检测这些事态所需要的监控能力|(((
302 * 利益相关者对监控和事态管理方法的满意度
303 * 组织对方法的坚持
304 * 未遵循或发现不切实际的方法建议/要求的百分比
305 )))
306 |确保向利益相关者提供及时、相关和充分的监控数据|(((
307 * 利益相关者对监控数据及其表述的满意度
308 * 监控数据的质量（根据商定的数据质量标准）
309 )))
310 |确保检测、解释事件，并在需要时尽快采取措施|(((
311 * 事态管理错误的影响
312 * 事态交流“噪音”的数量和影响
313 * 因为事态管理不善而无法预防或解决的事件和问题的影响
314 )))
315
316 表2.2 实践成功因素的示例指标
317
318 将指标正确汇总到复杂指标中将使它们更易用于价值流的持续管理，以及用于定期评估和持续改进监控和事态管理实践。没有单一的最佳解决方案。指标将基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。
319
320
321
322 ----
323
324 = **3 价值流和流程** =
325
326
327 == **3.1 价值流的贡献** ==
328
329 像其他ITIL 管理实践一样，监控和事态管理实践也有助于多个价值流。请记住，没有任何价值流是由单个实践组成。监控和事态管理实践与其他实践相结合，可以为消费者提供高质量的服务。
330
331 图3.1中显示了监控和事态实践对服务价值链的贡献。
332
333
334 [[image:微信截图_20210217171257.png]]
335
336 图3.1 监控和事态管理实践对价值链活动的贡献的热力图。
337
338
339 监控和事态管理实践贡献的主要价值链活动是：
340
341 * 交付和支持
342 * 设计和转换
343 * 改进
344
345 == **3.2 流程** ==
346
347 每个实践可包含一个或多个为实现该实践的目的而可能需要的流程和活动。
348
349 监控和事态管理实践活动形成三个流程：
350
351 * **监控规划流程 **这个流程在监控中添加元素，定义元素的优先级，选择要监控的功能，为事态分类建立指标和阈值，为事态与行动计划和负责团队建立映射关系。
352 * **事态处理流程**
353 * **监控和事态管理评审 **安排和触发该流程是为了评审主要事态事后分析、有关过滤和相关性分析的更新、服务“运行状况模型”、以及用于监控自动化和操作的改进。
354
355 === **3.2.1 监控规划** ===
356
357 |**关键输入**|**活动**|**关键输出**
358 |(((
359 服务设计的服务健康标准
360
361 服务级别协议
362
363 来自可用性、容量和性能管理实践中的服务性能阈值
364
365 知识文章
366
367 服务目录
368
369 配置项（CI） 数据
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 表3.1 监控规划流程的输入、活动和输出
395
396
397
398 [[image:图片3.png]]
399
400 图3.2 监控规划流程的工作流程
401
402
403
404 表3.2监控规划流程的活
405
406 |**活动**|**描述**
407 |定义监控目标|(((
408 利用从服务设计阶段、服务验证和测试实践以及服务开发（可用性，容量和性能管理实践）和服务级别管理实践收到的信息，团队定义监控的关键目标。
409
410 该讨论应覆盖功效需求到功用需求（首先涵盖最明显的功能要求，例如，在应用程序的用户案例中）。另外，从关键服务性能到更多详细信息和组件，它的颗粒度应增加。
411
412 团队应列出一个优先级降序的监控列表。
413 )))
414 |评估可用的度量监控标准|(((
415 然后，将监控优先级列表项映射或转换为可用度量或基于可用度量的综合度量。
416
417 应该探索添加度量值。
418 )))
419 |定义监控对象的事态类型|团队对不同类型的事态进行定义和分类。类型可以是一般性的，例如信息性，警告性，异常性，也可以取决于功能，用户组及其优先级，再通过关键监控目标的组件或类型进行划分。
420 |定义不同事态类型的阈值|(((
421 团队与服务或组件开发团队一起定义不同类型事态的阈值。相同的组件指标可能是根据现有的SLA和针对服务或组件定义的可用性，容量和性能的要求，它基于服务进行了不同的处理。
422
423 另外，应该将处理吞吐量的事态纳入考量，因为尽管现代IT系统几乎可以探测到任何事态，但不是所有事态都需要进行响应。因此，从最初预防灾难到后来完善组件，通常都应将监控和事态管理进行迭代开发。
424 )))
425 |定义服务'运行状况模型'（端到端事态）|(((
426 根据参与服务设计的团队的输入，构建了一个“运行状况模型”，它反映了服务及其关联的关键事态。一个服务可能有几种模型。
427
428 这些模型使监控团队可以评估服务的用户体验。例如，可以为单个银行客户交易构建模型，并度量从移动应用程序中的请求（包括所有银行数据库系统到移动应用程序中完成交易的通知）花费的时间。
429
430 服务“运行状况模型”也可以实现为服务健康和性能的报告或仪表板，并由服务所有者，参与其他实践的团队和其他利益相关者临时使用。这样，有关这些服务的信息就被干系人“拉”走了。
431 )))
432 |定义事态关联和规则集|(((
433 与参与服务设计的团队一起，定义事态关联和相应的规则集。
434
435 某些关联可能会使用第二个事态作为对第一个事态的检查，或者进一步过滤事态的范围。同样，已定义的关联可以帮助防止事态同时发生时可能产生的负面协同效应。
436
437 规则集由多个规则组成，这些规则定义了如何处理和评估特定事态的事态消息。例如，每次磁盘日志文件到达其容量时都可能生成警告事态，但是如果已生成四个以上的警告事件，则会生成异常事态。
438
439 规则本身通常嵌入监控和事态处理技术中。它们由布尔类型的算法组成，用于关联已生成的事态，以创建需要传达的其他事态。这些算法可以编入通常称为关联引擎的事态管理软件中。
440
441 人工智能（AI）系统可用于定义用户，管理员，系统等的典型和非典型行为。这可能形成其他检查以过滤事态。
442 )))
443 |将事态与行动计划、职能部门和通知对应起来|(((
444 对于每个事态或事态组，都定义了一个行动计划以尽量减少事态的负面影响。基于行动计划，可以定义响应事态的团队或职能部门。
445
446 行动计划还可以自动执行或半自动执行，包括对某些重要操作进行人工干预。
447
448 在此阶段创建的行动计划成为事态程序和自动化的基础。
449 )))
450
451 === 3.2.2 事态规划 ===
452
453 表3.3事态处理流程的输入、活动和输出
454
455 |**关键输入**|**活动**|**关键输出**
456 |(((
457 * 来自监控对象，监控工具的通知
458 * 监控计划
459 )))|(((
460 * 事态检测
461 * 事态日志记录
462 * 事态过滤和相关性检查（可能是迭代的）
463 * 事态分类
464 * 事态响应选择
465 * 发送通知，执行响应规程
466 )))|(((
467 * 事态记录
468 * 已更新的事态统计信息
469 * 事态响应错误
470 * 已启动的重大事态事后反思
471 * 利益干系人通知
472 * 知识文章更新
473 * 记录的事件
474 * 更新的报告和仪表板
475 )))
476
477 图3.3事态处理流程的工作流程
478
479 [[image:图片4.png]]
480
481
482
483 表3.4事态处理流程的活动
484
485 |**活动**|**描述**
486 |事态检测|(((
487 监控系统检测到的事态，或作为手动监控的结果。
488
489 并非所有事态都应被检测到，监控系统带宽也应纳入考量。在现有有限的资源中应仅检测到关键事件和需要采取行动的事态。
490 )))
491 |事态记录|事态应该最好自动记录在监控系统中。
492 |事态过滤和相关性检查（可能是迭代的）|(((
493 事态应该按照规则集进行处理，以过滤和查找相关性，以实现更好的分类。
494
495 该活动可能是迭代的。
496 )))
497 |事态分类|事态分为组或类型，如果需要选择适当的响应，则在组内进一步过滤特定的事态。
498 |事态响应选择|在监控规划流程中应该为每个事态制定行动计划或响应规程。根据规划中定义的规则，选择事态响应和通知的团队。
499 |发送通知，执行响应规程|响应规程执行后，将通知负责操作或监督的团队（如果响应规程是全自动的）。
500
501 |**关键输入**|**活动**|**关键输出**
502 |(((
503 * 更新的知识文章
504 * 重大事态记录
505 * 重大事件记录
506 * 改进建议
507 * 事态记录和统计
508 * 服务所有者和利益相关者的信息请求
509 )))|(((
510 * 评审重大事态和事件
511 * 评审过滤和相关性分析
512 * 评审服务“运行状态模式”
513 * 评估事态的响应程序和自动化程度
514 * 评审用于数据分析、相关性分析、人工智能（AI）和机器学习（ML）的工具
515 * 评审监控工具收集的统计信息
516 )))|(((
517 * 更新的事态响应程序
518 * 过滤和相关分析的改进建议
519 * 针对自动化的变更
520 * 更新的监控标准和阈值
521 * 更新的过滤方法
522 * 更新的被使用的工具和技术清单
523 * 更新的已提供的报告和统计信息清单
524 )))
525
526 === **3.2.3 监控和事态管理评审** ===
527
528 |活动|描述
529 |评审重大事态和事件|(((
530 事实上，重大事件发生通常可能意味着未检测到某些异常服务或组件行为并对其采取行动。因此，重大事态和事件为监控知识发现和改进提供了良好的基础。
531
532 应审查和分析重大事态的性质、相关性，并将其分解为组件甚至配置项，并应探索相应的指标，这些指标可能有助于检测导致重大事件的重大事态或异常。
533
534 应探索组件的其他或类似风险，并将已识别的事态添加到监控中。
535
536 建议对监控进行更改以在未来检测类似的事态。
537 )))
538 |(((
539 评审过滤和相关性分析的评审
540
541 评审服务的“运行状态模式”
542 )))|当监控检测到大量事态或检测不到事态时，应进行过滤和相关性分析。有时可以考虑采取临时措施，例如放宽阈值或事态分组。否则，应进行详细分析和详尽的规则定义，以及建议对监控进行更改。
543 |评估事态响应程序和自动化程度|(((
544 应评审因事态响应导致的事件和故障并提出变更建议。
545
546 同样，此评审的目标应是提高事态检测和事态响应的自动化程度。也可以建议其他的自动化。
547 )))
548 |评审用于数据分析、相关性分析、人工智能（AI）和机器学习（ML）的工具|(((
549 应审查内部和市场上可能提高监控效率的工具。应在监控预算内建议试用和试运行。
550
551 另外，此评审应该讨论监控中使用的任何新技术或最佳实践，应该进行市场基准测试的开发，并提出对监控的改进。
552 )))
553 |评审监控工具收集的统计信息|(((
554 应该审查统计信息，以提出对监控的改进，并监控服务。
555
556 服务生命周期涉及的所有团队均应评审检测到的服务趋势。
557 )))
558
559 表3.6 监控和事态管理评审流程的活动
560
561
562
563 ----
564
565 = **4 ** **组织和人员** =
566
567
568 == **4.1 角色，能力和责任** ==
569
570 实践指南没有描述实践管理的角色，例如实践所有者，实践领导者或实践教练。实践指南着重于每个实践的专家角色。每个角色的结构和命名都可能在组织间存在差异，因此ITIL中定义的任何角色都不应被视为强制性的，甚至不被视为建议。请记住，角色不是职务头衔。一个人可以担任多个角色，同样，一个角色可以分配给多个人。
571
572 流程和活动中描述了角色。每个角色可以基于以下能力框架模型进行描述：
573
574 |能力代码|描述
575 |**L**|**Leader 领导者** 与此能力相关的活动和技能包括决策、授权、监督其他活动、激励措施和动机、以及评估结果。
576 |**А**|**Administrator 管理员** 与此功能相关的活动和技能包括任务的分配和优先级，记录保存，持续报告以及基本改进计划。
577 |**C**|**Coordinator/Communicator 协调员/沟通者** 与此能力相关的活动和技能包括多方协调，利益相关方之间的沟通以及开展提高认识行动。
578 |**М**|**Methods and techniques expert 方法和技术专家** 与该能力相关的活动和技能包括设计和工作技术的实施，程序文档，有关流程的咨询，工作分析以及持续改进。
579 |**Т**|**Technical expert 技术专家** 此能力专注于技术（IT）专业知识和基于专业知识的任务。
580
581 |(% style="width:203px" %)活动|(% colspan="2" style="width:205px" %)负责角色|(% colspan="2" %)能力框架|**具体技能**
582 |(% colspan="6" %)监控规划流程
583 |(% style="width:203px" %)定义监控目标|(% style="width:199px" %)(((
584 服务负责人
585
586 设计人
587
588 开发人员
589
590 用户
591
592 交付经理
593
594 客户经理
595
596 测试人员
597
598 服务验证专家
599
600 运维经理
601 )))|(% colspan="2" %)协调员、管理员（CA）|(% colspan="2" %)(((
602 理解利益相关者的服务价值和服务主张
603
604 服务级别和用户体验方面的专业知识
605 )))
606 |(% style="width:203px" %)(((
607 评估可用的度量监控标准
608
609 定义监控对象的事态类型
610
611 定义不同事态类型的阈值
612 )))|(% style="width:199px" %)(((
613 测试人员
614
615 服务验证专家
616
617 监控专家
618
619 开发人员
620
621 设计人员
622
623 架构师
624
625 业务经理
626 )))|(% colspan="2" %)技术专家、方法技术专家（T M）|(% colspan="2" %)(((
627 服务架构和设计的知识
628
629 监控工具，探头探测器和传感器方面的专业知识
630 )))
631 |(% style="width:203px" %)(((
632 定义服务'运行状况模型'（端到端事件）
633
634 定义事件关联和规则集
635 )))|(% style="width:199px" %)(((
636 服务负责人
637
638 用户
639
640 交付经理
641
642 客户经理
643
644 运维经理
645
646 测试人员
647
648 服务验证专家
649
650 监控专家
651
652 开发人员
653
654 设计人员
655
656 架构师
657 )))|(% colspan="2" %)技术专家、方法技术专家、管理员（T M A）|(% colspan="2" %)(((
658 用户体验的知识
659
660 功效需求和功用需求的知识
661
662 服务主题和业务流程知识
663
664 服务架构和设计的知识
665
666 监控工具、探头探测器和传感器方面的专业知识
667 )))
668 |(% style="width:203px" %)建立行动计划和需要响应和通知的职能部门之间的映射关系|(% style="width:199px" %)(((
669 服务负责人
670
671 用户
672
673 交付经理
674
675 客户经理
676
677 测试人员
678
679 服务验证专家
680
681 监控专家
682
683 开发人员
684
685 设计人员
686
687 架构师
688 )))|(% colspan="2" %)管理员、技术专家、方法技术专家（A T M）|(% colspan="2" %)(((
689 运维和支持基础设施以及组织的知识
690
691 服务架构和设计的知识
692
693 监控工具以及探头探测器和传感器方面的专业知识
694 )))
695 |(% colspan="6" %)(((
696 事态处理流程
697
698 应尽一切努力使此流程尽可能自动化，因此将不讨论该流程的角色。
699 )))
700 |(% colspan="6" %)监控和事态管理评审
701 |(% style="width:203px" %)(((
702 评审重大事件或事态
703
704 评审过滤和相关性分析
705
706 评审服务“运行状况模式“
707 )))|(% style="width:199px" %)(((
708 服务负责人
709
710 用户
711
712 交付经理
713
714 客服经理
715
716 监控专家
717
718 开发人员
719
720 设计人员
721
722 架构师
723 )))|(% colspan="2" %)技术专家、方法技术专家、管理员（T M A）|(% colspan="2" %)(((
724 服务架构和设计的知识
725
726 监控工具方面的专业知识
727
728 服务主题知识和业务流程知识
729
730 持续改进技能
731 )))
732 |(% style="width:203px" %)评估事态的响应程序和自动化程度|(% style="width:199px" %)(((
733 服务负责人
734
735 交付经理
736
737 监控专家
738
739 开发人员
740
741 设计人员
742
743 架构师
744
745 服务台经理
746
747 运维经理
748 )))|(% colspan="2" %)管理员、技术专家、方法技术专家、协调员（ATMC）|(% colspan="2" %)(((
749 运维和支持基础设施以及组织的知识
750
751 监控工具方面的专业知识
752
753 自动化专业知识
754
755 服务主题知识和业务流程知识
756
757 持续改进技能
758 )))
759 |(% style="width:203px" %)评审用于数据分析、相关性分析、人工智能（AI）和机器学习（ML）的工具|(% style="width:199px" %)(((
760 监控专家
761
762 架构师
763
764 业务分析员
765
766 技术顾问
767 )))|(% colspan="2" %)方法技术专家、技术专家、管理员（MTA）|(% colspan="2" %)(((
768 监控工具，AI，ML方面的专业知识
769
770 自动化专业知识
771
772 持续改进技能
773 )))
774 |(% style="width:203px" %)评审监控工具收集的统计信息|(% style="width:199px" %)(((
775 监控专家
776
777 架构师
778
779 业务分析员
780 )))|(% colspan="2" %)方法技术专家、技术专家、管理员（M T A）|(% colspan="2" %)(((
781 服务架构和设计的知识
782
783 监控工具方面的专业知识
784
785 服务主题知识和业务流程知识
786
787 持续改进技能
788 )))
789
790 表4.1 监控和事态管理实践活动涉及的角色
791
792
793 == **4.2 组织结构和团队** ==
794
795
796 组织中很少有专门的监控和事态管理团队。通常，负责服务交付和运维的人员是参与监控的人员。
797
798 确保在服务生命周期的设计阶段规划监控是很重要的。因此，负责监控的人员应该参与设计阶段，开发服务或组件的团队可以将服务移交给运维和建立监控。这包括架构师，软件开发团队，基础设施团队，设计人员，负责服务验证、可用性、连续性、容量和性能的团队，等等。
799
800
801
802 ----
803
804 = **5 信息和技术** =
805
806
807 == **5.1 信息交流** ==
808
809
810 监控和事态管理实践的效果基于所使用信息的质量。该信息包括但不限于以下信息：
811
812 1. (((
813 客户和用户
814 )))
815 1. (((
816 服务，及其架构和设计，接受标准和SLA
817 )))
818 1. (((
819 合作伙伴和供应商，包括有关它们提供的服务的SLA信息
820 )))
821 1. (((
822 规范服务提供的政策和要求
823 )))
824 1. (((
825 持续的服务交付，包括：
826 )))
827
828 * 有关当前运行的服务状态的信息
829 * 服务功效需求和功用需求
830 * 可用的服务指标
831 * 服务依赖的配置项
832 * 服务组件与其性能之间的相互依赖性
833 * 有关重大事件的信息
834 * 与已计划的和正在进行的变更及其对服务性能的预期影响有关的信息
835 * 可用性，容量和性能目标
836 * 负责服务和组件的团队
837 * 有关服务的知识文章
838
839 6.有关服务改进状态的信息
840
841
842 该信息可以采用各种形式。实践的关键输入和输出在本指南的“ 价值流和流程”部分中列出。
843
844
845 == 5.2  自动化和工具 ==
846
847
848 在某些情况下，监控和事态管理实践的工作可以大大受益于自动化（有关何时适用的详细信息，请参见本指南的“ 价值流和流程”部分）。在这种情况下，自动化是可能且有效的，它可能涉及表5.1中概述的解决方案。
849
850 |流程活动|自动化手段|关键功能|实践的效果上的影响
851 |(% colspan="4" %)监控规划流程
852 |(((
853 定义监控目标
854
855 评估可用的度量监控标准
856
857 定义监控对象的事态类型
858 )))|(((
859 可视化工具（例如思维导图，服务图表，架构可视化）
860
861 服务目录工具
862
863 配置管理数据库
864 )))|(((
865 服务结构，依赖项，配置项等的可视化
866
867 提供有关服务结构的信息，以及
868
869 组件/ 服务的相互依赖性
870
871 提供有关
872
873 服务SLA和要求的信息
874 )))|中
875 |(((
876 定义不同事态类型的阈值
877
878 定义服务'运行状况模型'（端到端事件）
879
880 定义事态关联和规则集
881 )))|(((
882 监控和事态管理工具
883
884 ITSM工具
885
886 软件定义的基础设施工具
887
888 基础设施和平台内置的监控工具
889
890 服务可视化工具
891 )))|主动和被动性监控，事态设置，数据收集，数据分析，警报，规则设置|高
892 |建立行动计划和需要响应和通知的职能部门之间的映射关系|(((
893 监控和事态管理工具
894
895 ITSM工具
896
897 软件定义的基础设施工具
898
899 协作和通讯工具
900
901 集成总线
902
903 自动化系统
904
905 用于事态关联、行为监控与分析的AI和ML工具
906 )))|(((
907 ITSM工具集成（例如，基于事态的事件记录）
908
909 通知和通讯，任务创建。
910
911 自动化脚本运行
912
913 AI和ML 事态关联，正常/异常行为分析
914 )))|高
915 |(% colspan="4" %)事态处理流程
916 |(((
917 事态检测
918
919 事态日志记录
920
921 事态过滤和相关性检查（可能是迭代的）
922
923 事态分类
924
925 事态响应选择
926
927 发送通知、执行响应过程
928 )))|(((
929 监控和事态管理工具
930
931 ITSM工具
932
933 软件定义的基础设施工具
934
935 协作和
936
937 通讯工具
938
939 集成总线
940
941 自动化系统
942
943 报告和仪表板工具和门户
944 )))|(((
945 ITSM工具集成（例如，基于事态的事件记录）
946
947 通知和通讯，任务创建。
948
949 自动化脚本运行
950
951 AI和ML 事态关联，正常/异常行为分析
952
953 报告和仪表板发布
954 )))|高
955 |(% colspan="4" %)监控和事态管理评审
956 |(((
957 评审重大事件或事态
958
959 评审过滤和相关性分析
960
961 评审服务“运行状况模式“
962
963 评估事态的响应程序和自动化程度
964
965 评审用于数据分析、相关性分析、人工智能和机器学习的工具
966
967 评审监控工具收集的统计信息
968 )))|(((
969 可视化工具（例如思维导图，服务图表，架构可视化）
970
971 统计分析工具，数据库
972
973 服务目录工具
974
975 配置管理数据库
976
977 监控和事态管理工具
978
979 ITSM工具
980
981 协作和通讯工具
982
983 报告和仪表板工具和门户
984
985 业务分析工具
986
987 基准工具和
988
989 知识管理工具
990 )))|(((
991 服务结构，依赖项，配置项等的可视化
992
993 提供有关服务结构和组件/ 服务相互依赖关系的信息
994
995 提供有关服务SLA和要求，合规性和违规的信息
996
997 提供重大事件的信息
998
999 报告和仪表板发布
1000
1001 通知，聊天
1002
1003 分析和评估
1004
1005 知识共享
1006 )))|中
1007
1008 表5.1 监控和事态管理活动的自动化解决方案
1009
1010
1011
1012 ----
1013
1014 = **6  合作伙伴和供应商** =
1015
1016
1017 只有很少的服务是使用自己的资源提供的。大多数（如果不是全部）依赖于其他服务，这些服务通常由组织以外的第三方提供（请参阅ITIL//®//Foundation：ITIL 4 Edition出版物中的第2.4节，了解服务关系的模型）。支持服务在供应商管理的实践指南中介绍了关系和依赖性。
1018
1019 通信和云服务的开发使得外部监控服务非常受欢迎。配置项像服务器，数据库实例可以安装监控代理并将信息输入云存储库。这样的解决方案使其他使用了AI和机器学习（ML）的分析变得更容易，更便宜。这种解决方案中的机器学习（ML）通过合并来自数千个监控对象的数据以及对系统和用户的正常和异常行为理解的不断修正而得到改进。
1020
1021 另一个重要的考量是涉及到外包服务和组件监控权限的问题，因此组织会控制与服务提供者达成共识的度量标准。
1022
1023 此外，必须将外部供应商开发的所有服务设计为具有监控功能，这意味着设计的服务必须能够提供有关其性能和运行状态的信息。
1024
1025 当组织旨在确保监控和事态管理快速有效时，他们通常会试图同意与合作伙伴和供应商的密切合作，消除沟通，协作和决策方面的正式官僚障碍。有关更多信息，请参考供应商管理实践指南。
1026
1027
1028
1029 ----
1030
1031 = **7  重要提醒** =
1032
1033
1034 实践指南的大部分内容都应作为组织在建立和发展自己的实践时可能考虑的领域的建议。实践指南是组织可能考虑的事情的目录，而不是答案的列表。使用ITIL 实践指南的内容时，组织应始终遵循ITIL 指导原则：
1035
1036 1. 聚焦价值
1037 1. 从你所处的地方开始
1038 1. 基于反馈迭代推进
1039 1. 协作和提升可视化程度
1040 1. 整体性思考和工作
1041 1. 保持简单实用
1042 1. 优化和自动化。
1043
1044 有关指导原则及其应用程序的更多信息，请参见以下内容的第4.3节：
1045
1046 //ITIL®Foundation：ITIL 4Edition//.
1047
1048
1049
1050 ----
1051
1052 = **8  致谢** =
1053
1054
1055 AXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
1056
1057
1058 == **8.1 作者** ==
1059
1060 Dennis Cotter .
1061
1062
1063 == **8.2 审稿人** ==
1064
1065 Roman Jouravlev.
深圳市艾拓先锋企业管理咨询有限公司