本帖最后由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
|