Changes for page 服务管理实践 - 02 事件
Last modified by superadmin on 2024/12/25, 15:38
Summary
Details
- Page properties
-
- Content
-
... ... @@ -39,6 +39,8 @@ 39 39 * 支持实践的信息和技术 40 40 * 对实践的合作伙伴和供应商的考虑。 41 41 42 + 43 + 42 42 == **1.1 ITIL®4 认证方案** == 43 43 44 44 本文档的部分内容可以作为以下教学大纲的一部分以供检查: ... ... @@ -56,7 +56,7 @@ 56 56 = **2 一般信息** = 57 57 58 58 59 -== **2.1****目的和描述** ==61 +== 2.1 **目的和描述** == 60 60 61 61 |((( 62 62 **关键信息** ... ... @@ -68,6 +68,7 @@ 68 68 事件管理实践是服务管理的基本元素。服务的快速恢复是用户和客户满意、服务提供者的信誉,以及组织在服务关系中创建价值的关键因素。 69 69 70 70 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 ))) ... ... @@ -171,6 +171,7 @@ 171 171 * 不断改进事件管理方法。 172 172 173 173 178 + 174 174 === **2.4.1 尽早发现事件** === 175 175 176 176 以前,实践通常是根据最终用户和IT专家的信息来报告大多数事件的。这种获取信息的方法仍被广泛使用,但是现在一个好的实践建议是自动发现和报告事件。可以在事件发生后和开始影响用户之前立即被发现。这种方法具有多种好处,其中包括: ... ... @@ -196,6 +196,7 @@ 196 196 * 在复杂的情况下,事件的确切性质未知,但支持团队熟悉系统和组件,并且组织可以获取专家知识,因此通常会将事件分派到一个或多个专家组进行诊断和解决。有时,这可以帮助识别模式,并产生一个模型和/或解决方案,可以应用于未来的类似事件。 197 197 * 在非常复杂的情况下,很难或不可能确定专家区域和专家组,或者已确定的专家组找不到解决方案时,采用集体方法可能会有用。此技术称为“全功能团队”。 198 198 204 + 199 199 |**全功能团队** 200 200 |解决各种复杂任务的技术方法。在全功能团队中,具有不同专业知识领域的多个人员一起完成一项任务,直到明确哪些能力最相关和最需要。 201 201 ... ... @@ -216,6 +216,7 @@ 216 216 * 机器学习的可能性和质量。 217 217 218 218 225 + 219 219 ==== **2.4.2.1 事件的优先级** ==== 220 220 221 221 事件应尽快解决。但是,参与事件解决的团队的资源是有限的,并且这些团队通常同时参与其他类型的工作。应该优先处理某些事件,以最大程度地减少对用户的负面影响。 ... ... @@ -254,8 +254,9 @@ 254 254 全面描述采取行动的原因与描述行动本身同样重要。 255 255 ))) 256 256 264 +(% class="wikigeneratedid" %) 265 +== == 257 257 258 - 259 259 == **2.5 关键指标** == 260 260 261 261 应该基于每个实践对价值流的贡献来评估ITIL实践的有效性和绩效。与任何工具的绩效一样,实践的绩效只能在其应用情境中评估。工具在设计和质量上可能会有很大差异,按照工具的用途使用时,这些差异定义了工具有效性的潜力或能力。关于度量标准,关键绩效指标(KPI)和其它技术的进一步指导,请参见度量和报告实践指南。 ... ... @@ -327,7 +327,7 @@ 327 327 图3.1 事件管理实践对价值链活动的贡献热力图 328 328 329 329 330 -== **3.2 流程** == 338 +== **3.2 流程** == 331 331 332 332 每个实践可以包含一个或多个过程和活动,这是实现这一实践目的所必需的。 333 333 ... ... @@ -343,6 +343,7 @@ 343 343 * **定期事件评审**。该流程确保从事件处理和解决的过程中吸取教训,并确保持续改进事件管理的方法。 344 344 345 345 354 + 346 346 === **3.2.1 事件处理和解决** === 347 347 348 348 该过程包括表3.1中列出的活动,并将输入转换为输出。 ... ... @@ -379,15 +379,15 @@ 379 379 380 380 表3.2 事件处理和事件解决过程的活动 381 381 382 -(% style="width: 889px" %)383 -|(% style="width:85px" %)**活动**|(% style="width:39 9px" %)**手动处理用户发现的事件**|(% style="width:403px" %)**自动发现和处理事件**384 -|(% style="width:85px" %)事件发现|(% style="width:39 9px" %)用户发现服务运营中的故障,并通过约定的渠道与服务提供者的服务台联系。服务台客服对该用户问询进行初始分类,确认该问询确实属于事件。|(% style="width:403px" %)监控系统检测到事态,并基于预定义的分类将其标识为事件。385 -|(% style="width:85px" %)事件登记|(% style="width:39 9px" %)服务台客服执行事件登记,将有效数据添加到事件记录中。|(% style="width:403px" %)登记事件记录并将其与发现事态的CI关联。登记预定义的技术参数。必要时,给相关技术专家发送通知。386 -|(% style="width:85px" %)事件分类|(% style="width:39 9px" %)(((391 +(% style="width:1010px" %) 392 +|(% style="width:85px" %)**活动**|(% style="width:439px" %)**手动处理用户发现的事件**|(% style="width:484px" %)**自动发现和处理事件** 393 +|(% style="width:85px" %)事件发现|(% style="width:439px" %)用户发现服务运营中的故障,并通过约定的渠道与服务提供者的服务台联系。服务台客服对该用户问询进行初始分类,确认该问询确实属于事件。|(% style="width:484px" %)监控系统检测到事态,并基于预定义的分类将其标识为事件。 394 +|(% style="width:85px" %)事件登记|(% style="width:439px" %)服务台客服执行事件登记,将有效数据添加到事件记录中。|(% style="width:484px" %)登记事件记录并将其与发现事态的CI关联。登记预定义的技术参数。必要时,给相关技术专家发送通知。 395 +|(% style="width:85px" %)事件分类|(% style="width:439px" %)((( 387 387 服务台客服完成事件初始分类;这有助于确定事件的影响,确定为失效CI和/或服务确定责任团队,并将事件关联到其他过去和正在处理的事态,事件和/或问题。 388 388 389 389 在某些情况下,分类有助于找到以前为此类事件定义的解决方案。 390 -)))|(% style="width:4 03px" %)(((399 +)))|(% style="width:484px" %)((( 391 391 根据预定义的规则,将自动发现: 392 392 393 393 * 事件对服务和用户的影响 ... ... @@ -394,19 +394,19 @@ 394 394 * 可用的解决方案 395 395 * 如果自动化解决方案无效或不可用,找到负责事件解决的技术团队。 396 396 ))) 397 -|(% style="width:85px" %)事件诊断|(% style="width:39 9px" %)(((406 +|(% style="width:85px" %)事件诊断|(% style="width:439px" %)((( 398 398 如果分类没有关联到已知解决方案, 399 399 400 400 专家团队开展事件诊断。这可能涉及将事件升级到不同团队,或其他联合技术团队加入(如全功能团队)。 401 401 402 402 如果由于配置项关联错误而导致分类错误,则应将此信息传达给负责配置管理的人员(请参阅服务配置实践指南)。 403 -)))|(% style="width:4 03px" %)(((412 +)))|(% style="width:484px" %)((( 404 404 如果自动解决方案无效或不可用,则将事件上报给负责诊断的技术团队。可能涉及事件升级到不同团队,或其他技术团队加入(如全功能团队)。 405 405 406 406 如果由于配置项关联错误而导致自动化解决方案失败,则应将此信息传达给负责配置管理的人员(请参阅服务配置实践指南)。 407 407 ))) 408 -|(% style="width:85px" %)事件解决|(% style="width:39 9px" %)找到解决方案后,相关专家团队将尝试按顺序或并行工作方式执行,这可能需要启动变更。如果解决方案不起作用,则再次诊断。|(% style="width:403px" %)如果有可用的自动化解决方案,则实施它,并完成测试和确认。如果需要手动干预,则相关的专业团队尝试实施,这可能需要启动变更。如果解决方案不起作用,则再次诊断。409 -|(% style="width:85px" %)事件关闭|(% style="width:39 9px" %)(((417 +|(% style="width:85px" %)事件解决|(% style="width:439px" %)找到解决方案后,相关专家团队将尝试按顺序或并行工作方式执行,这可能需要启动变更。如果解决方案不起作用,则再次诊断。|(% style="width:484px" %)如果有可用的自动化解决方案,则实施它,并完成测试和确认。如果需要手动干预,则相关的专业团队尝试实施,这可能需要启动变更。如果解决方案不起作用,则再次诊断。 418 +|(% style="width:85px" %)事件关闭|(% style="width:439px" %)((( 410 410 成功解决事件之后,可能需要一些正式的关闭过程: 411 411 412 412 * 用户确认服务恢复 ... ... @@ -416,7 +416,7 @@ 416 416 * 事件评审 417 417 418 418 完成所有必需的操作并更新了相应地事件记录后,事件正式关闭。这可以由产品负责人,服务负责人,事件经理或服务台客服完成,具体取决于商定的事件模型。 419 -)))|(% style="width:4 03px" %)如果自动解决方案证明有效,则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者,则应向其传达事件关闭的信息。428 +)))|(% style="width:484px" %)如果自动解决方案证明有效,则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者,则应向其传达事件关闭的信息。 420 420 421 421 422 422 ... ... @@ -616,7 +616,6 @@ 616 616 )))|CA|熟悉沟通程序和沟通工具 617 617 618 618 619 - 620 620 == **4.2** **组织结构和团队** == 621 621 622 622 事件管理实践不推荐任何特定的组织模型。但是,组织结构会影响实践的执行方式,因为它涉及具有不同领域和专业水平的专家。专家分组的典型方法包括: ... ... @@ -647,7 +647,6 @@ 647 647 ))) 648 648 649 649 650 - 651 651 === **4.2.2 团队动力** === 652 652 653 653 事件管理实践是团队动力的基础,它们影响着运维支持团队的职责履行。经常出现以下问题: ... ... @@ -787,6 +787,7 @@ 787 787 788 788 789 789 797 + 790 790 ---- 791 791 792 792 = **6 合作伙伴和供应商** =