本帖最后由 monicazhang 于 2015-7-8 10:42 编辑
20150708 淡然
目录 1 文档介绍............................................................................................................................... 5 1.1 编写目的................................................................................................................. 5 1.2 适用范围................................................................................................................. 5 2 术语、定义和缩略语.............................................................................................................. 5 3 内容...................................................................................................................................... 6 3.1 流程介绍................................................................................................................. 6 3.1.1 流程解释.......................................................................................................... 6 3.1.2 业务价值.......................................................................................................... 7 3.1.3 流程政策.......................................................................................................... 7 3.1.4 问题单代码设计.............................................................................................. 12 3.2 角色及职责............................................................................................................ 15 3.2.1 角色简介......................................................................................................... 15 3.2.2 问题流程负责人.............................................................................................. 15 3.2.3 问题流程经理.................................................................................................. 16 3.2.4 问题分析专家.................................................................................................. 17 3.3 流程输入及输出..................................................................................................... 18 3.3.1 流程触发条件.................................................................................................. 18 3.3.2 输入................................................................................................................ 18 3.3.3 输出................................................................................................................ 18 3.3.4 流程关闭条件.................................................................................................. 19 3.4 问题管理流程描述.................................................................................................. 19 3.4.1 流程综述......................................................................................................... 19 3.4.2 作业流程图..................................................................................................... 19 3.4.3 流程活动说明.................................................................................................. 21 3.5 流程衡量指标及报表.............................................................................................. 23 4 参考..................................................................................................................................... 24 4.1 相关文件................................................................................................................ 24 4.2 相关表单................................................................................................................ 25
1 文档介绍
1.1 编写目的
本文档描述的内容是依据目前运营总部通号中心IT运维服务部(简称IT运维服务部)的IT运维团队现状而制定的问题管理流程二级文档,其编写的目的是为了有效地解决IT环境的问题隐患,减少或消除事件的发生,提高IT系统和服务的质量,为客户提供更优质的IT服务,并且可以促进其他相关服务管理流程,如变更管理的实施。 ITSS培训 通过本文档的定义,将建立一个完整的问题管理系统,从而实现: · 确保分析并确定事件的根本原因,以防止事件再次发生 · 确保问题分派了正确支持人员,提高解决率. · 根据IT资源情况分派问题优先级 · 主动提供预防性措施 · 及时改进IT架构的重大隐患; · 提高IT服务的可靠性 · 降低IT支持成本 · 提高IT运维团队的整体形象和声誉
1.2 适用范围
本流程适用于IT运维服务部的IT运维团队。管理范围指的是IT运维服务部所有运维管理对象。
2 术语、定义和缩略语
术语 | | | | | 导致一起或多起事件的潜在原因。这种原因会(或可能会)导致一起或多起事件的发生。 | | | 问题管理旨在发现IT基础设施中事件/问题产生背后的根本原因,包括问题处理和问题控制,其目标在于将IT基础设施中的事件/问题对业务产生的负面影响减小到最低,以及防止与这些错误有关的事件再次发生。为了实现这个目标,问题管理调查分析事件的根本原因然后采取有关行动改进或纠正这种情形。 | | Proactive problem management | 是指在事件发生之前发现和解决的有关问题和已知错误,从而使事件对服务的负面影响及相关成本控制到最低的一种管理活动。通过化被动为主动,IT支持组织提供了更好的服务并提高了自身的资源使用效率。 | | | 问题经过诊断后找到根本原因时所处的状态称之为知名错误。在这种状态下,临时措施(workarounds)或永久性的方案已经得到确认。如果出现了一个知名错误,则应当提出一个变更请求(RFC)。但是,在通过一项变更将此知名错误永久性地修复之前,它仍将作为一个知名错误。 |
3 内容
3.1 流程介绍
3.1.1 流程解释
问题管理流程的根本目的是消除或减少事件的发生,此流程分析发生在生产/运行环境的事件,确定最常发生或具有最大影响的事件,找出根本原因,然后生成相应的变更请求、临时解决方法或建议的预防性措施来防止事件的再次发生。所以问题管理流程需要和变更管理流程一起来实施找出的解决方案以从根本上解决问题。 问题通常具有如下特征: · 一组具有相同特征的事件 · 一个重大或紧急事件(事件处理结束后定义为问题,由问题管理找出根本解决方案,问题的根本原因找出后即成为已知错误,对已知错误实施解决方案,从而解决问题)
3.1.2 业务价值
· 在第一现场阻止问题发生 · 如果问题已经发生,通过深入有效的诊断和调查,阻止问题再次发生 · 如果没有达到问题的解决目标或者存在风险,问题管理逐步将问题提升到尽可能快地解决速度 · 提高服务水平和减少成本 · 通过沟通和客户意识的提高,更有效地解决主要事件 · 问题管理帮助缩短事件处理周期,以便快速提升IT服务质量 · 问题管理过程是基于学习过去经验的概念,过程提供历史数据用于识别趋势和预防失败的方法,减少失败的影响。 · 通过捕捉,保留和事件解决能力以及查询知识库中的数据提高服务台首次解决率。
3.1.3 流程政策
3.1.3.1 流程常规机制
· 所有问题都应该被完整准确的记录下来,并保证相关信息应尽可能详细。 · 明确问题管理的问题信息来源,消除事件管理与问题管理之间存在的灰色地带,屏蔽掉流程概念上的混淆。问题可能来源于某些事件的进一步调查,也可能来源于主动巡检和例会制度。 · 所有对用户业务环境可能造成影响的问题都应通过问题管理流程处理;并遵守流程定义的相关标准、政策和指导原则。 · 应该定期(每月)产生和回顾问题管理报表。对未解决的问题,应该举行定期的问题管理会议进行讨论对其评估与分析。 · 应当定期(每半年)进行流程回顾和评审,以改善问题管理流程。
3.1.3.2 责任人机制
责任人机制用来确保每个问题在任何时段都有适当的人员负责,而全面落实责任制需要实行问题的有效管理方案,从而保证问题处理的及时性及有效性。 · 当问题单创建后,由问题经理作为问题处理过程的负责人,负责全程跟踪与协调此问题处理。 · 当问题单被分派后,被分派方(指定的问题分析专家或是问题经理)负责该问题的处理责任。 · 如果需要向问题提交人反馈问题的处理情况,由问题单的当前处理责任人(问题分析专家)负责。
3.1.3.3 分派机制
问题分派原则是确保问题在服务目标时段内处理和解决的重要因素。 关于对问题的分派: · 问题的分派是由问题经理经过评审确认后,分派给问题分析专家的,由被分派任务的问题分析专家负责对故障的潜在原因进行调查、诊断及解决。 · 问题分析专家对潜在的问题进行分析后,如果未能找到问题的根本原因,那么需要把问题单退回给问题经理并写明退回原因,以便让问题经理把问题重新分派给合适的问题分析专家或者取消该问题调查。 · 问题经过问题分析专家诊断与查明根源后,调查解决方案,如果找到,需要把相应的解决方案/替代方法提交给问题经理进行评审。 · 问题的解决方案可能需要发起一个变更请求来彻底解决该问题时,需通知变更管理中的相关角色人,再由变更管理相关角色人负责变更的计划、审批和执行。 · 问题解决后,可把根源、解决方案等信息作为知识条目录入到知识库中,加强后期事件/问题处理的准确性及时效性。
3.1.3.4 再分派机制
· 重分派指第一次分派后被分派对象,将问题单分派给其他部门或个人。 Ø 当问题分析专家收到被分派问题后,如果该问题不属于本人支持范围或者自身能力无法处理时,需要写明问题重派的原因及说明,并把问题说明返回问题经理,由问题经理再进行重新分配。 Ø 所有问题单的转派必须通过问题经理。
3.1.3.5 优先级定义
问题的优先级表明了该问题对服务所产生的业务影响。它是评定问题处理优先等级的一个重要指标。所有问题都将分配到三个优先级中的一个。优先级从 1 (优先级最高) 到 3 (优先级最低) 。优先级的分类主要根据问题的“影响度”和“紧急度”组合决定。 影响度是指受影响业务系统的关键程度,通常通过受影响的客户数量、可能造成的业务损失,或是业务系统的重要程度来决定;紧急度是指解决问题所需要的速度。(需要指出的是:一个高影响度的问题并不一定非常紧急,反之亦然)。 优先级在问题的生命周期中是可以改变的。关于更改问题单优先级的原因和行为应该在问题单中记录。下表为综合了影响度和紧急度诸因素,针对IT运维服务部现状所定义的优先级划分:
优先级 | | | 会使在线业务系统立即停止服务的故障,会影响在线业务系统的服务,但不会使服务直接停止的故障
| | | | 会影响后台支持系统的服务,但不会使服务直接停止的故障
|
3.1.3.6 目标解决时间机制
· 为了更好的控制问题的解决,整个流程被分解成几个组成部分。每个流程的阶段都设定了目标时间。 · 问题的目标时间与事件的明显不同,这是由于两个管理流程目标不同决定的,通常事件比问题的目标时间更为严格。
特例1:如果事件的解决需要问题的解决相配合,则问题的目标时间应该服从于事件的目标时间。
3.1.3.7 升级机制
对于不同优先级的问题单,问题管理流程应确保分配合适的资源进行处理。为了达到这个目的,定义了升级机制的时间框架。当达到下列时间点时,如果问题还未解决,则将触发问题升级机制。 · 问题被响应和分派的时间点 · 问题变为已知错误的时间点(找到根本原因) · 问题找到解决方案的时间点 · 问题解决的时间点 问题升级机制如下表所示,各时间点定义参见问题时限: 问题优先级 | 问题当前处理人 | 问题经理 | 问题流程负责人 | 1 | 超时变为已知错误 超时找到解决方案 超时解决 | 超时响应 超时变为已知错误 超时解决 | 超时解决 | 2 | 超时变为已知错误 超时解决 | 超时响应 超时解决 | N/A | 3 | 超时解决 | 超时响应 | N/A |
3.1.3.8 关闭机制
· 问题单在实施了解决方案之后,需要经过一段时间的回顾。 · 只有问题经理才有权关闭问题单。 · 问题单不会被自动关闭。
3.1.3.9 流程关联机制
file:///C:/Documents%20and%20Settings/ac05/%E6%A1%8C%E9%9D%A2/ISO20000/%E9%97%AE%E9%A2%98%E7%AE%A1%E7%90%86%E6%B5%81%E7%A8%8B%E6%89%8B%E5%86%8C124_files/image005.gif 与配置管理的关系 § 配置管理提供了IT基础架构中硬件、软件、文档及服务等各种配置项的重要信息,这些信息帮助分析专家对问题进行有效的调查、分析和诊断。
与变更管理的关系 § 变更管理流程负责控制执行变更,包括由问题管理为消除问题而发出的RFC。 § 变更管理通知问题管理关于纠正性变更的进展和完成情况。这些纠正性变更的实施效果需要得到问题管理的最终确认。
与事件管理的关系 § 完整有效的事件记录是问题的主要来源,也是问题识别和分析诊断的重要基础。 § 问题管理通过趋势分析和主动问题分析,进而采取预防措施,有助于降低事件的重发率和事件总数
3.1.4 问题单代码设计
3.1.4.1 问题信息项
问题单应该包含如下问题信息项,IT运维服务部的IT运维团队可以在此基础上进行选择和修改: [td]序号 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 问题流程经理参考问题时限定义与问题分析专家共同确定计划解决时间 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 附件的主要目的是协助问题的分析处理,例如: 问题现象报告:由问题提交人提供 问题分析报告:由问题分析专家提供 问题协调报告:如果问题涉及其他部门,需要使用问题协调报告,由问题经理或问题分析专家提交 问题跟踪报告:如果无法立即解决问题,需要利用问题跟踪报告来跟踪问题进展,由问题分析专家提交 | | | | | | | | | |
3.1.4.2 问题来源
问题来源代码用来标明问题的提出方式,问题来源可以包括以下几种:
编号 | | | | | 单个重大故障升级为问题
事件流程中通过变通方法临时解决的事件,可作为的问题在问题流程中找到其根本原因和最终解决方案
| | | 类似的事件在某个时间周期内(如周/月)反复发生
多个事件具有相同症状 某类事件出现比例高于其他类型事件
某类事件数量连续数月呈逐渐攀升态势
| | | 日常运维工作中发现的系统隐患或需重视的异常
已知的IT运维服务部应用系统及第三方系统尚未解决的技术缺陷
|
3.1.4.3 问题分类
简单起见,问题采用与事件一致的分类,详见事件分类表。
3.1.4.4 问题状态
问题状态代码表明问题所处的处理状态,问题状态如下:
编号 | | | | | 问题分析专家通过分析诊断,找到导致问题发生的根本原因 | | | 问题分析专家在找到问题根本原因后,进一步分析并提交问题的解决方案或变通方法 | | | 问题经理批准解决方案,返回问题分析专家进行方案实施 | | | | | | 问题信息不完整,或在某些情况下阻止问题分析专家对问题的处理,挂起的原因为: · 未找到问题的根本原因 · 等待生产环境升级 · 等待RFC变更流程处理 · 等待其他厂商/第三方处理 | | | | | | 问题请求人已对问题处理结果进行了确认,并同意关闭问题 |
3.1.4.5 问题结束代码
问题结束代码说明了问题是在何种情况下关闭的,结束代码如下:
编号 | | | | | | | | 已找到问题解决方案,但由于目前条件/资源的限制而无法处理 | | | | | | 由于问题为重复或者无效问题,或涉及过大的成本及资源,相应问题单被问题经理评审后取消 |
3.2 角色及职责
3.2.1 角色简介
问题管理流程角色 | | IT运维服务部 对应的流程角色人员 | | · 问题管理解决方案的责任人; · 对于整个问题管理解决方案的结果承担责任,并有相应的权限; | | | · 协调问题管理步骤的日常操作; · 根据定义的标准,确保问题得到解决并关闭 ; · 确保问题分派给问题分析专家; · 确保问题分析专家在其管辖范围内的可用性和能力; | | | · 进行深入的问题分析,以找出根本原因,并提供解决方案; | | | · 记录问题基本信息并将其与相应事件、CI进行关联; · 将问题归类,设定其紧急度、影响度和优先级; · 将问题提交给问题经理; | |
3.2.2 问题流程负责人
问题管理流程负责人从宏观上监控流程,确保问题流程在IT运维服务部服务团队范围内被正确的执行。随着业务需求和IT环境的改变,流程负责人必须定期或不定期进行流程分析、找出缺陷、进行改进,从而实现服务能力的可持续提升。 ITSS认证
职责定义: · 确定问题管理流程的衡量指标 · 确保问题管理流程能够取得管理层的参与和支持 · 确保问题管理流程符合公司实际状况和公司 IT发展战略 · 总体上管理和监控流程,建立问题管理流程实施、评估和持续优化改进机制 · 对问题管理流程中的成本和投资负责 · 保持与其他流程负责人的定期沟通
专业技能: · 了解内部和外部业务环境 · 理解公司IT策略和业务计划 · 理解公司的IT政策,流程和标准 · 能够进行流程评估和设计 · 具备分析和计划能力
处事技能: · 良好的冲突管理能力 · 良好的口头和书面沟通能力 · 示范和领导能力 · 决策分析能力
3.2.3 问题流程经理
问题经理负责协调问题管理活动的日常执行和问题管理流程中的工作调度。
职责定义: · 定期组织相关人员对事件记录进行主动分析,发现潜在问题 · 对提交的潜在问题进行预审,并对所需资源进行评估 · 跟踪监控问题的分析、诊断和处理过程,确保问题能及时有效的得到解决 · 负责对分析专家提交的问题解决方案进行审核 · 定期制定问题报表,提供正确的决策信息 · 负责与事件及其他流程经理的沟通交流,确保与各个相关流程的有效合作
专业技能: · 熟悉公司的IT政策,流程和标准 · 了解问题管理流程 · 了解用户业务及其IT基础架构环境 · 具备很强的分析能力及跨领域的专业技能 · 了解向客户提供的服务级别承诺 · 了解事件管理流程
处事技能: · 良好的口头和书面沟通能力 · 具备冲突管理能力 · 能够监控和管理任务进程 · 管理经验 · 良好的团队工作能力
3.2.4 问题分析专家
问题分析专家负责寻找问题的根源,并提供和协助落实解决方案,必要时寻求IT运维服务部服务团队内部或第三方资源的帮助。通常由各专业组技术人员担任。
职责定义: · 定期分析事件记录数据及相关信息,发现和识别问题,进行主动预防 · 接受问题经理分派的问题,将本人不能受理的问题单及时退还给问题经理 · 分析诊断问题的根本原因 · 提出解决方案并落实执行,必要时发起变更请求并监控变更实施 · 必要时协调配合第三方供应商诊断和解决问题 · 将常见或者典型的问题整理为知识记录
专业技能: · 了解用户业务及其IT基础架构环境 · 了解服务级别承诺 · 具备很强的分析能力 · 具备某个领域较强的专业技能
处事技能: · 基本的人际关系沟通技巧 · 良好的口头和书面表达能力 · 能够监控和管理任务进度
3.3 流程输入及输出
3.3.1 流程触发条件
· 事件升级: o 一段周期内,同个事件,反复发生(一月发生三次以上) o 多个事件,具有相同的症状 o 单个重大故障 · 运行周报/月报的趋势分析 · 通过巡检发现的系统层面重大问题/隐患,可通过例会制度讨论
3.3.2 输入
· 未解决的事件单,需要通过问题管理流程解决 · 已解决的但需要进行根本原因分析的事件 · 对事件趋势分析的结果 · 虽然尚未发生事件,问题分析专家主动发现的新问题
3.3.3 输出· 对事件管理流程的通知 · 关闭的问题单
3.3.4 流程关闭条件
· 问题单分析处理完毕并经过评审,并在判断是否需要提交知识条目后可以关闭
3.4 问题管理流程描述
3.4.1 流程综述
问题管理的目标是减少因为IT架构错误引发的事件和问题对业务的反面冲击,并且阻止关系到这些错误的事件再次发生。 因此,问题管理关注于深入研究并在IT架构中清除已知错误,而事件管理主要注重的是响应和解决故障的速度。 这一流程主要关注: · 分析呼叫来决定趋势和共同特征 · 确定已知错误(问题控制-->诊断) · 关联被选方案(纠正行为)清除已知错误(错误控制) · 提升变更请求以清除事件发生 · 变更实施后,检查已知错误是否消除 · 显示需要改进区域
3.4.2 作业流程图
file:///C:/Documents%20and%20Settings/ac05/%E6%A1%8C%E9%9D%A2/ISO20000/%E9%97%AE%E9%A2%98%E7%AE%A1%E7%90%86%E6%B5%81%E7%A8%8B%E6%89%8B%E5%86%8C124_files/image007.gif 3.4.3 流程活动说明
1) 主要活动说明: 编码 | | | | | | | 本步骤的主要目的是识别问题(主动或是被动),创建问题单并确定其分类、根据影响度和紧急度决定问题的优先级。 | | | | 这个步骤是问题经理接受到问题单后,判断该问题是否值得解决,或是否可能解决,并据此确定是否正式创建问题。如果确定需要正式创建问题,则将该问题到分派给问题受理员。 | | | | 该步骤确定了问题信息的来源,对问题进行分析,找出问题的根本原因。 | | | | 本步骤的目的找出已成为“已知错误”的问题的解决方案,如果找到即实施该方案以解决问题。 | | | | | | | | | | |
2)分活动说明
编码 | | | | | | | · 问题提交员记录问题细节。 · 问题提交人将相关事件与问题进行关联 · 问题提交人将相关CI/资产与问题进行关联 · 问题提交人将问题分类 · 问题提交人确定问题的影响度和紧急度 · 影响度和紧急度确定后将自动确定其优先级 | | | | · 问题提交人将问题提交给问题经理,等待其评审 · 一旦问题经理确认收到该问题,则问题提交员不能撤销其提交的问题 · 问题单状态被标识为“新建” | | | | · 问题经理对问题提交人提交的问题单进行复核 · 问题经理对问题单进行初步审核,综合现有信息、资源决定是否需要进行问题调查 | | | | · 问题经理决定是否继续调查 · 如果不继续,则取消调查,关闭问题单,问题单结束代码标记为“取消” · 否则,转入任务PM2.3“分派问题单以查找根本原因” | | | | · 问题经理将问题指派给问题分析专家 · 问题分析专家获得问题受派通知 · 将问题单状态标识为“已分派” | | | | · 问题分析专家确定是否接受分派 · 如果接受分派,转入任务PM3.1“启动问题调查”,问题单状态变为“处理中” · 否则,转入任务PM2.5“说明拒绝理由”,从而进行问题的重新分配。 | | | | · 问题分析专家填写不接受指派原因,如果问题分类不正确,时将问题重新分类, · 问题分析专家可以提出重分派建议,之后将问题单重新推回到问题经理,由问题经理重新检查信息和分派问题,转入任务PM2.3“分派问题”。 | | | | 问题分析专家负责查找问题的根源。问题调查和分析包括如下一系列过程: · 问题分析专家检查最近的变更,看问题是否由相关CI近期实施的变更引起。如果是则将变更与问题进行关联 · 否则,看是否与已知错误相匹配。如果找到,则记录已知错误,否则继续诊断问题 · 如果从变更和已知错误找根源都失败,那么问题分析专家继续收集相关信息对问题进行分析诊断,查找问题根源 · 在此活动中,问题分析专家通常采取召开多位问题专家一起进行问题诊断 | | | | · 问题分析专家确定是否找到根源 · 如果找到,转到PM3.4“记录问题根源” · 否则,转向PM3.3“是否需要升级” | | | | · 如果需要,则进入PM3.5“注明调查情况并升级到问题经理” · 否则,问题挂起 | | | | · 问题分析专家将分析得出的问题产生原因完整记录下来 · 将问题单状态标识为“已找到根源” · 进入任务PM4.1“调查问题解决方案” | | | | · 问题分析专家将问题升级到问题经理,并重新转到PM3.1“问题调查和分析” | | | | · 问题分析专家根据问题根源,调查解决方案 · 问题找到根源后,无论是否解决问题,都可以视为问题已经完成,单问题分析专家应该尽力寻找问题的解决方案。 | | | | · 问题分析专家判断是否已经找到了该问题的解决方案, · 如果找到,则进入PM4.3,“实施并记录问题解决方案” · 如果找不到解决方案,则进入PM4.4“完成问题”,然后进入问题关闭流程 | | | | · 问题分析专家确定该解决方案可行,并记录解决方案 · 将问题单状态标识为“已提交方案” | | | | · 无论是否找到解决方案和是否需要实施,只要找到解决方案,都可视为问题完成。 · 如果找到并实施了解决方案,问题分析专家将解决方案和实施结果补充到问题单中,问题完成 · 问题分析专家将问题单的状态标识为“已完成” · 转向PM5.1“验证并与用户确认问题处理结果” | | | | · 问题分析专家验证问题调查记录,确认解决方案和问题信息 · 问题经理确认问题处理结果,判断是否达到预期 | | | | · 问题经理判断是否可以关闭问题, · 如果“是”则进入PM5.3,继续判断是否需要作为知识条目提交,更新知识库;如果“否”则进入PM3.1“问题调查分析”。 | | | | · 问题经理判断是否需要将该解决方案作为知识条目提交到知识库,如果“是”则进入PM5.4,进行知识条目的创建; · 如果“否”则直接进入PM5.5“问题关闭” | | | | | | | | · 问题经理关闭问题单,将问题单状态标识为“已关闭” · 问题经理设置关闭相应的代码。 |
3.5 流程衡量指标及报表
为了控制流程的质量,提高用户体验,必须为流程设置衡量指标。通过对指标的分析,可以有效地对流程的运行情况进行监控和改进。基于对IT运维服务部的IT服务现状的认识和了解,初步给出如下的问题管理和知识管理流程KPI指标。
序号 | | | | | 数量:在问题单中根据以下条件过滤 § 【重复问题标记】为空 § 【问题发生时间】在统计周期内 | | | 数量:在问题总数中过滤【优先级】=‘1、2、3、4’ 比例:数量/问题总数 × 100 % | | | 数量:在问题总数中过滤【问题关闭代码】=‘成功’or‘临时措施’ 比率:数量 / 问题总数 × 100 % | | | 数量:在问题总数中过滤【问题找到解决方案的时间】 >问题计划提供方案时间】 比率:数量/问题总数 × 100 % | | | 找到问题解决方案的时间=【问题解决时间】-【问题创建时间】 找到解决方案的问题数量=在问题总数中过滤【问题找到解决方案】=True 平均时间=sum(所有找到解决方案的问题的『找到问题根源的时间』)/找到解决方案的问题数量 |
问题流程管理相关报表建议如下,IT运维服务部运维服务团队可在此基础上自行补充:
[td]序号 | | | | | | | | | | | | | | | | | | | | | | | 超过指定时间分派的问题数量/比率 超过规定时间找到根本原因的问题数量/比率 超过规定时间找到解决方案的问题数量/比率 | | | | 分派成功所需的平均时间 找到问题根源所需的平均时间 找到问题解决方案所需的平均时间 | | | | | | | | |
4 参考
4.1 相关文件· 服务台 · 事件管理 · 变更管理 · 发布管理 · 服务级别管理
4.2 相关表单· 问题单 · 问题月报 · 已知错误库 · 知识库
本帖关键字:ITSS
|