文档更改服务管理实践 - 02 事件
由 superadmin 于 2024/12/25, 15:38 最后修改
Summary
Details
- Page properties
-
- Content
-
... ... @@ -40,6 +40,7 @@ 40 40 * 对实践的合作伙伴和供应商的考虑。 41 41 42 42 43 + 43 43 == **1.1 ITIL®4 认证方案** == 44 44 45 45 本文档的部分内容可以作为以下教学大纲的一部分以供检查: ... ... @@ -57,7 +57,7 @@ 57 57 = **2 一般信息** = 58 58 59 59 60 -== **2.1****目的和描述** ==61 +== 2.1 **目的和描述** == 61 61 62 62 |((( 63 63 **关键信息** ... ... @@ -68,6 +68,8 @@ 68 68 69 69 事件管理实践是服务管理的基本元素。服务的快速恢复是用户和客户满意、服务提供者的信誉,以及组织在服务关系中创建价值的关键因素。 70 70 72 + 73 + 71 71 == **2.2** **术语和概念** == 72 72 73 73 |**事件** ... ... @@ -100,6 +100,7 @@ 100 100 * 与用户,客户,监管机构,媒体和其他利益相关者进行沟通的机制 101 101 * 达成一致的评审与后续活动的规程。 102 102 106 + 103 103 |((( 104 104 **定义:变通方案** 105 105 ))) ... ... @@ -116,6 +116,7 @@ 116 116 |因选择变通方案而非系统性解决方案(需要花费更长时间),而累计的返工总量 117 117 118 118 123 + 119 119 == **2.3 范围** == 120 120 121 121 事件管理实践的范围包括: ... ... @@ -153,6 +153,7 @@ 153 153 |灾难情况下,恢复正常操作|服务连续性管理 154 154 155 155 161 + 156 156 == **2.4** **实践成功因素** == 157 157 158 158 |((( ... ... @@ -169,6 +169,7 @@ 169 169 * 不断改进事件管理方法。 170 170 171 171 178 + 172 172 === **2.4.1 尽早发现事件** === 173 173 174 174 以前,实践通常是根据最终用户和IT专家的信息来报告大多数事件的。这种获取信息的方法仍被广泛使用,但是现在一个好的实践建议是自动发现和报告事件。可以在事件发生后和开始影响用户之前立即被发现。这种方法具有多种好处,其中包括: ... ... @@ -194,6 +194,7 @@ 194 194 * 在复杂的情况下,事件的确切性质未知,但支持团队熟悉系统和组件,并且组织可以获取专家知识,因此通常会将事件分派到一个或多个专家组进行诊断和解决。有时,这可以帮助识别模式,并产生一个模型和/或解决方案,可以应用于未来的类似事件。 195 195 * 在非常复杂的情况下,很难或不可能确定专家区域和专家组,或者已确定的专家组找不到解决方案时,采用集体方法可能会有用。此技术称为“全功能团队”。 196 196 204 + 197 197 |**全功能团队** 198 198 |解决各种复杂任务的技术方法。在全功能团队中,具有不同专业知识领域的多个人员一起完成一项任务,直到明确哪些能力最相关和最需要。 199 199 ... ... @@ -214,6 +214,7 @@ 214 214 * 机器学习的可能性和质量。 215 215 216 216 225 + 217 217 ==== **2.4.2.1 事件的优先级** ==== 218 218 219 219 事件应尽快解决。但是,参与事件解决的团队的资源是有限的,并且这些团队通常同时参与其他类型的工作。应该优先处理某些事件,以最大程度地减少对用户的负面影响。 ... ... @@ -254,7 +254,6 @@ 254 254 255 255 (% class="wikigeneratedid" %) 256 256 257 - 258 258 == **2.5 关键指标** == 259 259 260 260 应该基于每个实践对价值流的贡献来评估ITIL实践的有效性和绩效。与任何工具的绩效一样,实践的绩效只能在其应用情境中评估。工具在设计和质量上可能会有很大差异,按照工具的用途使用时,这些差异定义了工具有效性的潜力或能力。关于度量标准,关键绩效指标(KPI)和其它技术的进一步指导,请参见度量和报告实践指南。 ... ... @@ -300,6 +300,7 @@ 300 300 ))) 301 301 302 302 311 + 303 303 ---- 304 304 305 305 = **3 价值流和流程** = ... ... @@ -341,6 +341,7 @@ 341 341 * **定期事件评审**。该流程确保从事件处理和解决的过程中吸取教训,并确保持续改进事件管理的方法。 342 342 343 343 353 + 344 344 === **3.2.1 事件处理和解决** === 345 345 346 346 该过程包括表3.1中列出的活动,并将输入转换为输出。 ... ... @@ -417,6 +417,7 @@ 417 417 )))|(% style="width:484px" %)如果自动解决方案证明有效,则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者,则应向其传达事件关闭的信息。 418 418 419 419 430 + 420 420 === **3.2.2 定期事件评审** === 421 421 422 422 该流程的重点是持续改进事件管理实践,事件模型和事件处理程序。它可以定期执行,也可以由事件报告触发,该报告突显低效率和其他改进点机会。根据现有模型和程序的效果,每两到三个月或更短时间进行一次定期检查。 ... ... @@ -467,6 +467,7 @@ 467 467 )))|如果事件模型成功地完成优化,这一事实将会传达给相关的利益相关者。这通常由事件经理和/或服务或资源所有者通过沟通过程完成。 468 468 469 469 481 + 470 470 ---- 471 471 472 472 = **4 组织和人员** = ... ... @@ -489,6 +489,7 @@ 489 489 |Т|**技术专家**提供技术(IT)专业知识并执行基于专家经验的作业 490 490 491 491 504 + 492 492 === **4.1.1 事件经理角色** === 493 493 494 494 在许多组织中,事件经理角色由专人担任,有时授予事件经理的职衔。在其他组织中,事件经理的责任由负责与事件关联的配置项,服务或产品的人员或团队承担;他可能是资源所有者,服务负责人或产品负责人。 ... ... @@ -610,6 +610,7 @@ 610 610 服务负责人 611 611 )))|CA|熟悉沟通程序和沟通工具 612 612 626 + 613 613 == **4.2** **组织结构和团队** == 614 614 615 615 事件管理实践不推荐任何特定的组织模型。但是,组织结构会影响实践的执行方式,因为它涉及具有不同领域和专业水平的专家。专家分组的典型方法包括: ... ... @@ -639,6 +639,7 @@ 639 639 * L3团队间协作,以取代多次重新分配和/或对专家和顶级人才的过度依赖。 640 640 ))) 641 641 656 + 642 642 === **4.2.2 团队动力** === 643 643 644 644 事件管理实践是团队动力的基础,它们影响着运维支持团队的职责履行。经常出现以下问题: ... ... @@ -723,6 +723,7 @@ 723 723 |分派|事件的个人或团队所有者| 724 724 725 725 741 + 726 726 == **5.2** **自动化和工具** == 727 727 728 728 事件管理实践应该是自动化的。在可行且有效的情况下,可能涉及表5.2中概述的解决方案。 ... ... @@ -777,6 +777,7 @@ 777 777 778 778 779 779 796 + 780 780 ---- 781 781 782 782 = **6 合作伙伴和供应商** = ... ... @@ -807,6 +807,7 @@ 807 807 * 优化和自动化。 808 808 809 809 827 + 810 810 ---- 811 811 812 812 = **8 致谢** =