如何定义ITSS问题单的各信息项目
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）已发生的多个有共同征兆的事件 例如：发生多起网络不能连接的事件，当时都采用临时措施解决了，此时就可以提出一个问题记录，以找出问题的原因并解决。 |
问题的优先级是问题处理专家解决问题的参照标准，对于关键优先级的问题，管理层应该优先协调资源进行这些问题的解决。结合广州地铁的实际情况，问题的优先级定义如下：
编号 | 代码 | 描述 |
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