ITSS运维服务问题管理制度.docx
《ITSS运维服务问题管理制度.docx》由会员分享，可在线阅读，更多相关《ITSS运维服务问题管理制度.docx（32页珍藏版）》请在冰豆网上搜索。
服务问题管理制度
文件编号：
ITSS-PM-PM-001
版本号：
V1.0
受控状态：
受控文件
服务问题管理制度
西安**信息科技有限公司
编制人：
杨帆
编写日期：
2018-12-10
审核人：
刘东
审批日期：
2018-12-25
29
文档控制
描述：
文档名：
服务问题管理制度
文档编号：
ITSS-PM-PM-001
版本号：
V1.0
定版日期：
2018年12月
编制人：
杨帆
审核人：
刘东
版本控制：
版本
日期
审核人
备注
V1.0
2018年12月
刘东
编写初稿。
目录
1 概述 1
1.1 目标 1
1.2 范围 1
2 制定依据 2
3 术语定义 2
4 角色和职责 3
5 内容 4
5.1 程序准则 4
5.1.1 执行准则 4
5.1.2 输入及入口准则 7
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）
信息系统资产如果出现问题则会产生非常大的损失。
例如：
机房、核心网络、服务器、应用系统等，宕机后严重影响公共秩序或安全。
中（3）
信息系统资产如果出现问题则会产生较大的损失。
例如：
核心网络、服务器、应用系统等，宕机后较大影响公共秩序或安全。
低
（2）
信息系统资产如果出现问题则会产生一定的损失。
例如：
网络、应用系统等，产生问题后较少影响公共秩序或安全。
很低
（1）
信息系统资产如果出现问题则会产生轻微的损失或无损失。
例如：
某一用户客户端等轻微影响公共秩序或安全。
3、紧急程度（DE）
紧急程度
定义
备注
高（4）
服务不可用，用户核心业务受到严重影响。
例如：
重点最终用户、关键部门、领导层服务出现问题。
中（3）
部分服务不可用，最终用户正常业务受到影响。
例如：
一定数量用户不能正常发展业务。
低
（2）
某项服务不可用，部分用户正常业务受到影响。
例如：
较少数量用户不能正常发展业务。
很低
（1）
服务性能下降，但没有影响最终用户的正常业务。
例如：
某个用户正常业务可处理但响应时间变慢。
4、优先级计算
问题优先级P=MAX（SI,DI,DE）;即取影响范围、重要程度、紧急程度三者之最大值为问题优先级取值。
优先级
代码
描述
4
极高
紧急事件升级来的问题；
专家组提出或趋势分析产生的问题从如下方面考虑，问题是否：
影响到关键业务（如：
关键应用系统和网络）
影响范围极大（如：
一个关键地区或半数以上非关键地区）
紧迫程度最高（如：
必须马上着手处理）
问题处理后可大幅节省投资、人力，有效提高服务质量和维护效率
3
高
从如下方面考虑，问题是否：
影响到较关键业务
影响范围较大
紧迫程度较高
问题处理后可有效节省投资、人力或提高维护质量
2
中
从如下方面考虑，问题是否：
影响到非关键业务
有一定影响范围
问题处理后对维护质量和效率的提升有限
1
低
很小范围内影响或影响短时间可忽略
5.2流程图
此流程为问题管理主流程，项目经理根据各类分析报告进行趋势分析提出问题。
问题专家在对问题进行初步分类和优先级判断后送至问题经理，问题经理审核并派发问题给相应的问题处理专家，问题处理专家根据问题原因查找可行的问题解决方案并解决问题，解决完成后告知问题经理并关闭问题。
5.3流程详述
流程编号
流程描述
成果物
负责
升级会员 