由 superadmin 于 2024/10/15, 16:43 最后修改
从版本< 8.1 >
由superadmin编辑
在2024/10/13, 16:55上
到版本
由superadmin编辑
在2024/10/13, 16:53上
< >
修改评论 该版本没有评论

Summary

Details

Icon Page properties
Content
... ... @@ -50,7 +50,6 @@
50 50  
51 51  在事故的早期阶段，能够得到相应的而且容易应用的建议，对于组织有效地解决事故的能力来说，这是最重要的。服务台接收到的事故，对于支持员工很少是初见的或是神秘的。相似地，处于二线或三线的支持员工中的专家也已经解决了许多困难和原始事故和问题。花费在这些解决方案上的资源的最好使用方式就是将它制作成文档，这样一线的员工就可以应用它们了。
52 52  
53 -
54 54  问题管理流程试图降低影响业务的事故和问题的数量及危害，因此，问题管理的部分职责是确保以前的信息被记录在档，这样对一线及其它二线支持员工就已经是准备好可用的了。它不是简单地记录文档的问题，它要求：
55 55  
56 56  1. 信息应该建立索引，以便根据来自新事故的简单的线索就能容易地查找；
... ... @@ -75,7 +75,6 @@
75 75  1. 提供知识库；
76 76  1. 引进新产品时的开发人员和提供商。
77 77  
78 -
79 79  一般情况下，问题是多个展现出共同特征的事故的结果。有时问题也可以根据单个明显的事故来识别，由单个错误引起，虽然原因未知，但影响明显。
80 80  
81 81  知名错误是对问题的根本原因成功诊断后识别的，后续将开发一个临时措施。
... ... @@ -98,10 +98,8 @@
98 98  
99 99  问题控制流程很相似于，且高度依赖于事故控制流程的质量。事故控制重点在于解决事故，提供临时措施，对特定的事故临时修复。如果对于一个或一组事故，识别出了问题，可用的临时措施和临时修复应该由问题控制流程记录在问题记录中。问题控制流程也对问题建议最佳的可用临时措施。
100 100  
101 -
102 102  因为问题控制关注于阻止事故的重复发生，因此流程的方法应该被仔细地管理和规划。管理和规划的程度要高于事故控制，因为它的目标只是尽快地恢复正常的服务。优先权应该分配组那些可能引起严重业务中断的问题的解决。
103 103  
104 -
105 105  在事故控制中的活动包括：
106 106  
107 107  1. 问题识别和记录；
... ... @@ -225,8 +225,9 @@
225 225  1. 问题的分类－根据对业务的影响；
226 226  1. 问题的调查和诊断。
227 227  
228 -[[image:1728809269856-411.png]]
229 229  
225 +[[image:1728809269856-411.png]]
226 +
230 230  当检测到根本原因时，就开始错误控制流程。
231 231  
232 232  
... ... @@ -268,6 +268,7 @@
268 268  1. 紧急程度
269 269  1. 优先级
270 270  
268 +
271 271  问题被归类到相关的组或域（例如硬件、软件、支持软件以及相应的其它种类）。这些组能够与机构的职责匹配，或者以用户和客户为基础归类，是将问题分配给支持职员的基础。附录A给出一个简单但对问题归类有效的结构。
272 272  
273 273  新问题的识别应该在受其影响的对象（也就是它对业务的影响）分析之后。登记在CMDB中的IT基础架构中的组件间的关系有助于判断问题的影响。
... ... @@ -286,6 +286,7 @@
286 286  1. 计划推迟解决的可能性；
287 287  1. 对业务未来影响的意识，如支持月末处理的设备需求。
288 288  
287 +
289 289  每个事故、问题和变更将都会对业务服务和紧急程度有影响：
290 290  
291 291  1. 影响－描述了业务受到破坏的可能；
... ... @@ -452,6 +452,7 @@
452 452  1. 特定类型或某个配置项重复出现的问题；
453 453  1. 客户对培训的需求或对更好文档的需求；
454 454  
454 +
455 455  事故和问题的分类，以及积极的分析可以揭露趋势，识别出需要进一步调查的特定（或潜在）的问题区域。例如，分析可能指出与最近安装的客户－服务器系统相关的事故是个问题区域，对客户业务的负面影响增长最快。
456 456  
457 457  
... ... @@ -477,6 +477,7 @@
477 477  1. 解决事故的持续时间和相关的成本
478 478  1. 业务成本－这可能是所有因素中最重要的
479 479  
480 +
480 480  这个方法避免将精力集中放在这样一组事故上，相对而言数量较大，而对提供的服务水平没有较高的影响；相反地，将精力放在调查一小组而更有益的事故上，它可能对组织的业务有很高的影响。
481 481  
482 482  
... ... @@ -556,6 +556,7 @@
556 556  1*. 成本（相对于预算）
557 557  1. 所采取行动的简单描述
558 558  
560 +
559 559  关于IT基础架构中不牢固的组件的信息、违背与业务协定的服务水平的信息以及与厂商定的服务水平信息都涉及到可用性管理。问题出现的频度和持续时间是相对于服务水平的效率的度量标准。要求的信息包括：
560 560  
561 561  1. 根据以下方面划分的问题和错误的数量：
... ... @@ -570,6 +570,7 @@
570 570  1. 任何临时解决行动；
571 571  1. 重大问题期望的解决时间；
572 572  
575 +
573 573  定期审计
574 574  
575 575  流程要求要求对所有操作和过程进行定期审计。审计的目的是确认问题管理和支持小组执行了预定义的过程。审计应该分析主要的问题回顾，检查：
... ... @@ -640,6 +640,7 @@
640 640  1. 对未解决的问题/知名错误，向事故管理职员建议与之相关事故的最佳的可用临时措施；
641 641  1. 帮助处理主要事故，识别根本原因；
642 642  
646 +
643 643  * **主动责任**
644 644  
645 645  1. 识别趋势和潜在的问题源（通过回顾事故和问题分析）；
... ... @@ -665,6 +665,7 @@
665 665  1. 测试最可能的原因
666 666  1. 核实真正的原因
667 667  
672 +
668 668  根据时间和可用的信息，这些阶段实现的规模可大可小。即使在只有有限的信息可用，或者时间压力很大，采取结构化的方法来分析问题，提高成功的机会也是值得的。
669 669  
670 670  
深圳市艾拓先锋企业管理咨询有限公司