问题管理流程

1、ITIT 服务管理体系服务管理体系 问题管理流程 文件编号：文件编号： ITSS-15-04ITSS-15-04 版本版本/ /版次：版次： V1.0V1.0 生效日期：生效日期： 2019.6.12019.6.1 制订制订审核审核批准批准 版本历史记录版本历史记录 版本生效日期修订内容制订者审核人批准人 目目 录录 1.目的 .4 2.范围 .4 3.名词术语 .4 4.问题状态定义 .4 5.问题来源 .5 6.问题的分类.5 7.问题分级 .5 8.问题处理原则 .7 9.问题升级处理 .8 10.流程角色.8 11.流程.10 11.1 问题管理流程.10 11.2 问题导入知识库机制

2、.12 12.审核.12 13.关键绩效指标（KPI）.12 14.问题管理和其它流程关系.12 15.参照文件.13 1.目的 本规范的目的是消除或减少运维过程中事件发生的数量和严重程度，防止相同事件的再 次发生，从而为客户建立一个稳定的 IT 环境，提高 IT 服务的可用性。 问题管理包括主动性问题管理和被动问题管理两类活动。前者的目标是通过找出基础设 施中的薄弱环节来阻止事件再次发生，以及提出消除这些薄弱环节的建议；后者的目标是找 出导致以前发生事件的根本原因，以及提出解决措施或纠正建议。 2.范围 应用于公司所有 ITSS 运维服务与问题相关的活动。 3.名词术语 问题：造成一个或多个

3、事件的根本原因。 注：问题的根本原因在问题创建通常是未知的，问题管理过程就是负责探寻这些未知。 4.问题状态定义 为方便问题状态的跟踪和查询，对问题状态定义如下。 编号状态描述 1处理中问题正在处理 2待签收问题等待处理人签收 3已关闭问题流程已经结束 4待确认问题处理完成，等待结果确认 5已撤销问题已经被撤销 6搁置中问题进入搁置状态 7搁置请求审批中问题处理人申请搁置等待审批 5.问题来源 问题的来源主要有： 事件没有得到解决，需要升级为问题进行进一步分析处理时，应创建问题； 事件虽然得到解决，但还可能存在未知错误时，应创建问题； 重大事件，无论是否得到解决，为防止再次出现，应创建问题；

4、在事件分析报告中提出的存在趋势或潜在隐患的可能问题，例如事件类型或数量的趋势 分析存在问题； 对基础设施和服务的主动性问题检查； 供应商提供的已知产品缺陷、已知错误； 与信息安全有关的安全事件或安全风险也应作为问题来管理。 6.问题的分类 问题分类公司应根据实际情况对问题进行分类，本公司目前依据运维对象依据事件类型 进行分类，问题的分类参照事件的分类方法进行，包括：故障类问题、信息安全类问题和询 问性的问题三大类，问题涉及到的运维服务范围包括： 1、网络运维服务； 2、主机运维服务； 3、存储运维服务； 4、基础软件运维服务。 运维问题分类代码要和来源事件的编码进行关联，以便跟踪问题产生的根本

5、原因，从而 获得有价值的信息。 7.问题分级 问题级别 优先级是问题管理的一个关键要素，优先级决定处理问题的顺序及所需的资源。在 运维 服务中，问题优先级可分为五级：S1（紧急，即：最高）、S2（高）、S3（中）、S4（低） 。为方便服务支持对于问题优先级的判断，建议从问题影响程度和问题紧急程度两维来进行 优先级定位。 问题的影响程度主要是对事件发生的关键程度以及问题发生后的影响范围综合考虑得出。 在运维业务中，要考虑以下几个方面： 受影响用户数量和范围 紧急程度 业务重要性 相关用户部门 相关用户职位 表 1 问题影响程度 类别级别备注 高中低 影响程度 信息系统中发生 的已经影响或者 即将

6、影响 24 小时 的业务运行 信息系统中发生 的已经影响或者 即将影响 8 小时 的业务运行 信息系统中发生 的已经影响或者 即将影响 4 小时 的业务运行 从影响客户 的数量方面 进行分类 问题的紧急程度主要由问题本身是否涉及关键业务系统来进行判定，如问题涉及关键业 务系统，则认为紧急程度较高，需要尽快恢复；如问题不涉及关键业务系统，则认为紧急程 度较低，可优先处理紧急程度较高的问题。在 运维业务中，问题紧急程度定义具体如下： 表 2 问题紧急程度 类别级别备注 紧急高中低 紧急程度 客户关键核心 业务无法使用； 信息安全事件 客户关键核心 业务受影响 客户普通业务 受影响 客户业务可能 有

7、潜在影响 从业务影 响程度进 行分类 结合问题发生时的影响程度和紧急程度，可以通过下表确定问题的优先级： 表 3 问题优先级矩阵 影响度 问题优先级 高中低 1-紧急 S1S2S3 2-高 S2S3S4 3-中 S3S4S4 紧急度 4-低 S3S4S5 服务台在创建工单时可结合其他因素确定实际优先级别。 8.问题处理原则 处理问题的原则是尽可能消除对业务的影响； 问题管理流程必须包括管理服务事件影响的步骤，比如评估影响、沟通、提供变通方案 等,使消除问题对客户业务活动的影响，并按问题目标解决要求进行外理问题。 问题目标解决时间 问题目标时间问题目标时间 问题被分派并得到问题被分派并得到 接受

8、接受 问题找到根本原问题找到根本原 因因 问题找到解决方案问题找到解决方案问题单关闭问题单关闭 S1 1 工作日2 工作日4 工作日 N/A S2 1 工作日3 工作日6 工作日 N/A S3 1 工作日5 工作日10 工作日 N/A S4 2 工作日10 工作日20 工作日 N/A 9.问题升级处理 当问题未能或预计未能按照服务等级协议（SLA）的要求，得以修复时，将按照预定的 时间表自动（或由服务台）发起问题升级。另当，用户或支持队伍认为有必要时，可以要求 发起问题升级。 表 5 问题升级时间表 问题升级机制 问题专家 问题经理 技术总监 S1 N/A 2 工作日 4 工作日 S2 N/A

9、 3 工作日 6 工作日 S3 N/A 5 工作日 10 工作日 S4 N/A 10 工作日 20 工作日 10. 流程角色 角色职责职能岗位 运维服务 经理 开发和维护问题管理流程 提供管理信息并运用这些信息主动预防问题的发生 确保和外部供应商等其他角色的有效合作 获取问题管理流程各项活动所需的资源 进行事后检查或组织重大问题审查 分析和评价主动问题管理活动的有效性 识别问题管理过程中存在的问题并提出改进措施 定期编写问题报告 技术部经理 问题提交 人 负责问题确认、记录、分级及跟踪 确保所有相关问题信息都被正确登记 对登记的问题进行分类 负责根据问题解决方案实施 运维项目经理 问题分析 员

10、 （二线、 三线） 接收由问题经理派发的问题。 确认问题的分类和关联配置项。 通过详细分析确认问题根源。 提出问题的解决方案。 识别问题发展趋势。 防止问题扩散到其他系统。 必要时提交变更请求。 参与问题解决。 各部门参与问题 分析与解决的人 员 二线：技术专家 团队 三线：供应商和 研发团队 11. 流程 11.1 问题管理流程 问题管理流程 问题分析 员 问题经理问题提交人 开始 1 确认问题 2 记录问题信息 3 问题分类/ 分级 4 分析、确认问题 根源，提出解决 方案，参与问题 解决 6 跟踪问题 7 问题关闭 及后续处 理 结束 5 解决问题 活动描述责任人输入输出 1 问题确认用

11、户事件产生的问题； 运行工程师巡检发现的问题； 现场工 程师 事件记录 巡检报告 提出问题 2 记录问题信 息 服务台记录问题及用户基本信息。 服务台提出的问题 问题记录 3 问题分类/分 派 服务台人员参考目前问题分类、 分级标准对该问题进行分类/分级； 服务台人员将问题派发给问题分 析员； 服务台问题记录已分类及 分派的问题 活动描述责任人输入输出 4 解决问题分析记录的问题信息； 确认问题的根源； 提出问题的解决方案； 根据方案解决问题。 问题分 析员 运维工 程师/技 术支持 工程师 含有分类及 准确信息的 问题记录 问题解决 方案 5 跟踪/关闭问 题 跟踪问题的解决情况； 服务台在

12、用户认可后关闭问题记 录。 服务台已解决的问 题记录 已关闭的 事件记录 6 问题后续处 理 流程经理在问题关闭后检查； 生成问题报告并根据需要转向其 他流程。 问题经理关闭问题后，根据解 决方案判断是否需要更新知识 库 运维服 务经理 已关闭的记 录 定期事件报 告 相关知识 定期事件 报告 需要提交 其他流程处 理的问题记 录 总结的 知识 活动描述责任人输入输出 更新的 知识库 11.2 问题导入知识库机制 问题经理关闭问题后，根据解决方案判断是否需要更新知识库；若需要则由问题经理负 责将问题描述和问题解决方案在知识库中更新，必要时组织相关人员培训。 12. 审核 技术部定期对问题管理全流程进行审核。 13. 关键绩效指标（KPI） 问题解决率60%，（已解决的问题数量/问题总数）*100%。 14. 问题管理和其它流程关系 问题管理与其它流程关系图 问题管理 事件管理 知识管理 由事件产生 的问题 变更管理 解决方案