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

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

From version < 10.1 >

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

To version < 8.1 >

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

< >

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Content

@@ -39,6
          +39,7 @@
  * 支持实践的信息和技术
  * 对实践的合作伙伴和供应商的考虑。
++
  == **1.1 ITIL®4 认证方案** ==
  本文档的部分内容可以作为以下教学大纲的一部分以供检查：
@@ -67,7
          +67,6 @@
  事件管理实践是服务管理的基本元素。服务的快速恢复是用户和客户满意、服务提供者的信誉，以及组织在服务关系中创建价值的关键因素。
--
  == **2.2** **术语和概念** ==
  |**事件**
@@ -115,6
          +115,7 @@
  )))
  |因选择变通方案而非系统性解决方案（需要花费更长时间），而累计的返工总量
++
  == **2.3 范围** ==
  事件管理实践的范围包括：
@@ -151,6
          +151,7 @@
  |服务请求的管理和执行|服务请求管理
  |灾难情况下，恢复正常操作|服务连续性管理
++
  == **2.4** **实践成功因素** ==
  |(((
@@ -166,6
          +166,7 @@
  * 快速有效地解决事件
  * 不断改进事件管理方法。
++
  === **2.4.1 尽早发现事件** ===
  以前，实践通常是根据最终用户和IT专家的信息来报告大多数事件的。这种获取信息的方法仍被广泛使用，但是现在一个好的实践建议是自动发现和报告事件。可以在事件发生后和开始影响用户之前立即被发现。这种方法具有多种好处，其中包括：
@@ -210,6
          +210,7 @@
  * 找到并纠正根本原因的能力
  * 机器学习的可能性和质量。
++
  ==== **2.4.2.1 事件的优先级** ====
  事件应尽快解决。但是，参与事件解决的团队的资源是有限的，并且这些团队通常同时参与其他类型的工作。应该优先处理某些事件，以最大程度地减少对用户的负面影响。
@@ -248,9
          +248,9 @@
  全面描述采取行动的原因与描述行动本身同样重要。
  )))
++(% class="wikigeneratedid" %)
--
  == **2.5 关键指标** ==
  应该基于每个实践对价值流的贡献来评估ITIL实践的有效性和绩效。与任何工具的绩效一样，实践的绩效只能在其应用情境中评估。工具在设计和质量上可能会有很大差异，按照工具的用途使用时，这些差异定义了工具有效性的潜力或能力。关于度量标准，关键绩效指标（KPI）和其它技术的进一步指导，请参见度量和报告实践指南。
@@ -295,6
          +295,7 @@
  事件解决的速度和有效性指标之间的平衡
  )))
++
  ----
  = **3 价值流和流程** =
@@ -320,7
          +320,7 @@
  图3.1 事件管理实践对价值链活动的贡献热力图
--== **3.2 流程** ==
++== **3.2 流程** ==
  每个实践可以包含一个或多个过程和活动，这是实现这一实践目的所必需的。
@@ -335,6
          +335,7 @@
  * **事件的处理和解决**。该流程的重点是从发现到关闭的单个事件的处理和解决。
  * **定期事件评审**。该流程确保从事件处理和解决的过程中吸取教训，并确保持续改进事件管理的方法。
++
  === **3.2.1 事件处理和解决** ===
  该过程包括表3.1中列出的活动，并将输入转换为输出。
@@ -371,15
          +371,15 @@
  表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" %)(((
++(% 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和/或服务确定责任团队，并将事件关联到其他过去和正在处理的事态，事件和/或问题。
  在某些情况下，分类有助于找到以前为此类事件定义的解决方案。
--)))|(% style="width:403px" %)(((
++)))|(% style="width:484px" %)(((
  根据预定义的规则，将自动发现：
  * 事件对服务和用户的影响
@@ -386,19
          +386,19 @@
  * 可用的解决方案
  * 如果自动化解决方案无效或不可用，找到负责事件解决的技术团队。
  )))
--|(% style="width:85px" %)事件诊断|(% style="width:399px" %)(((
++|(% style="width:85px" %)事件诊断|(% style="width:439px" %)(((
  如果分类没有关联到已知解决方案，
  专家团队开展事件诊断。这可能涉及将事件升级到不同团队，或其他联合技术团队加入（如全功能团队）。
  如果由于配置项关联错误而导致分类错误，则应将此信息传达给负责配置管理的人员（请参阅服务配置实践指南）。
--)))|(% style="width:403px" %)(((
++)))|(% style="width:484px" %)(((
  如果自动解决方案无效或不可用，则将事件上报给负责诊断的技术团队。可能涉及事件升级到不同团队，或其他技术团队加入（如全功能团队）。
  如果由于配置项关联错误而导致自动化解决方案失败，则应将此信息传达给负责配置管理的人员（请参阅服务配置实践指南）。
  )))
--|(% style="width:85px" %)事件解决|(% style="width:399px" %)找到解决方案后，相关专家团队将尝试按顺序或并行工作方式执行，这可能需要启动变更。如果解决方案不起作用，则再次诊断。|(% style="width:403px" %)如果有可用的自动化解决方案，则实施它，并完成测试和确认。如果需要手动干预，则相关的专业团队尝试实施，这可能需要启动变更。如果解决方案不起作用，则再次诊断。
--|(% style="width:85px" %)事件关闭|(% style="width:399px" %)(((
++|(% style="width:85px" %)事件解决|(% style="width:439px" %)找到解决方案后，相关专家团队将尝试按顺序或并行工作方式执行，这可能需要启动变更。如果解决方案不起作用，则再次诊断。|(% style="width:484px" %)如果有可用的自动化解决方案，则实施它，并完成测试和确认。如果需要手动干预，则相关的专业团队尝试实施，这可能需要启动变更。如果解决方案不起作用，则再次诊断。
++|(% style="width:85px" %)事件关闭|(% style="width:439px" %)(((
  成功解决事件之后，可能需要一些正式的关闭过程：
  * 用户确认服务恢复
@@ -408,8
          +408,9 @@
  * 事件评审
  完成所有必需的操作并更新了相应地事件记录后，事件正式关闭。这可以由产品负责人，服务负责人，事件经理或服务台客服完成，具体取决于商定的事件模型。
--)))|(% style="width:403px" %)如果自动解决方案证明有效，则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者，则应向其传达事件关闭的信息。
++)))|(% style="width:484px" %)如果自动解决方案证明有效，则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者，则应向其传达事件关闭的信息。
++
  === **3.2.2 定期事件评审** ===
  该流程的重点是持续改进事件管理实践，事件模型和事件处理程序。它可以定期执行，也可以由事件报告触发，该报告突显低效率和其他改进点机会。根据现有模型和程序的效果，每两到三个月或更短时间进行一次定期检查。
@@ -459,6
          +459,7 @@
  变更的沟通
  )))|如果事件模型成功地完成优化，这一事实将会传达给相关的利益相关者。这通常由事件经理和/或服务或资源所有者通过沟通过程完成。
++
  ----
  = **4 组织和人员** =
@@ -480,6
          +480,7 @@
  |М|**方法和技巧专家 **设计和实施技术、文件化步骤、流程咨询、工作分析和持续改进
  |Т|**技术专家**提供技术（IT）专业知识并执行基于专家经验的作业
++
  === **4.1.1 事件经理角色** ===
  在许多组织中，事件经理角色由专人担任，有时授予事件经理的职衔。在其他组织中，事件经理的责任由负责与事件关联的配置项，服务或产品的人员或团队承担；他可能是资源所有者，服务负责人或产品负责人。
@@ -713,6
          +713,7 @@
  |诊断详情（如果有）|诊断步骤和每步的结果|减少重复工作
  |分派|事件的个人或团队所有者|
++
  == **5.2** **自动化和工具** ==
  事件管理实践应该是自动化的。在可行且有效的情况下，可能涉及表5.2中概述的解决方案。
@@ -765,6
          +765,8 @@
  |事件模型优化的启动|工作流系统和待办项管理工具|优化的正式登记|低到中
  |事件模型更新的沟通|通信系统和协作系统|与受影响团队沟通更新|中到高，尤其当组织较大，更新较多时为高
++
++
  ----
  = **6 合作伙伴和供应商** =
@@ -794,6
          +794,7 @@
  * 保持简单实用
  * 优化和自动化。
++
  ----
  = **8 致谢** =

粤ICP备17056641号

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