Wiki源代码05 监控和事态管理实践

Version 39.1 by superadmin on 2022/01/15, 17:20

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

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司