2问题管理流程文件.docx
《2问题管理流程文件.docx》由会员分享，可在线阅读，更多相关《2问题管理流程文件.docx（25页珍藏版）》请在冰豆网上搜索。
2问题管理流程文件
问题管理流程文件
修订记录
版本号
章节号
修订内容
作者/
修改人
作成/修改日期
审核人
A/0
目录
范围5
问题管理概述6
目标6
术语定义6
主要角色及职责8
流程描述8
问题管理主流程9
被动问题来源11
主动问题来源11
问题调查和诊断子流程12
问题处理子流程13
问题升级子流程14
问题关闭子流程15
问题后续处理子流程16
问题管理中的相关标准16
问题识别标准16
问题的分类17
问题的优先级标准17
问题转向已知错误的判别标准17
问题触发变更管理流程的标准17
解决方案的分类标准18
问题的记录与状态跟踪18
问题的记录18
问题的状态19
问题分析方法20
Kepner&Tregoe问题分析法20
与其他流程的关系21
工具与方法23
衡量标准23
流程改进23
相关文档23
附录23
范围
本文档内容包括：
1.问题管理概述：
从整体的角度对问题管理进行简要的描述；
2.问题管理目标，描述问题管理流程所要达到的目标；
3.术语定义：
在本文档中出现的关键术语的说明；
4.主要角色及职责：
描述在事件管理活动中各主要的角色及其所担负的职责和活动；
5.流程描述：
包括问题管理主体流程与各子流程。
主体流程中包括流程图，各阶段的活动描述及输入、控制和输出；子流程包括详细活动的流程图和流程描述；
6.问题管理中的相关标准：
包括流程中用来进行判断，分类，分级以及升级的标准；
7.问题记录与状态跟踪：
包括问题各阶段，应该记录的内容；问题的状态与状态跟踪；
8.问题分析方法：
描述了问题分析时使用的各种方法；
9.与其它流程之间的关系：
描述为其他流程提供的输出，及其他流程的输入；
10.工具与方法：
描述该流程将用何种工具来进行具体操作；
11.衡量指标，定义衡量管理绩效的指标；
12.流程改进，定义流程回顾和改进方法；
13.相关文档：
与本文档相关联的一些文档；
14.附录：
文档主体中涉及的记录表单等。
问题管理概述
问题管理是针对运维工作中出现的重大事件的根本原因进行分析，以期寻找到临时或永久解决方案，或针对某一时间段内发生的事件，进行统计、分析以期发现可能引起事件的潜在问题并解决，或通过对运营趋势的分析寻找潜在的可能引起事件的问题并解决的一系列动作。
问题管理的主要目的是调查和分析事故的原因，防止事故的重复发生和业务上的已知错误。
在问题管理中还会有相关的标准来约束和规范问题管理中的关键节点，并且可以通过这些标准改进、升级流程和服务质量。
目标
问题管理的目标是最小化事件的不利影响以及由于IT基础设施中的错误造成的业务上的问题，阻止与这些错误相关的事件的重复发生。
为了达到这个目标，问题管理寻求找到事件的根本原因，采取行动改善或纠正这种状况。
问题管理流程具有主动和被动两个方面。
被动的问题管理关注于解决问题以响应一个或多个事件。
主动问题管理关注于在事件首次出现前就能识别和解决问题以及知名错误。
1.找出一个或多个事件背后的根本原因并寻求相应的解决方案；
2.及时主动的识别和解决问题；
3.确保一致地处理问题而不会有任何遗漏；
4.及时汇报、登记、分类、排序所有的问题并分配适当的资源加以解决；
5.监控/跟踪问题管理流程，为其他IT服务管理流程提供有效信息支持；
术语定义
生产系统：
是指运维中心管理的所有对内部用户提供服务的各类系统和对外部客户提供服务的系统。
包括硬件系统和应用系统。
问题：
是指存在某个未知的潜在原因的情形，这种原因会或可能会导致一起或多起事件发生。
已知错误：
已知其根源并且已确定临时的解决办法或永久的替代方案的问题。
除非通过某个变更永久地解决，否则，将一直都保持为已知错误。
永久解决方案：
是指通过分析查明问题的根本原因并找到能够永久解决该问题或同类问题的方法。
临时解决方案：
针对某一个或某一类问题可以消除这个问题带来的影响，但不能从根本上解决问题的解决方案。
问题管理：
问题管理强调的是事件产生的根源，通过识别、分析找到问题的根本原因使之变为一个已知错误，协调资源针对已知错误提出永久解决方案并通过发起变更来消除这些已知错误，避免同类事件重复发生。
主要角色及职责
角色名称
职责描述
责任人
问题经理
开发和维护问题管理流程；
回顾问题控制流程的效率和效果；
管理问题解决小组；
问题处理过程中的资源分配；
监督问题处理过程中的进展情况；
必要时引入第三方厂商的支持
定期对配置库中的信息进行检查，定期分析基础设施的运行趋势，主动发现问题；
确认问题是否得到解决；
问题管理中相关标准的制定；
问题评审小组
对升级进行授权；
解决方案评审；
问题解决小组
问题的录入；
根据问题的分类和优先级，对问题进行分类、分优先级；
问题调查和诊断
提出问题的解决方案；
及时向问题经理汇报问题处理的进度和进展情况；
更新问题记录，记录问题解决方案和问题的状态；
将无法在时限内处理的问题提请进行升级；
跟踪第三方厂商的问题发布和定期检查、分析事件数据库，主动发现问题
定期对多次重复的事件进行分析主动发现问题；
审计人员
问题处理流程的审计；
重大问题处理过程的审计；
流程描述
问题经过分类和优先级设计以确保为它们安排正确的优先顺序并保证分配正确的资源支持问题的解决。
在问题管理中根据问题不同来源分为被动问题管理主流程和主动问题管理主流程，根据问题管理的生命周期通过调查和诊断子流程、处理子流程、升级子流程、关闭子流程、问题的后续处理子流程和解决方案实施后的评审流程来控制、跟踪和监控问题管理的整个过程。
问题管理主流程
活动
描述
责任人
输入
控制
输出
1.1.1主动问题发现和被动问题产生
Ø问题经理和问题解决小组主动发现问题或者接受被动问题
问题经理
问题解决小组
主动问题发现
被动问题产生
问题识别标准
问题单
1.1.2问题类别和优先级确认
Ø问题解决小组根据问题的分类标准和问题的有线及标准确认问题的优先级
问题解决小组
问题单生成
问题类别和优先级标准
含有问题分类和哟优先级信息的问题单
1.1.3问题的调查和诊断
Ø问题解决小组通过问题的调查和诊断流程确定问题产生的根本原因
Ø问题评审小组对问题解决小组提交的问题根本原因进行评审
Ø评审通过后进入问题处理
问题解决小组
问题评审小组
问题的调查和诊断
评审委员会对问题解决小组的调查和诊断结果进行评审
包含有问题分类和优先级信息以及问题根本原因的问题单
1.1.4问题处理
Ø根据调查与诊断的结果来提出解决方案
Ø解决方案的评审
Ø解决方案实施
问题经理
问题解决小组
问题评审小组
包含有问题分类和优先级信息以及问题根本原因的问题单
问题经理对问题是否升级的控制
问题经理对是否变更的控制
解决方案实施后的问题单
1.1.5问题评审小组对问题解决方案实施后的评审
Ø问题评审小组对问题解决方案实施后的结果进行评审
Ø如果问题解决则转向问题关闭流程
Ø如果问题没有解决则返回问题处理流程
问题评审小组
解决方案实施后的问题单
评审意见
问题结果确认的问题单
1.1.6问题关闭
Ø问题经理确认问题是否为永久解决方案
Ø问题经理确认是否是临时解决方案
Ø问题评审小组决定是否继续寻找永久解决方案
问题经理
问题解决小组
问题评审小组
问题结果确认的问题单
问题关闭的标准
返回的寻找问题永久解决方案的问题单
返回的重新寻找解决方案的问题单
问题关闭的问题单
问题关闭但状态为已知错误的问题单
1.1.7问题的后续处理
Ø问题经理定期生成问题管理报告
Ø问题经理提出问题记录内容改进要求
Ø对重大问题处理过程的回审
Ø问题评审小组对问题管理报告和问题记录内容改进要求作出评审
问题经理
问题评审小组
问题关闭的问题单
问题关闭但状态为已知错误的问题单
问题管理报告的内容
定期生成问题管理报告的时间间隔
限定时限内进行重大问题处理过程的回审
问题管理流程的改进
问题记录内容的改进
被动问题来源
流程描述
被动问题的来源主要有三个方面，并由这三个方面的信息形成问题单：
1、重大事件
2、多次重复发生的事件背后的原因（暂先定为5次，由人工判断）
3、未得到永久解决方案的事件
主动问题来源
流程描述
1、问题经理定期检查配置库、定期分析基础设施的运行趋势形成问题单；
2、问题解决小组跟踪第三方长商的问题发布和定期检查、分析事件数据库形成问题单；
问题调查和诊断子流程
流程描述
1.问题经理定期检查配置项、定期分析分析基础设施的运行趋势，由这些信息确定问题产生的来源并确定问题产生的根本原因向问题评审小组提交；
2.问题解决小组跟踪第三方厂商的问题报告、分析事件记录数据库和重大事件中收集的信息，由这些信息确定问题产生的来源并确定问题产生的根本原因向问题评审小组提交；
3.问题评审小组对提交上来的问题产生的根本原因做出判断，如果确定问题产生的根本原因，则此子流程结束，并进入问题处理子流程；
4.问题评审小组否认了提交上来的原因是问题产生的根本原因，则返回到问题经理和问题解决小组重新寻找问题产生的根本原因；
问题处理子流程
流程描述
1、收到问题单之后，与用户进行电话再次沟通，同时在配置管理信息库中收集信息以获得更多的信息来支持问题的处理，并形成新的问题记录单；生成问题单后，发email给用户告知该问题单的url地址，方便用户随时查看问题解决进度。
2、由问题经理确认问题能否解决；如果能够解决，那么形成解决方案；
3、如果不能解决，那么由问题经理决定问题是否需要升级；
4、如果不需要升级，那么返回并重新收集信息，形成新的问题记录单，进入问题解决的循环；
5、如果需要升级，那么进入问题升级流程，这时也许需要外部供应商介入或者专家团队的介入，返回并重新收集信息，形成新的问题记录单，进入问题解决的循环；
6、解决方案形成后由问题评审小组对解决方案进行评审；
7、如果解决方案没有通过评审，则返回并重新收集信息，形成新的问题记录单，进入问题解决的循环；
8、如果解决方案通过评审，则由问题解决小组将问题状态置为已知错误，然后由问题经理确认解决方案中是否有变更需求；
9、如果解决方案中有变更需求则由问题经理提交RFC，申请变更，进入变更流程，变更实施完毕后可以关闭问题；
10、如果解决方案中没有变更需求则实施解决方案，并进入问题关闭子流程；
问题升级子流程
流程描述
1.在问题处理过程中问题经理可以根据问题处理的情况要求问题升级或者由问题解决小组请求问题升级；
2.问题经理确认问题升级的方法；
3.如果需要管理升级则由问题经理向问题评审小组提出管理升级的授权并重新分配资源，升级完成；
4.如果不需要管理升级则由问题经理进行技术升级并重新分配资源，升级完成；
问题关闭子流程
流程描述
1.确认解决方案是否为永久解决方案，如果是永久，则将问题状态置为关闭并随永久解决方案一起录入永久解决方案库；
2.如果不是永久解决方案，那么确认是否为临时解决方案，如果不是，则返回问题处理子流程重新寻找解决方案；
3.如果确认解决方案是临时解决方案则问题状态保持为已知错误，然后向问题评审小组提交是否寻找永久解决方案的提案，如果问题评审小组要求寻找永久解决方案则返回问题处理子流程；
4.如果问题评审小组确认不需要继续寻找永久解决方案，则由问题解决小组将问题和临时解决方案一起录入已知错误库；
5.问题解决后需电话或邮件告知用户。
问题后续处理子流程
流程描述
1.依照问题管理衡量标准定期生成问题报告，然后由问题经理分析问题报告，将发现的问题、总结的经验以及改进的方法生成问题管理报告；
2.由问题经理定期Review问题记录，提出改进文体记录的内容要求；
3.由问题经理对重大问题处理过程进行回审，并提出问题处理过程的改进建议；
4.由问题经理向问题评审小组提交问题管理报告和问题记录内容改进要求；
5.问题评审小组对问题经理提交的问题管理报告和问题记录内容改进要求进行评审；
6.如果评审通过则此子流程结束；
7.如果评审没有通过则返回，进入下一轮问题后续处理流程；
问题管理中的相关标准
问题识别标准
问题识别标准，目的是定义是否接受为一个问题，进入问题管理流程，主要包括：
1.高优先级或重大事件引起的并发问题；
2.多次重复的事件，可能内含潜在的问题；
3.通过对运营趋势的分析，主动发现的问题；
4.通过定期巡检，主动发现的问题；
5.通过跟踪外部厂商发布的问题，根据实际情况确认是否可能为问题；
问题的分类
问题的分类及优先级设计的目的是便于资源的分配和后续的统计分析。
问题的分类详见相关文档中的《问题类型.xls》。
问题的优先级标准
对问题进行优先级划分的目的是尽量将最优资源调配给高优先级的问题，提升服务质量，控制问题所造成的风险面，尽快解决高优先级的问题。
因此，优先级决定了问题得到处理的先后顺序。
影响度（Impact）——影响度指就所影响的用户或业务数量而言，问题偏离正常服务级别的程度。
重要问题是指那些对用户团体带来非常严重影响的问题。
而有些在时间上极度紧迫的需要解决的问题也应当作重要问题来处理。
紧急度（urgency）——紧急度指处理问题时，对用户或业务来说可接受的耽搁时间。
优先级（priority）——主要基于紧急度和影响度来决定。
而对于具有同样优先级的问题，可按解决他们需花费的精力的多少来安排顺序。
例如，对某个影响不大且容易解决的故障，可先于一个影响较大且需要大量精力解决的故障。
中国电信运维中心按问题对系统的不同影响程度，将问题由高到低分为三个级别：
✓一级（重大问题）
由重大事件生成的问题，都是重大问题，或者是主动运维中发现的核心业务系统受到了直接威胁的问题。
✓二级（严重问题）
由一般事件产生的问题，或者是主动运维中发现的对核心业务系统造成安全隐患的问题。
✓三级（一般问题）
主动运维中发现的未对核心业务系统造成隐患的问题。
问题转向已知错误的判别标准
针对某个问题的解决方案出来的时候问题即转向已知错误，
问题触发变更管理流程的标准
问题解决方案出台后，无论是临时解决方案还是永久解决方案，只要解决方案中涉及配置项的变更，那么将提交变更请求RFC，触发变更管理流程。
但当一个问题的解决方案被放弃时，即便内含涉及配置项的变更内容，也将不触发变更管理流程。
解决方案的分类标准
永久解决方案：
使问题不再发生的解决方案，实施解决方案后，问题将消失。
临时解决方案：
由于一些原因不能实施永久解决方案或者找不到永久解决方案时的临时措施。
放弃的解决方案：
由于解决方案成本过高，或者已经有计划中的其他方法使这个问题消失，或者这个问题可以容忍，而不实施的解决方案。
最优解决方案：
用最小的成本、最快的速度、最少的影响解决问题的解决方案。
需要注意的是永久解决方案并不一定就是是最优解决方案。
问题的记录与状态跟踪
问题的记录
所有的问题都应该被记录，原因如下：
1.只有记录问题才能监控问题的发展情况；
2.已有的问题记录有助于对产生的问题进行诊断；
3.如果没有问题记录，那么将不能监控协商好的服务级别是否得到满足；
4.及时地对问题进行记录可以避免在解决问题时出现几个人同时解决同样的问题，或在某一问题的处理过程中什么工作都没有做等情形。
要避免对同一问题进行重复记录的情况出现。
因此，在记录某一问题时需要进行一项检查来确定是否已有相似的记录。
如果有（而且是关于同一问题的记录）：
则应该更新问题信息或将问题单独记录后将其关联到主问题记录；如果有必要，可对其影响度和优先级进行一些修正，同时加上一些与问题的发现者相关的信息；如果没有：
则增加一条新的问题记录。
记录发生在问题管理流程的各个阶段。
每个阶段记录的内容可能不同。
记录的内容应该包括：
1.分配一个问题索引序号：
大多数情况下系统会自动分配一个惟一的问题索引序号。
告知用户的文体索引号，以便在后续沟通过程中，用户可使用通过提供的索引号来查询问题。
2.记录基本的诊断信息：
日期和时间、用户及联系方法、记录问题的人员的身份、地点、症状和任何错误代码、基本诊断数据。
3.附加问题信息：
包括与问题相关的其他信息（例如一个脚本或交流过程记录）或与之相关的配置管理数据库中的一些配置条目的信息（受影响的服务或硬件等信息，通常以数据库中定义的关系为基础）。
问题记录在整个问题生命周期中保持最新是很重要的，这样使所有支持人员都能看到当前正在发生的问题、谁当前正在处理该问题，以及先前曾尝试过什么和发现了什么。
在处理完毕之后，应该将处理过程或处理办法进行记录。
更新问题记录内容应包括：
1.记录该操作的支持小组和人员的名称/ID。
2.操作的类型（重新分配、诊断、恢复、解决、终结，等等）。
3.操作的日期/时间。
4.操作的描述和结果。
最新的记录还允许任何被联系的人员为请求发起者提供进度更新。
让用户了解最新的进度情况是直接影响客户满意度的重要因素。
更新应该定期提供，具体取决于问题的优先级。
例如，高优先级问题可能需要每小时的更新，而中优先级问题每日接收更新，低优先级、长时间处理的问题需要每周甚至每两周的更新。
问题最终解决或处理办法的记录，需要审批之后才能进行记录。
问题的状态
问题的状态主要有：
问题：
还没有解决方案的时候问题的状态
已知错误：
问题的解决方案已经形成时，问题的状态就成为已知错误。
当确认问题的解决方案为永久解决方案时，则改变状态为永久解决方案，若不是，则保持已知错误的状态。
状态为已知错误的问题，当决定不再寻找永久解决方案时，问题可以被关闭。
永久解决：
当针对一个问题的永久解决方案实施之后，问题的状态就成为永久解决。
关闭：
问题在两种情况下可以被关闭，一种情况是在问题采用临时解决方案处理之后，问题可以被关闭（见上面已知错误的内容）；还有一种情况是问题被永久解决之后问题可以被关闭。
问题分析方法
问题的分析方法是指在一个问题产生时，我们采取什么样的方法来定位问题，寻找问题的解决方案。
一些文献对于结构化问题分析和诊断提供了许多方法。
这样的文献有：
1.KepnerandTregoe
2.Ishikawadiagrams
3.头脑风暴会话
4.流程图方法
Kepner&Tregoe问题分析法
Kepner&Tregoe问题分析法是一个系统化的问题解决流程，并尽可能的最大化地利用知识和经验。
这个问题分析法将问题分析划分为下面五个阶段：
1、定义问题
2、描述问题的识别、位置、时间和大小
3、确立可能的原因
4、测试最可能的原因
5、核实真正的原因
定义问题
因为调查是基础问题的定义，因此定义必须精确地陈述已经出现的与协定的服务水平的偏差。
经常在问题定义期间，最可能的问题原因已经显示。
但不要直接给出结论，否则，可能从开始就将调查引导到错误的方向。
描述问题
以下方面用于描述问题，也就是问题“是”什么：
1、识别－哪一部分不能很好地起作用？
问题是什么？
2、位置－问题出现在哪儿？
3、时间－问题从什么时候开始出现？
问题出现的频率怎样？
4、大小－问题的大小怎样？
多少部分受到影响？
“是”的状况取决于这些问题的答案。
下一步是调查在相似的环境中哪些相似的部分还在正确地起作用。
据此，问题的答案可以描述为“哪些部分表现同样的问题但还在起作用？
”
然后可能在两个环境中有效地调查相应的不同点，而且，过去的变更（可能是引起不同的原因）会被识别出来。
确立可能的原因
上面提到的不同点列表以及变更最可能含有问题的原因，因此可能的原因可以从列表中提取出来。
测试最可能的原因
每个可能的原因需要被评定，确定是否是问题所有症状的原因。
校验真正的原因
剩下的可能的原因必须被核实是问题的源泉。
只要以一种方式来证明这点就行－例如，通过实施变更或替换部件。
解决这个被快速而简单核实的原因。
与其他流程的关系
1.事件管理
事件管理对问题管理来说是一个重要的信息提供者。
有效的事件记录对成功地进行问题管理来说非常重要，因为这些信息是用于发现问题的。
问题管理支持事件管理流程的工作。
问题管理对问题进行分析，直到找到问题的解决方案；同时问题管理还能为事件管理提供应急措施（通常是在对问题进行研究时找到）来对事件进行处理。
一旦确定了问题的原因并且定义了一个已知错误，那么提供一个临时修复以阻止事件的再次发生并降低事件的影响。
理想的情况下，问题管理还可提供一个变更请求（RFC），这会使问题得到最终的解决。
注意：
事件管理和问题管理都可以提供应急措施。
2.变更管理
变更管理负责控制执行变更，包括由问题管理为消除问题而发出的变更请求（RFC）。
变更管理负责预测所需变更产生的影响，同时估算在对其进行计划、协调、评价时所需的资源。
它还通知问题管理了解关于纠错性变更的进展和完成情况。
这些纠正性变更的评价需要与问题管理进行磋商。
这样能产生一个实施后评审，如果变更成功进行，此后所有相关的事件和问题记录（已知错误）都可以终止了。
3.配置管理
配置管理提供关于基础设施、结构图（Blueprints）、硬件和软件配置及服务等组件的重要信息。
配置管理流程还描述这些组件之间的关系，如“与……相关联”、“使用……”、“组成……的一部分”等。
这些关系对问题管理的调查工作至关重要，因为它们定义了整个IT基础设施之间的相互关系。
4.可用性和服务持续性管理
可用性管理的目标是规划服务的可用性级别、确保这些可用性级别得到实现，同时将有关可用性方面的信息提供给问题管理流程。
问题管理流程通过找出服务无效的原因和补救方法来支持可用性管理流程的工作。
可用性管理负责基础设施的设计和规划基础设施的架构，通过优化可用性的设计、规划和监控来防止问题和事件的发生。
问题管理也经常在分析导致服务出现故障的原因（服务故障分析）时与可用性管理流程一起工作。
5.能力管理
能力管理优化对IT资源的使用。
能力管理为问题管理提供用于定义问题的重要信息，而问题管理找出与能力有关的问题，查明原因并进行纠正，以此来支持能力管理流程的工作。
6.服务级别管理
服务级别管理包括就实施IT服务时的服务质量问题进行协商和谈判。
服务级别管理为问题管理提供用于定义问题的信息，而问题管理流程应当遵守、支持规定的服务级别。
问题管理与财务管理和IT服务持续性管理之间也有类似的关系。
工具与方法
事件管理使用CA的ServiceDesk服务台实现。
衡量标准
1、是否重大事件或重复出现多次的一般事件,被归入问题管理流程；
2、是否对问题解决过程进行了全程监控和跟踪记录，最终获得合适的解决（未能解决的问题已与用户沟通，并获得用户的谅解），已解决的问题（即已知错误）都已分类、分级记录入知识库。
3
升级会员 