Version 45.2 by superadmin on 2024/03/07, 12:30
Show last authors
1 如有[[ITIL认证>>url:http://www.itilchina.cn/achotsao/vip_doc/13354653.html]]、[[ITIL培训>>url:http://www.itilchina.cn/achotsao/vip_doc/13354653.html]]或[[ITIL考试>>url:http://www.itilchina.cn/achotsao/vip_doc/13354653.html]]需求，可[[点击了解详情>>url:http://www.itilchina.cn/achotsao/vip_doc/13354653.html]]
2
3
4 **申明：**
5
6 本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注微信公众号：ITILXF，并回复“**监控和事态管理**”即可。
7
8 {{box cssClass="floatinginfobox" title="**Contents**"}}
9 {{toc/}}
10 {{/box}}
11
12
13 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
14
15
16 翻译：刘祥发  审校：冯广成  审核： 徐建中
17
18 (% class="row" %)
19 (((
20 (% class="col-xs-12 col-sm-4" %)
21 (((
22
23 )))
24 )))
25
26 = **1 关于本文件** =
27
28 本文件为监控和事态管理实践提供了实用指南。它分为五个主要部分，内容包括：
29
30 * 有关实践的一般信息
31 * 监控和事态管理的流程和活动及其在服务价值链中的角色
32 * 监控和事态管理中涉及的组织和人员
33 * 支持监控和事态管理的信息和技术
34 * 合作伙伴和供应商对监控和事态管理的思考
35
36 == **1.1** **ITIL®4 认证体系** ==
37
38 本文件所选内容可作为以下教学大纲的一部分进行考查：
39
40 * ITIL专业人员：创建、交付和支持
41 * ITIL专业人员：指导、计划和改进
42
43 有关详细信息，请参阅相应的教学大纲文件。
44
45
46
47 ----
48
49 = **2 一般信息** =
50
51
52 == **2.1 目的和描述** ==
53
54
55 监控和事态管理实践的目的是系统地观察服务和服务组件，将其状态变化识别为事态并进行记录和报告。该实践识别基础设施、服务、业务流程和信息安全等事态，确定其优先级，建立对这些事态的适当响应，包括对可能导致潜在故障或事件的条件作出响应。
56
57
58 |(((
59 **事态**
60
61 对服务或其他配置项（CI）的管理具有重要意义的任何状态变更。
62 )))
63
64 监控和事态管理用于管理整个生命周期中的事态，以了解和优化它们对组织及其服务的影响。监控和事态管理包括识别、聚类或者分析与所有级别的基础设施相关的事态、以及组织及其服务使用者之间的服务交互。监控和事态管理确保对这些事态做出适当及时的响应。
65
66 本实践的监控部分专注于服务和配置项（CIs），以探测潜在的重要情况、跟踪和记录服务和配置项（CIs）的状态，并将此信息提供给相关方。
67
68 本实践的事态管理部分着重于那些由组织定义为事态的被监控的状态变化，确定其重要性，识别并启动对它们的正确响应。有关事态的信息也会被记录、存储并提供给相关方。
69
70 监控和事态管理的数据和信息是许多实践的重要输入，包括：
71
72 * 事件管理
73 * 问题管理
74 * 信息安全管理
75 * 可用性管理
76 * 性能和容量管理
77 * 变更支持
78 * 风险管理
79 * 基础设施和平台管理
80 * 软件开发和管理
81 * 其他
82
83 有一个关键点，监控是事态管理发生所必需的，但并非所有的监控都会检测到事态。阈值和其他准则确定哪些状态更改将被视为事态。同样，另一个重要的关注点就是，并非所有事态具有相同的重要性或需要相同的响应。准则将定义发生的事态属于什么类别。按照重要性增加的顺序，典型的事态类别是信息、警告和异常。
84
85
86 == **2.2 **术语和概念 ==
87
88
89 |(((
90 **监控**
91
92 通过对系统、实践、流程、服务或其他实体的重复观察，探测事态并确保已知其当前状态。
93 )))
94
95 了解服务的状态和服务组件对于管理它们至关重要。有关服务运行状态和性能的信息使组织能够对已发生的对服务造成影响的事态做出适当的响应（响应式监控），或者根据对过去事件的模式分析采取主动行动，以防止将来面临不利事态（预防式监控）。
96
97 监控通过多种不同的方式得以实现。配置项（CIs）可以通过轮询（即响应监控工具收集特定目标数据的请求）或通过在满足某些条件时自动通知监控工具来共享有关其自身的信息。监控工具对服务组件的询问代表着主动监控，而配置项（CIs）向监控工具发送的通知代表着被动监控。
98
99 (% style="text-align:center" %)
100 [[image:图片1.png]]
101
102
103 图2.1 监控的类型
104
105
106 注意事项：当使用主动监控来识别趋势时，它可能有助于比被动监控更早地识别趋势（监控工具在配置项自身发送信息之前先请求信息）。但是，当使用主动监控来检测事态时，它可能比被动监控迟一些：在主动监控中，信息是根据计划收集的，但是，被动监控中，配置项会在事态发生变化之后立即共享它。本注意事项的重要性取决于主动监控是连续的还是基于间隔的。需重要强调的是，从监控工具到服务和配置项的请求之间的间隔时间越长，事态与其注册之间的潜在延迟就越长。
107
108 监控利用了被观察的服务组件的本机监控功能。例如，有关操作系统（OS）的数据（例如磁盘空间，CPU负载，交换使用情况等）已经由OS公开，并指示底层物理资源的使用情况。同样，许多Web服务器，数据库服务器和其他软件都具有内置的监控功能，并将生成度量数据。所有这些数据都可以轻松发送到监控工具。
109
110 除了本机监控功能外，监控还采用了专门设计的监控系统。这些是用于监视Web和云应用程序、基础设施、网络、平台、应用程序和微服务的定制软件功能。对于某些服务组件，尤其是内部开发的应用程序，可能有必要向服务中添加自定义工具，例如，代码或接口，这些代码或接口收集并公开对于组织非常重要的度量数据。
111
112 尽管监控和事态管理传统上专注于服务的技术组件，但对了解其他服务管理资源和活动（包括流程，人员和供应商）的状态也很有用。
113
114
115 |(((
116 **指标**
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 * 一小时内出现X个以上磁盘错误
148 * CPU利用率达到或超过N％三次，任何两个连续事态之间的间隔小于Z秒
149
150 |(((
151 **警报**
152
153 通知已到达阈值、已更改某些内容或已发生故障。
154 )))
155
156 警报由监控工具创建和控制，并在监控和事态管理实践中管理。报警是监控系统的一个非常重要的方面。报警系统必须具有几个特征，包括：
157
158 * 高度可靠
159 * 灵活，并可以通过多种媒体通知操作员
160 * 能够生成详细且可行的通知消息
161
162 对于监控和事态管理，“过度报警”是潜在的危险。出现这样一种情况：即生成的警报数量超出企业的处理能力，真正重要的警报却被遗漏在“警报噪音”中。如今，通过人工智能操作（AIOps）和机器学习（ML）可以对警报进行聚合、关联和过滤，从而为这种潜在的危险提供了补救措施。
163
164 服务和服务组件的状态变更在IT 环境中连续发生。如该实践中所述，通常可以通过IT服务，CI或监控工具创建的通知来识别这些变更。为了正确处理和响应数据流，有必要对传入的信息进行过滤和分类。
165
166 根据事态的影响将事态分为三个事态组，并定义三个相应的响应：信息，警告或异常。
167
168 * 信息类事态在被识别后，不需要进行响应。信息类事态提供设备或服务的状态，或确认某个任务的状态。信息类事态的示例包括：用户登录，操作完成等。信息类事态表示正在执行常规操作，并存储在日志文件中一段时间。组织可以选择在以后分析信息事态，并且可能发现有益于服务的预防措施。信息类事态也可以在状态仪表板上发布给供服务提供者或服务消费者使用。
169 * 警告类事态可以在经历任何负面的影响之前采取行动。警告类事态表示发生了非常规但没有抛出异常的操作。警告类事态通知相应的团队或工具采取必要的措施，以防止发生异常。警告的示例包括：计划备份未运行，或者资源利用率在约定异常阈值的10％之内。
170 * 异常类事态表示已达到服务或组件指标的关键阈值。这一违反服务或组件性能既定规范的行为可能尚未对业务运营产生影响，但是，异常事态也可能表示服务或组件发生故障，性能
171
172 下降或功能丧失，而所有这些都将会影响业务运营。无论哪种情况，异常事态都需要进行响应，因为它们表示常规操作正在发生异常。异常事态的示例包括：计算机扫描显示未授权软件的安装、服务器关闭、备份失败等。这是监控和事态管理实践启用事件检测的方式。
173
174 事态分类将注意力集中在对服务的管理和交付真正重要的事态上。它确保适当地跟踪、评估和管理事态。
175
176 监控和事态管理能够检测事件，将其与信息事态及警告区分开。检测到的事件在事件管理实践中处理。监控和事态管理还通过提供有关影响服务和服务组件的趋势和事态的信息来识别问题。此外，监控和事态管理通过服务和服务组件的监控和汇报机制为已知错误进行错误控制。已识别的问题和已知错误的错误控制在问题管理实践中处理。
177
178
179 == **2.3 范围** ==
180
181 监控和事态管理实践的范围涵盖了组织内需要控制和自动化的服务管理的所有方面。这包括：
182
183 * 识别和优化监控的范围
184 * 实施和维护连续监控
185 * 建立和维护事态的识别，分类和处理规则
186 * 实施流程和自动化工具使已定义的事态管理规则产生作用
187 * 根据议定和实施的规则以及流程对事件进行持续处理
188 * 以商定的形式向利益相关者提供受监控服务和资源的当前和历史状态的信息。
189
190 尽管有些活动和责任领域仍然与监控和事态管理实践密切相关，但它们并没有被包含其中。表2.1中列出了它们以及那些包含了它们的实践的相关引用。重要的是要记住，ITIL实践只是那些在价值流环境中被使用的工具的集合，应根据情况进行必要的组合。
191
192 (% style="width:476px" %)
193 |(% style="width:320px" %)活动|(% style="width:153px" %)实践指南
194 |(% style="width:320px" %)事件的管理|(% style="width:153px" %)事件管理
195 |(% style="width:320px" %)事态和趋势的原因调查|(% style="width:153px" %)问题管理
196 |(% style="width:320px" %)响应事态的变更管理|(% style="width:153px" %)变更支持
197 |(% style="width:320px" %)与用户沟通|(% style="width:153px" %)服务台
198 |(% style="width:320px" %)基于监控数据的决策支持|(% style="width:153px" %)度量和报告
199 |(% style="width:320px" %)设置服务质量和性能的目标和阈值|(% style="width:153px" %)(((
200 服务级别管理
201
202 可用性管理
203
204 性能和容量管理
205
206 信息安全管理
207
208 连续性管理
209 )))
210 |(% style="width:320px" %)设置基础设施和应用程序组件的阈值|(% style="width:153px" %)(((
211 基础设施和平台管理
212
213 软件开发和管理
214 )))
215 |(% style="width:320px" %)设定第三方服务的目标和门槛|(% style="width:153px" %)供应商管理
216
217 表2.1其他实践指南中描述的与监控和事态管理相关的活动
218
219
220 == **2.4 实践成功因素** ==
221
222
223 实践的成功因素（PSF）不仅仅是一项任务或活动；它包括服务管理四维模型的所有组件。实践成功因素活动和资源的性质可能彼此有所不同，但它们共同确保实践有效。
224
225 监控和事态管理实践包含以下实践成功因素活动(PSF)：
226
227 * 建立和维护描述各类型事态和探测它们所需的监控功能的方法/模型
228 * 确保及时，相关且足够的监控数据提供给相关的利益相关者
229 * 确保发现、解释事态，并在需要时尽快采取措施
230
231 === **2.4.1 建立和维护描述各类事态和探测它们所需的监控功能的方法/模型** ===
232
233 在大多数情况下，现代技术为度量和监控服务以及服务组件操作的各个方面提供了机会，但是从业人员应认真管理监控的范围以及度量指标的频率和数量。现代监控和事态管理实践的主要挑战不是缺少数据，而是监控必须处理的数据的规模。监控和事态管理实践的重点应该是获取有意义的信息，以支持服务的操作与改进，决策和价值的创造。建立或改进监控和事态管理实践时，应考虑以下方面：
234
235 * 识别所监控的服务和服务组件并划分优先级
236
237 实践的关键活动在于确定哪些实体需要监控并划分优先级，这有助于检测状态更改（或缺少所需的状态更改），这些更改对于CI的服务的管理最重要。确定要监视的服务，系统，CI和其他服务组件将基于组织的业务目标。它还需要对组织的服务设计架构有透彻的了解。
238
239 监控和事态管理的从业者将需要了解服务依赖映射关系：哪些顶级业务功能映射到支持那些功能的产品和服务，而哪些产品和服务映射到支持该产品和服务的底层IT基础设施。通过对交付服务所涉及的实体有一个完整的端到端的描述，，监控和事态管理的从业人员将能够正确识别需要监控的关键实体并确定其优先级。
240
241 这里，还应该评估服务组件的“可监控性”，并定义一套有效的标准。所选择的标准应该具有足够的揭示性，并为诊断和决策提供依据。
242
243 * 在监控的信息性，颗粒度和频率之间找到平衡
244
245 建立和维护对服务组件的监控可以视为对资源（监控工具，数据存储，工时等）的投资，并且捕获的数据越多，预期的回报就越少。这是因为监控的规则数量和探测频率越多，用于过滤、分类和分析数据的时间和精力就越多。虽然自动化和基于机器学习的解决方案有助于释放人工和改进数据分析的结果，但从业人员应始终致力于使监控效率最高。
246
247 * 维护数据收集，存储，过滤和关联的能力。监控和事态管理实践很大程度上依赖于服务管理的信息和技术层面。如果没有观察到服务和服务组件的本机监控功能，或没有IT 监控工具（一般广泛通用的商业工具以及定制工具），则几乎不可能检测到对CI或服务管理具有重要意义的状态变化。
248
249 服务元素通过轮询（即响应监控工具的询问来收集特定的目标数据），或者在某些条件被满足时通过自动化的通知发送给监控工具，来传达有关自身的信息。该通信取决于监控工具的可用性和传输事态数据的网络。
250
251 另外，应该特别注意执行数据分类、过滤和关联的工具，以及用于事态响应的自动化工具。
252
253 单个服务的许多服务架构通常由组织集成的第三方产品和服务组成，以向客户和用户提供端到端服务。这些第三方产品和服务的内置监控功能是监控和事态管理实践的关键部分。监控和事态管理从业人员以及服务设计实践中的同行需要能够与他们的设备和服务供应商频繁且良好地合作。这样，监控和事态管理和服务设计可以保护构成组织服务的必要产品和服务，并确保这些服务是可监视和可管理的。
254
255 为事态确定适当的控制动作取决于对检测到的状态变化的过滤和分类。信息和技术服务维度中发生的过滤和分类在很大程度上由组织的事态管理系统（EMS）自动完成，IT 监控工具将检测到的、收集的和传输的信息馈送到其中。但是，EMS用于对数据进行过滤和分类，并确定它们的重要性（确定数据代表信息，警告还是异常事态）的业务规则已建立在服务管理的组织和人员维度中。监控工具和EMS配置的阈值，警报参数，准则都是组织优先级以及那些为服务生态系统的健康运营而工作的有经验的领导者和工作人员的成果。
256
257 需要制定策略来处理不同类型的事态。对事态采取“一刀切”的做法是不合适的，而且浪费资源。不同类型的事态需要针对该事态的类型量身定制对应的响应。应该为每个事态类建立一套通用的控制操作。当适用自动响应时、当适用告警和需要升级为人为干预时、或当事件/问题/变更需要启动处理时，都可以通过制定策略来解决。例如，在某个安全违规的情境中，它可能对运营有潜在的影响，但尚未影响服务的可用性。
258
259 策略在组织和人员维度中定义，并在信息和技术维度中实施。
260
261 为事态（例如信息，警告和异常）使用适当的标准分类方案可以实现通用处理和升级流程。它还允许事态通知仅发送给负责处理与事态有关的进一步动作或决策的人员，通常是在事件，问题或变更管理实践中。避免向未直接参与事态处理的个人发送通知是对资源的有效利用。为此，事态通知将确定需要响应事态的部门，团体或个人。随着新事态的添加或人员职责变更，维护事态路由信息是一项连续不变的任务。
262
263 一个标准的事态分类方案将能够为每一类事态建立一套通用的操作。在价值流中，当对已识别的事态采取行动时，会考虑服务操作和服务级别目标。触发事件和问题通知的事态操作可以与事件和问题管理已建立的现有分类和优先级策略进行绑定。
264
265 许多IT 监控工具和EMS本身很可能由第三方供应商提供，监控和事态管理实践和供应商管理实践将保持稳定的工作关系。
266
267
268 === **2.4.2 确保将及时，相关且足够的监控数据提供给相关的利益相关者** ===
269
270 当根据原始服务设计和与客户达成的服务级别协议（SLA）进行基准校对时，监控和事态管理的报告能够使服务提供者的实际操作性能和行为基本真实。监控和事态管理提供了直接的观察结果、基于事实的经验证据，而不是预期或期望的结果。
271
272 收集监控和事态管理实践中准确及完整的数据对于使用服务时交付高质量服务和高质量客户体验的工作至关重要。服务度量（收集有关服务的数据）取决于监控和事态管理监控和报告。由于监控和事态管理专注于服务和服务组件的效果和效率，因此其对于持续改进的工作至关重要。
273
274 监控和事态管理确定了薄弱区域，因此可以采取补救行动（如果有正当的业务案例），以改进将来的服务质量。监控和事态管理还可以显示客户动作在哪里导致故障，并确定工作效率和/或培训可以在哪些地方得到改善。监控和事态管理还可以同时处理内部和外部供应商，因为他们的绩效必须得到评估和管理。
275
276
277 === **2.4.3 确保探测、解释事件，并在需要时尽快采取措施** ===
278
279 仅仅为监控和事态管理定义规则还不够，事态的实际探测和处理程序才能使这些规则有价值。事态管理的效率和范围在很大程度上取决于服务架构和服务管理自动化水平。在数字化基础设施和现代应用程序中，许多用于监控和事态管理的工具是内置的，实践的重点是事态处理规则的集成和调整。
280
281 与此相反，拥有许多不是为监控设计的遗留系统的组织必须将重点放在专用监控和事态管理工具和附加组件的实现上，或者甚至集中在手动监控和事态管理上。
282
283 技术机会和限制应告知监控和事态管理的范围、决策和日常活动。
284
285 不管组织的监控和事态管理功能有多有限，都应持续改进，以确保实践满足组织的需求。
286
287
288 == **2.5  关键指标** ==
289
290 ITIL实践是产品和服务管理的手段或工具。像任何工具的性能一样，只能在该工具的应用程序的环境中评估实践绩效。但是，不同工具在质量上可能有所不同。这种差异定义了工具根据其用途在使用时的能力或潜力。
291
292 这同样适用于实践：它们的绩效应在价值流的环境里评估，但其潜力由它们的设计和资源的质量来定义的。有关指标，KPI和其他可帮助解决此问题的技术的进一步指南，请参见度量和报告实践指南。
293
294 监控和事态管理实践的关键指标已映射到其实践成功因素（PSF）。它们可以用作价值流环境中的KPI，以评估监控和事态管理实践对那些价值流的效果和效率的贡献。表2.2中给出了一些关键指标的示例。
295
296 (% style="width:923px" %)
297 |(% style="width:503px" %)**实践成功因素**|(% style="width:418px" %)**指标样例**
298 |(% style="width:503px" %)建立和维护描述各类事态的方法/模型以及检测这些事态所需要的监控能力|(% style="width:418px" %)(((
299 * 利益相关者对监控和事态管理方法的满意度
300 * 组织对方法的坚持
301 * 未遵循或发现不切实际的方法建议/要求的百分比
302 )))
303 |(% style="width:503px" %)确保向利益相关者提供及时、相关和充分的监控数据|(% style="width:418px" %)(((
304 * 利益相关者对监控数据及其表述的满意度
305 * 监控数据的质量（根据商定的数据质量标准）
306 )))
307 |(% style="width:503px" %)确保检测、解释事件，并在需要时尽快采取措施|(% style="width:418px" %)(((
308 * 事态管理错误的影响
309 * 事态交流“噪音”的数量和影响
310 * 因为事态管理不善而无法预防或解决的事件和问题的影响
311 )))
312
313 表2.2 实践成功因素的示例指标
314
315 将指标正确汇总到复杂指标中将使它们更易用于价值流的持续管理，以及用于定期评估和持续改进监控和事态管理实践。没有单一的最佳解决方案。指标将基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。
316
317
318
319 ----
320
321 = **3 价值流和流程** =
322
323
324 == **3.1 价值流的贡献** ==
325
326 像其他ITIL 管理实践一样，监控和事态管理实践也有助于多个价值流。请记住，没有任何价值流是由单个实践组成。监控和事态管理实践与其他实践相结合，可以为消费者提供高质量的服务。
327
328 图3.1中显示了监控和事态实践对服务价值链的贡献。
329
330
331 (% style="text-align:center" %)
332 [[image:微信截图_20210217171257.png]]
333
334 图3.1 监控和事态管理实践对价值链活动的贡献的热力图。
335
336
337 监控和事态管理实践贡献的主要价值链活动是：
338
339 * 交付和支持
340 * 设计和转换
341 * 改进
342
343 == **3.2 流程** ==
344
345 每个实践可包含一个或多个为实现该实践的目的而可能需要的流程和活动。
346
347 监控和事态管理实践活动形成三个流程：
348
349 * **监控规划流程 **这个流程在监控中添加元素，定义元素的优先级，选择要监控的功能，为事态分类建立指标和阈值，为事态与行动计划和负责团队建立映射关系。
350 * **事态处理流程**
351 * **监控和事态管理评审 **安排和触发该流程是为了评审主要事态事后分析、有关过滤和相关性分析的更新、服务“运行状况模型”、以及用于监控自动化和操作的改进。
352
353 === **3.2.1 监控规划** ===
354
355 |**关键输入**|**活动**|**关键输出**
356 |(((
357 服务设计的服务健康标准
358
359 服务级别协议
360
361 来自可用性、容量和性能管理实践中的服务性能阈值
362
363 知识文章
364
365 服务目录
366
367 配置项（CI） 数据
368 )))|(((
369 定义监控目标
370
371 评估可用的度量监控标准
372
373 定义监控对象的事态类型
374
375 定义不同事态类型的阈值
376
377 定义服务'运行状况模型'（端到端事态）
378
379 定义事态关联和规则集
380
381 建立行动计划与需要响应和通知的职能部门之间的映射关系
382 )))|(((
383 目标监控计划
384
385 服务健康状态模型
386
387 已定义的事态类型、事态检测标准、事态的优先级以及响应措施
388
389 事态责任矩阵
390 )))
391
392 表3.1 监控规划流程的输入、活动和输出
393
394
395
396 (% style="text-align:center" %)
397 [[image:图片3.png]]
398
399 图3.2 监控规划流程的工作流程
400
401
402
403 表3.2监控规划流程的活动
404
405 [[image:1642237641108-965.png]]
406
407 [[image:1642237710166-351.png]]
408
409 [[image:1642237738910-108.png]]
410
411
412
413 === **3.2.2 事态规划** ===
414
415 表3.3事态处理流程的输入、活动和输出
416
417 [[image:1642238606576-143.png]]
418
419 图3.3事态处理流程的工作流程
420
421
422 (% style="text-align:center" %)
423 [[image:图片4.png]]
424
425
426
427 表3.4事态处理流程的活动
428
429 [[image:1642237833826-395.png]]
430
431 [[image:1642237866153-106.png]]
432
433
434
435 === **3.2.3 监控和事态管理评审** ===
436
437 [[image:1642237945213-442.png]]
438
439 表3.6 监控和事态管理评审流程的活动
440
441
442
443 ----
444
445 = **4 ** **组织和人员** =
446
447
448 == **4.1 角色，能力和责任** ==
449
450 实践指南没有描述实践管理的角色，例如实践所有者，实践领导者或实践教练。实践指南着重于每个实践的专家角色。每个角色的结构和命名都可能在组织间存在差异，因此ITIL中定义的任何角色都不应被视为强制性的，甚至不被视为建议。请记住，角色不是职务头衔。一个人可以担任多个角色，同样，一个角色可以分配给多个人。
451
452 流程和活动中描述了角色。每个角色可以基于以下能力框架模型进行描述：
453
454 |能力代码|描述
455 |**L**|**Leader 领导者** 与此能力相关的活动和技能包括决策、授权、监督其他活动、激励措施和动机、以及评估结果。
456 |**А**|**Administrator 管理员** 与此功能相关的活动和技能包括任务的分配和优先级，记录保存，持续报告以及基本改进计划。
457 |**C**|**Coordinator/Communicator 协调员/沟通者** 与此能力相关的活动和技能包括多方协调，利益相关方之间的沟通以及开展提高认识行动。
458 |**М**|**Methods and techniques expert 方法和技术专家** 与该能力相关的活动和技能包括设计和工作技术的实施，程序文档，有关流程的咨询，工作分析以及持续改进。
459 |**Т**|**Technical expert 技术专家** 此能力专注于技术（IT）专业知识和基于专业知识的任务。
460
461 [[image:1642237990168-323.png]]
462
463 [[image:1642238024237-336.png]]
464
465 [[image:1642238202293-164.png]]
466
467 [[image:1642238225338-195.png]]
468
469 [[image:1642238253882-729.png]]
470
471 表4.1 监控和事态管理实践活动涉及的角色
472
473
474 == **4.2 组织结构和团队** ==
475
476
477 组织中很少有专门的监控和事态管理团队。通常，负责服务交付和运维的人员是参与监控的人员。
478
479 确保在服务生命周期的设计阶段规划监控是很重要的。因此，负责监控的人员应该参与设计阶段，开发服务或组件的团队可以将服务移交给运维和建立监控。这包括架构师，软件开发团队，基础设施团队，设计人员，负责服务验证、可用性、连续性、容量和性能的团队，等等。
480
481
482
483 ----
484
485 = **5 信息和技术** =
486
487
488 == **5.1 信息交流** ==
489
490
491 监控和事态管理实践的效果基于所使用信息的质量。该信息包括但不限于以下信息：
492
493 1. (((
494 客户和用户
495 )))
496 1. (((
497 服务，及其架构和设计，接受标准和SLA
498 )))
499 1. (((
500 合作伙伴和供应商，包括有关它们提供的服务的SLA信息
501 )))
502 1. (((
503 规范服务提供的政策和要求
504 )))
505 1. (((
506 持续的服务交付，包括：
507 )))
508
509 * 有关当前运行的服务状态的信息
510 * 服务功效需求和功用需求
511 * 可用的服务指标
512 * 服务依赖的配置项
513 * 服务组件与其性能之间的相互依赖性
514 * 有关重大事件的信息
515 * 与已计划的和正在进行的变更及其对服务性能的预期影响有关的信息
516 * 可用性，容量和性能目标
517 * 负责服务和组件的团队
518 * 有关服务的知识文章
519
520 6.有关服务改进状态的信息
521
522
523 该信息可以采用各种形式。实践的关键输入和输出在本指南的“ 价值流和流程”部分中列出。
524
525
526 == **5.2  自动化和工具** ==
527
528
529 在某些情况下，监控和事态管理实践的工作可以大大受益于自动化（有关何时适用的详细信息，请参见本指南的“ 价值流和流程”部分）。在这种情况下，自动化是可能且有效的，它可能涉及表5.1中概述的解决方案。
530
531 [[image:1642238337737-961.png]]
532
533 [[image:1642238364744-334.png]]
534
535 [[image:1642238466365-934.png]]
536
537 [[image:1642238480595-735.png]]
538
539 表5.1 监控和事态管理活动的自动化解决方案
540
541
542
543 ----
544
545 = **6  合作伙伴和供应商** =
546
547
548 只有很少的服务是使用自己的资源提供的。大多数（如果不是全部）依赖于其他服务，这些服务通常由组织以外的第三方提供（请参阅ITIL//®//Foundation：ITIL 4 Edition出版物中的第2.4节，了解服务关系的模型）。支持服务在供应商管理的实践指南中介绍了关系和依赖性。
549
550 通信和云服务的开发使得外部监控服务非常受欢迎。配置项像服务器，数据库实例可以安装监控代理并将信息输入云存储库。这样的解决方案使其他使用了AI和机器学习（ML）的分析变得更容易，更便宜。这种解决方案中的机器学习（ML）通过合并来自数千个监控对象的数据以及对系统和用户的正常和异常行为理解的不断修正而得到改进。
551
552 另一个重要的考量是涉及到外包服务和组件监控权限的问题，因此组织会控制与服务提供者达成共识的度量标准。
553
554 此外，必须将外部供应商开发的所有服务设计为具有监控功能，这意味着设计的服务必须能够提供有关其性能和运行状态的信息。
555
556 当组织旨在确保监控和事态管理快速有效时，他们通常会试图同意与合作伙伴和供应商的密切合作，消除沟通，协作和决策方面的正式官僚障碍。有关更多信息，请参考供应商管理实践指南。
557
558
559
560 ----
561
562 = **7  重要提醒** =
563
564
565 实践指南的大部分内容都应作为组织在建立和发展自己的实践时可能考虑的领域的建议。实践指南是组织可能考虑的事情的目录，而不是答案的列表。使用ITIL 实践指南的内容时，组织应始终遵循ITIL 指导原则：
566
567 * 聚焦价值
568 * 从你所处的地方开始
569 * 基于反馈迭代推进
570 * 协作和提升可视化程度
571 * 整体性思考和工作
572 * 保持简单实用
573 * 优化和自动化。
574
575 有关指导原则及其应用程序的更多信息，请参见以下内容的第4.3节：
576
577 //ITIL®Foundation：ITIL 4Edition//.
578
579
580
581 ----
582
583 = **8  致谢** =
584
585
586 AXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
587
588
589 == **8.1 作者** ==
590
591 Dennis Cotter .
592
593
594 == **8.2 审稿人** ==
595
596 Roman Jouravlev.
深圳市艾拓先锋企业管理咨询有限公司