Changes for page 服务管理实践 - 02 事件

Last modified by superadmin on 2024/12/25, 15:38

From version < 3.1 >

edited by superadmin
on 2021/12/16, 22:52

To version < 9.1 >

edited by superadmin
on 2021/12/16, 23:04

< >

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,0 +1,1 @@
	1	+ITIL 4事件管理实践中文版

Parent

...	...	@@ -1,0 +1,1 @@
	1	+Main.WebHome

Content

@@ -1,0
          +1,818 @@
++**申明：**
++
++本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众
++多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信
++公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
++
++
++请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
++
++
++本文档翻译工作参与人员：
++
++翻译：秦佩君
++
++审校：马军
++
++
++总审： 长河
++
++审核： 李锐
++
++统筹： 常宏
++
++
++
++----
++
++{{box cssClass="floatinginfobox" title="**Contents**"}}
++{{toc/}}
++{{/box}}
++
++= **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 >>path:#_bookmark2]]对于在高度变化的复杂环境中处理事件很有用。
++
++无论复杂性如何，从事件处理的第一步开始，都要确认事件数据的质量是否较高。这在以下方面具有强大的影响力：
++
++* 决策的正确性
++* 服务的恢复速度
++* 有效利用资源
++* 找到并纠正根本原因的能力
++* 机器学习的可能性和质量。
++
++==== **2.4.2.1 事件的优先级** ====
++
++事件应尽快解决。但是，参与事件解决的团队的资源是有限的，并且这些团队通常同时参与其他类型的工作。应该优先处理某些事件，以最大程度地减少对用户的负面影响。
++
++* 任务优先级是任务相对于其他任务的重要性。具有更高优先级的任务应首先处理。优先级在待办项中所有任务的背景中定义。
++* 当无法在待办项中为所有任务分配资源时，优先选择首先要处理的任务。
++
++事件优先级划分有许多简单准则：
++
++* 评估事件的影响和紧急程度（以及调查和解决的时间限制）是不分优先顺序的。但是，这种评估可用于确定优先级和其他重要的考虑因素，例如估计执行工作所需的时间。
++* 仅当存在资源冲突时才需要确定优先级。如果在时间限制内有足够的资源用于流程的每个任务，则无需进行优先级排序。
++* 事件应在单个待办项中与其他任务（计划内的和计划外的）一起等待处理。
++* 优先级排序是一种工具，用于在团队中分配人员执行任务。如果事件由多个团队处理，则将根据资源可用性、目标解决时间和估算的处理时间在各团队中确定优先级。
++* 资源可用性和估算的处理时间由团队确定。此外，对于重复性操作可以将处理时间标准化。目标解决时间可以由SLA和/或服务提供方的内部服务规范定义。随着支持团队发现新信息，原来的影响度评估结果和完成（解决）时间可能会有变化。
++* 可视化工具（如看板）和精益原则（如对在建工程的限制）对于提高优先级排序的有效性是有用的。
++
++这些规则适用于服务提供方的专业团队执行的，无论是计划内还是计划外的所有类型的工作。在所有实践中，参与组织服务管理活动的每个人都必须同意并遵循这些原则，这一点很重要。
++
++
++=== **2.4.3 持续改进事件管理方法** ===
++
++应当定期对事件进行评审，以提高事件管理实践的有效性和效率。对于重大事件、新类型的事件以及未及时解决的事件通常需要在解决后进行单独评审。大多数事件除了确认成功解决外，不需要单独进行评审。尽管如此，在一定的时间间隔内对事件管理记录进行回顾有助于总结成功经验、识别改进点，有助于在专业团队间实现知识共享、识别新的事件类型，有助于改进或引入事件模型。
++
++定期评审提供一个机会来分析利益相关方对事件管理实践的满意度。定期事件评审也是机构和组织持续改进产品及服务的关键。
++
++
++|**关键信息**
++|(((
++//数据的重要性//
++
++有效的评审一定需要数据支撑，认同记录数据的要求很重要。数据应该是：
++
++* 在持续改进中，要求利益相关方在事件处置过程中（而不是事后）更新事件记录，以保证所有人同时且准确地知道什么时间做了什么事非常有用。同样，准确的时间表有助于调查问题。
++* 在一个简单的描述中可能隐藏着大量的具体活动。例如，“我们重新启动集群并在45分钟后观察到功能正常”之类的语句可能隐藏了有用的细节。这可能意味着：“我们先重启服务器1，然后重启2，然后再重启3，然后发现原来正常运行的服务器4停机了。我们查阅了手册，重新启动了服务器2和4，之后是服务器1和3。所有服务器在10分钟后都能正确处理数据。
++
++全面描述采取行动的原因与描述行动本身同样重要。
++)))
++
++(% class="wikigeneratedid" %)
++
++
++
++== **2.5 关键指标** ==
++
++应该基于每个实践对价值流的贡献来评估ITIL实践的有效性和绩效。与任何工具的绩效一样，实践的绩效只能在其应用情境中评估。工具在设计和质量上可能会有很大差异，按照工具的用途使用时，这些差异定义了工具有效性的潜力或能力。关于度量标准，关键绩效指标（KPI）和其它技术的进一步指导，请参见度量和报告实践指南。
++
++事件管理实践的关键指标已映射到其PSF。它们可以用作价值流情景下的KPIs，来评估实践对这些价值流的效能和效率的贡献。表2.2中给出了一些关键指标的例子。
++
++在实践中，应将指标应用于特定的场景，例如事件的类型，服务，专家组或时间区间。将度量标准正确地聚合到复杂的指标中，将使数据更容易用于价值流的持续管理，以及事件管理实践的定期评估和持续改进。并没有唯一的最佳解决方案，度量标准将基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。
++
++
++表2.2 实践成功因素的关键指标示例
++
++|**实践成功因素**|**指标示例**
++|尽早发现事件|(((
++事件发生到发现之间的时间
++
++通过监控和事态管理发现的事件百分比
++)))
++|快速有效地解决事件|(((
++从事件发现到接受诊断之间的时间
++
++派单次数
++
++等待时间占事件总处理时间的百分比
++
++首次解决比率
++
++按时解决率
++
++用户对事件处理和解决的满意度
++
++自动解决事件的百分比
++
++用户报告之前已解决的事件的百分比
++)))
++|不断改进事件管理方法|(((
++使用先前确定和记录的解决方案的事件解决率
++
++使用事件模型解决的事件的百分比
++
++超时关键实践指标的改善
++
++事件解决的速度和有效性指标之间的平衡
++)))
++
++----
++
++= **3 价值流和流程** =
++
++
++== **3.1** **价值流贡献** ==
++
++像任何其他ITIL管理实践一样，事件管理实践对多条价值流有帮助。重要的是要记住，价值流不是由单一实践形成的。例如，即使当价值流专注于事件解决时，也会涉及其他实践，例如服务台、监控和事态管理、服务配置管理、变更支持、供应商管理、基础设施和平台管理以及软件开发和管理。
++
++事件管理实践主要与在各种工作环境中恢复正常系统或服务运营有关。实践贡献的主要价值链活动是：
++
++* 契动
++* 交付和支持
++* 设计和转换
++* 改进
++* 获取或构建。
++
++事件管理实践对服务价值链的贡献如图3.1所示。
++
++(% style="text-align:center" %)
++[[image:1639666274571-239.png]]
++
++图3.1 事件管理实践对价值链活动的贡献热力图
++
++
++== **3.2 流程** ==
++
++每个实践可以包含一个或多个过程和活动，这是实现这一实践目的所必需的。
++
++
++|(((
++**流程**
++)))
++|将输入转换为输出的一组相互关联或相互作用的活动。过程接受一个或多个已定义的输入，并将其转换为已定义的输出。过程定义操作的顺序及依赖关系。
++
++事件管理活动分为两个流程：
++
++* **事件的处理和解决**。该流程的重点是从发现到关闭的单个事件的处理和解决。
++* **定期事件评审**。该流程确保从事件处理和解决的过程中吸取教训，并确保持续改进事件管理的方法。
++
++
++=== **3.2.1 事件处理和解决** ===
++
++该过程包括表3.1中列出的活动，并将输入转换为输出。
++
++表3.1 事件处理和解决过程的输入，活动和输出
++
++(% style="width:552px" %)
++|(% style="width:254px" %)**关键输入**|(% style="width:119px" %)**活动**|(% style="width:177px" %)**关键输出**
++|(% style="width:254px" %)监控和事件数据|(% style="width:119px" %)事件发现|(% style="width:177px" %)事件记录
++|(% style="width:254px" %)用户查询|(% style="width:119px" %)事件登记|(% style="width:177px" %)事件状态沟通
++|(% style="width:254px" %)配置信息|(% style="width:119px" %)事件分类|(% style="width:177px" %)问题调查请求
++|(% style="width:254px" %)IT资产信息|(% style="width:119px" %)事件诊断|(% style="width:177px" %)变更请求
++|(% style="width:254px" %)服务目录|(% style="width:119px" %)事件解决|(% style="width:177px" %)事件报告
++|(% style="width:254px" %)与消费者和供应商/合作伙伴的SLA|(% style="width:119px" %)事件关闭|(% style="width:177px" %)知识库更新
++|(% style="width:254px" %)容量和性能信息|(% style="width:119px" %) |(% style="width:177px" %)恢复CI和服务
++|(% style="width:254px" %)连续性策略和计划|(% style="width:119px" %) |(% style="width:177px" %)
++|(% style="width:254px" %)信息安全策略和计划|(% style="width:119px" %) |(% style="width:177px" %)
++|(% style="width:254px" %)问题记录|(% style="width:119px" %) |(% style="width:177px" %)
++|(% style="width:254px" %)知识库|(% style="width:119px" %) |(% style="width:177px" %)
++
++图3.2展示事件处理和解决的工作流程图。
++
++
++(% style="text-align:center" %)
++[[image:1639666329840-902.png]]
++
++图3.2 事件处理和解决流程的工作流
++
++
++在整个过程中，应明确每个事件的所有权。在处理和解决过程中，所有权有可能会转移，但是每个事件应在任意时间都有人负责。另外，只要事件状态发生变化，就应与利益相关者沟通。
++
++基于不同的事件模型，流程可能会有较大差异。表3.2提供了两种事件模型（手动和自动）的活动示例，它们只是许多可选项中的两个，用来说明事件模型之间的差异。
++
++
++表3.2 事件处理和事件解决过程的活动
++
++(% style="width:889px" %)
++|(% style="width:85px" %)**活动**|(% style="width:399px" %)**手动处理用户发现的事件**|(% style="width:403px" %)**自动发现和处理事件**
++|(% style="width:85px" %)事件发现|(% style="width:399px" %)用户发现服务运营中的故障，并通过约定的渠道与服务提供者的服务台联系。服务台客服对该用户问询进行初始分类，确认该问询确实属于事件。|(% style="width:403px" %)监控系统检测到事态，并基于预定义的分类将其标识为事件。
++|(% style="width:85px" %)事件登记|(% style="width:399px" %)服务台客服执行事件登记，将有效数据添加到事件记录中。|(% style="width:403px" %)登记事件记录并将其与发现事态的CI关联。登记预定义的技术参数。必要时，给相关技术专家发送通知。
++|(% style="width:85px" %)事件分类|(% style="width:399px" %)(((
++服务台客服完成事件初始分类；这有助于确定事件的影响，确定为失效CI和/或服务确定责任团队，并将事件关联到其他过去和正在处理的事态，事件和/或问题。
++
++在某些情况下，分类有助于找到以前为此类事件定义的解决方案。
++)))|(% style="width:403px" %)(((
++根据预定义的规则，将自动发现：
++
++* 事件对服务和用户的影响
++* 可用的解决方案
++* 如果自动化解决方案无效或不可用，找到负责事件解决的技术团队。
++)))
++|(% style="width:85px" %)事件诊断|(% style="width:399px" %)(((
++如果分类没有关联到已知解决方案，
++
++专家团队开展事件诊断。这可能涉及将事件升级到不同团队，或其他联合技术团队加入（如全功能团队）。
++
++如果由于配置项关联错误而导致分类错误，则应将此信息传达给负责配置管理的人员（请参阅服务配置实践指南）。
++)))|(% style="width:403px" %)(((
++如果自动解决方案无效或不可用，则将事件上报给负责诊断的技术团队。可能涉及事件升级到不同团队，或其他技术团队加入（如全功能团队）。
++
++如果由于配置项关联错误而导致自动化解决方案失败，则应将此信息传达给负责配置管理的人员（请参阅服务配置实践指南）。
++)))
++|(% style="width:85px" %)事件解决|(% style="width:399px" %)找到解决方案后，相关专家团队将尝试按顺序或并行工作方式执行，这可能需要启动变更。如果解决方案不起作用，则再次诊断。|(% style="width:403px" %)如果有可用的自动化解决方案，则实施它，并完成测试和确认。如果需要手动干预，则相关的专业团队尝试实施，这可能需要启动变更。如果解决方案不起作用，则再次诊断。
++|(% style="width:85px" %)事件关闭|(% style="width:399px" %)(((
++成功解决事件之后，可能需要一些正式的关闭过程：
++
++* 用户确认服务恢复
++* 计算解决方案成本并报告
++* 解决方案结算报价和发票
++* 问题调查启动
++* 事件评审
++
++完成所有必需的操作并更新了相应地事件记录后，事件正式关闭。这可以由产品负责人，服务负责人，事件经理或服务台客服完成，具体取决于商定的事件模型。
++)))|(% style="width:403px" %)如果自动解决方案证明有效，则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者，则应向其传达事件关闭的信息。
++
++
++=== **3.2.2 定期事件评审** ===
++
++该流程的重点是持续改进事件管理实践，事件模型和事件处理程序。它可以定期执行，也可以由事件报告触发，该报告突显低效率和其他改进点机会。根据现有模型和程序的效果，每两到三个月或更短时间进行一次定期检查。
++
++该流程包括表3.3中列出的活动，并将输入转换为输出。
++
++
++表3.3定期事件评审的输入、输出和活动
++
++(% style="width:738px" %)
++|(% style="width:297px" %)**关键输入**|(% style="width:233px" %)**活动**|(% style="width:207px" %)**关键输出**
++|(% style="width:297px" %)当前事件的模型和程序|(% style="width:233px" %)事件评审和事件记录分析|(% style="width:207px" %)更新的事件模型
++|(% style="width:297px" %)事件记录|(% style="width:233px" %)事件模型优化的启动|(% style="width:207px" %)更新的事件处理程序
++|(% style="width:297px" %)事件报告|(% style="width:233px" %) |(% style="width:207px" %)事件记录
++|(% style="width:297px" %)策略和法规要求|(% style="width:233px" %)事件模型更新的沟通|(% style="width:207px" %)更新的事件模型和过程的沟通
++|(% style="width:297px" %)配置信息|(% style="width:233px" %) |(% style="width:207px" %)
++|(% style="width:297px" %)IT资产信息|(% style="width:233px" %) |(% style="width:207px" %)变更请求
++|(% style="width:297px" %)与消费者和供应商/合作伙伴的SLA|(% style="width:233px" %) |(% style="width:207px" %)(((
++改进计划
++
++事件评审报告
++)))
++|(% style="width:297px" %)容量和性能信息|(% style="width:233px" %) |(% style="width:207px" %)
++|(% style="width:297px" %)连续性策略和计划|(% style="width:233px" %) |(% style="width:207px" %)
++|(% style="width:297px" %)安全策略和计划|(% style="width:233px" %) |(% style="width:207px" %)
++
++图3.3 展示事件评审的工作流程图。
++
++
++(% style="text-align:center" %)
++[[image:1639666373428-469.png]]
++
++图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负责事件管理活动的角色示例
++
++|**实现价值**|**负责角色**|**能力简介**|**具体技能**
++|(% colspan="4" %)**事件处理和解决流程**
++|事件发现|(((
++技术专家
++
++用户
++)))|TC|理解服务设计，资源配置和业务影响，了解事态的特征
++|事件登记|(((
++事件经理
++
++服务台客服
++
++技术专家
++)))|AT|熟练掌握IT服务管理(ITSM)工具和程序
++|事件分类|(((
++事件经理
++
++服务台客服
++
++技术专家
++)))|TC|(((
++理解服务设计，资源配置和业务影响
++
++熟悉事件解决的要求和承诺
++
++熟悉事件模型
++)))
++|事件诊断|(((
++供应商
++
++技术专家
++)))|TC|(((
++理解服务设计，资源配置和业务影响
++
++具备事件模型、诊断工具、诊断方法的知识
++
++分析能力
++)))
++|事件解决|(((
++供应商
++
++技术专家用户
++)))|T|了解事件解决的方法和程序要求
++|事件关闭|(((
++事件经理
++
++服务台客服
++
++技术专家
++)))|ACT|(((
++理解服务设计，资源配置和业务影响
++
++熟悉事件解决的要求和承诺
++)))
++|(% colspan="4" %)**定期事件评审流程**
++|事件评审和事件记录分析|(((
++事件经理
++
++产品负责人
++
++服务负责人
++
++供应商
++)))|TCL|(((
++理解服务设计，资源配置和业务影响
++
++熟悉事件解决的要求和承诺
++
++具备事件模型、诊断工具，诊断方法的知识和分析能力
++)))
++|事件模型优化的启动|(((
++事件经理
++
++产品负责人
++
++服务负责人
++)))|TMC|(((
++理解服务设计，资源配置和业务影响
++
++熟悉事件解决的要求和承诺
++
++具备事件模型、诊断工具，诊断方法的知识
++
++熟悉组织的持续改进和变更管理实践
++)))
++|事件模型变更的沟通|(((
++事件经理
++
++产品负责人
++
++服务台客服
++
++服务负责人
++)))|CA|熟悉沟通程序和沟通工具
++
++== **4.2** **组织结构和团队** ==
++
++事件管理实践不推荐任何特定的组织模型。但是，组织结构会影响实践的执行方式，因为它涉及具有不同领域和专业水平的专家。专家分组的典型方法包括：
++
++* 技术领域
++* 生产/服务
++* 管区
++* 消费者类型。
++
++依据组织的需求和资源，组织的构建方式会有所不同。事件管理实践应采取灵活的构建方式，必要时包括来自不同内部和外部团队的资源。
++
++
++=== **4.2.1 分层型与扁平型团队结构** ===
++
++历史上，处理事件的团队具有分层或分级的结构，其中能力，专业知识和专业技能随级别的增加而增加。为了降低成本，尽可能用最低的层级人员解决大多数事件。如果无法在当前级别解决事件，则将事件转移到高一层级或升级。在这样的团队中，事件升级的级别和程序均有明确的界限。缺点是，这样的结构会抑制协作和信息流动，导致解决时间延长。因此，对于高优先级事件，通过团队协作来促进快速解决。
++
++敏捷方法的扩展应用和IT系统质量提升（如自愈系统），要求更广泛地使用扁平型团队结构，而不是分层型团队结构。更扁平的结构和相应的协作方法（如全功能团队）代替了分层结构，以促进合作和信息的自有流动。这种变化的主要驱动力是摒弃了刚性分层，取而代之的是更具活力的、自组织的协作。
++
++
++|(((
++**范例**
++)))
++|(((
++三层（L1，L2，L3）团队中的典型升级流程可以替换为以下内容：
++
++* 用扁平的配对系统（或类似的系统）代替L1到L2的升级以快速的解决事件，和尽快将剩余的未决问题流转到L3，
++* L3团队间协作，以取代多次重新分配和/或对专家和顶级人才的过度依赖。
++)))
++
++=== **4.2.2 团队动力** ===
++
++事件管理实践是团队动力的基础，它们影响着运维支持团队的职责履行。经常出现以下问题：
++
++* 事件在团队之间重定向
++* 团队成员缺乏自主性，报告被他人拖延
++* 事件解决后，“个人英雄主义”的文化盛行。
++
++这导致事件管理实践不同步，解决方案执行缓慢或根本不执行，士气下降，缺乏动力以及不健康的工作氛围，甚至导致团队成员间的信任关系破裂。尽管DevOps和全功能团队等方法表现出鼓励积极团队文化所需的一些特征，但是实现正确的团队动力也不是必须遵循这些方法。主要解决以下三个问题：
++
++
++==== **4.2.2.1 集体责任** ====
++
++如果解决事件是首要责任，那么团队中的每个人都将聚焦于此。团队动力仅次于实现SLA或按时完成。改变这一点的第一步是建立一种给团队成员共享成功和失败的文化。责任分担的团队可能只有一个人负责事件发现到解决，但是应该鼓励他在这个过程中与其他有经验的人合作。此时，组织将从快速恢复政策服务和知识共享中受益。
++
++
++==== **4.2.2.2 不责备文化** ====
++
++团队中应建立不责备文化；否则，会导致个人，团队和供应商之间的信任度下降。事件诊断和事件评审应关注事件解决和服务恢复过程。如果事件团队的设想失败，必须鼓励他们采取行动，而不必担心受到责罚。
++
++
++==== **4.2.2.3 持续学习** ====
++
++团队成员需要分享他们从实验中学到的经验和教训，以便他们可以学习改进。事实证明，这在许多环境中都是一个重大的文化飞跃，尤其是外包比例较高的环境中。
++
++
++
++
++----
++
++= **5 信息和技术** =
++
++
++== **5.1** **信息沟通** ==
++
++事件管理实践的有效性取决于所用信息的质量。这包括但不限于以下信息：
++
++* 客户和用户
++* 服务的架构和设计
++* 合作伙伴和供应商，包括其提供的服务合同和SLA信息
++* 规范服务提供的政策和要求
++* 利益相关者对实践的满意度。
++
++信息可采用多种形式，具体取决于所使用的事件模型。实践的关键输入和输出在第3节中列出。
++
++事件的细节是最重要的信息。这些通常包括：
++
++* 信息来源
++* 对失效的或未达标的产品、服务或配置项的说明
++* 受影响的用户或服务
++* 性能下降的状况
++* 观察到性能下降的时间
++* 症状前最近一次已知的正常运行的时间点
++* 是否应用了自动修复（如果没有，原因）
++* 地理位置和虚拟位置
++* 影响正常运行的性质和程度
++* 可能受不良性能或绩效影响且当前运行正常的类似系统
++* 导致观察到症状的一系列事件。
++
++事件管理实践中将交换和记录的其他信息应包括以下细节：
++
++* 诊断（如果有）
++* 每个采取的行动，包括结果。
++
++为形成准确的时间表，任何采取的措施都应记录在案。如果实时记录操作不现实，则应记录启动和完成的记录，以避免创建错误的历史日志。但是，如果客户可以通过门户查看信息，则最好捕获实时操作。如果可能，应自动化记录操作。
++
++应提供遵循支持客服或专家的工作流程的事件记录，并应包括表5.1中所示的数据。
++
++
++表5.1 事件记录中包含的数据
++
++|**域**|**推荐内容**|**说明**
++|事件标题（简短说明）|观察到的降低或失效的功能或过程|带有清晰说明的解决方案搜索速度更快
++|用户|受影响的用户，被报告的用户|
++|当前影响|对用户/客户工作流程的实际影响的文字说明|创建上下文，允许排障组提供适当的变通或者解决方法
++|未来影响|如果事件持续下去，对客户的潜在影响的文字说明|创建上下文，允许排障组提供适当的变通或者解决方法
++|首次症状的时间|监控或用户体验中的日期和时间|诊断原因之前的准确时间点
++|最近一次正常状态的时间|验证功能正常的日期和时间|触发事态的准确时间点（此信息是人为添加还是自动记录的，可能会影响可信度）
++|受影响项目（功能，配置项，流程）的详细信息|资产ID号，应用程序和流程名称以及配置项索引|集中精力进行修复
++|未受影响的可比项目（如果有）的详细信息|未受影响的资产ID号，应用程序和流程名称以及配置项索引|缩小搜索范围
++|诊断详情（如果有）|诊断步骤和每步的结果|减少重复工作
++|分派|事件的个人或团队所有者|
++
++== **5.2** **自动化和工具** ==
++
++事件管理实践应该是自动化的。在可行且有效的情况下，可能涉及表5.2中概述的解决方案。
++
++在某些情况下，事件处理和解决过程中特定活动之后的所有活动都可以使用针对特定类型事件的预定义脚本和场景实现完全自动化。
++
++请注意，事件管理实践中使用的自动化工具不仅包括对所有事件都有效的组织范围内的工具，还包括一些本地自定制化工具和脚本，这些工具和脚本是在定期事件评审过程中为特定事件模型创建的。两者都应该用来推动自动化工作。
++
++
++表5.2 事件管理活动的自动化解决方案
++
++|**过程活动**|**自动化方式**|**关键功能**|**对实践有效性的影响**
++|(% colspan="4" %)**事件处理和解决流程**
++|事件发现|监控工具和事态相关引擎|早期的检测和事件关联，初始化事件管理实践|高
++|事件登记|用户查询管理和工作流程工具，以及协同工具|有效记录事件|高
++|事件分类|(((
++用户查询管理和工作流程工具，
++
++协同工具，
++
++知识管理工具，
++
++配置管理工具
++
++和基于机器学习的分类引擎
++)))|快速、准确的分类和事件分派，已知解决方案的识别，重大事件的识别|非常高，尤其是在事件数量多的情况下
++|事件诊断|(((
++分析和诊断工具
++
++知识管理工具
++
++配置管理工具
++
++协同工具
++)))|快速、准确的定义和测试假设，多个专家/团队的有效协作|高，特别是在需要手动协作的复杂事件数量很多时
++|事件解决|(((
++远程管理工具
++
++自动化的部署系统，
++
++和协同工具
++)))|快速纠正失效的配置项并恢复服务|高，特别是提供远程服务时
++|事件关闭|用户查询和工作流管理工具，和协同工具|快速而全面的回顾事件生命周期|中
++|**定期事件评审流程**| | |
++|事件评审和事件记录分析|协同系统，分析和报告系统以及调查工具|(((
++远程协作，事件数据分析和用户调查数据
++
++分析和报告
++)))|中到高，尤其是对批量事件
++|事件模型优化的启动|工作流系统和待办项管理工具|优化的正式登记|低到中
++|事件模型更新的沟通|通信系统和协作系统|与受影响团队沟通更新|中到高，尤其当组织较大，更新较多时为高
++
++
++----
++
++= **6 合作伙伴和供应商** =
++
++很少的服务是仅用组织自身资源就能交付的。大部分（即使不是全部）依赖于组织外的第三方提供的服务（参见ITIL Foundation：ITIL 4出版物第2.4节，服务关系模型）。支持服务引入的关系和依赖关系在《ITIL供应商管理和服务级别管理实践指南》中有相关叙述。
++
++事件模型应定义第三方如何参与事件解决，以及组织如何确保有效协作。这取决于产品、服务和价值流的架构和设计解决方案。尽管如此，支持这些解决方案的事件模型的优化将涉及到事件管理实践。通常，为事件选择正确的模型后，在事件诊断、解决和评审期间需要进一步考虑第三方依赖关系。
++
++为了使供应商成为组织生态系统的一部分，定义标准界面可能是沟通状况和要求的简便方法。这种界面描述可能包括在多供应商环境中，创建使用通用语言描述的数据交换规则、工具和过程。
++
++当组织的目标是确保快速有效的事件解决时，他们通常会尝试与合作伙伴和供应商达成紧密合作，消除沟通、协作和决策制定中形式化的官僚壁垒。（有关这方面的更多信息，请参阅《供应商管理实践指南》）。
++
++
++
++
++----
++
++= **7 重要提醒** =
++
++实践指南的大部分内容应作为组织在建立和培养自身实践时相关领域可考虑的建议。实践指南是组织可以考虑的主题目录，而非答案列表。在使用ITIL实践指南的内容时，组织应始终遵循ITIL指导原则：
++
++* 聚焦价值
++* 从你所处的地方开始
++* 基于反馈迭代推进
++* 协作和提升可视化程度
++* 通盘思考和工作
++* 保持简单实用
++* 优化和自动化。
++
++----
++
++= **8 致谢** =
++
++AXELOS有限公司感谢所有为本指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
++
++
++
++== **8.1 作者** ==
++
++Barry Corless, Roman Jouravlev, Andrew Vermes.
++
++
++
++== **8.2 审稿人** ==
++
++Akshay Anand, Sofi Fahlberg, Michael G. Hall, Steve Harrop, Piia Karvonen, Anton Lykov, Paula Määttänen, Christian F. Nissen, Mark O’Loughlin, Tatiana Orlova, Elina Pirjanti, Stuart Rance.
++
++

粤ICP备17056641号

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