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

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

From version < 8.1 >

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

To version < 5.1 >

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

< >

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Content

@@ -24,11
          +24,9 @@
  ----
--
  {{box cssClass="floatinginfobox" title="**Contents**"}}
  {{toc/}}
  {{/box}}
--
  = **1 关于本文件** =
  本文档提供事件管理实践实用指南。分为五个主要部分，内容包括：
@@ -42,6
          +42,8 @@
  == **1.1 ITIL®4 认证方案** ==
++ [[image:file:///C:\Users\19805\AppData\Local\Temp\ksohtml\wps87EB.tmp.png]]
++
  本文档的部分内容可以作为以下教学大纲的一部分以供检查：
  * ITIL专家：创建、交付和支持
@@ -57,7
          +57,7 @@
  = **2 一般信息** =
--== **2.1** **目的和描述** ==
++== 2.1 **目的和描述** ==
  |(((
  **关键信息**
@@ -64,15
          +64,19 @@
  )))
  |事件管理实践的目的是尽快恢复正常的服务运作，以尽量减少事件的负面影响。
++
  规范的服务运维通常是在服务级别协议（SLA）定义，或在服务质量规范的其他形式中定义的，因为这可以是服务提供者在内部达成的协议。规范可以包含比最初与客户达成的协议更多的质量准则。因此，事件管理实践包括恢复服务和资源的正常运行，即使服务使用者看不到它们的失效或偏差。在这种情况下，日常运维操作在配置项（CI）或服务技术规范中定义。但是，如果没有日常运维的书面规范，则可以使用专家意见来评估资源和服务的状况。如果需要，可以使用事件管理实践来纠正有故障的资源或服务。
  事件管理实践是服务管理的基本元素。服务的快速恢复是用户和客户满意、服务提供者的信誉，以及组织在服务关系中创建价值的关键因素。
--== **2.2** **术语和概念** ==
++
++== 2.2 **术语和概念** ==
++
  |**事件**
  |服务的计划外中断或服务质量的降低。
++
  事件管理实践确保将计划外的服务不可用或降级的时间减至最少，从而减少对用户的负面影响。有两个主要因素可以实现这一点：早期的事件检测和快速恢复正常的运维。
  借助有效、高效的流程，自动化工具和供应商关系以及技术精湛且积极进取的专家团队，可以快速检测和解决事件。服务管理四维模型的资源被整合以形成事件管理实践。
@@ -84,12
          +84,12 @@
  尽管有些事件在服务运营和消费方面的影响相对较低，但其他事件却给服务消费者和服务提供者带来了严重后果，这些被称为重大事件，需要特别注意。
--
  |(((
-- **定义：重大事件**
++**定义：重大事件**
  )))
  |具有重要业务影响的事件，需要立即协调解决。
++
  重要的业务影响并不是重大事件的唯一特征。例如，当有多个为高可用性设计的系统和服务时，单个故障不太可能导致严重的业务影响。故障将迅速且通常是自动检测并修复。重大事件通常与更高级别的复杂性相关。例如，如果多个看似微不足道的事件同时发生，则可能会升级并对服务使用者产生影响。诸如此类的复杂事件需要一些特殊的管理和解决方法。实施一个模型来管理所有事件将是有益的，尽管重大事件很少发生且通常具有不同的性质。重大事件的模型可能包括：
  * 清晰的准则，以区分重大事件与灾难及其他事件
@@ -100,11
          +100,13 @@
  * 与用户，客户，监管机构，媒体和其他利益相关者进行沟通的机制
  * 达成一致的评审与后续活动的规程。
++
  |(((
  **定义：变通方案**
  )))
  |当事件或者问题无法彻底解决，而采取减少或消除事件或问题影响的变通解决方案。一些变通方案还可以降低事件发生的可能性。
++
  有时，可能找不到事件的系统性解决方案。在这些情况下，服务提供者可以应用变通方案。
  变通方案可以立即将服务恢复到可接受的质量。但是，变通方案可能会增加技术债务，并可能在将来导致新的事件。问题管理实践可用于减少事件解决方法创建的技术债务。在许多情况下，了解事件的原因可以帮助找到最佳解决方案。
@@ -116,7
          +116,7 @@
  |因选择变通方案而非系统性解决方案（需要花费更长时间），而累计的返工总量
--== **2.3 范围** ==
++== 2.3 **范围** ==
  事件管理实践的范围包括：
@@ -153,7
          +153,7 @@
  |灾难情况下，恢复正常操作|服务连续性管理
--== **2.4** **实践成功因素** ==
++== 2.4 **实践成功因素** ==
  |(((
  **实践成功因素**
@@ -160,6
          +160,7 @@
  )))
  |相关联的一组事务的协同工作机制，是实践活动实现其目的所必需的。
++
  实践的成功因素（PSF）不仅仅是一项任务或活动，它包括服务管理四维模型的所有功能组件。在一项实践中，PSFs活动和资源的性质可能不同，但这些资源和活动共同确保实践有效。
  事件管理实践包括以下PSFs：
@@ -194,9
          +194,11 @@
  * 在复杂的情况下，事件的确切性质未知，但支持团队熟悉系统和组件，并且组织可以获取专家知识，因此通常会将事件分派到一个或多个专家组进行诊断和解决。有时，这可以帮助识别模式，并产生一个模型和/或解决方案，可以应用于未来的类似事件。
  * 在非常复杂的情况下，很难或不可能确定专家区域和专家组，或者已确定的专家组找不到解决方案时，采用集体方法可能会有用。此技术称为“全功能团队”。
++
  |**全功能团队**
  |解决各种复杂任务的技术方法。在全功能团队中，具有不同专业知识领域的多个人员一起完成一项任务，直到明确哪些能力最相关和最需要。
++
  通常，全功能团队有助于降低复杂度，使其可以切换到低复杂性环境中使用的技术。但是，全功能团队通常适用于性质未知的重大事件。在这种情况下，与仍未解决的事件造成的损失相比，将大量专用资源集中在一起更具有成本效益。
  全功能团队不需要举行实际会议。建立计划后，专家可能会独自工作以完成实验，设计脚本，并使用其他工具来发现正在发生的事情。为了应对这一事件，全功能团队使用正确的人员，而不是大量的人员。
@@ -252,11
          +252,9 @@
  全面描述采取行动的原因与描述行动本身同样重要。
  )))
--(% class="wikigeneratedid" %)
++== 2.5 **关键指标** ==
--== **2.5 关键指标** ==
--
  应该基于每个实践对价值流的贡献来评估ITIL实践的有效性和绩效。与任何工具的绩效一样，实践的绩效只能在其应用情境中评估。工具在设计和质量上可能会有很大差异，按照工具的用途使用时，这些差异定义了工具有效性的潜力或能力。关于度量标准，关键绩效指标（KPI）和其它技术的进一步指导，请参见度量和报告实践指南。
  事件管理实践的关键指标已映射到其PSF。它们可以用作价值流情景下的KPIs，来评估实践对这些价值流的效能和效率的贡献。表2.2中给出了一些关键指标的例子。
@@ -300,12
          +300,13 @@
  )))
++
  ----
  = **3 价值流和流程** =
--== **3.1** **价值流贡献** ==
++== 3.1 **价值流贡献** ==
  像任何其他ITIL管理实践一样，事件管理实践对多条价值流有帮助。重要的是要记住，价值流不是由单一实践形成的。例如，即使当价值流专注于事件解决时，也会涉及其他实践，例如服务台、监控和事态管理、服务配置管理、变更支持、供应商管理、基础设施和平台管理以及软件开发和管理。
@@ -317,6
          +317,7 @@
  * 改进
  * 获取或构建。
++
  事件管理实践对服务价值链的贡献如图3.1所示。
  (% style="text-align:center" %)
@@ -325,7
          +325,7 @@
  图3.1 事件管理实践对价值链活动的贡献热力图
--== **3.2 流程** ==
++== 3.2 **流程** ==
  每个实践可以包含一个或多个过程和活动，这是实现这一实践目的所必需的。
@@ -335,6
          +335,7 @@
  )))
  |将输入转换为输出的一组相互关联或相互作用的活动。过程接受一个或多个已定义的输入，并将其转换为已定义的输出。过程定义操作的顺序及依赖关系。
++
  事件管理活动分为两个流程：
  * **事件的处理和解决**。该流程的重点是从发现到关闭的单个事件的处理和解决。
@@ -361,6
          +361,7 @@
  |(% style="width:254px" %)问题记录|(% style="width:119px" %) |(% style="width:177px" %)
  |(% style="width:254px" %)知识库|(% style="width:119px" %) |(% style="width:177px" %)
++
  图3.2展示事件处理和解决的工作流程图。
@@ -377,15
          +377,14 @@
  表3.2 事件处理和事件解决过程的活动
--(% style="width:1010px" %)
--|(% style="width:85px" %)**活动**|(% style="width:439px" %)**手动处理用户发现的事件**|(% style="width:484px" %)**自动发现和处理事件**
--|(% style="width:85px" %)事件发现|(% style="width:439px" %)用户发现服务运营中的故障，并通过约定的渠道与服务提供者的服务台联系。服务台客服对该用户问询进行初始分类，确认该问询确实属于事件。|(% style="width:484px" %)监控系统检测到事态，并基于预定义的分类将其标识为事件。
--|(% style="width:85px" %)事件登记|(% style="width:439px" %)服务台客服执行事件登记，将有效数据添加到事件记录中。|(% style="width:484px" %)登记事件记录并将其与发现事态的CI关联。登记预定义的技术参数。必要时，给相关技术专家发送通知。
--|(% style="width:85px" %)事件分类|(% style="width:439px" %)(((
++|**活动**|**手动处理用户发现的事件**|**自动发现和处理事件**
++|事件发现|用户发现服务运营中的故障，并通过约定的渠道与服务提供者的服务台联系。服务台客服对该用户问询进行初始分类，确认该问询确实属于事件。|监控系统检测到事态，并基于预定义的分类将其标识为事件。
++|事件登记|服务台客服执行事件登记，将有效数据添加到事件记录中。|登记事件记录并将其与发现事态的CI关联。登记预定义的技术参数。必要时，给相关技术专家发送通知。
++|事件分类|(((
  服务台客服完成事件初始分类；这有助于确定事件的影响，确定为失效CI和/或服务确定责任团队，并将事件关联到其他过去和正在处理的事态，事件和/或问题。
  在某些情况下，分类有助于找到以前为此类事件定义的解决方案。
--)))|(% style="width:484px" %)(((
++)))|(((
  根据预定义的规则，将自动发现：
  * 事件对服务和用户的影响
@@ -392,19
          +392,19 @@
  * 可用的解决方案
  * 如果自动化解决方案无效或不可用，找到负责事件解决的技术团队。
  )))
--|(% style="width:85px" %)事件诊断|(% style="width:439px" %)(((
++|事件诊断|(((
  如果分类没有关联到已知解决方案，
  专家团队开展事件诊断。这可能涉及将事件升级到不同团队，或其他联合技术团队加入（如全功能团队）。
  如果由于配置项关联错误而导致分类错误，则应将此信息传达给负责配置管理的人员（请参阅服务配置实践指南）。
--)))|(% style="width:484px" %)(((
++)))|(((
  如果自动解决方案无效或不可用，则将事件上报给负责诊断的技术团队。可能涉及事件升级到不同团队，或其他技术团队加入（如全功能团队）。
  如果由于配置项关联错误而导致自动化解决方案失败，则应将此信息传达给负责配置管理的人员（请参阅服务配置实践指南）。
  )))
--|(% style="width:85px" %)事件解决|(% style="width:439px" %)找到解决方案后，相关专家团队将尝试按顺序或并行工作方式执行，这可能需要启动变更。如果解决方案不起作用，则再次诊断。|(% style="width:484px" %)如果有可用的自动化解决方案，则实施它，并完成测试和确认。如果需要手动干预，则相关的专业团队尝试实施，这可能需要启动变更。如果解决方案不起作用，则再次诊断。
--|(% style="width:85px" %)事件关闭|(% style="width:439px" %)(((
++|事件解决|找到解决方案后，相关专家团队将尝试按顺序或并行工作方式执行，这可能需要启动变更。如果解决方案不起作用，则再次诊断。|如果有可用的自动化解决方案，则实施它，并完成测试和确认。如果需要手动干预，则相关的专业团队尝试实施，这可能需要启动变更。如果解决方案不起作用，则再次诊断。
++|事件关闭|(((
  成功解决事件之后，可能需要一些正式的关闭过程：
  * 用户确认服务恢复
@@ -414,7
          +414,7 @@
  * 事件评审
  完成所有必需的操作并更新了相应地事件记录后，事件正式关闭。这可以由产品负责人，服务负责人，事件经理或服务台客服完成，具体取决于商定的事件模型。
--)))|(% style="width:484px" %)如果自动解决方案证明有效，则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者，则应向其传达事件关闭的信息。
++)))|如果自动解决方案证明有效，则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者，则应向其传达事件关闭的信息。
  === **3.2.2 定期事件评审** ===
@@ -443,6
          +443,7 @@
  |(% style="width:297px" %)连续性策略和计划|(% style="width:233px" %) |(% style="width:207px" %)
  |(% style="width:297px" %)安全策略和计划|(% style="width:233px" %) |(% style="width:207px" %)
++
  图3.3 展示事件评审的工作流程图。
@@ -467,12
          +467,14 @@
  )))|如果事件模型成功地完成优化，这一事实将会传达给相关的利益相关者。这通常由事件经理和/或服务或资源所有者通过沟通过程完成。
++
++
  ----
  = **4 组织和人员** =
--== **4.1 角色，能力和责任** ==
++== 4.1 **角色，能力和责任** ==
  实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定于每个实践的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住，角色并非职位头衔。一个人可担任多个角色，一个角色也可以分配给多个人员。
@@ -610,6
          +610,8 @@
  服务负责人
  )))|CA|熟悉沟通程序和沟通工具
++
++
  == **4.2** **组织结构和团队** ==
  事件管理实践不推荐任何特定的组织模型。但是，组织结构会影响实践的执行方式，因为它涉及具有不同领域和专业水平的专家。专家分组的典型方法包括：
@@ -639,6
          +639,8 @@
  * L3团队间协作，以取代多次重新分配和/或对专家和顶级人才的过度依赖。
  )))
++
++
  === **4.2.2 团队动力** ===
  事件管理实践是团队动力的基础，它们影响着运维支持团队的职责履行。经常出现以下问题：
@@ -672,7
          +672,7 @@
  = **5 信息和技术** =
--== **5.1** **信息沟通** ==
++== 5.1 **信息沟通** ==
  事件管理实践的有效性取决于所用信息的质量。这包括但不限于以下信息：
@@ -807,6
          +807,7 @@
  * 优化和自动化。
++
  ----
  = **8 致谢** =

粤ICP备17056641号

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