×

微信扫一扫,快捷登录!

如何定义ITSS问题单的各信息项目

标签: 暂无标签
本帖最后由monicazhang于2015-11-610:58编辑

20151106淡然
续上




7流程相关定义
7.1问题信息项
问题单包含如下信息项:
序号

信息项

描述

1

问题ID

为每个问题分配一个唯一的序列号(系统自动生成)

2

请求人信息

问题申报人的信息,包括:姓名、部门、办公电话、手机(手工填写)

3

登记时间

生成问题记录的时间(系统自动生成)

4

问题来源

参见“问题来源”定义ITSS考试

5

问题优先级

参见“问题优先级”定义

6

应用系统

参见“应用系统”定义

7

问题分类(与事件管理一致)

参见“问题分类”定义

8

问题标题

简单描述问题(手工填写)

9

问题描述

详细描述问题内容(手工填写)

10

问题拒绝原因

详细描述拒绝问题原因,并推荐其他专家或专家组(手工填写)
【非必填项】

11

变通方法

详细记录问题的变通方法
【非必填项】

12

问题原因

详细记录问题产生的根本原因(手工填写)
【非必填项】

13

重复问题标记

标记为重复问题,并且在系统中与相关问题做关联
【非必填项】

14

问题状态

参见“问题状态”定义

15

分配对象

将问题分配到问题处理专家(手工选择)

16

问题日志

反映问题处理过程中问题信息项的变化历史,包括分配的人员,状态等信息(系统自动生成)

17

实际开始诊断时间

问题状态更新为“分析中”的时间(系统自动生成)

18

实际诊断结束时间

问题状态更新为“已有解决方案”的时间(系统自动生成)

19

解决方案

问题解决方案的详细描述(手工填写)

20

问题结束代码

参见“问题结束代码”定义

21

问题无法解决原因

解释问题无法解决的原因(手工填写)
【非必填项】

22

关联配置项

记录问题的配置项代码(手工选择)

23

关联的事件单号

记录引发该问题的事件单号(手工填写)
【非必填项】

24

关联的变更单号

记录由问题发变更时,关联的变更单号(手工填写)
【非必填项】

25

问题关闭时间

当问题状态更新为“结束并关闭“的时间(系统自动生成)


对于问题单可以在问题描述域中通过添加附件进行补充说明
【注】:问题信息项的“描述”中
l标注“(系统自动生成)”的信息项,表示由SM自动生成,不可以手工填写或选择;
l标注“(手工选择)”的信息项,表示SM提供选择项,只能由使用者手工进行选择,不可填写;
l标注“(手工填写)”的信息项,需要使用者手工进行填写;
l标注“【非必填项】”的信息项为非必填项,其他的均为必填项;

7.2问题来源
根据问题的不同来源对问题分类如下:
编号

代码

描述

1

事件管理流程

事件恢复服务后提出的问题,以便进行事件的根本原因分析。

例如:某日发生了一起集群无法切换的事件,导致某台主机发生故障后,没有切换到备用主机中去,从而影响了业务,事件的处理人员在采取了手工切换的替代措施后,恢复了服务。
为了分析为什么会发生该事件,以及查看其他的集群是否也存在类似的问题,此时可以提出一个问题记录,以便对该事件根本原因进行分析。

2

维护中提出

在维护中技术专家发现或监控系统发现的问题

1)技术专家在日常维护工作中提出的问题
例如:维护专家在日常维护中发现,目前的数据库版本可能会存在着死锁等方面的问题,此时就可以提出一个问题记录,以便分析。
2)监控系统前瞻性发现问题
例如,监控系统检测到某一台关键主机在某一个时间段,CPU的使用率一直是100%,此时可以提出一个问题记录,以找出问题的原因并解决。

3

趋势分析

分析事件记录找出的问题

1)有明显发展趋势的一类事件
例如:在定期的会议中,对某类的事件进行分析后发现,上周该类型的事件比平常的时候多了30,超过了规定的阀值,这表明该系统有可能存在着一些潜在的隐患,此时就可以提出一个问题记录,以找出问题的原因并解决。
2)已发生的多个有共同征兆的事件
例如:发生多起网络不能连接的事件,当时都采用临时措施解决了,此时就可以提出一个问题记录,以找出问题的原因并解决。

7.3问题优先级
问题的优先级是问题处理专家解决问题的参照标准,对于关键优先级的问题,管理层应该优先协调资源进行这些问题的解决。结合广州地铁的实际情况,问题的优先级定义如下:
编号

代码

描述

1

关键

维护专家提出或趋势分析产生的问题从如下方面考虑,问题是否:
l紧迫程度最高(如:必须马上着手处理)(按照关键业务和影响范围考虑紧迫程度)
l资源现状ITSS认证
l问题处理后可大幅节省投资、人力,有效提高服务质量和维护效率

2

重要

从如下方面考虑,问题是否:
l紧迫程度较高(按照关键业务和影响范围考虑紧迫程度)
l资源现状
l问题处理后可有效节省投资、人力,一定程度提高维护质量

3

普通

从如下方面考虑,问题是否:
l紧迫程度低(按照关键业务和影响范围考虑紧迫程度)
l资源现状
l问题处理后对维护质量和效率的提升有限



7.4问题状态
为了记录问题处理的生命周期,需要设置不同的状态加以描述,如下所示:
编号

代码

描述

1

已登记

问题登录到系统中

2

分析中

问题处理专家正在分析问题过程中

3

已定位原因

问题根本原因已找出

4

已有解决方案

解决方案已找到

5

已提出变更请求

已提交变更请求(RFC)

6

已回顾

已经对问题进行了回顾

7

结束并关闭

问题结束


7.5应用系统
根据现有应用系统业务情况进行定义,当问题发生时,可以初步定位到是哪个系统出现问题。
类别

子类

已委托运维类系统

SPS平台

IT运维系统

办公自动化系统

合同管理系统

档案管理系统

P3E

统一通讯平台

视频会议系统

基建物流管理系统

人力资源管理系统

财务管理系统

运营物流管理系统

企业内部门户

工程设计管理系统

内部专家评标系统

内部网站

交流园地

WCM

外部网站

内部网站后台

外部网站后台

外部网站招聘管理

外部网站招投标管理

资产标识码系统

企业统计报表系统

运营日报

MAXINMO系统

施工调度管理系统

运营调度命令发布系统

票务管理系统

工作证管理系统

车站收益系统




7.6
问题分类(与事件管理一致)
问题分类是针对问题所属的专业类型进行划分的,通过问题分类可以定位解决问题的人,并针对问题分类进行分类统计。
问题的分类层次设计不超过三层,第一级分类,称之为“类别”,第二级分类,称之为”子类”,第三级分类,称之为”条目”。

类别

子类

条目/供应商

第三方



ITSS培训

其他







7.7问题结束代码
为了表明问题的不同解决方式,定义如下结束代码:
编号

代码

描述

1

根本解决

找出问题的根本原因,并得到解决方案,成功解决

2

变通方法

没有根本解决方案或目前没有办法实施根本解决方案,但有临时解决方案作为变通方法

3

无法解决

未找到问题的根本原因,没有解决方案,或目前无法实施解决方案,也无变通方法

4

取消

问题被拒绝、问题误报等






本帖关键字:ITSS




上一篇:问题管理的角色和ITSS人员要如何合理的对应
下一篇:用矩阵表来看问题管理流程同ITSS其他流程的关系
monicazhang

写了 2297 篇文章,拥有财富 12859,被 21 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

Powered by IT 运维管理
返回顶部