由 superadmin 于 2024/12/25, 15:38 最后修改
从版本< 7.1 >
由superadmin编辑
在2021/12/16, 23:03上
到版本
由superadmin编辑
在2021/12/16, 23:07上
< >
修改评论 该版本没有评论

Summary

Details

Icon Page properties
Content
... ... @@ -39,8 +39,6 @@
39 39  * 支持实践的信息和技术
40 40  * 对实践的合作伙伴和供应商的考虑。
41 41  
42 -
43 -
44 44  == **1.1 ITIL®4 认证方案** ==
45 45  
46 46  本文档的部分内容可以作为以下教学大纲的一部分以供检查：
... ... @@ -58,7 +58,7 @@
58 58  = **2 一般信息** =
59 59  
60 60  
61 -== 2.1 **目的和描述** ==
59 +== **2.1** **目的和描述** ==
62 62  
63 63  |(((
64 64  **关键信息**
... ... @@ -70,7 +70,6 @@
70 70  事件管理实践是服务管理的基本元素。服务的快速恢复是用户和客户满意、服务提供者的信誉，以及组织在服务关系中创建价值的关键因素。
71 71  
72 72  
73 -
74 74  == **​​​​​​​2.2** **术语和概念** ==
75 75  
76 76  |**事件**
... ... @@ -103,7 +103,6 @@
103 103  * 与用户，客户，监管机构，媒体和其他利益相关者进行沟通的机制
104 104  * 达成一致的评审与后续活动的规程。
105 105  
106 -
107 107  |(((
108 108  **定义：变通方案**
109 109  )))
... ... @@ -175,7 +175,6 @@
175 175  * 不断改进事件管理方法。
176 176  
177 177  
178 -
179 179  === **2.4.1 尽早发现事件** ===
180 180  
181 181  以前，实践通常是根据最终用户和IT专家的信息来报告大多数事件的。这种获取信息的方法仍被广泛使用，但是现在一个好的实践建议是自动发现和报告事件。可以在事件发生后和开始影响用户之前立即被发现。这种方法具有多种好处，其中包括：
... ... @@ -201,7 +201,6 @@
201 201  * 在复杂的情况下，事件的确切性质未知，但支持团队熟悉系统和组件，并且组织可以获取专家知识，因此通常会将事件分派到一个或多个专家组进行诊断和解决。有时，这可以帮助识别模式，并产生一个模型和/或解决方案，可以应用于未来的类似事件。
202 202  * 在非常复杂的情况下，很难或不可能确定专家区域和专家组，或者已确定的专家组找不到解决方案时，采用集体方法可能会有用。此技术称为“全功能团队”。
203 203  
204 -
205 205  |**全功能团队**
206 206  |解决各种复杂任务的技术方法。在全功能团队中，具有不同专业知识领域的多个人员一起完成一项任务，直到明确哪些能力最相关和最需要。
207 207  
... ... @@ -222,7 +222,6 @@
222 222  * 机器学习的可能性和质量。
223 223  
224 224  
225 -
226 226  ==== **2.4.2.1 事件的优先级** ====
227 227  
228 228  事件应尽快解决。但是，参与事件解决的团队的资源是有限的，并且这些团队通常同时参与其他类型的工作。应该优先处理某些事件，以最大程度地减少对用户的负面影响。
... ... @@ -261,8 +261,8 @@
261 261  全面描述采取行动的原因与描述行动本身同样重要。
262 262  )))
263 263  
264 -(% class="wikigeneratedid" %)
265 265  
258 +
266 266  == **​​​​​​​2.5 关键指标** ==
267 267  
268 268  应该基于每个实践对价值流的贡献来评估ITIL实践的有效性和绩效。与任何工具的绩效一样，实践的绩效只能在其应用情境中评估。工具在设计和质量上可能会有很大差异，按照工具的用途使用时，这些差异定义了工具有效性的潜力或能力。关于度量标准，关键绩效指标（KPI）和其它技术的进一步指导，请参见度量和报告实践指南。
... ... @@ -334,7 +334,7 @@
334 334  图3.1 事件管理实践对价值链活动的贡献热力图
335 335  
336 336  
337 -== **​​​​​​​3.2 流程** ==
330 +== **3.2 流程** ==
338 338  
339 339  每个实践可以包含一个或多个过程和活动，这是实现这一实践目的所必需的。
340 340  
... ... @@ -350,7 +350,6 @@
350 350  * **定期事件评审**。该流程确保从事件处理和解决的过程中吸取教训，并确保持续改进事件管理的方法。
351 351  
352 352  
353 -
354 354  === **3.2.1 事件处理和解决** ===
355 355  
356 356  该过程包括表3.1中列出的活动，并将输入转换为输出。
... ... @@ -387,15 +387,15 @@
387 387  
388 388  表3.2 事件处理和事件解决过程的活动
389 389  
390 -(% style="width:1010px" %)
391 -|(% style="width:85px" %)**活动**|(% style="width:439px" %)**手动处理用户发现的事件**|(% style="width:484px" %)**自动发现和处理事件**
392 -|(% style="width:85px" %)事件发现|(% style="width:439px" %)用户发现服务运营中的故障，并通过约定的渠道与服务提供者的服务台联系。服务台客服对该用户问询进行初始分类，确认该问询确实属于事件。|(% style="width:484px" %)监控系统检测到事态，并基于预定义的分类将其标识为事件。
393 -|(% style="width:85px" %)事件登记|(% style="width:439px" %)服务台客服执行事件登记，将有效数据添加到事件记录中。|(% style="width:484px" %)登记事件记录并将其与发现事态的CI关联。登记预定义的技术参数。必要时，给相关技术专家发送通知。
394 -|(% style="width:85px" %)事件分类|(% style="width:439px" %)(((
382 +(% style="width:889px" %)
383 +|(% style="width:85px" %)**活动**|(% style="width:399px" %)**手动处理用户发现的事件**|(% style="width:403px" %)**自动发现和处理事件**
384 +|(% style="width:85px" %)事件发现|(% style="width:399px" %)用户发现服务运营中的故障，并通过约定的渠道与服务提供者的服务台联系。服务台客服对该用户问询进行初始分类，确认该问询确实属于事件。|(% style="width:403px" %)监控系统检测到事态，并基于预定义的分类将其标识为事件。
385 +|(% style="width:85px" %)事件登记|(% style="width:399px" %)服务台客服执行事件登记，将有效数据添加到事件记录中。|(% style="width:403px" %)登记事件记录并将其与发现事态的CI关联。登记预定义的技术参数。必要时，给相关技术专家发送通知。
386 +|(% style="width:85px" %)事件分类|(% style="width:399px" %)(((
395 395  服务台客服完成事件初始分类；这有助于确定事件的影响，确定为失效CI和/或服务确定责任团队，并将事件关联到其他过去和正在处理的事态，事件和/或问题。
396 396  
397 397  在某些情况下，分类有助于找到以前为此类事件定义的解决方案。
398 -)))|(% style="width:484px" %)(((
390 +)))|(% style="width:403px" %)(((
399 399  根据预定义的规则，将自动发现：
400 400  
401 401  * 事件对服务和用户的影响
... ... @@ -402,19 +402,19 @@
402 402  * 可用的解决方案
403 403  * 如果自动化解决方案无效或不可用，找到负责事件解决的技术团队。
404 404  )))
405 -|(% style="width:85px" %)事件诊断|(% style="width:439px" %)(((
397 +|(% style="width:85px" %)事件诊断|(% style="width:399px" %)(((
406 406  如果分类没有关联到已知解决方案，
407 407  
408 408  专家团队开展事件诊断。这可能涉及将事件升级到不同团队，或其他联合技术团队加入（如全功能团队）。
409 409  
410 410  如果由于配置项关联错误而导致分类错误，则应将此信息传达给负责配置管理的人员（请参阅服务配置实践指南）。
411 -)))|(% style="width:484px" %)(((
403 +)))|(% style="width:403px" %)(((
412 412  如果自动解决方案无效或不可用，则将事件上报给负责诊断的技术团队。可能涉及事件升级到不同团队，或其他技术团队加入（如全功能团队）。
413 413  
414 414  如果由于配置项关联错误而导致自动化解决方案失败，则应将此信息传达给负责配置管理的人员（请参阅服务配置实践指南）。
415 415  )))
416 -|(% style="width:85px" %)事件解决|(% style="width:439px" %)找到解决方案后，相关专家团队将尝试按顺序或并行工作方式执行，这可能需要启动变更。如果解决方案不起作用，则再次诊断。|(% style="width:484px" %)如果有可用的自动化解决方案，则实施它，并完成测试和确认。如果需要手动干预，则相关的专业团队尝试实施，这可能需要启动变更。如果解决方案不起作用，则再次诊断。
417 -|(% style="width:85px" %)事件关闭|(% style="width:439px" %)(((
408 +|(% style="width:85px" %)事件解决|(% style="width:399px" %)找到解决方案后，相关专家团队将尝试按顺序或并行工作方式执行，这可能需要启动变更。如果解决方案不起作用，则再次诊断。|(% style="width:403px" %)如果有可用的自动化解决方案，则实施它，并完成测试和确认。如果需要手动干预，则相关的专业团队尝试实施，这可能需要启动变更。如果解决方案不起作用，则再次诊断。
409 +|(% style="width:85px" %)事件关闭|(% style="width:399px" %)(((
418 418  成功解决事件之后，可能需要一些正式的关闭过程：
419 419  
420 420  * 用户确认服务恢复
... ... @@ -424,7 +424,7 @@
424 424  * 事件评审
425 425  
426 426  完成所有必需的操作并更新了相应地事件记录后，事件正式关闭。这可以由产品负责人，服务负责人，事件经理或服务台客服完成，具体取决于商定的事件模型。
427 -)))|(% style="width:484px" %)如果自动解决方案证明有效，则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者，则应向其传达事件关闭的信息。
419 +)))|(% style="width:403px" %)如果自动解决方案证明有效，则事件记录将自动更新并关闭。发送报告给负责的技术团队。如果在先前的任何步骤中已将有关事件的信息传达给其他利益相关者，则应向其传达事件关闭的信息。
428 428  
429 429  
430 430  
... ... @@ -624,6 +624,7 @@
624 624  )))|CA|熟悉沟通程序和沟通工具
625 625  
626 626  
619 +
627 627  == **​​​​​​​4.2** **组织结构和团队** ==
628 628  
629 629  事件管理实践不推荐任何特定的组织模型。但是，组织结构会影响实践的执行方式，因为它涉及具有不同领域和专业水平的专家。专家分组的典型方法包括：
... ... @@ -654,6 +654,7 @@
654 654  )))
655 655  
656 656  
650 +
657 657  === **4.2.2 团队动力** ===
658 658  
659 659  事件管理实践是团队动力的基础，它们影响着运维支持团队的职责履行。经常出现以下问题：
... ... @@ -793,7 +793,6 @@
793 793  
794 794  
795 795  
796 -
797 797  ----
798 798  
799 799  = **6 合作伙伴和供应商** =
深圳市艾拓先锋企业管理咨询有限公司