本帖最后由 monicazhang 于 2015-10-22 11:26 编辑
20151022 淡然
续上
5.6 流程相关定义5.6.1 问题信息项 问题单包含如下信息项:
表7-1 问题信息项
[td]
序号
| | |
1
| | |
| | 问题请求人的信息,包括:姓名、省/分公司、部门、电子邮件、办公电话、手机(手工填写) |
3
| | |
4
| | |
5
| | |
6
| | |
7
| | |
8
| | |
9
| | |
10
| | |
11
| | 详细描述拒绝问题原因,并推荐其他专家或专家组(手工填写) |
12
| | |
13
| | |
14
| | |
15
| | |
16
| | |
17
| | |
18
| | |
19
| | 反映问题处理过程中问题信息项的变化历史,包括分配的人员,状态等信息(系统自动产生) |
20
| | |
21
| | |
22
| | |
23
| | |
24
| | |
| | |
| | |
| | |
| | |
| | |
5.6.2 问题来源 根据问题的不同来源对问题分类如下:
编号
| | |
1
| | 事件恢复服务后提出的问题,以便进行事件的根本原因分析。业务恢复后,相应事件应结束关闭,以免影响事件处理时长。如果事件对应的潜在故障原因后后续规避措施仍需继续研究,应启动问题管理流程,创建问题单。 例如:某日发生了一起集群无法切换的事件,导致某台主机发生故障后,没有切换到备用主机中去,从而影响了业务,事件处理人员在采取了手工切换的替代措施后,恢复了服务。为了分析为什么会发生该事件,以及查看其他的集群是否也存在类似的问题,此时可以提出一个问题记录,以便对该事件进行研究分析。 ITSS认证 |
2
| | 技术专家在日常维护工作中提出的问题。日常维护中发现的潜在故障如果没有影响到业务,应启动问题管理流程,创建问题单。 例如:维护专家在日常维护中发现,目前的数据库版本可能会存在着死锁、心跳不一致等方面的问题,此时就可以提出一个问题记录,以便研究分析,避免日后发生故障。 |
3
| | 分析事件记录找出的问题。常规的工作分析会上确定的、需要深入研究的任务落实到维护专家后,应启动问题管理流程,创建问题单。 例如:在定期的会议中,对计费类的事件进行分析后发现,上周该类型的事件比平常的时候多了30%,超过了规定的阀值,这表明计费系统有可能存在着一些潜在的隐患,此时就可以提出一个问题记录,以找出问题的原因并解决。 |
5.6.3 问题优先级 问题的优先级是问题处理专家解决问题的参照标准,对于关键优先级的问题,管理层应该优先协调资源进行这些问题的解决。结合中国移动的实际情况,问题的优先级定义如下:
编号
| | |
1
| | 从如下方面考虑,问题是否: l 影响到关键业务(如:综合帐务、定单管理、电话呼叫中心等) l 影响范围极大(如:一个关键地区或半数以上非关键地区) l 紧迫程度最高(如:必须马上着手处理) l 问题处理后可大幅节省投资、人力,有效提高服务质量和维护效率 |
2
| | 从如下方面考虑,问题是否: l 影响到较关键业务(如:综合采集、融合计费、产品管理等) l 影响范围较大(如:一个以上非关键地区) l 紧迫程度较高 l 问题处理后可有效节省投资、人力,一定程度提高维护质量 |
3
| | 从如下方面考虑,问题是否: l 影响到非关键业务 l 有一定影响范围 l 问题处理后对维护质量和效率的提升有限 |
5.6.4 问题状态 为了记录问题处理的生命周期,需要设置不同的状态加以描述,如下所示:
5.6.5 所属系统类型 请参照事件管理“6.6.4所属系统类型”。
5.6.6 问题分类 问题分类与事件分类相同,请参照事件管理“6.6.5事件分类”。
5.6.7 问题结束代码 为了表明问题的不同解决方式,定义如下结束代码:
编号
| | |
1
| | |
2
| | 没有根本解决方案或目前没有办法实施根本解决方案,但有临时解决方案作为变通方法 |
3
| | 未找到问题的根本原因,没有解决方案,或目前无法实施解决方案,也无变通方法 |
4
| | |