问题管理流程.docx
《问题管理流程.docx》由会员分享，可在线阅读，更多相关《问题管理流程.docx（11页珍藏版）》请在冰豆网上搜索。
问题管理流程
IT服务管理体系
问题管理流程
文件编号：
ITSS-15-04
版本/版次：
V1.0
生效日期：
2019.6.1
制订
审核
批准
版本历史记录
版本
生效日期
修订内容
制订者
审核人
批准人
1.目的
本规范的目的是消除或减少运维过程中事件发生的数量和严重程度，防止相同事件的再次发生，从而为客户建立一个稳定的IT环境，提高IT服务的可用性。
问题管理包括主动性问题管理和被动问题管理两类活动。
前者的目标是通过找出基础设施中的薄弱环节来阻止事件再次发生，以及提出消除这些薄弱环节的建议；后者的目标是找出导致以前发生事件的根本原因，以及提出解决措施或纠正建议。
2.范围
应用于公司所有ITSS运维服务与问题相关的活动。
3.名词术语
问题：
造成一个或多个事件的根本原因。
注：
问题的根本原因在问题创建通常是未知的，问题管理过程就是负责探寻这些未知。
4.问题状态定义
为方便问题状态的跟踪和查询，对问题状态定义如下。
编号
状态
描述
1
处理中
问题正在处理
2
待签收
问题等待处理人签收
3
已关闭
问题流程已经结束
4
待确认
问题处理完成，等待结果确认
5
已撤销
问题已经被撤销
6
搁置中
问题进入搁置状态
7
搁置请求审批中
问题处理人申请搁置等待审批
5.问题来源
问题的来源主要有：
事件没有得到解决，需要升级为问题进行进一步分析处理时，应创建问题；
事件虽然得到解决，但还可能存在未知错误时，应创建问题；
重大事件，无论是否得到解决，为防止再次出现，应创建问题；
在事件分析报告中提出的存在趋势或潜在隐患的可能问题，例如事件类型或数量的趋势分析存在问题；
对基础设施和服务的主动性问题检查；
供应商提供的已知产品缺陷、已知错误；
与信息安全有关的安全事件或安全风险也应作为问题来管理。
6.问题的分类
问题分类公司应根据实际情况对问题进行分类，本公司目前依据运维对象依据事件类型进行分类，问题的分类参照事件的分类方法进行，包括：
故障类问题、信息安全类问题和询问性的问题三大类，问题涉及到的运维服务范围包括：
1、040201网络运维服务；
2、040202主机运维服务；
3、040203存储运维服务；
4、040301基础软件运维服务。
运维问题分类代码要和来源事件的编码进行关联，以便跟踪问题产生的根本原因，从而获得有价值的信息。
7.问题分级
问题级别
优先级是问题管理的一个关键要素，优先级决定处理问题的顺序及所需的资源。
在运维服务中，问题优先级可分为五级：
S1（紧急，即：
最高）、S2（高）、S3（中）、S4（低）。
为方便服务支持对于问题优先级的判断，建议从问题影响程度和问题紧急程度两维来进行优先级定位。
问题的影响程度主要是对事件发生的关键程度以及问题发生后的影响范围综合考虑得出。
在运维业务中，要考虑以下几个方面：
受影响用户数量和范围
紧急程度
业务重要性
相关用户部门
相关用户职位
表1问题影响程度
类别
级别
备注
影响程度
高
中
低
从影响客户的数量方面进行分类
信息系统中发生的已经影响或者即将影响24小时的业务运行
信息系统中发生的已经影响或者即将影响8小时的业务运行
信息系统中发生的已经影响或者即将影响4小时的业务运行
问题的紧急程度主要由问题本身是否涉及关键业务系统来进行判定，如问题涉及关键业务系统，则认为紧急程度较高，需要尽快恢复；如问题不涉及关键业务系统，则认为紧急程度较低，可优先处理紧急程度较高的问题。
在运维业务中，问题紧急程度定义具体如下：
表2问题紧急程度
类别
级别
备注
紧急程度
紧急
高
中
低
从业务影响程度进行分类
客户关键核心业务无法使用；
信息安全事件
客户关键核心业务受影响
客户普通业务受影响
客户业务可能有潜在影响
结合问题发生时的影响程度和紧急程度，可以通过下表确定问题的优先级：
表3问题优先级矩阵
问题优先级
影响度
高
中
低
紧急度
1-紧急
S1
S2
S3
2-高
S2
S3
S4
3-中
S3
S4
S4
4-低
S3
S4
S5
服务台在创建工单时可结合其他因素确定实际优先级别。
8.问题处理原则
处理问题的原则是尽可能消除对业务的影响；
问题管理流程必须包括管理服务事件影响的步骤，比如评估影响、沟通、提供变通方案等,使消除问题对客户业务活动的影响，并按问题目标解决要求进行外理问题。
问题目标解决时间
问题目标时间
问题被分派并得到接受
问题找到根本原因
问题找到解决方案
问题单关闭
S1
1工作日
2工作日
4工作日
N/A
S2
1工作日
3工作日
6工作日
N/A
S3
1工作日
5工作日
10工作日
N/A
S4
2工作日
10工作日
20工作日
N/A
9.问题升级处理
当问题未能或预计未能按照服务等级协议（SLA）的要求，得以修复时，将按照预定的时间表自动（或由服务台）发起问题升级。
另当，用户或支持队伍认为有必要时，可以要求发起问题升级。
表5问题升级时间表
问题升级机制
问题专家
问题经理
技术总监
S1
N/A
2工作日
4工作日
S2
N/A
3工作日
6工作日
S3
N/A
5工作日
10工作日
S4
N/A
10工作日
20工作日
10.流程角色
角色
职责
职能岗位
运维服务经理
●开发和维护问题管理流程
●提供管理信息并运用这些信息主动预防问题的发生
●确保和外部供应商等其他角色的有效合作
●获取问题管理流程各项活动所需的资源
●进行事后检查或组织重大问题审查
●分析和评价主动问题管理活动的有效性
●识别问题管理过程中存在的问题并提出改进措施
●定期编写问题报告
技术部经理
问题提交人
●负责问题确认、记录、分级及跟踪
●确保所有相关问题信息都被正确登记
●对登记的问题进行分类
●负责根据问题解决方案实施
运维项目经理
问题分析员
（二线、三线）
●接收由问题经理派发的问题。
●确认问题的分类和关联配置项。
●通过详细分析确认问题根源。
●提出问题的解决方案。
●识别问题发展趋势。
●防止问题扩散到其他系统。
●必要时提交变更请求。
●参与问题解决。
各部门参与问题分析与解决的人员
二线：
技术专家团队
三线：
供应商和研发团队
11.流程
11.1问题管理流程
活动
描述
责任人
输入
输出
1问题确认
Ø用户事件产生的问题；
Ø运行工程师巡检发现的问题；
Ø
现场工程师
Ø事件记录
Ø巡检报告
Ø提出问题
2记录问题信息
Ø服务台记录问题及用户基本信息。
服务台
Ø提出的问题
Ø问题记录
3问题分类/分派
Ø服务台人员参考目前问题分类、分级标准对该问题进行分类/分级；
Ø服务台人员将问题派发给问题分析员；
服务台
Ø问题记录
Ø已分类及分派的问题
4解决问题
Ø分析记录的问题信息；
Ø确认问题的根源；
Ø提出问题的解决方案；
Ø根据方案解决问题。
问题分析员
运维工程师/技术支持工程师
Ø含有分类及准确信息的问题记录
Ø问题解决方案
5跟踪/关闭问题
Ø跟踪问题的解决情况；
Ø服务台在用户认可后关闭问题记录。
服务台
Ø已解决的问题记录
Ø已关闭的事件记录
6问题后续处理
Ø流程经理在问题关闭后检查；
Ø生成问题报告并根据需要转向其他流程。
Ø问题经理关闭问题后，根据解决方案判断是否需要更新知识库
运维服务经理
Ø已关闭的记录
Ø定期事件报告
Ø相关知识
Ø定期事件报告
Ø需要提交其他流程处理的问题记录
Ø总结的知识
Ø更新的知识库
11.2问题导入知识库机制
问题经理关闭问题后，根据解决方案判断是否需要更新知识库；若需要则由问题经理负责将问题描述和问题解决方案在知识库中更新，必要时组织相关人员培训。
12.审核
技术部定期对问题管理全流程进行审核。
13.关键绩效指标（KPI）
问题解决率≥60%，（已解决的问题数量/问题总数）*100%。
14.问题管理和其它流程关系
问题一般由事件而来；问题的解决方案就是知识，验证的解决方案必须导入知识库，由运维服务经理监督提交；在解决问题过程中往往需要变更管理。
15.参照文件
GB/T28827.1-2012《信息技术服务运行维护第1部分:
通用要求》
ISO/IEC20000-1：
2011《IT服务管理体系要求》
ISO/IEC20000-2：
2012《IT服务管理体系实践指南》
升级会员 