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