问题管理程序方案.doc

《问题管理程序方案.doc》由会员分享，可在线阅读，更多相关《问题管理程序方案.doc（7页珍藏版）》请在麦多课文档分享上搜索。

1、 1.1 目的 主动识别 、处置对 IT 服务造成影响的因素或潜在 原因， 以 减少对 IT 服务运营 的影响。 1.2 适用范围 适用于公司通过对问题原因的识别、分析 及 管理，最小化对业务影响的服务管理活动。 1.3 术语表 问题： 引发一个或多个事件的未知因素。 问题通常具有如下特征： 一组具有一定关系的已结束的事件 一个重大事件 问题的根本原因找出后即成为已知错误；许多事件往往是有一个问题引起的。 问题管理流程的输出有 ： 变更请求 变通方法 预防性措施 已知错误： 查明事件原因并且已有临时、应急处理措施的问题。 主动问题管理： 通过改进基础设施以 及提出变更请求来阻止可避免事件的发生

2、。 通过找出基础设施中的薄弱环节来阻止事件的再次发生，以及提出消除这些薄弱环节的建议。 分析基础设施的运行趋势并找出那些潜在事件以防止其发生。 1.4 问题分类 由于用户提供信息的不完整，可能导致开始的分级 /分类 与 最终的分级 /分类有很大的差别。 1.4.1 分类 问题的分类，原则上与事件的分类相一致。 编号 一级分类 二级分类 描述 1 合同服务 视讯系统 包括视频会议、视频监控系统线路及外围设备 网络 PC 终端 PC 服务器 小型机 存储系统 应用软件 公司自主开发软件或由公司提供服务的第三方软件 基础设施 电源、空调、门禁、 KVM 2 工程售后 视讯系统 全球眼 网络 PC 终

3、端 PC 服务器 小型机 存储系统 应用软件 基础设施 3 公司资产维护 硬件送修 PC 机 网络 前端应用系统 公司协同办公、 MIS 系统服务 4 业务咨询 5 单次收费服务 1.4.2 分级 给问题分配优先级，以保证支持组对问题必要的重视。分级应基于是问题的紧急程度和影响面 。 问题的严重程度定义如下。 问题的分 级 ，原则上与事件的分 级 相一致。 事件级别 级别定义 影响业务范围 影响业务程度 业务修复紧急程度 一级事件 客户业务中断，无法工作 80%以上客户业务受影响 非常紧急 二级事件 客户业务性能严重下降 50%以上客户业务受影响 紧急 三级事件 客户业务性能下降 20%以上客

4、户业务受影响 普通 四级事件 问题请求，业务性能无下降 客户业务可能有潜在影响 与客户协商确定 1.5 问题状态分类 为方便问题状态的跟踪和查询，对问题状态 定义如下。 编号 状态 描述 1 已登记 问题已进行登记 2 处理中 问题正在处理过程中 3 拒绝 问题分派被拒绝 4 已知错误 问题根本原因已找出 5 RFC 已提交 变更请求 (RFC) 6 结束 问题已结束 7 没有解决 问题没有解决 1.6 引用文件 【 1】 ISO/IEC 20000 【 2】 IT 服务管理手册 2 流程图 4 . 2 问 题 的 分 类4 . 2 问 题 的 确 定 和 记 录4.6问题跟踪和监控4 . 4

5、 R F C 以 及 对 事 件 的临 时 修 复4 . 3 问 题 的 调 查 和 诊 断4 . 5 问 题 关 闭4 . 4 变 更 控 制R F C( 必 要 时 ）变 更 成 功 实 施3 具体内容 3.1 问题来源 3.1.1 服务部负责在生产系统日常维护过程中问题的记录和监控，问题的来源主要有： 3.1.1.1 事件没有得到解决，需要升级为 问题进行进一步分析处理时，应创建问题。 3.1.1.2 事件虽然得到解决，但可能存在未知错误时，应创建问题。 3.1.1.3 重大事件，无论是否得到解决，为防止再次出现，应创建问题。 3.1.1.4 在事件分析报告中提出的存在趋势或潜在隐患的可

6、能问题，例如事件类型或数量的趋势分析存在问题。 3.1.1.5 对基础设施和服务的主动性问题检查。 3.1.1.6 供应商提供的已知产品缺陷、已知错误。 3.1.2 与信息安全有关的安全事件或安全风险也应作为问题来管理。 3.2 问题 的接收记录和分类 3.2.1 对出现的问题，项目经理负责收集、识别，并填写问题记录表。其中应包括： 3.2.1.1 问题 编 号 。 3.2.1.2 记录日期和时间 。 3.2.1.3 记录人。 3.2.1.4 问题来源 。 3.2.1.5 问题类别。 3.2.1.6 症状描述和任何错误代码 。 3.2.1.7 已经产生的影响或可能导致的影响等级。 3.2.1.

7、8 问题处理进程的状态 。 3.2.2 问题的分级 /分类 3.2.2.1 在接受和记录 问题 之后，服务台首先根据 1.4 的问题分级分类准则， 对受理的 问题 进行分级和分类以方便后续的监视和报告。 3.2.2.2 在问题进行分级 /分类后，项目经理将问题转给相应的专项工程师。 3.3 问题调查和诊断 3.3.1.1 专项技术工程师根据判断发现问题应该由其他组分析解决，将问题处理报告发回技术经理，注明拒绝理由并推荐组名。 3.3.1.2 如果问题确应由本人或本小组解决接受分派的问题，在调查诊断问题后，如有必要成立问题分 析小组，举行问题根本原因分析研讨会议并确定问题的潜在原因。必要时更新问

8、题状态。 3.3.1.3 如找到根本原因的得以确定，将问题转化为已知错误。 3.4 变更请求（ RFC）及临时措施 3.4.1 专项技术工程师找出问题的根本原因后，根据实际情况制定变通方法或根本性解决方案，并确保这些方法或方案将降低或消除问题的发生率或影响度，更新问题记录。 3.4.2 技术组组长根据专项技术工程师提交的解决方案或变通方法决定是否需要进行变更，进入问题关闭，否则提交变更申请。 3.5 问题关闭 3.5.1 变更结束后（如果有变更），确认问题已经解决，根据是否需要问题回顾选择相应的结束状态，更 新问题状态，关闭问题记录。负责处理问题的工程师向项目经理提交问题处理报告。 3.5.2

9、 对于重大问题，进行问题回顾，找出可能改进的机会，包括问题的解决方案和管理流程方面 ,如改进升级规则、改进事件监测、找出技能差距和文档资料改进等。负责处理问题的工程师向项目经理提交问题处理报告。 3.6 问题的评价和监控 3.6.1 项目经理在问题解决后，负责监控、评价和反馈问题解决的绩效，在问题处理报告单上填写问题跟踪表记录。如仍存在问题，应重新填写问题处理报告，按原流程提交处理；如问题已解决，应及时检查原问题处理报告相关内容完整性，关闭问题。 3.6.2 对暂时无解决方案的问题，项目经理负责组织对问题发展趋势的跟踪和监控，及时了解问题的影响及风险，视对 SLA 的影响情况组织对问题重新分析，并按原处理流程执行。 3.6.3 问题在得到解决后，专项工程师应及时更新问题知识库；对涉及配置项的变更，专项工程师应在问题解决后及时更新；对涉及质量标准的变更，项目经理组织更新有关的质量标准和流程文件。 3.7 分析和评估报告 3.7.1 服务部负责监控生产系统日常的运营，拟制服务月报，并将报告提交事业部总监审批。其中与问题相关的内容应包括： 3.7.1.1 问题分类、数量及性质 。 3.7.1.2 对业务的影响 。 3.7.1.3 解决成本 。 3.7.1.4 重大问题分析 。 3.7.1.5 改进措施 。