问题关系管理程序.docx

《问题关系管理程序.docx》由会员分享，可在线阅读，更多相关《问题关系管理程序.docx（11页珍藏版）》请在优知文库上搜索。

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

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

3、统公司协同办公、MIS系统服务4业务咨询5单次收费服务1.4.2 分级给问题分配优先级，以保证支持组对问题必要的重视。分级应基于是问题的紧急程度和影响面。问题的严重程度定义如下。问题的分级，原则上与事件的分级相一致。级别定义事件级别影响业务范围影响业务程度业务修复紧急程度一级事件客户业务中断，无法工作80%以上客户业务受影响非常紧急二级事件客户业务性能严重下降50%以上客户业务受影响紧急三级事件客户业务性能下降20%以上客户业务受影响普通四级事件问题请求，业务性能无下降客户业务可能有潜在影响与客户协商确定1.5 问题状态分类为方便问题状态的跟踪和查询，对问题状态定义如下。编号状态描述1已登记问

4、题已进行登记2处理中问题正在处理过程中3拒绝问题分派被拒绝4已知错误问题根本原因已找出5RFC已提交变更请求(RFC)6结束问题已结束7没有解决问题没有解决1.6 引用文件1ISOIEC200002IT服务管理手册2.1 技术组组长2.1.1 根据服务台提供的信息找出问题，与专项工程师一起探讨发现IT系统基础平台中存在的技术问题。2.1.2 确定并协调必要资源来处理所有（潜在）影响服务级别的所有类型问题，最小化问题的负面影响。2.1.3 领导专项技术小组，制定清晰有效的工作流程和准则，确保员工的积极性、技能水平和绩效表现。2.1.4 发现造成问题的可能原因，将问题分派给有能力将其解决的IT职能

5、部门。2.1.5 跟踪问题解决的过程，必要时进行升级以及问题升级后的协调工作。2.1.6 将关键问题的解决状态及时地通报给事业部管理层。2.1.7 提出变更请求来消除事件和问题的根本原因。2.1.8 确保使事件发生时把它的影响降到最小，同时确保根除事件的根本原因从而防止事件的再次发生。2.1.9 与内部和外部支持部门就问题的解决方案和防范进行讨论，并确保与他们的良好关系。2.1.10 通过对历史和现有环境的有效分析以确保IT服务的主动性。2.1.11 提供关于IT服务和客户支持的正确有效的管理信息，生成有效的管理报表。2.1.12 确保所有相关人员都足够程度地引入到问题管理的流程中。2.2 专

6、项技术工程师2.2.1 通过在某一方面的专业知识和技能（网络或应用）来支持事件管理的一线工程师和技术组组长，确保事件的快速解决和IT服务的快速恢复。2.2.2 接受来自问题管理经理分派的问题。2.2.3 基于影响度/优先级和分类代码执行问题分析,在规定的时间范围内调查可能的事件根本原因，测试解决方案，同时确保问题得以解决。2.2.4 在需要时请其它技术专家介入，以确保问题得以及时解决。2.2.5 协调变更管理功能，实施解决方案2.2.6 不但使事件发生时把它的影响降到最小，也使用根除事件的根本原因从而防止事件的再次发生。2.2.7 利用现有IT环境分析历史数据来改善IT系统和工作方法从而避免潜

7、在问题的发生。2.2.8 在必要时修正事件或问题的影响度和分类编码。2.2.9 在需要时与外部供应商作接口。2.2.10 参与升级流程。2.2.11 在服务中断时，尽快提供临时解决方案，帮助客户尽快恢复正常工作状态。4.2问题的确定和记录A4.2问题的分类4.6问题跟踪和监控43问题的调查和诊断4.4RFC以及对事件的临时修复RFC（必要时）4.4变更控制变更成功实施一14.5问题关闭4.1 问题来源4.1.1 服务部负责在生产系统日常维护过程中问题的记录和监控，问题的来源主要有：4.1.1.1 事件没有得到解决，需要升级为问题进行进一步分析处理时，应创建问题。4.1.1.2 事件虽然得到解决

8、，但可能存在未知错误时，应创建问题。4.1.1.3 重大事件，无论是否得到解决，为防止再次出现，应创建问题。4.1.1.4 在事件分析报告中提出的存在趋势或潜在隐患的可能问题，例如事件类型或数量的趋势分析存在问题。4.1.1.5 对基础设施和服务的主动性问题检查。4.1.1.6 供应商提供的已知产品缺陷、已知错误。4.1.2 与信息安全有关的安全事件或安全风险也应作为问题来管理。4.2 问题的接收记录和分类4.2.1 对出现的问题，项目经理负责收集、识别，并填写问题记录表。其中应包括：4.2.1.1 问题编号。4.2.1.2 记录日期和时间。4.2.1.3 记录人。4.2.1.4 问题来源。4

9、.2.1.5 问题类别。4.2.1.6 症状描述和任何错误代码。4.2.1.7 已经产生的影响或可能导致的影响等级。4.2.1.8 问题处理进程的状态。4.2.2 问题的分级/分类4.2.2.1 在接受和记录问题之后，服务台首先根据1.4的问题分级分类准则，对受理的问题进行分级和分类以方便后续的监视和报告。4.222在问题进行分级/分类后，项目经理将问题转给相应的专项工程师。4.3 问题调查和诊断4.3.1.1 专项技术工程师根据判断发现问题应该由其他组分析解决，将问题处理报告发回技术经理，注明拒绝理由并推荐组名。4.3.1.2 如果问题确应由本人或本小组解决接受分派的问题，在调查诊断问题后，

10、如有必要成立问题分析小组，举行问题根本原因分析研讨会议并确定问题的潜在原因。必要时更新问题状态。4.3.1.3 到根本原因的得以确定，将问题转化为已知错误。4.4 变更请求（RFC）及临时措施4.4.1 专项技术工程师找出问题的根本原因后，根据实际情况制定变通方法或根本性解决方案，并确保这些方法或方案将降低或消除问题的发生率或影响度，更新问题记录。4.4.2 技术组组长根据专项技术工程师提交的解决方案或变通方法决定是否需要进行变更，进入问题关闭,否则提交变更申请。4.5 问题关闭4.5.1 变更结束后（如果有变更），确认问题已经解决，根据是否需要问题回顾选择相应的结束状态，更新问题状态，关闭问

11、题记录。负责处理问题的工程师向项目经理提交问题处理报告。4.5.2 对于重大问题，进行问题回顾，找出可能改进的机会，包括问题的解决方案和管理流程方面,如改进升级规则、改进事件监测、找出技能差距和文档资料改进等。负责处理问题的工程师向项目经理提交问题处理报告。4.6 问题的评价和监控4.6.1 项目经理在问题解决后，负责监控、评价和反馈问题解决的绩效，在问题处理报告单上填写问题跟踪表记录。如仍存在问题，应重新填写问题处理报告，按原流程提交处理；如问题已解决，应及时检查原问题处理报告相关内容完整性，关闭问题。4.6.2 对暂时无解决方案的问题，项目经理负责组织对问题发展趋势的跟踪和监控，及时了解问

12、题的影响及风险，视对S1.A的影响情况组织对问题重新分析，并按原处理流程执行。4.6.3 问题在得到解决后，专项工程师应及时更新问题知识库；对涉及配置项的变更，专项工程师应在问题解决后及时更新；对涉及质量标准的变更，项目经理组织更新有关的质量标准和流程文件。4.7 分析和评估报告4.7.1 服务部负责监控生产系统日常的运营，拟制服务月报，并将报告提交事业部总监审批。其中与问题相关的内容应包括：4.7.1.1 问题分类、数量及性质。4.7.1.2 对业务的影响。4.7.1.3 解决成本。4.7.1.4 重大问题分析。5输出的文件和记录文件和记录文件属性完成的部门职位问题处理报告D专项工程师问题记录表D项目经理服务月报D服务部6附录附录A一文件流转表文件名称文件编号拟制审核批准收文人员问题处理报告技术组事业部总监/问题记录表项目组二级部门经理/服务月报服务部事业部总监/