文档更改服务管理实践 - 02 事件
由 superadmin 于 2024/12/25, 15:38 最后修改
Summary
Details
- Page properties
-
- Content
-
... ... @@ -39,7 +39,6 @@ 39 39 * 支持实践的信息和技术 40 40 * 对实践的合作伙伴和供应商的考虑。 41 41 42 - 43 43 == **1.1 ITIL®4 认证方案** == 44 44 45 45 本文档的部分内容可以作为以下教学大纲的一部分以供检查: ... ... @@ -115,7 +115,6 @@ 115 115 ))) 116 116 |因选择变通方案而非系统性解决方案(需要花费更长时间),而累计的返工总量 117 117 118 - 119 119 == **2.3 范围** == 120 120 121 121 事件管理实践的范围包括: ... ... @@ -152,7 +152,6 @@ 152 152 |服务请求的管理和执行|服务请求管理 153 153 |灾难情况下,恢复正常操作|服务连续性管理 154 154 155 - 156 156 == **2.4** **实践成功因素** == 157 157 158 158 |((( ... ... @@ -168,7 +168,6 @@ 168 168 * 快速有效地解决事件 169 169 * 不断改进事件管理方法。 170 170 171 - 172 172 === **2.4.1 尽早发现事件** === 173 173 174 174 以前,实践通常是根据最终用户和IT专家的信息来报告大多数事件的。这种获取信息的方法仍被广泛使用,但是现在一个好的实践建议是自动发现和报告事件。可以在事件发生后和开始影响用户之前立即被发现。这种方法具有多种好处,其中包括: ... ... @@ -213,7 +213,6 @@ 213 213 * 找到并纠正根本原因的能力 214 214 * 机器学习的可能性和质量。 215 215 216 - 217 217 ==== **2.4.2.1 事件的优先级** ==== 218 218 219 219 事件应尽快解决。但是,参与事件解决的团队的资源是有限的,并且这些团队通常同时参与其他类型的工作。应该优先处理某些事件,以最大程度地减少对用户的负面影响。 ... ... @@ -255,6 +255,7 @@ 255 255 (% class="wikigeneratedid" %) 256 256 257 257 253 + 258 258 == **2.5 关键指标** == 259 259 260 260 应该基于每个实践对价值流的贡献来评估ITIL实践的有效性和绩效。与任何工具的绩效一样,实践的绩效只能在其应用情境中评估。工具在设计和质量上可能会有很大差异,按照工具的用途使用时,这些差异定义了工具有效性的潜力或能力。关于度量标准,关键绩效指标(KPI)和其它技术的进一步指导,请参见度量和报告实践指南。 ... ... @@ -299,7 +299,6 @@ 299 299 事件解决的速度和有效性指标之间的平衡 300 300 ))) 301 301 302 - 303 303 ---- 304 304 305 305 = **3 价值流和流程** = ... ... @@ -325,7 +325,7 @@ 325 325 图3.1 事件管理实践对价值链活动的贡献热力图 326 326 327 327 328 -== ** 3.2 流程** ==323 +== **3.2 流程** == 329 329 330 330 每个实践可以包含一个或多个过程和活动,这是实现这一实践目的所必需的。 331 331 ... ... @@ -377,15 +377,15 @@ 377 377 378 378 表3.2 事件处理和事件解决过程的活动 379 379 380 -(% style="width: 1010px" %)381 -|(% style="width:85px" %)**活动**|(% style="width: 439px" %)**手动处理用户发现的事件**|(% style="width:484px" %)**自动发现和处理事件**382 -|(% style="width:85px" %)事件发现|(% style="width: 439px" %)用户发现服务运营中的故障,并通过约定的渠道与服务提供者的服务台联系。服务台客服对该用户问询进行初始分类,确认该问询确实属于事件。|(% style="width:484px" %)监控系统检测到事态,并基于预定义的分类将其标识为事件。383 -|(% style="width:85px" %)事件登记|(% style="width: 439px" %)服务台客服执行事件登记,将有效数据添加到事件记录中。|(% style="width:484px" %)登记事件记录并将其与发现事态的CI关联。登记预定义的技术参数。必要时,给相关技术专家发送通知。384 -|(% style="width:85px" %)事件分类|(% style="width: 439px" %)(((375 +(% style="width:889px" %) 376 +|(% style="width:85px" %)**活动**|(% style="width:399px" %)**手动处理用户发现的事件**|(% style="width:403px" %)**自动发现和处理事件** 377 +|(% style="width:85px" %)事件发现|(% style="width:399px" %)用户发现服务运营中的故障,并通过约定的渠道与服务提供者的服务台联系。服务台客服对该用户问询进行初始分类,确认该问询确实属于事件。|(% style="width:403px" %)监控系统检测到事态,并基于预定义的分类将其标识为事件。 378 +|(% style="width:85px" %)事件登记|(% style="width:399px" %)服务台客服执行事件登记,将有效数据添加到事件记录中。|(% style="width:403px" %)登记事件记录并将其与发现事态的CI关联。登记预定义的技术参数。必要时,给相关技术专家发送通知。 379 +|(% style="width:85px" %)事件分类|(% style="width:399px" %)((( 385 385 服务台客服完成事件初始分类;这有助于确定事件的影响,确定为失效CI和/或服务确定责任团队,并将事件关联到其他过去和正在处理的事态,事件和/或问题。 386 386 387 387 在某些情况下,分类有助于找到以前为此类事件定义的解决方案。 388 -)))|(% style="width:4 84px" %)(((383 +)))|(% style="width:403px" %)((( 389 389 根据预定义的规则,将自动发现: 390 390 391 391 * 事件对服务和用户的影响 ... ... @@ -392,19 +392,19 @@ 392 392 * 可用的解决方案 393 393 * 如果自动化解决方案无效或不可用,找到负责事件解决的技术团队。 394 394 ))) 395 -|(% style="width:85px" %)事件诊断|(% style="width: 439px" %)(((390 +|(% style="width:85px" %)事件诊断|(% style="width:399px" %)((( 396 396 如果分类没有关联到已知解决方案, 397 397 398 398 专家团队开展事件诊断。这可能涉及将事件升级到不同团队,或其他联合技术团队加入(如全功能团队)。 399 399 400 400 如果由于配置项关联错误而导致分类错误,则应将此信息传达给负责配置管理的人员(请参阅服务配置实践指南)。 401 -)))|(% style="width:4 84px" %)(((396 +)))|(% style="width:403px" %)((( 402 402 如果自动解决方案无效或不可用,则将事件上报给负责诊断的技术团队。可能涉及事件升级到不同团队,或其他技术团队加入(如全功能团队)。 403 403 404 404 如果由于配置项关联错误而导致自动化解决方案失败,则应将此信息传达给负责配置管理的人员(请参阅服务配置实践指南)。 405 405 ))) 406 -|(% style="width:85px" %)事件解决|(% style="width: 439px" %)找到解决方案后,相关专家团队将尝试按顺序或并行工作方式执行,这可能需要启动变更。如果解决方案不起作用,则再次诊断。|(% style="width:484px" %)如果有可用的自动化解决方案,则实施它,并完成测试和确认。如果需要手动干预,则相关的专业团队尝试实施,这可能需要启动变更。如果解决方案不起作用,则再次诊断。407 -|(% style="width:85px" %)事件关闭|(% style="width: 439px" %)(((401 +|(% style="width:85px" %)事件解决|(% style="width:399px" %)找到解决方案后,相关专家团队将尝试按顺序或并行工作方式执行,这可能需要启动变更。如果解决方案不起作用,则再次诊断。|(% style="width:403px" %)如果有可用的自动化解决方案,则实施它,并完成测试和确认。如果需要手动干预,则相关的专业团队尝试实施,这可能需要启动变更。如果解决方案不起作用,则再次诊断。 402 +|(% style="width:85px" %)事件关闭|(% style="width:399px" %)((( 408 408 成功解决事件之后,可能需要一些正式的关闭过程: 409 409 410 410 * 用户确认服务恢复 ... ... @@ -414,7 +414,7 @@ 414 414 * 事件评审 415 415 416 416 完成所有必需的操作并更新了相应地事件记录后,事件正式关闭。这可以由产品负责人,服务负责人,事件经理或服务台客服完成,具体取决于商定的事件模型。 417 -)))|(% style="width:4 84px" %)如果自动解决方案证明有效,则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者,则应向其传达事件关闭的信息。412 +)))|(% style="width:403px" %)如果自动解决方案证明有效,则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者,则应向其传达事件关闭的信息。 418 418 419 419 420 420 === **3.2.2 定期事件评审** === ... ... @@ -466,7 +466,6 @@ 466 466 变更的沟通 467 467 )))|如果事件模型成功地完成优化,这一事实将会传达给相关的利益相关者。这通常由事件经理和/或服务或资源所有者通过沟通过程完成。 468 468 469 - 470 470 ---- 471 471 472 472 = **4 组织和人员** = ... ... @@ -488,7 +488,6 @@ 488 488 |М|**方法和技巧专家 **设计和实施技术、文件化步骤、流程咨询、工作分析和持续改进 489 489 |Т|**技术专家**提供技术(IT)专业知识并执行基于专家经验的作业 490 490 491 - 492 492 === **4.1.1 事件经理角色** === 493 493 494 494 在许多组织中,事件经理角色由专人担任,有时授予事件经理的职衔。在其他组织中,事件经理的责任由负责与事件关联的配置项,服务或产品的人员或团队承担;他可能是资源所有者,服务负责人或产品负责人。 ... ... @@ -722,7 +722,6 @@ 722 722 |诊断详情(如果有)|诊断步骤和每步的结果|减少重复工作 723 723 |分派|事件的个人或团队所有者| 724 724 725 - 726 726 == **5.2** **自动化和工具** == 727 727 728 728 事件管理实践应该是自动化的。在可行且有效的情况下,可能涉及表5.2中概述的解决方案。 ... ... @@ -776,7 +776,6 @@ 776 776 |事件模型更新的沟通|通信系统和协作系统|与受影响团队沟通更新|中到高,尤其当组织较大,更新较多时为高 777 777 778 778 779 - 780 780 ---- 781 781 782 782 = **6 合作伙伴和供应商** = ... ... @@ -806,7 +806,6 @@ 806 806 * 保持简单实用 807 807 * 优化和自动化。 808 808 809 - 810 810 ---- 811 811 812 812 = **8 致谢** =