05 监控和事态管理（尚未发布）

注意事项：当使用主动监控来识别趋势时，它可能有助于比被动监控更早地识别趋势（监控工具在配置项自身发送信息之前先请求信息）。但是，当使用主动监控来检测事态时，它可能比被动监控迟一些：在主动监控中，信息是根据计划收集的，但是，被动监控中，配置项会在事态发生变化之后立即共享它。本注意事项的重要性取决于主动监控是连续的还是基于间隔的。需重要强调的是，从监控工具到服务和配置项的请求之间的间隔时间越长，事态与其注册之间的潜在延迟就越长。

111

112

监控利用了被观察的服务组件的本机监控功能。例如，有关操作系统（OS）的数据（例如磁盘空间，CPU负载，交换使用情况等）已经由OS公开，并指示底层物理资源的使用情况。同样，许多Web服务器，数据库服务器和其他软件都具有内置的监控功能，并将生成度量数据。所有这些数据都可以轻松发送到监控工具。

113

114

除了本机监控功能外，监控还采用了专门设计的监控系统。这些是用于监视Web和云应用程序、基础设施、网络、平台、应用程序和微服务的定制软件功能。对于某些服务组件，尤其是内部开发的应用程序，可能有必要向服务中添加自定义工具，例如，代码或接口，这些代码或接口收集并公开对于组织非常重要的度量数据。

115

116

尽管监控和事态管理传统上专注于服务的技术组件，但对了解其他服务管理资源和活动（包括流程，人员和供应商）的状态也很有用。

|(((

**指标**

为了管理和改进而监控或报告的度量或计算。

)))

指标是监控和事态管理实践的原始数据的来源。监控系统收集、汇总和分析度量指标数据。指标涵盖多个层次，包括：

125

126

* 低级基础设施指标（主机、服务器、网络和其他）

127

* 应用程序指标（响应时间、错误率、资源使用情况…）

128

* 服务级别指标，包括基于基础设施、连接性、应用程序以及基于服务动作的指标（如果适用）

129

* 第三方服务绩效指标（基于商定的服务级别）

* 操作、流程和价值流绩效指标

|(((

**阈值**

触发预定义响应的指标值。

)))

对阈值的响应各不相同，可能包括：

* 创建一个警报或其他通知

* 创建一个事件

* 变更先前记录的警报或通知的状态

* 响应各自组件或服务

阈值是一种初始过滤可通过监控工具收集的大量监控数据的方法。阈值的值应谨慎定义，以防止产生过多的响应，从而超越资源，人力和机器的响应能力。处理度量数据的其他规则通常与阈值结合，例如事态相关规则和引擎。这些可以由组件供应商规定，由组织定义，或由机器学习支持。

监控和事态管理中的一些阈值示例可以是：

* 一小时内出现X个以上磁盘错误

* CPU利用率达到或超过N％三次，任何两个连续事态之间的间隔小于Z秒

|(((

**警报**

通知已到达阈值、已更改某些内容或已发生故障。

157

)))

158

159

警报由监控工具创建和控制，并在监控和事态管理实践中管理。报警是监控系统的一个非常重要的方面。报警系统必须具有几个特征，包括：

* 高度可靠

* 灵活，并可以通过多种媒体通知操作员

* 能够生成详细且可行的通知消息

对于监控和事态管理，“过度报警”是潜在的危险。出现这样一种情况：即生成的警报数量超出企业的处理能力，真正重要的警报却被遗漏在“警报噪音”中。如今，通过人工智能操作（AIOps）和机器学习（ML）可以对警报进行聚合、关联和过滤，从而为这种潜在的危险提供了补救措施。

166

167

服务和服务组件的状态变更在IT 环境中连续发生。如该实践中所述，通常可以通过IT服务，CI或监控工具创建的通知来识别这些变更。为了正确处理和响应数据流，有必要对传入的信息进行过滤和分类。

168

169

根据事态的影响将事态分为三个事态组，并定义三个相应的响应：信息，警告或异常。

170

171

* 信息类事态在被识别后，不需要进行响应。信息类事态提供设备或服务的状态，或确认某个任务的状态。信息类事态的示例包括：用户登录，操作完成等。信息类事态表示正在执行常规操作，并存储在日志文件中一段时间。组织可以选择在以后分析信息事态，并且可能发现有益于服务的预防措施。信息类事态也可以在状态仪表板上发布给供服务提供者或服务消费者使用。

172

* 警告类事态可以在经历任何负面的影响之前采取行动。警告类事态表示发生了非常规但没有抛出异常的操作。警告类事态通知相应的团队或工具采取必要的措施，以防止发生异常。警告的示例包括：计划备份未运行，或者资源利用率在约定异常阈值的10％之内。

173

* 异常类事态表示已达到服务或组件指标的关键阈值。这一违反服务或组件性能既定规范的行为可能尚未对业务运营产生影响，但是，异常事态也可能表示服务或组件发生故障，性能

174

175

下降或功能丧失，而所有这些都将会影响业务运营。无论哪种情况，异常事态都需要进行响应，因为它们表示常规操作正在发生异常。异常事态的示例包括：计算机扫描显示未授权软件的安装、服务器关闭、备份失败等。这是监控和事态管理实践启用事件检测的方式。

176

177

事态分类将注意力集中在对服务的管理和交付真正重要的事态上。它确保适当地跟踪、评估和管理事态。

178

179

监控和事态管理能够检测事件，将其与信息事态及警告区分开。检测到的事件在事件管理实践中处理。监控和事态管理还通过提供有关影响服务和服务组件的趋势和事态的信息来识别问题。此外，监控和事态管理通过服务和服务组件的监控和汇报机制为已知错误进行错误控制。已识别的问题和已知错误的错误控制在问题管理实践中处理。

== **2.3 范围** ==

监控和事态管理实践的范围涵盖了组织内需要控制和自动化的服务管理的所有方面。这包括：

* 识别和优化监控的范围

* 实施和维护连续监控

* 建立和维护事态的识别，分类和处理规则

* 实施流程和自动化工具使已定义的事态管理规则产生作用

190

* 根据议定和实施的规则以及流程对事件进行持续处理

191

* 以商定的形式向利益相关者提供受监控服务和资源的当前和历史状态的信息。

192

193

尽管有些活动和责任领域仍然与监控和事态管理实践密切相关，但它们并没有被包含其中。表2.1中列出了它们以及那些包含了它们的实践的相关引用。重要的是要记住，ITIL实践只是那些在价值流环境中被使用的工具的集合，应根据情况进行必要的组合。

|活动|实践指南

|事件的管理|事件管理

|事态和趋势的原因调查|问题管理

|响应事态的变更管理|变更支持

|与用户沟通|服务台

|基于监控数据的决策支持|度量和报告

|设置服务质量和性能的目标和阈值|(((

服务级别管理

可用性管理

性能和容量管理

信息安全管理

连续性管理

)))

|设置基础设施和应用程序组件的阈值|(((

基础设施和平台管理

软件开发和管理

)))

|设定第三方服务的目标和门槛|供应商管理

表2.1其他实践指南中描述的与监控和事态管理相关的活动

== **2.4 实践成功因素** ==

实践的成功因素（PSF）不仅仅是一项任务或活动；它包括服务管理四维模型的所有组件。实践成功因素活动和资源的性质可能彼此有所不同，但它们共同确保实践有效。

226

227

监控和事态管理实践包含以下实践成功因素活动(PSF)：

228

229

* 建立和维护描述各类型事态和探测它们所需的监控功能的方法/模型

230

* 确保及时，相关且足够的监控数据提供给相关的利益相关者

231

* 确保发现、解释事态，并在需要时尽快采取措施

232

233

=== 2.4.1 建立和维护描述各类事态和探测它们所需的监控功能的方法/模型 ===

234

235

在大多数情况下，现代技术为度量和监控服务以及服务组件操作的各个方面提供了机会，但是从业人员应认真管理监控的范围以及度量指标的频率和数量。现代监控和事态管理实践的主要挑战不是缺少数据，而是监控必须处理的数据的规模。监控和事态管理实践的重点应该是获取有意义的信息，以支持服务的操作与改进，决策和价值的创造。建立或改进监控和事态管理实践时，应考虑以下方面：

236

237

* 识别所监控的服务和服务组件并划分优先级

238

239

实践的关键活动在于确定哪些实体需要监控并划分优先级，这有助于检测状态更改（或缺少所需的状态更改），这些更改对于CI的服务的管理最重要。确定要监视的服务，系统，CI和其他服务组件将基于组织的业务目标。它还需要对组织的服务设计架构有透彻的了解。

240

241

监控和事态管理的从业者将需要了解服务依赖映射关系：哪些顶级业务功能映射到支持那些功能的产品和服务，而哪些产品和服务映射到支持该产品和服务的底层IT基础设施。通过对交付服务所涉及的实体有一个完整的端到端的描述，，监控和事态管理的从业人员将能够正确识别需要监控的关键实体并确定其优先级。

242

243

这里，还应该评估服务组件的“可监控性”，并定义一套有效的标准。所选择的标准应该具有足够的揭示性，并为诊断和决策提供依据。

244

245

* 在监控的信息性，颗粒度和频率之间找到平衡

246

247

建立和维护对服务组件的监控可以视为对资源（监控工具，数据存储，工时等）的投资，并且捕获的数据越多，预期的回报就越少。这是因为监控的规则数量和探测频率越多，用于过滤、分类和分析数据的时间和精力就越多。虽然自动化和基于机器学习的解决方案有助于释放人工和改进数据分析的结果，但从业人员应始终致力于使监控效率最高。

248

249

* 维护数据收集，存储，过滤和关联的能力。监控和事态管理实践很大程度上依赖于服务管理的信息和技术层面。如果没有观察到服务和服务组件的本机监控功能，或没有IT 监控工具（一般广泛通用的商业工具以及定制工具），则几乎不可能检测到对CI或服务管理具有重要意义的状态变化。

250

251

服务元素通过轮询（即响应监控工具的询问来收集特定的目标数据），或者在某些条件被满足时通过自动化的通知发送给监控工具，来传达有关自身的信息。该通信取决于监控工具的可用性和传输事态数据的网络。

252

253

另外，应该特别注意执行数据分类、过滤和关联的工具，以及用于事态响应的自动化工具。

254

255

单个服务的许多服务架构通常由组织集成的第三方产品和服务组成，以向客户和用户提供端到端服务。这些第三方产品和服务的内置监控功能是监控和事态管理实践的关键部分。监控和事态管理从业人员以及服务设计实践中的同行需要能够与他们的设备和服务供应商频繁且良好地合作。这样，监控和事态管理和服务设计可以保护构成组织服务的必要产品和服务，并确保这些服务是可监视和可管理的。

256

257

为事态确定适当的控制动作取决于对检测到的状态变化的过滤和分类。信息和技术服务维度中发生的过滤和分类在很大程度上由组织的事态管理系统（EMS）自动完成，IT 监控工具将检测到的、收集的和传输的信息馈送到其中。但是，EMS用于对数据进行过滤和分类，并确定它们的重要性（确定数据代表信息，警告还是异常事态）的业务规则已建立在服务管理的组织和人员维度中。监控工具和EMS配置的阈值，警报参数，准则都是组织优先级以及那些为服务生态系统的健康运营而工作的有经验的领导者和工作人员的成果。

258

259

需要制定策略来处理不同类型的事态。对事态采取“一刀切”的做法是不合适的，而且浪费资源。不同类型的事态需要针对该事态的类型量身定制对应的响应。应该为每个事态类建立一套通用的控制操作。当适用自动响应时、当适用告警和需要升级为人为干预时、或当事件/问题/变更需要启动处理时，都可以通过制定策略来解决。例如，在某个安全违规的情境中，它可能对运营有潜在的影响，但尚未影响服务的可用性。

260

261

策略在组织和人员维度中定义，并在信息和技术维度中实施。

262

263

为事态（例如信息，警告和异常）使用适当的标准分类方案可以实现通用处理和升级流程。它还允许事态通知仅发送给负责处理与事态有关的进一步动作或决策的人员，通常是在事件，问题或变更管理实践中。避免向未直接参与事态处理的个人发送通知是对资源的有效利用。为此，事态通知将确定需要响应事态的部门，团体或个人。随着新事态的添加或人员职责变更，维护事态路由信息是一项连续不变的任务。

264

265

一个标准的事态分类方案将能够为每一类事态建立一套通用的操作。在价值流中，当对已识别的事态采取行动时，会考虑服务操作和服务级别目标。触发事件和问题通知的事态操作可以与事件和问题管理已建立的现有分类和优先级策略进行绑定。

266

267

许多IT 监控工具和EMS本身很可能由第三方供应商提供，监控和事态管理实践和供应商管理实践将保持稳定的工作关系。

268

269

270

=== 2.4.2 确保将及时，相关且足够的监控数据提供给相关的利益相关者 ===

271

272

当根据原始服务设计和与客户达成的服务级别协议（SLA）进行基准校对时，监控和事态管理的报告能够使服务提供者的实际操作性能和行为基本真实。监控和事态管理提供了直接的观察结果、基于事实的经验证据，而不是预期或期望的结果。

273

274

收集监控和事态管理实践中准确及完整的数据对于使用服务时交付高质量服务和高质量客户体验的工作至关重要。服务度量（收集有关服务的数据）取决于监控和事态管理监控和报告。由于监控和事态管理专注于服务和服务组件的效果和效率，因此其对于持续改进的工作至关重要。

275

276

监控和事态管理确定了薄弱区域，因此可以采取补救行动（如果有正当的业务案例），以改进将来的服务质量。监控和事态管理还可以显示客户动作在哪里导致故障，并确定工作效率和/或培训可以在哪些地方得到改善。监控和事态管理还可以同时处理内部和外部供应商，因为他们的绩效必须得到评估和管理。

277

278

279

=== 2.4.3 确保探测、解释事件，并在需要时尽快采取措施 ===

280

281

仅仅为监控和事态管理定义规则还不够，事态的实际探测和处理程序才能使这些规则有价值。事态管理的效率和范围在很大程度上取决于服务架构和服务管理自动化水平。在数字化基础设施和现代应用程序中，许多用于监控和事态管理的工具是内置的，实践的重点是事态处理规则的集成和调整。

282

283

与此相反，拥有许多不是为监控设计的遗留系统的组织必须将重点放在专用监控和事态管理工具和附加组件的实现上，或者甚至集中在手动监控和事态管理上。

284

285

技术机会和限制应告知监控和事态管理的范围、决策和日常活动。

286

287

不管组织的监控和事态管理功能有多有限，都应持续改进，以确保实践满足组织的需求。

== **2.5 关键指标** ==

ITIL实践是产品和服务管理的手段或工具。像任何工具的性能一样，只能在该工具的应用程序的环境中评估实践绩效。但是，不同工具在质量上可能有所不同。这种差异定义了工具根据其用途在使用时的能力或潜力。

293

294

这同样适用于实践：它们的绩效应在价值流的环境里评估，但其潜力由它们的设计和资源的质量来定义的。有关指标，KPI和其他可帮助解决此问题的技术的进一步指南，请参见度量和报告实践指南。

295

296

监控和事态管理实践的关键指标已映射到其实践成功因素（PSF）。它们可以用作价值流环境中的KPI，以评估监控和事态管理实践对那些价值流的效果和效率的贡献。表2.2中给出了一些关键指标的示例。

297

298

|**实践成功因素**|**指标样例**

299

|建立和维护描述各类事态的方法/模型以及检测这些事态所需要的监控能力|(((

300

* 利益相关者对监控和事态管理方法的满意度

301

* 组织对方法的坚持

302

* 未遵循或发现不切实际的方法建议/要求的百分比

303

)))

304

|确保向利益相关者提供及时、相关和充分的监控数据|(((

305

* 利益相关者对监控数据及其表述的满意度

306

* 监控数据的质量（根据商定的数据质量标准）

307

)))

308

|确保检测、解释事件，并在需要时尽快采取措施|(((

309

* 事态管理错误的影响

310

* 事态交流“噪音”的数量和影响

311

* 因为事态管理不善而无法预防或解决的事件和问题的影响

)))

表2.2 实践成功因素的示例指标

将指标正确汇总到复杂指标中将使它们更易用于价值流的持续管理，以及用于定期评估和持续改进监控和事态管理实践。没有单一的最佳解决方案。指标将基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。

----

= **3 价值流和流程** =

== **3.1 价值流的贡献** ==

像其他ITIL 管理实践一样，监控和事态管理实践也有助于多个价值流。请记住，没有任何价值流是由单个实践组成。监控和事态管理实践与其他实践相结合，可以为消费者提供高质量的服务。

328

329

图3.1中显示了监控和事态实践对服务价值链的贡献。

330

331

[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml15296\wps8.png]]

332

333

图3.1 监控和事态管理实践对价值链活动的贡献的热力图。

334

335

[[image:微信截图_20210217171257.png]]

336

337

338

监控和事态管理实践贡献的主要价值链活动是：

* 交付和支持

* 设计和转换

* 改进

== **3.2 流程** ==

每个实践可包含一个或多个为实现该实践的目的而可能需要的流程和活动。

监控和事态管理实践活动形成三个流程：

* **监控规划流程 **这个流程在监控中添加元素，定义元素的优先级，选择要监控的功能，为事态分类建立指标和阈值，为事态与行动计划和负责团队建立映射关系。

351

* **事态处理流程**

352

* **监控和事态管理评审 **安排和触发该流程是为了评审主要事态事后分析、有关过滤和相关性分析的更新、服务“运行状况模型”、以及用于监控自动化和操作的改进。

353

354

=== **3.2.1 监控规划** ===

355

356

|**关键输入**|**活动**|**关键输出**

|(((

服务设计的服务健康标准

服务级别协议

来自可用性、容量和性能管理实践中的服务性能阈值

知识文章

服务目录

配置项（CI）数据

)))|(((

定义监控目标

评估可用的度量监控标准

定义监控对象的事态类型

定义不同事态类型的阈值

定义服务'运行状况模型'（端到端事态）

定义事态关联和规则集

建立行动计划与需要响应和通知的职能部门之间的映射关系

)))|(((

目标监控计划

服务健康状态模型

已定义的事态类型、事态检测标准、事态的优先级以及响应措施

事态责任矩阵

)))

表3.1 监控规划流程的输入、活动和输出

[[image:图片3.png]]

图3.2 监控规划流程的工作流程

表3.2监控规划流程的活

|**活动**|**描述**

|定义监控目标|(((

利用从服务设计阶段、服务验证和测试实践以及服务开发（可用性，容量和性能管理实践）和服务级别管理实践收到的信息，团队定义监控的关键目标。

406

407

该讨论应覆盖功效需求到功用需求（首先涵盖最明显的功能要求，例如，在应用程序的用户案例中）。另外，从关键服务性能到更多详细信息和组件，它的颗粒度应增加。

团队应列出一个优先级降序的监控列表。

)))

|评估可用的度量监控标准|(((

然后，将监控优先级列表项映射或转换为可用度量或基于可用度量的综合度量。

应该探索添加度量值。

)))

|定义监控对象的事态类型|团队对不同类型的事态进行定义和分类。类型可以是一般性的，例如信息性，警告性，异常性，也可以取决于功能，用户组及其优先级，再通过关键监控目标的组件或类型进行划分。

417

|定义不同事态类型的阈值|(((

418

团队与服务或组件开发团队一起定义不同类型事态的阈值。相同的组件指标可能是根据现有的SLA和针对服务或组件定义的可用性，容量和性能的要求，它基于服务进行了不同的处理。

419

420

另外，应该将处理吞吐量的事态纳入考量，因为尽管现代IT系统几乎可以探测到任何事态，但不是所有事态都需要进行响应。因此，从最初预防灾难到后来完善组件，通常都应将监控和事态管理进行迭代开发。

421

)))

422

|定义服务'运行状况模型'（端到端事态）|(((

423

根据参与服务设计的团队的输入，构建了一个“运行状况模型”，它反映了服务及其关联的关键事态。一个服务可能有几种模型。

424

425

这些模型使监控团队可以评估服务的用户体验。例如，可以为单个银行客户交易构建模型，并度量从移动应用程序中的请求（包括所有银行数据库系统到移动应用程序中完成交易的通知）花费的时间。

426

427

服务“运行状况模型”也可以实现为服务健康和性能的报告或仪表板，并由服务所有者，参与其他实践的团队和其他利益相关者临时使用。这样，有关这些服务的信息就被干系人“拉”走了。

428

)))

429

|定义事态关联和规则集|(((

430

与参与服务设计的团队一起，定义事态关联和相应的规则集。

431

432

某些关联可能会使用第二个事态作为对第一个事态的检查，或者进一步过滤事态的范围。同样，已定义的关联可以帮助防止事态同时发生时可能产生的负面协同效应。

433

434

规则集由多个规则组成，这些规则定义了如何处理和评估特定事态的事态消息。例如，每次磁盘日志文件到达其容量时都可能生成警告事态，但是如果已生成四个以上的警告事件，则会生成异常事态。

435

436

规则本身通常嵌入监控和事态处理技术中。它们由布尔类型的算法组成，用于关联已生成的事态，以创建需要传达的其他事态。这些算法可以编入通常称为关联引擎的事态管理软件中。

437

438

人工智能（AI）系统可用于定义用户，管理员，系统等的典型和非典型行为。这可能形成其他检查以过滤事态。

439

)))

440

|将事态与行动计划、职能部门和通知对应起来|(((

441

对于每个事态或事态组，都定义了一个行动计划以尽量减少事态的负面影响。基于行动计划，可以定义响应事态的团队或职能部门。

442

443

行动计划还可以自动执行或半自动执行，包括对某些重要操作进行人工干预。

444

445

在此阶段创建的行动计划成为事态程序和自动化的基础。

)))

=== 3.2.2 事态规划 ===

表3.3事态处理流程的输入、活动和输出

|**关键输入**|**活动**|**关键输出**

|(((

* 来自监控对象，监控工具的通知

* 监控计划

)))|(((

* 事态检测

* 事态日志记录

* 事态过滤和相关性检查（可能是迭代的）

* 事态分类

* 事态响应选择

* 发送通知，执行响应规程

)))|(((

* 事态记录

* 已更新的事态统计信息

* 事态响应错误

* 已启动的重大事态事后反思

* 利益干系人通知

* 知识文章更新

* 记录的事件

* 更新的报告和仪表板

)))

图3.3事态处理流程的工作流程

[[image:图片4.png]]

[[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml15296\wps11.jpg]]

表3.4事态处理流程的活动

|**活动**|**描述**

|事态检测|(((

监控系统检测到的事态，或作为手动监控的结果。

486

487

并非所有事态都应被检测到，监控系统带宽也应纳入考量。在现有有限的资源中应仅检测到关键事件和需要采取行动的事态。

488

)))

489

|事态记录|事态应该最好自动记录在监控系统中。

490

|事态过滤和相关性检查（可能是迭代的）|(((

491

事态应该按照规则集进行处理，以过滤和查找相关性，以实现更好的分类。

该活动可能是迭代的。

)))

|事态分类|事态分为组或类型，如果需要选择适当的响应，则在组内进一步过滤特定的事态。

496

|事态响应选择|在监控规划流程中应该为每个事态制定行动计划或响应规程。根据规划中定义的规则，选择事态响应和通知的团队。

497

|发送通知，执行响应规程|响应规程执行后，将通知负责操作或监督的团队（如果响应规程是全自动的）。

498

499

|**关键输入**|**活动**|**关键输出**

|(((

* 更新的知识文章

* 重大事态记录

* 重大事件记录

* 改进建议

* 事态记录和统计

* 服务所有者和利益相关者的信息请求

)))|(((

* 评审重大事态和事件

* 评审过滤和相关性分析

* 评审服务“运行状态模式”

* 评估事态的响应程序和自动化程度

* 评审用于数据分析、相关性分析、人工智能（AI）和机器学习（ML）的工具

* 评审监控工具收集的统计信息

)))|(((

* 更新的事态响应程序

* 过滤和相关分析的改进建议

* 针对自动化的变更

* 更新的监控标准和阈值

* 更新的过滤方法

* 更新的被使用的工具和技术清单

* 更新的已提供的报告和统计信息清单

)))

=== **3.2.3 监控和事态管理评审** ===

|活动|描述

|评审重大事态和事件|(((

事实上，重大事件发生通常可能意味着未检测到某些异常服务或组件行为并对其采取行动。因此，重大事态和事件为监控知识发现和改进提供了良好的基础。

529

530

应审查和分析重大事态的性质、相关性，并将其分解为组件甚至配置项，并应探索相应的指标，这些指标可能有助于检测导致重大事件的重大事态或异常。

531

532

应探索组件的其他或类似风险，并将已识别的事态添加到监控中。

533

534

建议对监控进行更改以在未来检测类似的事态。

)))

|(((

评审过滤和相关性分析的评审

评审服务的“运行状态模式”

)))|当监控检测到大量事态或检测不到事态时，应进行过滤和相关性分析。有时可以考虑采取临时措施，例如放宽阈值或事态分组。否则，应进行详细分析和详尽的规则定义，以及建议对监控进行更改。

541

|评估事态响应程序和自动化程度|(((

542

应评审因事态响应导致的事件和故障并提出变更建议。

543

544

同样，此评审的目标应是提高事态检测和事态响应的自动化程度。也可以建议其他的自动化。

545

)))

546

|评审用于数据分析、相关性分析、人工智能（AI）和机器学习（ML）的工具|(((

547

应审查内部和市场上可能提高监控效率的工具。应在监控预算内建议试用和试运行。

548

549

另外，此评审应该讨论监控中使用的任何新技术或最佳实践，应该进行市场基准测试的开发，并提出对监控的改进。

550

)))

551

|评审监控工具收集的统计信息|(((

552

应该审查统计信息，以提出对监控的改进，并监控服务。

553

554

服务生命周期涉及的所有团队均应评审检测到的服务趋势。

555

)))

556

557

**表3.6 监控和事态管理评审流程的活动**

----

= 4 **组织和人员** =

== **4.1 角色，能力和责任** ==

567

568

**实践指南没有描述实践管理的角色，例如实践所有者，实践领导者或实践教练。实践指南着重于每个实践的专家角色。每个角色的结构和命名都可能在组织间存在差异，因此ITIL中定义的任何角色都不应被视为强制性的，甚至不被视为建议。请记住，角色不是职务头衔。一个人可以担任多个角色，同样，一个角色可以分配给多个人。**

569

570

**流程和活动中描述了角色。每个角色可以基于以下能力框架模型进行描述：**

571

572

|**能力代码**|**描述**

573

|**L**|**Leader 领导者** 与此能力相关的活动和技能包括决策、授权、监督其他活动、激励措施和动机、以及评估结果。

574

|**А**|**Administrator 管理员** 与此功能相关的活动和技能包括任务的分配和优先级，记录保存，持续报告以及基本改进计划。

575

|**C**|**Coordinator/Communicator 协调员/沟通者** 与此能力相关的活动和技能包括多方协调，利益相关方之间的沟通以及开展提高认识行动。

576

|**М**|**Methods and techniques expert 方法和技术专家** 与该能力相关的活动和技能包括设计和工作技术的实施，程序文档，有关流程的咨询，工作分析以及持续改进。

577

|**Т**|**Technical expert 技术专家** 此能力专注于技术（IT）专业知识和基于专业知识的任务。

578

579

|(% style="width:203px" %)**活动**|(% colspan="2" style="width:205px" %)**负责角色**|(% colspan="2" %)**能力框架**|**具体技能**

580

|(% colspan="6" %)**监控规划流程**

581

|(% style="width:203px" %)**定义监控目标**|(% style="width:199px" %)(((

**服务负责人**

**设计人**

**开发人员**

**用户**

**交付经理**

**客户经理**

**测试人员**

**服务验证专家**

**运维经理**

)))|(% colspan="2" %)**协调员、管理员（CA）**|(% colspan="2" %)(((

600

**理解利益相关者的服务价值和服务主张**

**服务级别和用户体验方面的专业知识**

)))

|(% style="width:203px" %)(((

**评估可用的度量监控标准**

**定义监控对象的事态类型**

**定义不同事态类型的阈值**

)))|(% style="width:199px" %)(((

**测试人员**

**服务验证专家**

**监控专家**

**开发人员**

**设计人员**

**架构师**

**业务经理**

)))|(% colspan="2" %)**技术专家、方法技术专家（T M）**|(% colspan="2" %)(((

625

**服务架构和设计的知识**

626

627

**监控工具，探头探测器和传感器方面的专业知识**

628

)))

629

|(% style="width:203px" %)(((

630

**定义服务'运行状况模型'（端到端事件）**

631

632

**定义事件关联和规则集**

633

)))|(% style="width:199px" %)(((

**服务负责人**

**用户**

**交付经理**

**客户经理**

**运维经理**

**测试人员**

**服务验证专家**

**监控专家**

**开发人员**

**设计人员**

**架构师**

)))|(% colspan="2" %)**技术专家、方法技术专家、管理员（T M A）**|(% colspan="2" %)(((

**用户体验的知识**

**功效需求和功用需求的知识**

**服务主题和业务流程知识**

**服务架构和设计的知识**

**监控工具、探头探测器和传感器方面的专业知识**

665

)))

666

|(% style="width:203px" %)**建立行动计划和需要响应和通知的职能部门之间的映射关系**|(% style="width:199px" %)(((

**服务负责人**

**用户**

**交付经理**

**客户经理**

**测试人员**

**服务验证专家**

**监控专家**

**开发人员**

**设计人员**

**架构师**

)))|(% colspan="2" %)**管理员、技术专家、方法技术专家（A T M）**|(% colspan="2" %)(((

**运维和支持基础设施以及组织的知识**

**服务架构和设计的知识**

**监控工具以及探头探测器和传感器方面的专业知识**

692

)))

693

|(% colspan="6" %)(((

694

**事态处理流程**

695

696

**应尽一切努力使此流程尽可能自动化，因此将不讨论该流程的角色。**

697

)))

698

|(% colspan="6" %)**监控和事态管理评审**

699

|(% style="width:203px" %)(((

**评审重大事件或事态**

**评审过滤和相关性分析**

**评审服务“运行状况模式“**

)))|(% style="width:199px" %)(((

**服务负责人**

**用户**

**交付经理**

**客服经理**

**监控专家**

**开发人员**

**设计人员**

**架构师**

)))|(% colspan="2" %)**技术专家、方法技术专家、管理员（T M A）**|(% colspan="2" %)(((

**服务架构和设计的知识**

**监控工具方面的专业知识**

**服务主题知识和业务流程知识**

**持续改进技能**

)))

|(% style="width:203px" %)**评估事态的响应程序和自动化程度**|(% style="width:199px" %)(((

**服务负责人**

**交付经理**

**监控专家**

**开发人员**

**设计人员**

**架构师**

**服务台经理**

**运维经理**

)))|(% colspan="2" %)**管理员、技术专家、方法技术专家、协调员（ATMC）**|(% colspan="2" %)(((

**运维和支持基础设施以及组织的知识**

**监控工具方面的专业知识**

**自动化专业知识**

**服务主题知识和业务流程知识**

**持续改进技能**

)))

|(% style="width:203px" %)**评审用于数据分析、相关性分析、人工智能（AI）和机器学习（ML）的工具**|(% style="width:199px" %)(((

**监控专家**

**架构师**

**业务分析员**

**技术顾问**

)))|(% colspan="2" %)**方法技术专家、技术专家、管理员（MTA）**|(% colspan="2" %)(((

766

**监控工具，AI，ML方面的专业知识**

**自动化专业知识**

**持续改进技能**

)))

|(% style="width:203px" %)**评审监控工具收集的统计信息**|(% style="width:199px" %)(((

**监控专家**

**架构师**

**业务分析员**

)))|(% colspan="2" %)**方法技术专家、技术专家、管理员（M T A）**|(% colspan="2" %)(((

**服务架构和设计的知识**

**监控工具方面的专业知识**

**服务主题知识和业务流程知识**

**持续改进技能**

)))

**表4.1 监控和事态管理实践活动涉及的角色**

789

790

791

== **4.2 组织结构和团队** ==

792

793

794

**组织中很少有专门的监控和事态管理团队。通常，负责服务交付和运维的人员是参与监控的人员。**

795

796

**确保在服务生命周期的设计阶段规划监控是很重要的。因此，负责监控的人员应该参与设计阶段，开发服务或组件的团队可以将服务移交给运维和建立监控。这包括架构师，软件开发团队，基础设施团队，设计人员，负责服务验证、可用性、连续性、容量和性能的团队，等等。**

----

= **5 信息和技术** =

== **5.1 信息交流** ==

**监控和事态管理实践的效果基于所使用信息的质量。该信息包括但不限于以下信息：**

1. (((

**客户和用户**

)))

1. (((

**服务，及其架构和设计，接受标准和SLA**

815

)))

816

1. (((

817

**合作伙伴和供应商，包括有关它们提供的服务的SLA信息**

)))

1. (((

**规范服务提供的政策和要求**

)))

1. (((

**持续的服务交付，包括：**

)))

* **有关当前运行的服务状态的信息**

* **服务功效需求和功用需求**

* **可用的服务指标**

* **服务依赖的配置项**

* **服务组件与其性能之间的相互依赖性**

831

* **有关重大事件的信息**

832

* **与已计划的和正在进行的变更及其对服务性能的预期影响有关的信息**

* **可用性，容量和性能目标**

* **负责服务和组件的团队**

* **有关服务的知识文章**

**~ 6.有关服务改进状态的信息**

**该信息可以采用各种形式。实践的关键输入和输出在本指南的“ 价值流和流程”部分中列出。**

== **5.2 自动化和工具** ==

**在某些情况下，监控和事态管理实践的工作可以大大受益于自动化（有关何时适用的详细信息，请参见本指南的“ 价值流和流程”部分）。在这种情况下，自动化是可能且有效的，它可能涉及表5.1中概述的解决方案。**

847

848

|**流程活动**|**自动化手段**|**关键功能**|**实践的效果上的影响**

849

|(% colspan="4" %)**监控规划流程**

|(((

**定义监控目标**

**评估可用的度量监控标准**

**定义监控对象的事态类型**

)))|(((

**可视化工具（例如思维导图，服务图表，架构可视化）**

**服务目录工具**

**配置管理数据库**

)))|(((

**服务结构，依赖项，配置项等的可视化**

**提供有关服务结构的信息，以及**

**组件/ 服务的相互依赖性**

**提供有关**

**服务SLA和要求的信息**

)))|**中**

|(((

**定义不同事态类型的阈值**

**定义服务'运行状况模型'（端到端事件）**

**定义事态关联和规则集**

)))|(((

**监控和事态管理工具**

**ITSM工具**

**软件定义的基础设施工具**

**基础设施和平台内置的监控工具**

**服务可视化工具**

)))|**主动和被动性监控，事态设置，数据收集，数据分析，警报，规则设置**|**高**

890

|**建立行动计划和需要响应和通知的职能部门之间的映射关系**|(((

**监控和事态管理工具**

**ITSM工具**

**软件定义的基础设施工具**

**协作和通讯工具**

**集成总线**

**自动化系统**

**用于事态关联、行为监控与分析的AI和ML工具**

904

)))|(((

905

**ITSM工具集成（例如，基于事态的事件记录）**

**通知和通讯，任务创建。**

**自动化脚本运行**

**AI和ML 事态关联，正常/异常行为分析**

912

)))|**高**

913

|(% colspan="4" %)**事态处理流程**

|(((

**事态检测**

**事态日志记录**

**事态过滤和相关性检查（可能是迭代的）**

**事态分类**

**事态响应选择**

**发送通知、执行响应过程**

)))|(((

**监控和事态管理工具**

**ITSM工具**

**软件定义的基础设施工具**

**协作和**

**通讯工具**

**集成总线**

**自动化系统**

**报告和仪表板工具和门户**

)))|(((

**ITSM工具集成（例如，基于事态的事件记录）**

**通知和通讯，任务创建。**

**自动化脚本运行**

**AI和ML 事态关联，正常/异常行为分析**

**报告和仪表板发布**

)))|**高**

|(% colspan="4" %)**监控和事态管理评审**

|(((

**评审重大事件或事态**

**评审过滤和相关性分析**

**评审服务“运行状况模式“**

**评估事态的响应程序和自动化程度**

**评审用于数据分析、相关性分析、人工智能和机器学习的工具**

**评审监控工具收集的统计信息**

)))|(((

**可视化工具（例如思维导图，服务图表，架构可视化）**

**统计分析工具，数据库**

**服务目录工具**

**配置管理数据库**

**监控和事态管理工具**

**ITSM工具**

**协作和通讯工具**

**报告和仪表板工具和门户**

**业务分析工具**

**基准工具和**

**知识管理工具**

)))|(((

**服务结构，依赖项，配置项等的可视化**

990

991

**提供有关服务结构和组件/ 服务相互依赖关系的信息**

992

993

**提供有关服务SLA和要求，合规性和违规的信息**

**提供重大事件的信息**

**报告和仪表板发布**

**通知，聊天**

**分析和评估**

**知识共享**

)))|**中**

**表5.1 监控和事态管理活动的自动化解决方案**

----

= **6 合作伙伴和供应商** =

**只有很少的服务是使用自己的资源提供的。大多数（如果不是全部）依赖于其他服务，这些服务通常由组织以外的第三方提供（请参阅ITIL//®//Foundation：ITIL 4 Edition出版物中的第2.4节，了解服务关系的模型）。支持服务在供应商管理的实践指南中介绍了关系和依赖性。**

1016

1017

**通信和云服务的开发使得外部监控服务非常受欢迎。配置项像服务器，数据库实例可以安装监控代理并将信息输入云存储库。这样的解决方案使其他使用了AI和机器学习（ML）的分析变得更容易，更便宜。这种解决方案中的机器学习（ML）通过合并来自数千个监控对象的数据以及对系统和用户的正常和异常行为理解的不断修正而得到改进。**

1018

1019

**另一个重要的考量是涉及到外包服务和组件监控权限的问题，因此组织会控制与服务提供者达成共识的度量标准。**

1020

1021

**此外，必须将外部供应商开发的所有服务设计为具有监控功能，这意味着设计的服务必须能够提供有关其性能和运行状态的信息。**

1022

1023

**当组织旨在确保监控和事态管理快速有效时，他们通常会试图同意与合作伙伴和供应商的密切合作，消除沟通，协作和决策方面的正式官僚障碍。有关更多信息，请参考供应商管理实践指南。**

1024

1025

1026