11 XX电信IT服务咨询问题管理规划设计
目录
一、问题管理设计目标
二、问题管理流程
三、问题管理相关表单、规范
四、问题管理角色、职责
五、问题管理考核标准
一、问题管理设计目标
问题管理 -- 目标
- 问题管理流程的根本目的是消除或减少生产环境中事件发生的数量和严重程度,从而为企业建立一个稳定的IT环境,提高IT服务的可用性。
对于XX电信问题管理的主要目标如下:
- 分析并确定故障的根本原因,找到最终解决方案,以防止此类事件再次发生
- 通过问题管理来提高二线支持人员的工作主动性和规范性,提升主动管理能力
- 通过问题管理来发现和集中IT支持能力的提升点,并合理分配IT处理资源
- 通过问题管理来追溯和管理厂商的技术支持工作
问题管理 -- 问题来源
对于问题管理而言,问题的产生主要来自于四个方面:
问题管理流程策略定义
策略 | 描述 |
策略一 | 问题管理覆盖范围与事件管理等同 所有技术支持人员均可参与问题管理流程 |
策略二 | 事件经理和事件分析员可以通过事件创建问题 企信部所有技术支持人员都可以主动建立问题 |
策略三 | 允许各个支持人员相互转派问题,但必须通过问题经理进行 |
策略四 | 需要召集分析会议的问题均由问题经理负责 |
策略五 | 问题单必须由问题经理关闭,问题单不能自动关闭。 |
策略六 | 成功解决的问题,必须形成知识条目 |
二、问题管理流程
问题管理流程概述
问题管理流程步骤概述
问题检测与记录 |
|
问题分类与分派 |
|
问题调查与 诊断 |
|
问题解决 |
|
问题关闭 |
|
步骤一的流程说明:问题识别与记录
步骤二的流程说明:问题分类与分派
步骤三的流程说明:问题调查与诊断
步骤四的流程说明:问题解决
步骤五的流程说明:问题关闭
步骤六的流程说明:问题跟踪与监控
三、问题管理相关表单、规范
问题管理相关表单 -- 问题来源
根据问题的来源不同,可以分为以下的问题来源代码:
编号 | 代码 | 描述 |
1 | 紧急事件 | 紧急事件恢复服务后关联提出的问题,以便进行紧急事件的根本原因分析 【例如】:某日发生了一起集群无法切换的事件,导致某台主机发生故障后,没有切换到备用主机中去,从而影响了业务,紧急事件的处理人员在采取了手工切换的替代措施后,恢复了服务 为了分析为什么会发生该重大事件,以及查看其他的集群是否也存在类似的问题,此时可以提出一个问题记录,以便对该紧急事件进行分析 |
2 | 未解事件 | 故障无法成功解决或者使用变通方式暂时解决,需要找出根本解决方案 【例如】:某应用系统内存经常爆满当机,暂时没有解决方案,只能通过重启临时解决,此时需要提出一个问题记录,找到问题的根源是开发上面的问题还是其他,再驱动根本解决。 |
3 | 运维工作 | 二线支持在日常维护工作中提出的问题 【例如】:维护专家在日常维护中发现,目前的数据库版本可能会存在着死锁、性能下降等方面的问题,此时就可以提出一个问题记录,以便分析 |
4 | 故障分析 | 分析事件记录找出的问题 【例如】:在定期的会议中,对某应用系统操作咨询类的事件进行分析后发现,上一阶段该类型的事件比平常的时候多了30%,超过了规定的阀值,这表明该应用系统操作有可能存在着一些潜在的隐患,此时就可以提出一个问题记录,以找出问题的原因并解决 |
5 | 失败变更 | 变更失败后,可能需要生成一个问题进入后续的解决过程 |
问题分类
问题分类与事件分类同步,原因是: 问题单来源很大程度上来自事件,同步分类有助于完整转述信息 事件管理的“故障现象”和“故障根源”区别的分类方式对于描述问题同样具有很大意义。
分类 | 原则 | 上级分类 |
类别(Category) | 分类原则以能够清晰描述技术条线,从框架角度区分事件为准,如CRM域、计费域、MSS | |
子类(Type) | 分类原则以能够准确定位事件所在系统、设备或者功能单元,指导事件分派到相应处理组为准,且需要兼顾服务台人员的判断能力,如OCS系统 | 类别 |
现象(Item) | 分类原则以能够描述故障现象为准,如计费出错 | 子类 |
根源(Causation) | 分类原则以能够描述故障根源为准,如数据错误 | 子类 |
分类示例表:
类别 | 子类 |
| |
计费域 …… | 计费系统(HB) | 现象 | 通话时长计算出错 |
统一充值系统(VC) | 根源 | 账单计算出错 | |
…… | 数据错误 | ||
配置错误 |
问题分派规范
分派规范 | 描述 |
规范一 | 基于目前管理状况,建议分派问题可以到技能组或岗位 |
规范二 | 可分派的人员组列表将根据问题分类和问题地点信息进行筛选 |
规范三 | 已分派的问题允许再次转派,组间转派到组,组内转派到人 |
规范四 | 再转派问题必须通过问题经理执行 |
规范五 | 组内转派问题不需要通过问题经理,可以直接转派 |
规范六 | 供应商等同于问题分析员,由问题经理直接分派 |
问题严重等级规范
问题的严重等级与事件管理同步,原因如下:
- 问题单来源很大程度上来自事件,同步严重等级的计算方式有助于完整转述信息
- 事件管理的“紧急程度”与“影响范围”交叉计算方式对于描述问题同样具有很大意义。
问题严重等级(优先级)
- 规则一:问题的严重等级由系统根据紧急程度和影响程度自动运算得出
计算规则如下表所示:
严重等级 | 影响程度 | ||||
1级(极高) | 2级(高) | 3级(中) | 4级(低) | ||
紧急程度 | 高 | 极高 | 极高 | 高 | 中 |
中 | 极高 | 高 | 中 | 中 | |
低 | 高 | 中 | 中 | 低 |
问题紧急程度
- - 规则一:问题的紧急程度划分为三级 ---- 高、中、低
- - 规则二:问题紧急程度由用户或服务台按照“用户类型”和“分类”交叉运算得出
- 规则三:没有明确用户类型的问题紧急程度默认为“中”
- 规则四:投诉类事件和升级事件生成的问题紧急度默认为“高”
紧急程度(示例表) | 用户类型 | |||
企业客户 | VIP会员 | 普通会员和客户 | ||
分类(三级) | 计费出错 | 高 | 中 | 低 |
停开机出错 | 高 | 中 | 低 | |
…… | 高 | 中 | 低 |
问题影响程度 :
- 规则一:问题影响程度由问题经理建单时主观定义
- 规则二:问题的影响包括已经造成的或者可能会造成的影响
- - 规则三:事件影响程度定义如下表所示
影响程度 | 极高 | 高 | 中 | 低 |
描述 | 重大的应用停机,影响很大数量的用户和业务单位。 关键业务不能运行。 | 应用的使用受到重大限制;系统性能严重下降。 | 事件影响一小部分用户,属于一般性故障。 | 事件不直接影响生产,或是存在变通的方式。 |
问题目标时间
对于问题管理而言,处理的第一目标是从根本上解决问题,处理效率的考虑并不是最关键的 在这里我们使用“目标时间”来对处理效率进行衡量,主要是两点考虑:
- 督促处理人员不要无限制的延误问题处理
- 督促厂商的问题处理工作(厂商在问题处理中作为问题分析员角色)
超过时间的问题单将执行超时上报
问题得到响应 | 问题单分派 | 问题得到解决 | 问题得到关闭 | |
严重等级1 | 8H | 6H | 3D | 8H |
严重等级2 | 1D | 8H | 5D | 1D |
严重等级3 | 2D | 1D | 10D | 2D |
严重等级4 | 3D | 2D | 20D | 4D |
问题管理相关表单 -- 问题状态
状态代码用于鉴别事件和问题在处理过程中所处的状态。
状态代码 | 描述 |
New(新建) | 一个问题被记录或创建 |
Assigned (已分配) | 一个问题已被分派给问题分析员或问题经理 |
Pending (等待中) | 问题信息不完整,或在某些情况下阻止问题分析员对问题进行处理,进入等待 |
Work in Progress (处理中) | 一个问题分析员接受了问题,并正在处理 |
Resolved (已解决) | 为一个问题找到解决方案或变通方法 |
Closed (已关闭) | 问题已经关闭 |
问题流转状态说明
纵向(左列)为原始状态,横向(上行)为目标状态。
状态 | 新建 | 已分派 | 处理中 | 等待中 | 已解决 | 已关闭 |
新建 | Y | N | N | N | N | |
已分派 | N | Y | Y | N | N | Y |
处理中 | N | Y | Y | Y | Y | |
等待中 | N | Y | Y | Y | Y | |
已解决 | N | Y | N | N | Y | |
已关闭 | N | N | N | N | N |
问题等待代码
- 当处理中的问题由于各种原因进入等待状态时,需要填写等待代码
等待代码 | 描述 |
等待进一步的信息 | 需要等待获取更多信息 |
等待变更管理处理 | 等待变更流程处理 |
由于不可抗力 | 由于灾难、气候条件、交通条件等不可抗因素 |
等待维护性需求处理 | 等待维护性需求处理 |
问题关闭规范
关闭规范 | 描述 |
规范一 | 问题单只能由问题经理关闭 |
规范二 | 问题单在关闭前,必须填写关闭代码 |
规范三 | 问题单不允许自动关闭 |
规范四 | 已关闭的问题单不允许重新打开 |
关闭代码 | 描述 |
成功解决 | 问题被正常解决 |
未发现根源 | 问题无法发现根源 |
解决失败 | 问题的解决方案失败,不能解决这个问题 |
问题撤销 | 问题经理撤销问题单 |
提交需求 | 问题单已提交需求管理流程处理 |
问题通知规范
规范 | 描述 |
规范一 | 在创建问题单后,通知对应的问题经理 |
规范二 | 问题单分派后,通知被分派的问题分析员 |
规范三 | 问题分析员提交转派申请后,通知问题经理 |
规范四 | 问题分析员处理完成,通知问题经理 |
问题管理相关表单 -- 问题记录信息项
问题记录信息项建议(包括但不限于)
序号 | 信息项 | 说明 |
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 | 附件 | 附件 |
四、问题管理角色、职责
问题管理 -- 角色、职责定义
原则:一个人员可以担任多个角色,同一角色也可以由多人担任
问题管理角色 | 主要职责 | 岗位映射 |
流程负责人 | 推动、推广问题管理流程,对流程的整体效果和效率负责。 | |
问题分析员 | 接受问题经理分派过来的问题 分析和诊断问题,确定根本原因 确定和测试解决方案 提交变更请求并监控变更实施 协助事件支持人员进行重大或紧急事件的处理 需要时协调第三方的资源来帮助诊断和改正问题 | 企信部所有技术人员,分为不同领域的各个技能组 各厂商,按照各自负责系统分为各个技能组 |
问题经理 | 领导问题管理小组,确保大家的积极性、技能水平 定期组织相关人员对事件记录进行分析,发现潜在问题 确认和审核问题 必要时对问题进行上报 监视问题的诊断、分析和处理过程 必要时与帮助台及问题请求者沟通问题的相关信息 必要时协调所需资源 定期制定问题报表,提供正确决策信息 | 建议多人担任,分别为各个技术团队的负责人(如各二线处理小组负责人) |
五、问题管理考核标准
问题管理 -- 考核指标
问题管理考核指标如下:
代码 | 状态 | 说明 |
流程 有效性 | 问题总数 | 数量:在问题单中根据以下条件过滤 1. 【重复问题标记】为空 2. 【问题结束代码】不等于“取消” 3. 【登记时间】在统计周期内 |
未解决故障问题所占比率 | 数量:在问题总数中,【问题来源】=“未解事件”的问题数量 比率:数量 / 问题总数 × 100 % | |
故障分析问题所占比率 | 数量:在问题总数中,【问题来源】=“故障分析”的问题数量 比率:数量 / 问题总数 × 100 % | |
关闭问题数量 | 数量:【问题关闭时间】在统计周期内,【问题状态】=“结束并关闭”的问题数量 | |
执行效率 | 问题成功解决率 | 数量:在关闭问题数量中,【关闭代码】=“成功解决”的问题个数 比率:数量 /关闭问题数量 × 100 % |
平均解决时间 | 完成问题数量:【结束时间】在统计周期内的问题个数 平均解决时间:累加完成问题的(【实际结束时间】-【实际开始时间】)/ 完成问题数量 |