问题管理流程的执行原则和重要的ITSS信息项
20150722淡然
续上8.2流程执行原则8.2.1流程常规原则
q信息与知识管理部所支持的操作环境中，所有对IT服务有影响的问题都会通过问题管理流程处理；处理过程将通过流程中定义的标准、政策和指导进行管理。
q所有报告问题的用户/部门将会参与统一的问题管理流程，不应该有任何例外。
q应该定期产生和回顾问题管理报表。对没有解决的问题，应该举行定期的管理会议对这些问题进行评估。
q应该定期对流程进行回顾，以改进问题及知识管理流程。ITSS认证
8.2.2责任制原则
q当一个问题被创建后，问题经理对问题单负责；
q当问题单被分派后，问题分析员对该问题单负责；同时分派方有责任通过电话通知被分派的问题分析员，并要求问题分析员接受或拒绝此问题单。
8.2.3问题分派原则
问题分派原则是确保问题在服务目标时段内处理和解决的重要因素。
关于对问题的分派：
q问题的分派是由问题经理经过评审确认后，分派给问题分析专家，由被分派任务的问题分析专家来对故障的潜在原因进行调查、诊断及解决。
q问题单需要多人或组同时处理时，通过分派协查任务单的方式进行。
q问题经过问题分析专家调查查明根源后，寻找解决方案或变通方法，如果找到，则把相应的解决方案/变通方法提交给问题经理进行评审。
q问题的解决方案可能需要发起一个变更请求来彻底解决该问题时，那么就要触发变更管理。由变更管理负责问题的解决并将解决后的结果反馈给问题管理。
q问题解决后，可根据问题的具体情况触发知识管理流程。根据问题的根源、解决方案等信息创建相应的知识条目，提高后期事件/问题处理的准确性及时效性。
q在系统上线后，问题管理可以通过系统平台的特征来完成问题单的首派及重派，实现每派一笔问题单就有一笔记录。
8.2.4问题重分派原则
q重分派又称转派，指问题第一次被分派后，由被分派对象将问题单返回问题经理并再分派给其他合适的问题分析专家。
q当问题分析专家收到被分派问题后，如果该问题不属于本人支持范围或者自身能力无法处理时，在进行分派时，可直接分派到人，也可分派到组。
q为提高问题解决效率，规定问题单重分派次数不得超过三次。
8.2.5重复/复发/重开问题原则
q如果被报告的问题与某个已经创建且尚未解决的问题单症状相同，则该问题被认为是重复的，标记为重复；原则上不对重复的问题单独创建新的问题单。所谓的问题症状相同则是指同类设备上症状描述相同的，问题经理可通过关键字判断。
q如果报告的问题与已经关闭的问题相同，该问题被认为是“复发”的问题单。这意味着为了解决问题而采取的解决措施失败了。此时应当创建一个新的问题单，复制原始问题单的内容，并说明这是复发的问题。所谓的问题相同则是指同类设备上症状描述相同的，问题经理可通过关键字判断。
q已关闭的问题单原则上不允许重新打开。如果问题复发，则创建一个新的问题单，并复制原始内容到新创建的问题单中。
q只有问题经理才有权重新打开问题单，并有权修改相关信息。
8.2.6问题关闭原则
q只有问题经理才有权关闭问题单。
q问题单在关闭前，必须填写关闭代码
q问题单不允许自动关闭
q已关闭的问题单不允许重新打开。
8.2.7主动发现问题原则
问题经理需要安排人员进行主动巡检和事件报表分析以主动发现需要讨论的问题。在某公司的问题管理流程中，我们建议通过以下方式来主动发现问题：
q各系统管理员每天对所负责系统进行巡检；
q各系统管理员每月底对所负责系统的事件月报表进行分析，并据此提交分析报告；
q服务台人员每周做一次事件报表分析并提交分析报告；
q每年由各系统管理员牵头对系统相关配置数据进行分析。ITSS考试
8.3流程相关定义
8.3.1问题信息项
问题单通常包含如下主要信息项，集团可以根据自身的情况在此该信息项上进行扩充或删减：
序号 | 信息项 | 说明 |
1 | 问题ID | 为每个问题分配一个唯一的序列号（系统自动产生） |
2 | 请求人信息 | 问题请求人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写） |
3 | 登记时间 | 生成问题记录的时间（系统自动产生） |
4 | 地点 | 记录问题发生的地点（手工填写） |
5 | 问题来源 | 参见“问题来源”定义 |
6 | 事件影响度 | 参见“问题紧影响程度”定义 |
7 | 事件紧急度 | 参见“问题紧急程度”定义 |
8 | 问题优先级 | 参见“问题优先级”定义 |
9 | 问题分类 | 参见“问题所属系统类型”定义 |
10 | 问题标题 | 简单描述问题（手工填写） |
11 | 问题描述 | 详细描述问题内容（手工填写） |
12 | 问题原因 | 详细记录问题产生的根本原因（手工填写） |
13 | 重复问题标记 | 标记为重复问题，用已有标题号标注（手工填写） |
14 | 问题状态 | 参见“问题状态”定义 |
15 | 问题经理 | 问题经理 |
16 | 受理组 | 将问题分配到问题处理专家组（手工填写） |
17 | 受理人 | 将问题分配到各问题处理专家（手工填写） |
18 | 问题日志 | 反映问题处理过程中问题信息项的变化历史，包括分配的人员，状态等信息（系统自动产生） |
19 | 实际开始诊断时间 | 问题状态更新为“分析中”的时间（手工填写） |
20 | 实际诊断结束时间 | 问题状态更新为“已有解决方案”的时间（手工填写） |
21 | 解决方案 | 问题解决方案的详细描述（手工填写） |
22 | 问题等待代码 | 参见“问题等待代码”定义 |
23 | 问题结束代码 | 参见“问题结束代码”定义 |
24 | 备注项 | 解释问题拒绝原因，无法解决的原因等 |
25 | 关联配置项 | 记录问题的配置项代码（手工填写） |
26 | 关联的事件单号 | 记录引发该问题的事件单号（手工填写） |
27 | 关联的变更单号 | 记录由问题发变更时，关联的变更单号（手工填写） |
28 | 问题关闭时间 | 当问题状态更新为“结束并关闭”的时间（手工填写） |
29 | 附件 | 附件 |
8.3.2问题来源
问题来源代码用来标明问题的提出方式，问题来源可以包括以下几种：ITSS认证
编号 | 代码 | 描述 |
1 | 事件触发 | 1.紧急事件恢复服务后关联提出的问题，以便进行紧急事件的根本原因分析 【例如】：某日发生了一起集群无法切换的事件，导致某台主机发生故障后，没有切换到备用主机中去，从而影响了业务，紧急事件的处理人员在采取了手工切换的替代措施后，恢复了服务 2.为了分析为什么会发生该紧急事件，以及查看其他的集群是否也存在类似的问题，此时可以提出一个问题记录，以便对该紧急事件进行分析 |
2 | 运维工作 | 二线支持在日常维护工作中提出的问题 【例如】：维护专家在日常维护中发现，目前的数据库版本可能会存在着死锁、心跳不一致等方面的问题，此时就可以提出一个问题记录，以便分析 |
3 | 趋势分析 | 分析事件记录找出的问题 【例如】：在定期的会议中，对某应用系统操作咨询类的事件进行分析后发现，上一阶段该类型的事件比平常的时候多了30％，超过了规定的阀值，这表明该应用系统操作有可能存在着一些潜在的隐患，此时就可以提出一个问题记录，以找出问题的原因并解决 |
4 | 变更触发 | 变更失败后，可能需要生成一个问题进入后续的解决过程 |
3. | ||
8.3.3问题分类
问题分类代码用于标识潜在问题的具体原因。当问题发生时，先由问题发起人做出初步分类，提交问题经理参考分派给相应的问题分析专家；问题分析专家接受分派后，再对潜在问题做进一步分类，需进行良好的分析与定位，一方面便于与以往问题或者知识库的信息匹配，另一方面也便于以后有针对性的选择问题分析专家进行潜在问题解决的任务分配。问题最终分类可由问题经理作进一步的确认，并在问题关闭前进行调整。
问题的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为“子类”，第三级分类，称之为“条目”。
详细分类与事件分类一致；
8.3.4问题优先级
优先级是问题管理的一个关键要素，优先级决定了问题处理的顺序。在本次项目中，问题优先级可分为四级：极高、高、中、低。为了方便服务台人员判断事件优先级，咨元建议从问题的影响程度和问题紧急程度两个维度来确定优先级。
问题的影响程度主要是对问题发生影响的关键程度以及问题发生后的影响范围综合考虑得出的。在本项目的影响度判断中，要考虑以下几个方面：
q用户身份；
q受影响的用户数量和范围；
q受影响设备；
q受影响系统。
具体影响程度的定义如下：
影响程度 | 广泛/普遍 | 极大/大型 | 适度/受限 | 次要/本地化 |
描述 | 重大的应用停机，影响很大数量的用户和业务单位。 关键业务不能运行。 | 应用的使用受到重大限制；系统性能严重下降。 | 影响一小部分用户，属于一般性故障。 | 不直接影响生产，或是存在变通的方式。 |
问题的紧急程度主要是以用户能容忍的问题解决时间来进行判定，按照此规则，问题紧急程度定义具体如下：
紧急度 | 紧急度时间标准 | 备注 |
严重 | ||
高 | ||
中等 | ||
低 |
结合问题发生时的影响程度和紧急程度，可以通过如下表确定问题的优先级：
严重等级 | 影响程度 | ||||
广泛/普遍 | 极大/大型 | 适度/受限 | 次要/本地化 | ||
紧急度 | 极高 | 极高 | 极高 | 高 | 中 |
高 | 极高 | 高 | 中 | 中 | |
中 | 高 | 中 | 中 | 低 | |
低 | 中 | 中 | 低 | 低 | |
8.3.5问题目标解决时间
为了更好的控制问题的解决，整个流程被分解成几个组成部分。每个流程的阶段都设定了目标时间。问题的目标时间与事件的明显不同，这是由于两个管理流程目标不同决定的，通常事件比问题的目标时间更严格。
问题得到响应 | 问题得到解决 | 问题得到关闭 | |
严重等级1 | 1D | 3D | 8H |
严重等级2 | 1D | 3D | 1D |
严重等级3 | 2D | 4D | 2D |
严重等级4 | 3D | 5D | 4D |
8.3.6问题状态
问题状态代码表明问题所处的处理状态，问题状态如下：
代码 | 描述 |
New（新建） | 一个问题被记录或创建 |
Assigned（已分配） | 一个问题已被分派给问题分析员或问题经理 |
Pending（等待中） | 问题信息不完整，或在某些情况下阻止问题分析员对问题进行处理，进入等待 |
WorkinProgress（处理中） | 一个问题分析员接受了问题，并正在处理 |
Resolved（已解决） | 为一个问题找到解决方案或变通方法 |
Closed（已关闭） | 问题已经关闭 |
8.3.7问题关闭代码
问题关闭代码说明了问题是在何种情况下关闭的，结束代码如下：
代码 | 描述 |
成功解决 | 问题被正常解决 |
变通解决 | 问题已通过变通方法解决，但需要进行更进一步的根源分析 |
解决失败 | 问题的解决方案或变通方法失败，不能解决这个问题 |
问题撤销 | 问题经理撤销问题单 |
8.3.8问题等待代码
问题等待代码说明了问题是在何种情况下等待的，等待代码如下：ITSS培训
代码 | 描述 |
等待进一步的信息 | 需要等待获取更多信息 |
等待变更管理处理 | 等待变更流程处理 |
等待分析会议结果 | 等待问题分析会议得出的结论 |
由于不可抗力 | 由于灾难、气候条件、交通条件等不可抗因素 |
等待其他信息 | 等待其他厂商/供应商处理 |
等待业务领导批复 | 等待业务部门领导批复 |
待续
本帖关键字：ITSS