问题管理流程设计说明书.doc
《问题管理流程设计说明书.doc》由会员分享，可在线阅读，更多相关《问题管理流程设计说明书.doc（30页珍藏版）》请在冰点文库上搜索。
文档标题
问题管理
2023年5月2日
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）。
在实践中，支持努力被分配到连接到单个事故的小面积的问题上。
问题分级的步骤类似于事故分级的步骤，这些步骤决定：
v类别
v影响
v紧急程度
v优先级
问题被归类到相关的组或域（例如硬件、软件、支持软件以及相应的其它种类）。
这些组能够与机构的职责匹配，或者以用户和客户为基础归类，是将问题分配给支持职员的基础。
附录A给出一个简单但对问题归类有效的结构。
新问题的识别应该在受其影响的对象（也就是它对业务的影响）分析之后。
登记在CMDB中的IT基础架构中的组件间的关系有助于判断问题的影响。
组织应该根据它们的业务需要设计自己的影响代码系统。
影响代码对于有效地分配支持力度是最有用的机制。
更进一步包括优先级、从属影响，提供了全面的控制机制。
当判断问题的影响时，登记在CMDB中的IT基础架构中组件间的关系是个极大的帮助。
通过查询CMDB，可能识别事故涉及到IT基础架构中的配置项，以及同样的或依赖的配置项。
紧急程度是指问题或错误的解决所能承受的延迟程度，它不应该与优先级混淆。
优先级指明一系列项目－无论是事故、问题、变更或错误－应该被解决的相应次序。
这会受到风险的考虑和资源可用性的影响，但更主要地是由紧急程度和影响的组合来决定。
尽管较低的业务影响，但要求紧急解决的事情经常要放在较高的潜在业务影响但较低的紧急程度的事情之前处理。
为每个方面分配数字值有帮助的，由此衍生出数字优先级，但是，对于所有的服务管理，这样的数字是凭人的直觉和业务意识来修改的。
然而，对每个问题的紧急程度和影响赋予1－4的数值，对它们求和给出相应的优先级，是一个简单而实用的起点。
那样做了，组织应该精密地监控和检查计算出的优先级，监控对应需求的功能。
影响紧急程度的方面如：
v临时修复的可用性；
v存在临时措施；
v计划推迟解决的可能性；
v对业务未来影响的意识，如支持月末处理的设备需求。
每个事故、问题和变更将都会对业务服务和紧急程度有影响：
v影响－描述了业务受到破坏的可能；
v紧急程度－表明了可用来转移或降低影响的时间。
*要点
在最早的时机为所有问题分配影响代码。
当这项工作完成后，重要的是在详细调查开始前，使所有问题归属到被管理的职员分配流程。
被分配的人负责问题的解决，成为协调问题解决活动的中心。
根据影响计划工作量，重要问题要立即引起注意。
对低影响的问题可以允许超出特定的时间限制。
影响分析流程遭遇一个重大的约束：
它只反映当时的看法。
虽然一个问题被正确地分配了低影响代码，但接下来属于该问题的事故数量陡然上升可能要求这个问题需要立即引起注意。
需要设置事故限制来解决这个困难。
如图3所示，问题管理流程被设计要维护与问题（和知名错误）记录匹配的事故的数量。
问题和错误控制系统周期性扫描这个数值，将它与预先定义的限制值比较。
当数量等于或超出这个限制，这样的问题/知名错误应该被升级到立即注意。
然而，注意数量并不总是等于重要：
当你发现订单不能输入超过$999,999.99的值，即使这样的情况只有0.5%，也必须被看做是关键的问题。
1.6.3问题调查和诊断
问题调查流程类似于事故调查流程－但是这两个流程的基本目标明显不同。
事故管理的目的是迅速恢复服务，而问题管理的目的是诊断出底层原因。
调查活动应该包括与该问题相关事故可用的临时措施，它登记在事故记录数据库。
问题管理活动还包括更改问题记录中推荐的临时措施，以支持事故控制。
诊断结果经常表明问题的原因不是登记的配置项（硬件、软件、文档或程序）的错误，而是过程上的。
例如，发布的程序版本不正确。
这种情况下，问题以适当的分类代码来关闭，但不会达到有知名错误的状态。
为了确保这类问题有章可循，采取措施解决它们，考虑为这种过失过程创建虚构的配置项，作为一个知名错误重新分级问题，或产生变更请求。
诊断揭示了原因是登记的配置项的错误，这时应该自动将问题的状态转成知名错误，由错误控制系统和过程接管。
正如前面所指出的，问题调查的目标经常会与事故解决的目标相冲突。
例如，问题调查可能要求详细的诊断数据，这些数据只有在事故出现时才能得到，而获得这些数据可能会明显地推迟正常服务的恢复。
确保将事故控制与计算机操作或网络控制功能紧密联系，对于此类的活动给予适当的时间平衡。
1.6.4问题分析的方法
一些文献对于结构化问题分析和诊断提供了许多方法。
这样的文献有：
vKepnerandTregoe（参见附录B）
vIshikawadiagrams（参见附录C）
v头脑风暴会话
v流程图方法
问题管理应该选择最适合本组织目的的方法。
1.6.5问题控制的要点
以下是在问题控制中值得记住的要点：
v事故分类是向问题定义发展的第一步，因此问题管理应该与事故管理紧密关联，考虑建立公用的事故和问题分类。
对于报告的事故以及最终检测的原因应该给予适当的分类，事故分类应该用“客户术语”，而检测的原因归类用“IT术语”来表达。
v如果可能的话，建立具有不同经验的人的小组，例如问题管理，在调查的时候，大家尽可能从不同的角度来参与。
v为了参与的支持专家能够有效地执行他们的任务，确保他们有合适的工具和诊断协助工具。
v如果问题不是由系统组件中的错误引起的，而是由于没有对用户培训引起的，解决并关闭问题记录。
另外，创建新的配置项记录－在这个例子中是“培训问题”－按照通常的方法将问题转化为知名错误。
确保检测的原因反映实际状况，例如，缺乏用户知识培训。
v在事故或问题控制流程的诊断过程中，要求IT基础架构中的所有产品的文档可用，以支持职员在处理过程中作为参考。
这些文档包括：
u应用系统
u系统软件
u内部工具程序
u网络硬件和软件
u全局配置/网络图表
v除了产品信息，具有有效的过程来收集诊断以解决问题也是必要的。
支持职员熟悉这些过程特别重要，因为在事故处理的过程中不适当的使用会推迟正常IT服务的恢复。
因此需要这些过程来支持和加强流程的需求－这些过程可能包括适当的培训、认证等。
v支持专家会经常同时参与事故管理流程和问题管理流程，切记这两个流程的目标不同（快速解决对结构化解决），在这两个流程中，将专家的时间按固定的百分比分配证明是有用的，可能是事故管理占80%，问题管理占20%。
这可以防止支持专家完全陷入被动事故管理。
v在事故和问题的诊断过程中，问题管理职员也要求精确地记录最近的变更，因为这些可能是问题的原因。
1.7错误控制的活动
错误控制包括了成功地纠正知名错误的流程。
其目标是变更IT组件，消除影响IT基础架构中知名错误，防止事故的重复发生。
许多IT部门关注于生产环境和开发环境的错误控制，它直接与变更管理流程接口。
图4示例了错误控制的三个阶段。
监控和跟踪阶段包括全部的问题/错误生命周期。
图4错误控制
1.7.1错误识别和记录
当有故障的配置项（引起或可能引起事故的配置项）被检测到就识别了错误。
当问题的根本原因被发现就被赋予知名错误的状态，同时开发临时措施。
流入错误控制系统的知名错误有两个来源，一个是生产系统中的问题控制子系统，另一个是相应的开发环境。
在生产操作中发现的错误，就如在问题控制活动调查和诊断中所描述的，被识别和记录。
在这种情况下，问题记录形成了知名错误记录的基础（事实上，它确实只是状态的改变）。
知名错误的第二来源是开发活动。
例如，新应用或打包发布的实施可能包括了在开发阶段形成的已知但未解决的错误。
当应用或发布包实施时，来自于开发的知名错误相关的数据应该对生产环境的管理人员可用。
许多IT部门参与过这样一系列事件。
问题管理系统应该记录所有解决活动，向支持职员提供监控与跟踪工具。
也应该提供全面的审计记录，从事故到问题、到知名错误、到变更请求或重大变更实施。
1.7.2错误评估
问题管理职员协同专业职员，对解决错误的方法进行初始的评估。
如果必要，接下他们根据变更管理过程，完成变更请求。
变更请求的优先组根据错误在业务上的紧急程度和影响来决定。
变更请求的标识符应该被包括在知名错误记录中，以便维护一个完全的审计路径，或者将两者连接。
错误解决的最终进程－影响分析、需要执行的解决步骤的详细评估、配置项错误的改正、变更的测试－要在变更管理的控制下执行。
在极端情况下，紧急的解决方案，进行授权执行是必要的。
*第三方产品中的错误
卖方维护的产品中的问题可能被问题管理或专家支持小组识别，应该向卖方支持的负责人报告。
应该监控卖方支持，确保在合理的时间内收到对问题报告的响应。
在设置了软件维护的目标－诸如修复的合理和最长时间，以及IT基础架构相关的可靠性和可服务性－应该在合同或许可条件中明确，应该由第三方发起补救措施，以免受到抱怨。
当购买软件时，特别是在业务上具有竞争的情况下，明确维护目标的可能性应该具备。
注意解决软件错误的必要的变更归属于变更管理，与内部产品一样。
*软件环境中的错误控制
在生产环境和开发环境中的问题和错误控制流程在本质上是一样的。
前面对生产环境中的问题管理所描述的支持工具，也适合于开发环境中所要求的。
图5显示了在生产和开发环境中的错误控制间的循环关系。
协同集成的问题管理系统促进这种情况的处理。
图5生产与开发环境中的错误周期
在生产运营期间发现的错误导致变更求的积累，发布策略（参见发布管理）允许最终创建一个发布协同授权的变更修正系统中的错误。
开发职员应该注意与打包发布相关的所有知名错误和问题，当知名错误被改正后要求被删除，加入到修订的错误数据库（或CMDB）。
当完成新的发布，这个修订的错误数据库替换以前版本的数据库作生产版本。
当新的错误在生产运营中被发现，重复这个周期。
1.7.3记录错误解决方案
每个知名错误的解决过程应该记录在问题管理系统。
与所有知名错误相关的配置项数据、症状、解决方案或防止措施保存在知名错误数据库是很关键的。
这些数据对于事故匹配、在将来的诊断解决事故以及防止事故方面提供指导、提供管理信息等方面都是有用的。
1.7.4关闭错误
在成功地实施变更解决错误后，相应的知名错误记录被关闭，同时任何相关的事故或问题记录也一起被关闭。
可以考虑在事故、知名错误和问题记录中插入一个中间状态“关闭但未进行实施后评价（ClosedpendingPIR）”，确保修正已经实际起作用。
实施后评价（Post-ImplementationReview,PIR）能确认最终关闭前解决的效果。
对于事故，除了打电话给用户确保他们已经满意就没有别的了，对于严重的问题和知名错误，要求进行正式的评价。
1.7.5监控问题/错误的解决
变更管理负责处理变更请求，同时错误控制负责监控解决知名错误的进展。
在整个的解决过程中，问题管理应该从解决问题和错误的变更管理进展中获得日常报告。
问题管理应该监控问题和知名错误对用户服务的持续影响。
在影响变得严重的事件中，问题管理应该升级问题，可能要咨询变更咨询委员会提升变更请求的优先级，在适当的时候实施紧急变更。
问题解决的进展应该结合SLA一起被监控。
典型地，SLA规定在每个测量间隔内（一般为四周）在每个严重级别上不应该有特定数量的突出错误。
如果在某个严重级别上问题或错误的数量达到预先定义的限制，可能引起与SLA的不一致，就必须升级。
1.7.6错误控制的要点
在错误控制中切记以下要点：
v不是所有的知名错误需要被解决。
组织能够决定允许保留知名错误－例如，因为解决的成本太高、技术上不可能或要求太多的时间来解决。
实践中，错误控制关注于选择合理的投资来解决问题；
v准备变更请求是错误控制的责任之一。
解决方法经常是技术上的调整，但不要忘记，变更请求也可能需要包括对过程、工作方法和/或组织结构的修正；
v对于日常的硬件故障，考虑根据特定的设备或设备分类创建标准的错误记录。
使用这些来维持对故障鉴定的快速指导－尽管多数信息（例如故障和宕机间的平均时间）来自于事故数据；
v许多硬件故障的
升级会员 