IT问题管理流程手册.docx
《IT问题管理流程手册.docx》由会员分享，可在线阅读，更多相关《IT问题管理流程手册.docx（41页珍藏版）》请在冰点文库上搜索。
IT问题管理流程手册
第1章文档介绍
文档简介
本文档参照ISO20000国际标准及ITIL业界标准的要求,结合公司IT服务的实际情况，描述了问题管理流程的详细设计。
本文档是IT服务管理文件体系的管理流程文件之一。
文档用途
本文档是公司综合运维管理平台中问题管理流程的初步设计，也是进一步改进问题管理流程的蓝本.
本文档作为公司实施问题管理流程的参考，读者对象为公司内参与问题管理流程的人员和相关的管理层。
本文档所描述的流程在IT服务管理中有如下作用：
❑规范所有IT问题请求,以保证问题的充分解决；并为降低突发事件提供依据
❑指导与IT问题流程的相关人员有一套规范的流程去执行问题流程
❑指导IT管理平台项目的建设
文档结构
本文档主要介绍了问题管理流程的执行原则、活动和相关角色。
各章节中内容概要如下:
❑文档介绍
主要对文档的目的、用途及文档章节进行简要描述，并就文档中出现的术语进行了说明。
❑问题管理流程简介
主要对问题管理流程的基本概念、目的进行了介绍。
同时简单梳理了问题管理流程中包含的主要活动内容，最后将问题管理流程对组织及用户的业务价值进行了相关阐述。
❑问题管理流程设计
首先对问题管理流程的执行原则和相关定义进行描述，其次对相关人员职责和技能进行了定义，最后基于流程原则和角色定义，进而对问题管理的概要设计流程及详细设计流程进行了充分定义，最后给出了问题管理流程的标准报表。
❑附件
与问题管理流程相关的附属内容
文档术语
❑服务台
在ITIL中,服务台从根本上来说提供了用户和IT部门的唯一接口。
此项功能常常通过集中的服务台进行体现.服务台的根本目的是提供一线支持,并通过变通方法、解决方案或升级到二线支持等手段帮助用户恢复到正常工作状态。
❑事件管理
ITIL流程，是负责解决所有的IT事件、问题和用户请求等的管理流程。
它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的,而不在于查找根本原因。
❑问题管理
ITIL流程，是负责对事件进行深入分析,找出根本原因并提供解决方案的管理流程。
它的目的是主动防御,找出根本原因并对其根除，所以它与配置管理流程有显著的不同，以“治本”为最终目标.
❑变更管理
ITIL流程，是负责对生产环境中支持IT服务的各种基础架构设备和应用系统的变更操作进行记录、分类、评估、计划和协调的流程。
它的目的是在权衡“风险”和“效率”的前提下,对变更操作进行有效的控制,以保证任何变更对IT环境和其所支撑的IT服务的影响最小。
❑发布管理
ITIL流程，是负责对应用系统上线过程的全局管理和控制。
管理范围涉及测试环境、预发布环境和生产环境等，旨在通过对发布单元的生命周期各个阶段的控制保证其安全稳妥的进入生产环境，而不引入新的缺陷或故障。
❑配置管理
ITIL流程,配置管理负责描述，跟踪和汇报所有IT基础架构中的每一个设备或系统的管理流程。
这些设备和系统被称为配置元素（CI）。
每一个CI必须有效管理，跟踪和控制以支持IT服务和基础设施成功运行.
❑ITIL
ITInfrastructureLibrary,是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT管理标准。
第2章问题管理流程简介
流程的基本概念
问题管理负责解决重大紧急事件或具有相同症状的一组事件。
它的目的是找出事件的根本原因，并通过解除该根本原因从而防止类似事件的再次发生。
同时问题管理流程也负责预防事件的发生。
流程目的
问题管理流程的根本目的是消除或减少生产环境中事件发生的数量和严重程度，从而为国家核电建立一个稳定的IT环境，提高IT服务的可用性。
此流程对发生在国家核电IT支撑系统生产环境中的问题进行管理,找出产生这些问题的根本原因，然后根据需要通过变更请求（RFC）、变通方法或建议的预防性措施来防止事件的再次发生。
问题管理流程常常需要和变更管理流程一起来实施找出的解决方案，以便从根本上解决问题.其目的包括：
❑分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生
❑确保问题分派了正确支持人员，提高解决率
❑根据问题优先级合理分派IT资源
❑对事件记录做趋势性分析,主动提供预防性措施
❑提高IT服务的可靠性
❑降低IT支持成本
流程的主要内容
问题管理流程着重于消除事件或减少事件发生，确定事件的根本原因。
主要活动包括分析事件、找出问题、分派问题、确定根本原因、找出解决方案、回顾及关闭。
其主要内容如下：
❑分析事件
定期对事件进行分析，找出事件的潜在问题。
❑生成问题记录
在系统中生成问题记录并把所有相关事件与此问题单关联起来
Ø重大事件处理完后定义为问题
Ø技术支持专家在日常维护中发现的问题
Ø事件历史记录趋势分析
❑分派
根据问题内容将问题记录分派给适当的技术小组。
❑根本原因分析
被分派的小组人员将调查问题以期找出其原因，制定解决方案、变通方法或提出预防性措施,以消除产生原因，或在重发时使其影响力最小化。
记录必须被更新以反映它是已定位原因状态，并且把任何变通方法、避免或最小化负面影响的动作行为也记录下来（如果需要添加到知识库中）。
❑开发、确认、提出实施解决方案
对问题的解决方案进行评估、测试,提出变更请求（RFC）或实施具体的解决方案.
❑回顾
对问题的解决方案进行回顾，确认解决方案达到了预期的效果。
❑总结及关闭
确认问题的信息记录填写完整，并关闭问题单。
第3章问题管理流程设计
流程的执行原则
3.1.1常规原则
❑建立独立问题管理流程,应该与事件管理流程相对独立，事件经理与问题经理应该尽可能的由不同的人员担任
❑应该每半年对问题管理流程的流程关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾，以改进和优化流程
❑应该每周对事件进行分析，找出潜在的问题
❑应该每月定期回顾和产生问题管理报表，对没有解决的问题,应该举行定期的问题管理会议对这些问题进行评估
3.1.2流程的关联原则
❑和事件管理的关联
Ø重复发生的事件解决后，服务台人员都应该创建问题单（问题单必须和事件单建立关联）
❑和变更管理的关联
Ø问题处理过程中，如果需要对系统进行变更,必须按照变更管理流程的定义，提交变更请求单（变更单必须和问题单建立关联），变更完成后，继续问题单的处理
❑和配置管理的关联
Ø问题处理过程中，可以通过配置管理查询相关的配置项信息
Ø问题处理过程中，如果可以将根本原因定位到某个配置项，则必须将问题单与该配置项关联
3.1.3问题所有权原则
❑有效管理问题的前提是必须确保每个问题在任何时段都有适当的人员负责
❑问题首先由问题经理审核,再负责分派给合适的问题处理专家或组
❑当问题分派到问题处理专家后，问题处理专家负责该问题的诊断与解决
❑问题经理负责与服务台或问题请求者沟通问题处理过程中的关键信息
3.1.4重复问题原则
❑重复问题是指经过分析之后,根本原因相同的问题.例如：
问题处理专家提出了几个问题，但是经过分析之后，发现这几个问题的根本原因是相同的,这几个问题就可以定义为重复问题。
对于重复问题需要进行标记，将相关问题单进行关联,当问题解决时同时进行回顾.
3.1.5问题关闭原则
❑通常，问题单在实施了解决方案之后，需要经过一段时间的回顾,由问题处理专家和问题经理一起来回顾解决方案是否达到了预期的效果，如果成功的实施，则提交给问题经理，由问题经理确认问题信息记录完整，关闭问题.
3.1.6趋势的分析原则
❑问题经理定期组织会议，对所处理事件历史记录进行趋势分析：
Ø参加者应包括事件经理及问题处理专家
Ø会议每周组织
Ø定义趋势分析规则
流程相关定义
3.1.7问题信息项
问题信息项包含如下信息：
序号
信息项
描述
问题的识别与记录阶段填写
1
报告人信息
问题报告人的信息，包括：
姓名、电子邮件、办公电话、
2
问题来源
参见“问题来源"定义
3
问题优先级
参见“问题优先级"定义
4
问题所属系统类型
参见“问题所属系统类型”定义
5
问题分类
参见“问题分类”定义
6
问题简要描述
简单描述问题（手工填写）
7
问题描述
详细描述问题内容（手工填写）
8
是否新业务引起
新业务上线后，但还未正式移交发生的问题（手工填写）
9
重复问题标记
标记为重复问题，用已有标题号标注（手工填写）
10
关联的事件单号
记录引发该问题的事件单号
11
关联的变更单号
记录由问题发变更时,关联的变更单号
12
关联配置项
记录问题的配置项代码
13
分配对象
将问题分配到各组问题处理专家
问题的识别与记录阶段，系统自动填写
1
问题ID
为每个问题分配一个唯一的序列号
2
登记时间
生成问题记录的时间（系统自动产生）
3
问题状态
参见“问题状态”定义
4
建单人
创建问题工单的IT人员
问题处理阶段填写
1
问题日志
反映问题处理过程中问题信息项的变化历史，包括分配的人员，状态等信息（系统自动产生）
2
实际开始诊断时间
问题状态更新为“分析中"的时间（手工填写）
3
实际诊断结束时间
问题状态更新为“已有解决方案"的时间（手工填写）
4
问题根本原因
查找出问题的根本原因（手工填写）
5
解决方案
问题解决方案的详细描述（手工填写）
问题关闭时填写
1
问题结束代码
参见“问题结束代码”定义
2
问题关闭时间
当问题状态更新为“结束并关闭“的时间（手工填写）
3.1.8问题的来源
问题来源定义如下:
编号
代码
描述
1
事件升级
多次发生的突发事件或重大事件由服务台人员升级为问题，以便进行重复事件和重大事件的根本原因分析。
事件处理过程中,需要通过问题处理流程，解决的事件，升级为问题。
2
维护中提出
技术专家在日常维护工作中提出的问题。
例如：
维护专家在日常维护中发现,目前的数据库版本可能会存在着死锁、心跳不一致等方面的问题，此时就可以提出一个问题记录，以便分析。
3
趋势分析
分析事件记录找出的问题。
例如：
在定期的会议中，对事件进行分析后发现,上周该类型的事件比平常的时候多了30％，超过了规定的阀值,这表明系统有可能存在着一些潜在的隐患，此时就可以提出一个问题记录，以找出问题的原因并解决。
3.1.9问题的优先级定义
问题的优先级是问题处理专家解决问题的参照标准，对于关键优先级的问题，管理层应该优先协调资源进行这些问题的解决.结合公司的实际情况,问题的优先级定义如下：
编号
代码
描述
1
关键
重大事件升级来的问题；
维护专家提出或趋势分析产生的问题从如下方面考虑，问题是否:
●影响到关键业务（如：
广域网、OA、核心交换网络等）
●影响范围极大（如：
一个关键地区或半数以上非关键地区，如北京上海山东之间的广域网）
●紧迫程度最高（如：
必须马上着手处理）
●问题处理后可大幅节省投资、人力,有效提高服务质量和维护效率
2
重要
从如下方面考虑，问题是否:
●影响到较关键业务（如：
广域网、OA、等）
●影响范围较大（如：
一个以上非关键地区）
●紧迫程度较高
●问题处理后可有效节省投资、人力，一定程度提高维护质量
3
普通
从如下方面考虑，问题是否:
●影响到非关键业务
●有一定影响范围
●问题处理后对维护质量和效率的提升有限
3.1.10问题的状态定义
为了记录问题处理的生命周期，需要设置不同的状态加以描述，如下所示：
编号
代码
描述
1
已登记
问题记录到系统中
2
分析中
问题处理专家正在分析问题过程中
3
已定位原因
问题根本原因已找出
4
已有解决方案
解决方案已找到
5
已提出变更请求
已提交变更请求（RFC）
6
已回顾
已经对问题进行了回顾
7
结束并关闭
问题结束
3.1.11问题的分类
问题分类是针对问题所属的专业类型进行划分的,通过问题分类可以定位解决问题的人，并针对问题分类进行分类统计.问题分类定义如下：
一级分类
二级分类
三级分类
网络系统
广域网
路由器
交换机
局域网
核心交换机
楼层交换机
桌面终端
硬件
台式机
笔记本
打印机
传真机
软件
操作系统
标准软件
非标准软件
安全系统
防火墙
CA
桌面安全管理系统
综合运行监控系统
运维服务台
防病毒软件
上网行为审计系统
电子签章
应用系统
OA系统
协同交换系统
公文交换系统
统一消息系统
门户网站系统
邮件系统
财务系统
反腐倡廉系统
视频会议系统
电话会议系统
存储系统
3.1.12问题的结束代码
为了表明问题的不同解决方式，定义如下结束代码：
编号
代码
描述
1
根本解决
找出问题的根本原因，并得到解决方案,成功解决
2
变通方法
没有根本解决方案或目前没有办法实施根本解决方案，但有临时解决方案作为变通方法
3
无法解决
未找到问题的根本原因，没有解决方案，或目前无法实施解决方案，也无变通方法
4
取消
问题被问题经理拒绝
问题管理流程角色定义
3.1.13问题处理专家
问题处理专家通常由各专业组技术人员承担，负责协调、监督厂商进行问题诊断及解决，有时也会自行承担问题的诊断和解决.
职责：
❑根据事件处理和日常维护要求创建问题，启动问题管理流程
❑协调、监督厂商进行问题诊断、确定解决方案
❑按照专业能力，对问题诊断,确定解决方案
❑回顾问题、整理解决方案并提交知识库
技能要求：
❑较强的问题解决能力，能够对问题进行分析并给出解决方案
❑较强的专业知识
❑较强的分析问题的能力和技巧
❑较好的沟通和表达能力
3.1.14问题经理
问题经理负责协调日常的问题管理工作，包括对问题的审核、监控、所需资源的协调、定期产生报表等。
职责:
❑定期组织相关人员对事件记录进行分析，发现潜在问题
❑确认、审核和监视问题处理过程
❑必要时协调所需资源
技能要求：
❑具有较好的沟通和口头表达能力
❑熟悉技术平台和技术环境
❑较强的分析事件趋势的能力
❑深刻熟悉问题管理流程
3.1.15问题流程负责人
问题管理流程负责人从总体上对问题管理流程的设计、实施、执行及优化负责，确保问题管理流程在业务支持中心范围内被正确的执行.当流程不能够适应公司的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高.
职责：
❑确保问题流程的设计、实施及执行，能够取得管理层的参与和支持
❑确保问题流程符合公司实际状况和公司IT发展战略
❑整体上对问题流程负责，建立流程实施、评估和持续优化机制
❑确保问题流程的有效执行，定期评估流程，制定流程改进计划
❑保持与其他流程负责人的定期沟通
技能要求:
❑深刻理解问题管理流程
❑能够很好地理解业务对于问题管理的需求
❑对质量控制与保障有很深入的了解
❑有决策权，能够确保问题管理流程设计要求在实施项目中得到贯彻和执行
❑具有很好的沟通技能，能够取得公司高层的支持，获得所需资源
❑具有较强的计划、组织、领导和控制才能，能够综合各方意见，按时制订和定期优化问题管理流程
3.1.16人员角色对应
实际人员与角色对应如下表:
角色
人员
技术特点
问题处理专家
事件管理流程经理
事件管理流程负责人
问题管理流程概要设计
问题管理流程概要设计如下:
各步骤描述如下:
序号
步骤名称
责任人
描述
2。
1
问题识别与记录
问题经理
问题处理专家
❑对重大事件，系统维护过程中发现的问题以及通过对事件记录进行的分析发现的潜在问题，根据需要在系统中进行记录，并对问题信息进行描述。
❑根据问题所属领域进行分类，并初步判断问题的优先级。
2。
2
问题审核
问题经理
❑问题经理对新建的问题进行审核：
问题经理确定问题是否有效、是否是重复问题，优先级的分配是否合适，问题信息项填写是否完整。
❑如果问题确认无效,则关闭问题，并通知问题报告人。
2。
3
问题分派
问题经理
❑根据问题的分类，把问题分派给相应问题处理专家。
如问题处理专家发现问题应该由其他组分析解决，就把问题发回问题经理，注明拒绝理由并推荐其他分析组.
2.4
分析诊断问题，提出变通方法
问题处理专家
问题处理专家接受问题，更新问题状态及实际开始诊断时间：
❑如需其他问题处理专家协助分析、诊断,则通知问题经理，由问题经理协调资源，成立问题分析小组，举行问题根本原因分析研讨会议，并确定问题的潜在原因，提供或更新问题变通方法,以降低问题在根本解决前对业务产生的影响；
❑将问题产生根本原因及变通方法及时更新到问题记录中；
❑将问题根本原因及变通方法通知问题经理；
❑如果问题处理专家预计无法找到问题的根本原因，及时通报问题经理
2。
5
开发、确认、实施和解决问题
问题处理专家
对于已经找到根本原因的问题,需要确定解决方案,以便永久的解决。
❑推荐并测试根本性解决方案,并确保这些方案彻底解决问题，更新问题记录中的实际诊断结束时间。
❑判断实施上述解决方案/变通方法是否需要通过其他流程（如变更流程等）：
-如需要，提交到相应的流程，并和该流程人员保持沟通，了解问题的解决状况；
-如不需要变更，计划并组织实施解决方案以解决问题。
❑如果需要第三方介入，则问题处理专家负责与第三方的接口与协调。
❑如果问题处理专家预计在无法找到根本解决方案或虽有解决方案但目前无法实施（如实施的代价太大），通报问题经理。
2.6
问题回顾
问题处理专家
问题处理专家对问题进行回顾，确认问题是否被正确的解决，如果没有解决,回到步骤2。
4
2。
7
问题关闭
问题经理
问题经理对问题记录的信息项进行总结，更新问题记录并关闭问题。
2。
8
问题监控
问题经理
问题经理负责问题分析、诊断、解决过程中的跟踪和监控：
❑在问题找到根本原因或解决方案之后，根据需要，向服务台或问题请求人员通报该问题的解决情况,以帮助和提高事件的解决率。
❑对于问题处理专家认为无法找到根本原因或虽有解决方案，但目前无法实施（如实施的代价太大等），问题经理协调问题处理专家进行分析判断，决定该问题是继续诊断、解决还是关闭该问题。
问题管理流程详细设计
3.1.17问题识别与记录
流程图:
流程描述:
序号
步骤名称
责任人
输入
输出
描述
1。
1。
1
用户电话/邮件
1.1.2
监控系统
1.1.3
新建事件单
服务台
用户电话或者电子邮件
新建事件表单
服务台负责创建新的事件单，填写详细情况描述，不属于IT部门处理的，直接电话回复。
记录的内容包括
事件请求人信息
事件影响人信息
事件简要描述
事件详细描述
1。
1.4
从监控系统接收事件
服务台
从UniMon综合监控平台接收IT系统自动产生的告警事件队列
生成需要处理的事件单
事件任务队列的来源：
1.监控系统自动发送的告警
2.业务部门通过其他接口转发的事件单
服务台负责检查事件任务队列中的新事件单,开始处理
重复事件判断
服务台
事件记录
相应的处理流程
如果事件为重复事件,则走重复事件处理流程,如果不是重复事件，则确定事件的性质
1。
1.5
重复事件处理
服务台
重复事件
标记重复事件，关联目标事件
将该事件标记成重复事件,并将该事件与对应的目标事件关联
1.1。
6
设定事件性质
服务台
非重复事件
确定事件性质为故障/请求/投诉/咨询
确定事件性质为故障/请求/投诉/咨询
1。
1.7
对事件进行分类
服务台
对事件进行分类
确定事件的类别为硬件/软件/服务/投诉咨询类别的事件
确定事件的类别为硬件/软件/服务/投诉咨询类别的事件
1.1。
8
匹配相关的CI和SLA
服务台
判断与该事件的相关联的CI和SLA
将事件关联配置管理流程中的CI项，将事件关联服务级别管理流程中的SLA项
判断与该事件的相关联的CI和SLA，将事件关联配置管理流程中的CI项，将事件关联服务级别管理流程中的SLA项
1.1.9
设定事件的优先级/影响度/紧急度
服务台
事件记录
确定事件的优先级/影响度/紧急度
根据事件描述和用户要求,判断事件的影响度和紧急度，并由影响度和紧急度，设定事件的优先级。
是否为重大事件
服务台
判断事件的优先级
确定事件是否为重大事件
根据优先级定义，判断优先级为1的事件为重大事件。
3.1.18初步支持
流程图:
流程描述:
序号
步骤名称
责任人
输入
输出
说明
趋势分析
问题经理
事件详细记录
事件趋势，潜在问题
问题经理周期性的召集由事件经理、问题处理专家参加的会议,对事件记录详细信息进行趋势分析（可以每周/每月为周期）：
❑在本周期内每类事件的数量
❑发生的频度有不断增加的趋势的事件
❑对于没有根本解决的事件记录进行分析
可采取趋势突变法（如有30%增长率的某类事件）或阈值法对事件进行分析，发现需进一步分析的潜在问题.
另外，问题经理也可以根据需要召集问题处理专家等相关技术人员对于未根本解决的问题进行再次分析，以决定是否需要创建问题来进一步分析。
事件升级
事件经理
重大事件详细记录
在重大事件处理完成后（无论是否根本解决），都由事件经理将重大事件的处理情况、事件记录提交给问题经理。
维护中提出
维护专家
由维护技术人员在日常维护工作中根据自己的经验或分析，在自己负责的领域内发现并提出的问题请求：
❑通过日常巡检发现的问题
❑对日常维护监控数据进行分析
2.1.1
创建问题记录
问题经理/问题处理专家
问题记录
综合上述三种情况,由问题经理或问题处理专家在系统中创建问题记录:
❑选择问题来源;
❑记录问题详细描述，包括产生时间、标题及现象描述等，例如在问题描述中也需要指出问题的来源具体人员；
❑问题状态设置为“已登记"。
2.1.2
初步确定问题优先级及分类
问题经理/问题处理专家
问题记录
问题优先级/分类
问题记录创建时，问题创建人需要完成：
❑根据问题记录的实际情况及预先制定的优先级描述,初步给问题记录分配相应的优先级代码；
❑根据问题的来源和所涉及的领域，及已定义的分类原则,初步对问题进行分类.
2。
1。
3
关联相关CI及事件记录
问题经理/问题处理专家
问题记录
进行关联之后的问题记录
根据问题记录的信息描述,对创建的问题记录关联相关CI,并将问题与系统中的事件记录进行关联。
以利于问题处理专家对问题的分析、解决。
例如：
问题记录是由重大事件升级而成的，此处便可以将该问题记录与原重大事件记录做关联。
3.1.19问题的审核
流程图：
流程描述:
序号
步骤名称
责任人
输入
输出
说明
2.2。
1
审核问题记录是否准确
问题经理
审核后的问题记录
需完善的问题记录/通知问题请求者
❑问题经理对新登记的问题记录进行审核，检
升级会员 