ITIL 4—事件管理实践

本文主要是介绍ITIL 4—事件管理实践，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1 关于本文

本文档提供事件管理实践实用指南。分为五个主要部分，内容包括：

本实践的一般信息
实践的流程和活动及其在服务价值链中的作用
参与实践的组织和人员
支持实践的信息和技术
对实践的合作伙伴和供应商的考虑。

1.1 ITIL®4 认证方案

本文档的部分内容可以作为以下教学大纲的一部分以供检查：

ITIL专家：创建、交付和支持
ITIL专家：高速IT

详情请参考各部分教学大纲。

2 一般信息

2.1 目的和描述

关键信息

事件管理实践的目的是尽快恢复正常的服务运作，以尽量减少事件的负面影响。

规范的服务运维通常是在服务级别协议（SLA）定义，或在服务质量规范的其他形式中定义的，因为这可以是服务提供者在内部达成的协议。规范可以包含比最初与客户达成的协议更多的质量准则。因此，事件管理实践包括恢复服务和资源的正常运行，即使服务使用者看不到它们的失效或偏差。在这种情况下，日常运维操作在配置项（CI）或服务技术规范中定义。但是，如果没有日常运维的书面规范，则可以使用专家意见来评估资源和服务的状况。如果需要，可以使用事件管理实践来纠正有故障的资源或服务。

事件管理实践是服务管理的基本元素。服务的快速恢复是用户和客户满意、服务提供者的信誉，以及组织在服务关系中创建价值的关键因素。

2.2 术语和概念

事件

服务的计划外中断或服务质量的降低。

事件管理实践确保将计划外的服务不可用或降级的时间减至最少，从而减少对用户的负面影响。有两个主要因素可以实现这一点：早期的事件检测和快速恢复正常的运维。

借助有效、高效的流程，自动化工具和供应商关系以及技术精湛且积极进取的专家团队，可以快速检测和解决事件。服务管理四维模型的资源被整合以形成事件管理实践。

一些系统和服务给出了包括所谓典型事件在内的操作范例。这些可能与已知的错误相关，例如缺乏兼容性或不正确的用户行为方式。服务提供者通常定义事件模型以优化处理和解决重复事件或类似事件，这些事件模型有助于快速、高效地解决事件，由于采用了经过验证和测试的解决方案，通常会产生更好的结果。

事件模型的创建和使用对于事件管理实践中的活动很重要。这将在第3节中进一步描述。

尽管有些事件在服务运营和消费方面的影响相对较低，但其他事件却给服务消费者和服务提供者带来了严重后果，这些被称为重大事件，需要特别注意。

定义：重大事件

具有重要业务影响的事件，需要立即协调解决。

重要的业务影响并不是重大事件的唯一特征。例如，当有多个为高可用性设计的系统和服务时，单个故障不太可能导致严重的业务影响。故障将迅速且通常是自动检测并修复。重大事件通常与更高级别的复杂性相关。例如，如果多个看似微不足道的事件同时发生，则可能会升级并对服务使用者产生影响。诸如此类的复杂事件需要一些特殊的管理和解决方法。实施一个模型来管理所有事件将是有益的，尽管重大事件很少发生且通常具有不同的性质。重大事件的模型可能包括：

清晰的准则，以区分重大事件与灾难及其他事件
特别负责的协调员，有时也称为重大事件经理（MIM）
创建了一个专门的临时团队来调查和解决重大事件
其他专用资源（包括预算），例如，与第三方专家进行紧急咨询或采购组件
特殊的调查方法（例如，全功能团队）
与用户，客户，监管机构，媒体和其他利益相关者进行沟通的机制
达成一致的评审与后续活动的规程。

定义：变通方案

当事件或者问题无法彻底解决，而采取减少或消除事件或问题影响的变通解决方案。一些变通方案还可以降低事件发生的可能性。

有时，可能找不到事件的系统性解决方案。在这些情况下，服务提供者可以应用变通方案。

变通方案可以立即将服务恢复到可接受的质量。但是，变通方案可能会增加技术债务，并可能在将来导致新的事件。问题管理实践可用于减少事件解决方法创建的技术债务。在许多情况下，了解事件的原因可以帮助找到最佳解决方案。

定义：技术债务

因选择变通方案而非系统性解决方案（需要花费更长时间），而累计的返工总量

2.3 范围

事件管理实践的范围包括：

发现和登记事件
诊断和调查事件
将受影响的服务和配置项还原到约定的质量
管理事件记录
在事件的全生命周期中与利益相关者进行沟通
在事件解决之后，进行事件故并发起服务改进和事件管理实践优化

尽管许多活动和责任领域仍与事件紧密相关，但它们并没有包含在事件管理实践中。表2.1中列出了这些活动，以及对实践指南的引用。重要的是要记住，ITIL实践指南仅仅是价值流中使用的工具集合，应根据情况的需求而组合。

表2.1 其他实践中描述的与事件管理实践相关的活动

活动	实践指南
调查事件原因	问题管理
与用户沟通	服务台
实施产品和服务的变更	变更支持
	部署管理基础设施和平台管理项目管理发布管理软件开发和管理
监控技术，团队和供应商绩效	监控和事态管理
改进计划的管理	持续改进
服务请求的管理和执行	服务请求管理
灾难情况下，恢复正常操作	服务连续性管理

2.4 实践成功因素

实践成功因素

相关联的一组事务的协同工作机制，是实践活动实现其目的所必需的。

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

事件管理实践包括以下PSFs：

及早发现事件
快速有效地解决事件
不断改进事件管理方法。

2.4.1 尽早发现事件

以前，实践通常是根据最终用户和IT专家的信息来报告大多数事件的。这种获取信息的方法仍被广泛使用，但是现在一个好的实践建议是自动发现和报告事件。可以在事件发生后和开始影响用户之前立即被发现。这种方法具有多种好处，其中包括：

事件较早发现缩短了服务不可用或降级的时间。
更高质量的初始数据支持事件正确的响应和解决，包括自动解决，也称为故障自愈。
某些事件对用户来说是不可见的，从而改进了用户满意度和客户满意度。
一些事件可能在影响与顾客约定的服务质量之前得到解决，从而提高感知服务和正式报告的服务质量。
与事件相关的成本可能会降低。

通过监控和事态管理实践可以发现事件。这包括用于事态分类的工具和流程，用于区分事件、信息事态和告警。

自动发现的事件可以自动，手动或部分自动地分类。部分自动分类是手动进行的，但会基于系统提出的建议。自动事件发现和分类可能受益于机器学习解决方案，使用从过去事件、事件、已知错误和其他来源获得的数据。

当无法自动发现事件时，通常会在事件已经影响到用户及其工作时发现事件。即使这样，事件的报告和报告越早越好。这可以通过在用户中推广负责任的服务的文化来实现，包括鼓励报告可疑事件和行为，并在合理范围内容忍误报。

2.4.2 快速有效地解决事件

该PSF对于事件管理实践和通用服务质量的成功至关重要。考虑到环境的复杂性，在检测到事件之后，应该有效地进行处理：

在简单的情况下，例如重复发生的事件和众所周知的事件，预设的解决程序可能是有效的。这些可能包括自动解决或标准化的分派和处理（根据适当的预先约定的事件模型）。
在复杂的情况下，事件的确切性质未知，但支持团队熟悉系统和组件，并且组织可以获取专家知识，因此通常会将事件分派到一个或多个专家组进行诊断和解决。有时，这可以帮助识别模式，并产生一个模型和/或解决方案，可以应用于未来的类似事件。
在非常复杂的情况下，很难或不可能确定专家区域和专家组，或者已确定的专家组找不到解决方案时，采用集体方法可能会有用。此技术称为“全功能团队”。

全功能团队

解决各种复杂任务的技术方法。在全功能团队中，具有不同专业知识领域的多个人员一起完成一项任务，直到明确哪些能力最相关和最需要。

通常，全功能团队有助于降低复杂度，使其可以切换到低复杂性环境中使用的技术。但是，全功能团队通常适用于性质未知的重大事件。在这种情况下，与仍未解决的事件造成的损失相比，将大量专用资源集中在一起更具有成本效益。

全功能团队不需要举行实际会议。建立计划后，专家可能会独自工作以完成实验，设计脚本，并使用其他工具来发现正在发生的事情。为了应对这一事件，全功能团队使用正确的人员，而不是大量的人员。

在复杂情况下可以使用其他技术。例如，可以将专家分析替换或与一系列旨在提高对事件性质理解的安全失效实验相结合：

基于复杂度的决策框架1 对于在高度变化的复杂环境中处理事件很有用。

无论复杂性如何，从事件处理的第一步开始，都要确认事件数据的质量是否较高。这在以下方面具有强大的影响力：

决策的正确性
服务的恢复速度
有效利用资源
找到并纠正根本原因的能力
机器学习的可能性和质量。

2.4.2.1 事件的优先级

事件应尽快解决。但是，参与事件解决的团队的资源是有限的，并且这些团队通常同时参与其他类型的工作。应该优先处理某些事件，以最大程度地减少对用户的负面影响。

任务优先级是任务相对于其他任务的重要性。具有更高优先级的任务应首先处理。优先级在待办项中所有任务的背景中定义。
当无法在待办项中为所有任务分配资源时，优先选择首先要处理的任务。

事件优先级划分有许多简单准则：

评估事件的影响和紧急程度（以及调查和解决的时间限制）是不分优先顺序的。但是，这种评估可用于确定优先级和其他重要的考虑因素，例如估计执行工作所需的时间。
仅当存在资源冲突时才需要确定优先级。如果在时间限制内有足够的资源用于流程的每个任务，则无需进行优先级排序。
事件应在单个待办项中与其他任务（计划内的和计划外的）一起等待处理。
优先级排序是一种工具，用于在团队中分配人员执行任务。如果事件由多个团队处理，则将根据资源可用性、目标解决时间和估算的处理时间在各团队中确定优先级。
资源可用性和估算的处理时间由团队确定。此外，对于重复性操作可以将处理时间标准化。目标解决时间可以由SLA和/或服务提供方的内部服务规范定义。随着支持团队发现新信息，原来的影响度评估结果和完成（解决）时间可能会有变化。
可视化工具（如看板）和精益原则（如对在建工程的限制）对于提高优先级排序的有效性是有用的。

这些规则适用于服务提供方的专业团队执行的，无论是计划内还是计划外的所有类型的工作。在所有实践中，参与组织服务管理活动的每个人都必须同意并遵循这些原则，这一点很重要。

2.4.3 持续改进事件管理方法

应当定期对事件进行评审，以提高事件管理实践的有效性和效率。对于重大事件、新类型的事件以及未及时解决的事件通常需要在解决后进行单独评审。大多数事件除了确认成功解决外，不需要单独进行评审。尽管如此，在一定的时间间隔内对事件管理记录进行回顾有助于总结成功经验、识别改进点，有助于在专业团队间实现知识共享、识别新的事件类型，有助于改进或引入事件模型。

定期评审提供一个机会来分析利益相关方对事件管理实践的满意度。定期事件评审也是机构和组织持续改进产品及服务的关键。

关键信息

数据的重要性

有效的评审一定需要数据支撑，认同记录数据的要求很重要。数据应该是：

在持续改进中，要求利益相关方在事件处置过程中（而不是事后）更新事件记录，以保证所有人同时且准确地知道什么时间做了什么事非常有用。同样，准确的时间表有助于调查问题。
在一个简单的描述中可能隐藏着大量的具体活动。例如，“我们重新启动集群并在45分钟后观察到功能正常”之类的语句可能隐藏了有用的细节。这可能意味着：“我们先重启服务器1，然后重启2，然后再重启3，然后发现原来正常运行的服务器4停机了。我们查阅了手册，重新启动了服务器2和4，之后是服务器1和3。所有服务器在10分钟后都能正确处理数据。

全面描述采取行动的原因与描述行动本身同样重要。

2.5 关键指标

应该基于每个实践对价值流的贡献来评估ITIL实践的有效性和绩效。与任何工具的绩效一样，实践的绩效只能在其应用情境中评估。工具在设计和质量上可能会有很大差异，按照工具的用途使用时，这些差异定义了工具有效性的潜力或能力。关于度量标准，关键绩效指标（KPI）和其它技术的进一步指导，请参见度量和报告实践指南。

事件管理实践的关键指标已映射到其PSF。它们可以用作价值流情景下的KPIs，来评估实践对这些价值流的效能和效率的贡献。表2.2中给出了一些关键指标的例子。

在实践中，应将指标应用于特定的场景，例如事件的类型，服务，专家组或时间区间。将度量标准正确地聚合到复杂的指标中，将使数据更容易用于价值流的持续管理，以及事件管理实践的定期评估和持续改进。并没有唯一的最佳解决方案，度量标准将基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。

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

实践成功因素	指标示例
尽早发现事件	事件发生到发现之间的时间通过监控和事态管理发现的事件百分比
快速有效地解决事件	从事件发现到接受诊断之间的时间派单次数等待时间占事件总处理时间的百分比首次解决比率按时解决率用户对事件处理和解决的满意度自动解决事件的百分比用户报告之前已解决的事件的百分比
不断改进事件管理方法	使用先前确定和记录的解决方案的事件解决率使用事件模型解决的事件的百分比超时关键实践指标的改善事件解决的速度和有效性指标之间的平衡

3 价值流和流程

3.1 价值流贡献

像任何其他ITIL管理实践一样，事件管理实践对多条价值流有帮助。重要的是要记住，价值流不是由单一实践形成的。例如，即使当价值流专注于事件解决时，也会涉及其他实践，例如服务台、监控和事态管理、服务配置管理、变更支持、供应商管理、基础设施和平台管理以及软件开发和管理。

事件管理实践主要与在各种工作环境中恢复正常系统或服务运营有关。实践贡献的主要价值链活动是：

契动
交付和支持
设计和转换
改进
获取或构建。

事件管理实践对服务价值链的贡献如图3.1所示。

图3.1 事件管理实践对价值链活动的贡献热力图

3.2 流程

每个实践可以包含一个或多个过程和活动，这是实现这一实践目的所必需的。

流程

将输入转换为输出的一组相互关联或相互作用的活动。过程接受一个或多个已定义的输入，并将其转换为已定义的输出。过程定义操作的顺序及依赖关系。

事件管理活动分为两个流程：

事件的处理和解决。该流程的重点是从发现到关闭的单个事件的处理和解决。
定期事件评审。该流程确保从事件处理和解决的过程中吸取教训，并确保持续改进事件管理的方法。

3.2.1 事件处理和解决

该过程包括表3.1中列出的活动，并将输入转换为输出。

表3.1 事件处理和解决过程的输入，活动和输出

关键输入	活动	关键输出
监控和事件数据	事件发现	事件记录
用户查询	事件登记	事件状态沟通
配置信息	事件分类	问题调查请求
IT资产信息	事件诊断	变更请求
服务目录	事件解决	事件报告
与消费者和供应商/合作伙伴的SLA	事件关闭	知识库更新
容量和性能信息		恢复CI和服务
连续性策略和计划
信息安全策略和计划
问题记录
知识库

图3.2展示事件处理和解决的工作流程图。

图3.2 事件处理和解决流程的工作流

在整个过程中，应明确每个事件的所有权。在处理和解决过程中，所有权有可能会转移，但是每个事件应在任意时间都有人负责。另外，只要事件状态发生变化，就应与利益相关者沟通。

基于不同的事件模型，流程可能会有较大差异。表3.2提供了两种事件模型（手动和自动）的活动示例，它们只是许多可选项中的两个，用来说明事件模型之间的差异。

表3.2 事件处理和事件解决过程的活动

3.2.2 定期事件评审

该流程的重点是持续改进事件管理实践，事件模型和事件处理程序。它可以定期执行，也可以由事件报告触发，该报告突显低效率和其他改进点机会。根据现有模型和程序的效果，每两到三个月或更短时间进行一次定期检查。

该流程包括表3.3中列出的活动，并将输入转换为输出。

表3.3定期事件评审的输入、输出和活动

关键输入	活动	关键输出
当前事件的模型和程序	事件评审和事件记录分析	更新的事件模型
事件记录	事件模型优化的启动	更新的事件处理程序
事件报告		事件记录
策略和法规要求	事件模型更新的沟通	更新的事件模型和过程的沟通
配置信息
IT资产信息		变更请求
与消费者和供应商/合作伙伴的SLA		改进计划事件评审报告
容量和性能信息
连续性策略和计划
安全策略和计划

图3.3 展示事件评审的工作流程图。

图3.3定期事件评审流程的工作流

表3.4提供了定期评审流程活动的示例。

表3.4 定期事件评审流程的活动

活动	示例
事件评审和事件记录分析	事件经理与服务所有者和其他相关的利益相关者一起，对选定的事件（例如重大事件，未及时解决的事件或特定时期内的所有事件）实施评审，确定事件模型和事件处理程序的改进机会，包括事件处理和解决方案的自动化。
事件模型优化的启动	事件经理记录优化方案，它将通过持续改进实践或启动变更请求开始。（如果事件模型、程序和自动化包含在变更支持实践的范围内）。
事件模型变更的沟通	如果事件模型成功地完成优化，这一事实将会传达给相关的利益相关者。这通常由事件经理和/或服务或资源所有者通过沟通过程完成。

4 组织和人员

4.1 角色，能力和责任

实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定于每个实践的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住，角色并非职位头衔。一个人可担任多个角色，一个角色也可以分配给多个人员。

在过程和活动的情景中描述角色。每个角色都有一个基于表4.1所示模型的能力类型。

表4.1能力代码和类型

能力代码	能力类型（活动和技能）
L	领导决策、授权、监督其他活动，提供激励和动力，并评估结果
А	管理员分配任务并确定优先级，保持记录，持续报告，并启动基本改进
C	协调者/沟通者协调多方，维护利益相关者之间的沟通，并开展宣传活动
М	方法和技巧专家设计和实施技术、文件化步骤、流程咨询、工作分析和持续改进
Т	技术专家提供技术（IT）专业知识并执行基于专家经验的作业

4.1.1 事件经理角色

在许多组织中，事件经理角色由专人担任，有时授予事件经理的职衔。在其他组织中，事件经理的责任由负责与事件关联的配置项，服务或产品的人员或团队承担；他可能是资源所有者，服务负责人或产品负责人。

该角色通常负责：

根据组织设计，协调在组织或特定区域（例如管区，产品和技术）内的事件处理
在事件中协调人工操作事宜，尤其是涉及多个团队的事件
监控并检查负责处理和解决事件的团队的工作情况
确保在组织层面对事件及其状况有足够的认知
组织定期的事件评审，对事件管理实践，事件模型和事件处理程序持续改进
发展组织在流程和事件管理实践方法上的专业知识。

在某些情况下，组织可能会设置重大事件经理（MIM）角色。该角色的职责与事件经理的职责相似，但只关注重大事件。该角色负责重大事件期间主要的联系和协调。MIM通常具有更广泛的权限，且可能有用于重大事件管理的专用资源。

尽管每种能力的重要性因活动而异，但这些角色的能力类型是LCTA。

4.1.2 事件管理活动中涉及的其他角色

表4.2中列出了事件管理活动中可能涉及的其他角色示例，以及相关的能力类型和特定技能。

表4.2负责事件管理活动的角色示例

4.2 组织结构和团队

事件管理实践不推荐任何特定的组织模型。但是，组织结构会影响实践的执行方式，因为它涉及具有不同领域和专业水平的专家。专家分组的典型方法包括：

技术领域
生产/服务
管区
消费者类型。

依据组织的需求和资源，组织的构建方式会有所不同。事件管理实践应采取灵活的构建方式，必要时包括来自不同内部和外部团队的资源。

4.2.1 分层型与扁平型团队结构

历史上，处理事件的团队具有分层或分级的结构，其中能力，专业知识和专业技能随级别的增加而增加。为了降低成本，尽可能用最低的层级人员解决大多数事件。如果无法在当前级别解决事件，则将事件转移到高一层级或升级。在这样的团队中，事件升级的级别和程序均有明确的界限。缺点是，这样的结构会抑制协作和信息流动，导致解决时间延长。因此，对于高优先级事件，通过团队协作来促进快速解决。

敏捷方法的扩展应用和IT系统质量提升（如自愈系统），要求更广泛地使用扁平型团队结构，而不是分层型团队结构。更扁平的结构和相应的协作方法（如全功能团队）代替了分层结构，以促进合作和信息的自有流动。这种变化的主要驱动力是摒弃了刚性分层，取而代之的是更具活力的、自组织的协作。

范例

三层（L1，L2，L3）团队中的典型升级流程可以替换为以下内容：