ITSS运维服务问题管理制度Word文档格式.docx
《ITSS运维服务问题管理制度Word文档格式.docx》由会员分享，可在线阅读，更多相关《ITSS运维服务问题管理制度Word文档格式.docx（32页珍藏版）》请在冰点文库上搜索。
5.1.3 输出及出口准则 8
5.1.4 问题定义准则 9
5.2 流程图 13
5.3 流程详述 14
5.4 子流程1：
问题识别与分类 17
5.4.1 流程图 17
5.4.2 流程详述 18
5.5 子流程2：
问题审核与分派 19
5.5.1 流程图 19
5.5.2 流程详述 19
5.6 子流程3：
问题分析与诊断 21
5.6.1 流程图 21
5.6.2 流程详述 22
5.7 子流程4：
问题解决 23
5.7.1 流程图 23
5.7.2 流程详述 24
5.8 子流程5：
问题关闭 26
5.8.1 流程图 26
5.8.2 流程详述 27
5.9 定期评估及改进 28
6 相关文件与记录 29
1概述
1.1目标
问题管理流程的根本目的是对发生在客户生产环境中的问题进行管理，找出产生这些问题的根本原因，然后根据需要通过变更请求（RFC）、变通方法或建议的预防性措施来消除引起事件的深层次根源以防止事件再次发生，从而为客户建立一个稳定的IT环境，提高IT服务的可用性。
问题管理流程常常需要和变更管理流程一起来实施找出解决方案，以便从根本上解决问题。
其目的包括：
1查明事故或问题产生的根本原因，制定解决方案和防止事故再次发生的预防措施。
2实施主动问题管理，在事故发生之前发现和解决可能导致事故产生的问题。
3提高IT服务的可靠性，降低IT支持成本。
1.2范围
问题管理范围包括合同范围内的客户的IT生产和运行环境中发生的服务事件提起的问题，本文档作为问题管理流程详细设计的交付物，适用对象为与问题管理流程相关的所有技术与管理人员。
2制定依据
1）ITSS.1—2015《信息技术服务运行维护服务能力成熟度模型》
2）GB/T28827.1-2012《信息技术服务运行维护第一部分：
通用要求》
3）GB/T29264-2012《信息技术服务分类与代码》
4）GB/T28827.2-2012《信息技术服务运行维护第2部分:
交付规范》
5）GB/T28827.3-2012《信息技术服务运行维护第3部分:
应急响应规范》
6）ISO20000.1：
2011《信息技术服务管理第一部分:
服务管理体系要求》
7）ISO9000：
2008《质量管理体系—基础和术语》
8）ISO9001：
2015《质量管理体系—要求》
3术语定义
本程序采用制定依据系列标准中的术语和定义。
4角色和职责
角色
职责
问题经理
1. 接受项目经理的分析报告，对问题进行审核确认。
2. 确保所有相关问题信息都被正确登记。
3. 对登记的问题进行分级和分类。
4. 将问题分派给所属相关专业的工程师进行处理。
5. 监控问题解决全过程，确保问题分派了正确支持人员，提高解决率。
6. 根据问题优先级合理分派IT资源。
7. 必要时组织客户探讨问题解决方案和变通方法。
8. 查看问题处理结果。
项目经理
1. 定期回顾事件，分析事件趋势。
2. 依据定义的问题入口准则进行问题录入。
3. 收集问题相关数据并验证其可用性。
4. 根据采集的数据诊断问题。
5. 确保问题准确分派相关人员。
6. 为用户提供相应的变通方法和最终的解决方案。
7. 实施解决方案。
8. 验证问题解决结果。
9.关闭问题。
5内容
5.1程序准则
5.1.1执行准则
5.1.1.1常规准则
1 建立独立问题管理流程，在整个企业范围内应该与事件管理流程相对独立，事件经理与问题经理应该尽可能的由不同的人员担任
2 应该每年对问题管理流程的流程关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾，以改进和优化流程
3 应该每月定期回顾和产生问题管理报表，对没有解决的问题，应该举行定期的问题管理会议对这些问题进行评估。
5.1.1.2流程关联准则
1和事件管理的关联：
多次重复发生的事件在恢复服务后，都应该由问题经理创建问题（问题必须和事件建立关联）
2和变更管理的关联：
问题解决后，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求（变更必须和问题建立关联），变更完成后，继续问题的处理
3和配置管理的关联：
问题流程中，可以通过配置管理查询相关的配置项信息
问题流程中，如果可以将根本原因定位到某个配置项，则必须将问题与该配置项关联。
5.1.1.3所有权准则
1 有效管理问题的前提是必须确保每个问题在任何时段都有适当的人员负责
2 问题首先由问题经理审核，再负责分派给合适的二/三线工程师、专家组
3 当问题分派到专家组后，专家组负责该问题的诊断与解决
4 问题经理负责与服务台或问题请求者沟通问题处理过程中的关键信息
5.1.1.4再分派准则
1 再分派又称转派，它确保问题单不被过于频繁的相互转派、以至于无法在规定时间内得到解决，应当尽量减少问题单再分派的几率，一个问题单再分派的次数不应该超过2次。
2 问题单再分派必须经过问题经理同意。
5.1.1.5重复问题准则
重复问题是指经过分析之后，根本原因相同的问题。
例如：
项目经理提出了几个问题，但是经过分析之后，发现这几个问题的根本原因是相同的，这几个问题就可以定义为重复问题。
对于重复问题需要进行标记，将相关问题记录进行关联，当问题解决时同时进行回顾。
5.1.1.6问题关闭准则
通常，问题单在实施了解决方案之后，需要经过一段时间的回顾，由项目经理和问题经理一起来回顾解决方案是否达到了预期的效果，如果成功的实施，则提交给问题经理，由问题经理确认问题信息记录完整，关闭问题。
5.1.1.7趋势分析准则
问题经理定期组织会议，对所处理事件历史记录进行趋势分析：
Ø
参加者应包括事件经理及项目经理
会议定期组织
定义趋势分析规则
5.1.2输入及入口准则
5.1.2.1入口准则
问题管理流程运作过程中需要输入的信息包括：
1 由事件管理流程提供的事件信息和应急措施。
2 由配置管理数据库提供的配置信息。
3 有关IT基础架构中所使用的产品的供应商的信息，包括有关这些产品的技术说明和已知错误的信息。
4 有关基础架构组件及其运行情况的信息，如能力管理报告、可用性管理报告和服务级别管理报告等。
触发问题的条件：
1 一段时间内某一类事件频繁发生，占用大量人工。
2 一段时间内某一设备频繁报同类事件单。
3 一段时间内某一人频繁报障。
4 影响范围较广的重大事件。
5 长期未解决的事件。
6 事件的根本原因没有找到。
7 变更失败，变更经理推送的问题。
8 客户直接提起的具有深层次原因的服务请求。
5.1.3输出及出口准则
5.1.3.1出口准则
问题管理流程输出的信息包括：
1 已知错误；
2 变更请求（RFCS）；
3 更新的问题记录（包括解决方案或变通方法）；
4 已经得到解决并终止的问题的记录；
5 将事件与问题、已知错误匹配的信息；
5.1.4问题定义准则
5.1.4.1问题分类定义
问题分类根据组织级服务目录进行分类，主要分为以下：
5.1.4.2问题优先级定义
问题的优先级由运维资产的影响范围、重要程度、紧急程度三个因素决定，分别定义如下:
1、影响范围（SI）
影响范围
定义
大（4）
信息系统运行维护过程中发生的已经影响或即将影响全公司用户
发生火情、机房漏水等险情，以及服务器或网络宕机、通讯线路中断4小时以上等
中（3）
信息系统运行维护过程中发生的已经影响或即将影响某部门、分支机构等多数最终用户
服务器或网络机宕机、通讯线路中断4小时以内
小
（2）
信息系统运行维护过程中发生的已经影响或即将影响少数最终用户
某个工作组内用户，不能登录系统
较小
（1）
信息系统运行维护过程中发生的已经影响或即将影响个别最终用户
单一最终用户，不能登录系统
2、重要程度（DI）
重要程度
高（4）
信息系统资产如果出现问题则会产生非常大的损失。
机房、核心网络、服务器、应用系统等，宕机后严重影响公共秩序或安全。
信息系统资产如果出现问题则会产生较大的损失。
核心网络、服务器、应用系统等，宕机后较大影响公共秩序或安全。
低
（2）
信息系统资产如果出现问题则会产生一定的损失。
网络、应用系统等，产生问题后较少影响公共秩序或安全。
很低
（1）
信息系统资产如果出现问题则会产生轻微的损失或无损失。
某一用户客户端等轻微影响公共秩序或安全。
3、紧急程度（DE）
紧急程度
服务不可用，用户核心业务受到严重影响。
重点最终用户、关键部门、领导层服务出现问题。
部分服务不可用，最终用户正常业务受到影响。
一定数量用户不能正常发展业务。
某项服务不可用，部分用户正常业务受到影响。
较少数量用户不能正常发展业务。
服务性能下降，但没有影响最终用户的正常业务。
某个用户正常业务可处理但响应时间变慢。
4、优先级计算
问题优先级P=MAX（SI,DI,DE）;
即取影响范围、重要程度、紧急程度三者之最大值为问题优先级取值。
优先级
代码
描述
4
极高
紧急事件升级来的问题；
专家组提出或趋势分析产生的问题从如下方面考虑，问题是否：
影响到关键业务（如：
关键应用系统和网络）
影响范围极大（如：
一个关键地区或半数以上非关键地区）
紧迫程度最高（如：
必须马上着手处理）
问题处理后可大幅节省投资、人力，有效提高服务质量和维护效率
3
高
从如下方面考虑，问题是否：
影响到较关键业务
影响范围较大
紧迫程度较高
问题处理后可有效节省投资、人力或提高维护质量
2
中
影响到非关键业务
有一定影响范围
问题处理后对维护质量和效率的提升有限
1
低
很小范围内影响或影响短时间可忽略
5.2流程图
此流程为问题管理主流程，项目经理根据各类分析报告进行趋势分析提出问题。
问题专家在对问题进行初步分类和优先级判断后送至问题经理，问题经理审核并派发问题给相应的问题处理专家，问题处理专家根据问题原因查找可行的问题解决方案并解决问题，解决完成后告知问题经理并关闭问题。
5.3流程详述
流程编号
流程描述
成果物
负责人
参与人
WTSBFL-01
问题识别与分类
l依据触发问题的条件定期对各类报告进行趋势分析，发现问题，根据需要在系统中创建或者关联问题，并对问题信息进行描述。
l根据问题所属领域进行分类，并初步判断问题的优先级。
问题记录单
专家组/二线工程师
WTSHFP-02
问题审核与分派
l问题经理对新建的问题进行审核：
问题经理确定问题是否有效、是否是重复问题，优先级的分配是否合适，问题信息项填写是否完整。
l如果问题确认无效，则关闭问题，并通知请求者。
l根据问题的分类，把问题分派给相应项目经理。
如项目经理发现问题应该由其他专家分析解决，就把问题发回问题经理，注明拒绝理由并推荐其他专家或组。
WTFXZD-03
问题分析与诊断
问题专家接受问题，更新问题状态及实际开始诊断时间：
l如需其他问题专家协助分析、诊断，则通知问题经理，由问题经理协调资源，成立专家组组，举行问题根本原因分析研讨会议，并确定问题的潜在原因，提供或更新问题变通方法，以降低问题在根本解决前对业务产生的影响；
l将问题产生根本原因及变通方法及时更新到问题记录中；
l将问题根本原因及变通方法通知问题经理；
l如果专家组无法找到问题的根本原因，及时通报问题经理。
已知错误
WTJJ-04
问题解决
对于已经找到根本原因的问题，需要确定解决方案，以便永久的解决。
l查找并验证根本性解决方案，并确保这些方案彻底解决问题，更新问题记录中的实际诊断结束时间。
l判断实施上述解决方案/变通方法是否需要通过其他流程（如变更流程等）：
-如需要，提交到相应的流程，并和该流程人员保持沟通，了解问题的解决状况；
-如不需要变更，计划并组织实施解决方案以解决问题。
l如果需要第三方介入，则问题专家负责与第三方的接口与协调。
l如果问题专家预计无法找到根本解决方案或虽有解决方案但目前无法实施（如实施的代价太大），通报问题经理。
RFC
WTGB-05
问题关闭
l确认问题是否被正确的解决，若果已经正确解决，通知问题经理并关闭问题，如果没有解决，转到“问题审核与分派”子流程。
l整理问题分析报告，更新知识库
l更新服务案例库
问题分析报告
5.4子流程1：
5.4.1流程图
5.4.2流程详述
WTZJ-01
事件回顾
定期回顾整理历史事件和各类报告
WTZJ-02
事件趋势分析
l依据入口准则分析事件特征（可以每周/每月为周期）：
l在本周期内每类事件的数量
l发生的频度有不断增加的趋势的事件
l对于没有根本解决的事件记录进行分析
WTZJ-03
判断是否为新问题
l判断分析结果是新问题还是重复问题，潜在问题转到流程编号WTZJ-04，重复问题转到流程编号WTZJ-06。
WTZJ-04
创建问题
l创建问题申请，在问题申请中记录问题的详细描述，包括产生时间、地点、标题及现象描述等，例如在问题描述中也需要指出潜在问题的来源具体人员。
l关联问题的事件。
l可以标识潜在问题。
WTZJ-05
初步判断严重等级
l根据问题申请中记录的实际情况及预先制定的优先级描述，初步给潜在问题申请分配相应的优先级
WTZJ-06
关联已有问题
l将分析结果的相关信息和CI关联到已有问题，以利于项目经理对问题的分析、解决。
WTZJ-07
提供事件状态和数量
l提供与该问题相关联事件的数量和状态并转入“问题审核与分派”流程。
5.5子流程2：
5.5.1流程图
5.5.2流程详述
查看问题记录信息
l问题经理对新登记的问题记录进行审核，检查问题记录信息是否正确和完整；
l如果问题记录信息不完整或不正确，则通知问题请求者，由其提供完善的问题信息。
是有效问题吗？
l问题经理审核该问题的有效性，如问题经理需判断该问题是否值得解决、该问题是否在将来的版本中已经考虑等，如果是无效问题，则转到“问题关闭”子流程，通知问题专家。
确认问题优先级和分类并分派给问题专家
l依据问题优先级评判标准，更新问题记录中的优先级并分类
l根据问题所属分类及优先级，把问题分派给相应的问题专家。
若问题比较复杂，问题经理需组建问题专家小组，并将该问题分配给当中最主要的处理人员
接受问题并收集相关数据
l问题专家接受并查看问题，收集问题相关数据，如果预计可以独立解决则流转至“问题分析与诊断”子流程，如果预计需要其他问题专家配合则通知问题经理协调资源。
5.6子流程3：
5.6.1流程图
5.6.2流程详述
调查问题
l问题专家依据问题信息对问题进行分析，匹配问题关联的CI和事件信息，找出可能的问题原因。
能否定位问题“根本原因”？
l如果当专家组预见或确认目前不能确定问题的根本原因时，则转入“问题审核与分析”子流程并通报问题经理，由问题经理组织问题采取变通方法解决问题。
l如果能定位根本原因，则记录问题根本原因，同时将定位后的分析结果反馈给质量管理流程。
记录问题根本原因
l记录问题根本原因和找到问题根本原因的分析办法及相关知识概要。
WTJL-02
标记问题为已知错误
l标记问题为已知错误
l通知事件流程相关事件负责人
l转入“问题解决”子流程
5.7子流程4：
5.7.1流程图
专家组根据问题的根本原因，尝试查找并提出解决方案或变通方法，制定实施计划提请客户同意，如果客户同意且该方案不涉及变更，则直接计划和安排实施方案，然后对该问题进行关闭；
如果有变更则进入变更管理流程；
如果客户不同意或者没有相应的解决方案和变通方法，则提请问题经理组织客户探讨。
5.7.2流程详述
流程编号及活动
查找问题解决方案：
l根据问题的根本原因，专家组尝试找出所有可能的解决方案和变通办法。
专家组
WTZJ-02能否找到解决方案/变通方法
l判断是否找到解决方案/变通方法，如果能找到，则制定实施计划，如果无法找到，则提请问题经理审批关闭问题
制定实施计划
l在问题管理中详细记录问题的解决方案/变通方法的实施计划并提交给问题经理审核，在制定实施计划时需要参考问题环境的CI信息。
WTJL-01
经问题经理审批
l当没有解决方案和变通方法，或者是解决方案变通方法实施代价太大时，由问题经理组织客户回顾探讨，确认客户可以接受问题后转入“问题关闭”子流程
验证实施计划是否可行？
l问题专家接收到实施计划后组织相关专家组评审实施计划的可行性，验证实施计划的能否解决问题，判断应用实施计划对问题环境产生的影响。
l如果验证不通过则准入流程编号WTZJ-01，进一步完善方案。
l如果验证通过则判断是否需要RFC
实施是否需要RFC？
l判断实施计划是否会引起变更请求，如果需要变更，则提起RFC并转至“变更流程”，如果不需要则转入流程编号WTZJ-05
实施解决方案/变通计划
l组织事件相关人和客户配合执行解决方案/变通计划的实施计划，转入“问题关闭”子流程
5.8子流程5：
5.8.1流程图
5.8.2流程详述
评估解决方案执行结果
l评估解决方案执行结果，分析问题解决是否彻底，问题解决过程是否按实施计划执行，是否有所变通，有变通则需要更新实施计划，同时要监控实施操作对问题环境是否产生其他影响。
是否完全解决问题？
l判断问题是否被正确的解决，如果问题没有被正确解决，转到“问题审核与分派”子流程，由问题经理组织专家组，重新对问题的根本原因进行分析。
如果问题正确解决且没有引起其他新问题的出现，则转入流程编号WTZJ-03
申请关闭问题
l将问题解决情况汇报给问题经理，申请关闭问题
批准关闭问题
l问题经理参考问题专家提交的问题解决情况记录，跟客户和事件处理人沟通问题解决效果，判断问题已经完全解决则批准关闭问题。
关闭问题
l关闭问题记录并通知问题经理。
l通知事件流程。
5.9定期评估及改进
主流程图：
进行问题管理定期或按需评估；
定期评估及改进：
问题经理每年12月份组织发起评估，并出具《问题评审表》，评估内容应包含问题解决率、平均工单处理时间等指标。
根据评估结果，提出改进建议，进行整改和提升。
按需评估及改进：
当问题重要程度、紧急程度、优先级均为高时，应组织相关部门进行此问题的评估，以期获得后期改进，避免问题再交发生。
6相关文件与记录
相关二级文件：
《服务事件管理制度》
《服务变更管理制度》
《服务配置管理制度》
相关记录文件：
《问题分析报告》（可记录在软件中）
《问题记录单》（可记录在软件中）
《月度问题统计表》
（责任编辑：
赵新娟13919325742QQ：
396317997）
升级会员 