问题管理流程设计说明书.doc

问题管理流程设计说明书.doc

《问题管理流程设计说明书.doc》由会员分享，可在线阅读，更多相关《问题管理流程设计说明书.doc（30页珍藏版）》请在冰豆网上搜索。

文档标题

问题管理

2022年10月9日

1问题管理

1.1问题管理的目标

问题管理的目标是最小化事故的不利影响以及由于IT基础设施中的错误造成的业务上的问题，阻止与这些错误相关的事故的重复发生。

为了达到这个目标，问题管理寻求找到事故的根本原因，采取行动改善或纠正这种状况。

问题管理流程具有主动和被动两个方面。

被动的问题管理关注于解决问题以响应一个或多个事故。

主动问题管理关注于在事故首次出现前就能识别和解决问题以及知名错误。

1.2问题管理的范围

问题控制、错误控制以及主动问题管理都属于问题管理流程的范围。

较为正式的定义是，问题是一个或多个事故未知的底层原因，知名错误是已经成功诊断出来的问题，并且为之定义了临时措施。

图1问题管理的范围

问题管理流程的输入是：

v来自事故管理的事故详细信息

v来自配置管理数据库的详细配置信息

v任何定义的临时措施（来自事故管理）

问题管理的主要活动包括：

v问题控制

v错误控制

v问题的主动预防

v识别问题趋势

v从问题管理数据中获得管理信息

v完成主要问题的评估

问题管理流程的输出：

v知名错误

v变更请求（RFC）

v更新后的问题记录（包括解决方案和/或任何可用的临时措施）

v关闭问题记录（对于解决的问题）

v与问题和知名错误匹配的事故的响应

v管理信息

1.3基本概念

在事故的早期阶段，能够得到相应的而且容易应用的建议，对于组织有效地解决事故的能力来说，这是最重要的。

服务台接收到的事故，对于支持员工很少是初见的或是神秘的。

相似地，处于二线或三线的支持员工中的专家也已经解决了许多困难和原始事故和问题。

花费在这些解决方案上的资源的最好使用方式就是将它制作成文档，这样一线的员工就可以应用它们了。

问题管理流程试图降低影响业务的事故和问题的数量及危害，因此，问题管理的部分职责是确保以前的信息被记录在档，这样对一线及其它二线支持员工就已经是准备好可用的了。

它不是简单地记录文档的问题，它要求：

v信息应该建立索引，以便根据来自新事故的简单的线索就能容易地查找；

v进行例行检查，以确保持续的文档记录与变更相一致：

u技术

u可用的外部解决方案

u业务实践和需求

u内部技巧

u重复事故的频度和影响

u阐明内部最佳实践

v进行详细评估的流程；

v训练员工使用信息，理解可用信息的深度和作用，以及怎样访问和理解信息，在提供反馈方面，信息的相关性和易于使用；

v存贮信息的知识库－典型地基于集成的服务管理工具，使得在登录后或者在事故处理流程的初始分析阶段就能使用知识。

一般地使用“专家系统”软件来发挥问题管理流程的作用。

然而，重要的是包括专家知识，让使用系统的员工根据反馈来更新：

v被识别的问题和知名错误；

v分析他们遇到的事故（被动问题管理）；

v按时间段分析事故（主动问题管理）；

v分析IT基础架构；

v提供知识库；

v引进新产品时的开发人员和提供商。

一般情况下，问题是多个展现出共同特征的事故的结果。

有时问题也可以根据单个明显的事故来识别，由单个错误引起，虽然原因未知，但影响明显。

知名错误是对问题的根本原因成功诊断后识别的，后续将开发一个临时措施。

IT基础架构的结构化分析、来自支持软件的报告以及用户组会议有助于问题和知名错误的识别。

这就是主动问题管理。

问题控制重点在于将问题转化为知名错误，错误控制重点在于通过变更管理流程结构化地解决知名错误。

1.3.1事故管理和问题管理的不同

问题管理不同于事故管理，它的主要目标是事故底层原因的检测，提供后续的解决方案，阻止事故的发生。

在许多情况下，这个目标可能与事故管理的目标有直接的冲突，因为事故管理的目标是尽可能快的为客户恢复服务，经常通过临时措施，而不是通过彻底地解决。

因此在这个方面，找到解决方案的速度是次要的。

底层问题的调查需要花费时间，这样会推迟服务的恢复，但阻止了事故的重复发生。

1.3.2问题控制

问题控制流程关注于以有效地方式处理问题。

问题控制的目标是识别根本原因，诸如存在错误的配置项，向服务台提供可用的关于临时措施的信息和建议。

问题控制流程很相似于，且高度依赖于事故控制流程的质量。

事故控制重点在于解决事故，提供临时措施，对特定的事故临时修复。

如果对于一个或一组事故，识别出了问题，可用的临时措施和临时修复应该由问题控制流程记录在问题记录中。

问题控制流程也对问题建议最佳的可用临时措施。

因为问题控制关注于阻止事故的重复发生，因此流程的方法应该被仔细地管理和规划。

管理和规划的程度要高于事故控制，因为它的目标只是尽快地恢复正常的服务。

优先权应该分配组那些可能引起严重业务中断的问题的解决。

在事故控制中的活动包括：

v问题识别和记录；

v问题分类；

v问题调查和诊断；

1.3.3错误控制

错误控制包括的流程是，在变更管理流程的控制下，能过成功地实施变更，使知名错误得以消除。

错误控制的目标是发现错误、监控错误、在成本合理且可行的时候排除错误。

错误控制是开发（包括应用开发、功能扩展和维护）和生产环境的桥梁。

在开发阶段产生的软件错误会影响生产运营，在开发和维护环境识别的知名错误会被移交到生产环境。

错误控制中的活动包括：

v错误鉴定和记录；

v错误评估；

v记录错误的解决（方案调查、提出变更请求）；

v关闭错误；

v监控问题和错误的解决进展。

在实践中，问题管理的每个流程要求仔细的管理和控制，不同的操作对象应用在不同的流程中。

1.3.4主动问题管理

主动问题管理中各项活动的目的是，在事故发生前识别和解决问题。

这些活动有：

趋势分析；

定位支持行动；

向组织提供信息；

通过将IT部门的作用从被动地解决大量事故，重定位到阻止事故，它将向客户提供更好的服务，使得IT支持部门的资源得到更有效地利用。

1.3.5主要问题评价

通过对主要问题进行事后的评价，有助于服务的提升。

1.4问题管理的益处

采取正式的方法进行问题管理带来以下益处：

*提升IT服务质量

问题管理有助于形成迅速提高IT服务质量良性循环。

高质量可靠的服务有益于IT的业务用户、有益于生产力的提高、有益于IT服务提供者的士气。

*事故数量下降

问题管理是降低造成业务中断的事故数量的利器。

*永久的解决方案

随着问题和知名错误被解决，它们的数量及影响会逐步减少。

*提高了组织的知识

问题管理流程基础于从过去的经验获得知识的概念。

这些流程提供了历史数据来识别趋势，阻止错误的出现，降低错误的影响，从而提高了用户生产力。

*提高服务台第一时间修复率

在客户打进电话时，服务台通过存贮在知识库中事故解决方案和临时措施，在第一时间在服务台解决事故。

相反地，没有实施问题管理流程的成本可能包括：

v一个纯粹的被动支持的组织，只有在客户的服务被中断时才面对问题；

v面对重复发生的事故，IT用户部门会对IT支持部门的服务质量失去信任；

v因为相似的事故不得不反复地被解决，而没有提供结构化的解决方案，所以成为一个高成本、缺乏员工积极性、无效率的支持部门。

1.5规划与实施

1.5.1时机和规划

时机和规划是很重要的，因为：

v良好的问题管理在很程度上依赖已经实施且有效的事故管理流程。

因此，与事故管理流程并行或在它之后实施问题管理是明智的；

v如果缺乏资源，建议首先实施问题和错误控制（被动问题管理）。

当这些活动成熟时，资源可以直接转向主动问题管理。

主动问题管理的质量非常依赖成功地实施了服务监控活动以及因此获得的基础数据；

v较小规模的组织通过聚集于日常的“前十名”事故实现被动问题管理。

这被证明有有效的，因为经验表明20%的问题引起了80%的服务降低。

1.5.2关键成功因素

考虑要点包括：

v有效的事故自动登记、有效的事故分类，是问题管理成功的基础；

v设置可完成的目标，利用既有员工解决问题的才能是个关键的活动。

考虑“兼职”问题管理，让员工看到随着问题的解决，他们远离每天“救火”的压力；

v考虑事故管理和问题管理间潜在的冲突，在两个流程间进行良好的协调是必要的。

同时两者又都有可能彼此帮助的配合。

参与两个流程的支持职员应该意识到平衡两者的活动的重要性；

1.5.3风险

问题管理的益处会被以下因素减弱：

v没有良好的事故控制流程，这样就缺乏关于事故的详细信息（这对正确的问题识别是必要的）；

v不能够将事故记录与问题/错误记录连接起来，意味着失去了许多潜在的益处。

在从被动支持向更有规划和主动支持转移方面，这是关键的功能；

v缺乏管理，因此支持职员（通常也参与在被事故控制流动中）不能分配充分的时间在结构化的问题解决活动中；

v削弱服务台的角色。

问题管理职员应该仅从授权的发起者那里接受支持请求。

如果流程处理来自许多发起者的请求就会出现困难，因为相同原因的多个事故报告可能会被以不同的方式来解释；

v不能留出时间来建立和维护知识库将限制问题管理的益处；

v没有能力准确地判断事故和问题的业务影响，导致对业务而言关键的事故和问题没有给予正确的优先级。

1.6问题控制的活动

实际上，由于计算机设备和通信线路的偶然出错，发生事故是不可避免的。

许多其它事故不是由随机产生的故障引起的，而是由组织日益复杂的IT基础架构某处错误造成的。

即使可预料的计算或通信设备故障也会由于提供商的产品中的错误，导致无法接受的影响。

被动问题控制关注于识别事故真正的底层原因，以阻止将来的重复发生。

在问题控制流程中有三个阶段：

v问题的识别和记录；

v问题的分类－根据对业务的影响；

v问题的调查和诊断。

图2问题控制

当检测到根本原因时，就开始错误控制流程。

1.6.1问题识别和记录

问题识别发生在：

v在事故的初始支持和分类阶段，不能够找到匹配的既有问题和知名错误；

v事故数据的分析揭示了重复发生的事故；

v事故数据的分析揭示了还存在没有与能够与既有的问题和知名错误匹配的事故；

vIT基础架构的分析表明存在可能导致事故的问题；

v重大或明显的事故（对客户的服务具有严重的不利影响）发生，需要找到结构化的解决方案。

注意有些问题可能在问题管理小组之外被某个识别，如在能力管理中。

无论如何，所有的问题应该通知问题管理流程被记录。

可用性管理流程的许多方面关注于IT基础架构中的问题和事故的检测和避免，这两个领域的配合对提高服务质量具有重大的价值。

*要点

问题管理要求效力和资源，因此是昂贵的。

组织要能够判定对某些类型的未能匹配的事故付出努力和成本是划算的－例如能够快速解决，影响较小或重复发生的可能性很小的事故。

在这种情况下，可以在CMDB中引入虚构的问题记录，关联到所有有联系的事故、知名错误、变更请求以及配置项。

问题记录需要记录在数据库（理想情况下是CMDB），这一点类似于事故记录。

它们通常不包括某些不适用的标准事故数据（如用户数据）。

然而问题记录应该连接到所有相关的事故记录。

事故的解决方案和临时措施应该被记录在相关的问题记录中，以便另外相关的事故发生时能够访问。

图3事故匹配处理流程

问题识别的流程如上图所示，包括基本的问题分类。

受影响的配置项的数据应该准确地追加到这个基本分类数据中。

理想情况下，这些配置可被单独修改的最低层的项目－例如，应用代码块或硬件组件。

然而在问题识别阶段对于有问题的配置项的识别达到这个层次经常是不可能的。

1.6.2问题的分级

当问题被识别时，需要较大的努力来检测和恢复断定存在故障的配置项。

因此意识到问题对既有服务水平的影响是很重要的。

这个流程被称为“分级”（classification）。

在实践中