ITIL v3核心读物 图解集之问题管理流程.docx
- 文档编号:4695214
- 上传时间:2022-12-07
- 格式:DOCX
- 页数:8
- 大小:83.30KB
ITIL v3核心读物 图解集之问题管理流程.docx
《ITIL v3核心读物 图解集之问题管理流程.docx》由会员分享,可在线阅读,更多相关《ITIL v3核心读物 图解集之问题管理流程.docx(8页珍藏版)》请在冰豆网上搜索。
ITILv3核心读物图解集之问题管理流程
前言
随着ITILv3在国内的普及和应用,越来越多的读者希望更进一步地提升对ITILv3核心图书的学习,为此,上海翰纬信息管理咨询有限公司作为中国领先的专注于IT服务管理研究和咨询的机构,于2010年11月启动《翰纬ITILv3图解集》的开发工作。
《翰纬ITILv3图解集》的开发将采取“OpenSource”的方式,希望广大的“ITIL”迷们积极地与翰纬联系,参与本图解集的开发指导工作,分享自己的最佳实践。
《翰纬ITILv3图解集》力图通过较短的篇幅,结合翰纬自身丰富的咨询研究经验,深入浅出地对ITILv3原书中的重要图表进行解释说明和点评,能让读者更加深入的理解和应用ITILv3的重要内容。
《翰纬ITILv3图解集》按辑发布,本文为第三辑——问题管理流程图解,接下来即将推出第四辑,敬请留意:
✧ 第四辑——IT服务连续性管理
ITILv3核心读物图解集之问题管理流程
1.0 图解概述
问题管理是负责管理所有问题生命周期的流程。
问题管理的目的是IT基础架构中的错误引起的故障和问题对业务的负面影响,并且防止再次发生与这些错误有关的故障。
图1是问题管理的流程图(ITIL原书ServiceOperation 的Figure4.4),该图说明了从问题识别、记录开始到问题关闭整个问题管理流程所涉及的各个活动及其关系。
2.0 图解说明
问题管理包括诊断故障根本原因的活动,及确定这些问题的解决方案。
它还负责确保方案通过合适的控制流程实施,特别是变更和发布流程。
问题管理还维护关于问题、适当的规避措施和解决方案的信息,以便组织能够减少故障的数量和影响。
这方面,问题管理应该与知识管理和KEDB类的工具软件有一个紧密的接口。
尽管故障和问题管理是独立的流程,但它们紧密相关,一般都使用相同的工具软件,并使用相似的分类、影响和优先级代码系统。
这样,在处理相关的故障和问题时,可以确保有效的沟通。
问题管理流程图中的每一个活动的详细说明如下:
2.1 问题检测和记录
在不同的组织,可能存在不同的问题检测手段,包括:
● 服务台怀疑或检测到一个或多个原因未知的故障,会建立问题记录。
有时候是服务台已经解决了故障,但不能确定引起故障的原因并怀疑它可能会再次出现,因此会建立问题记录,以便解决根本原因;或者,从一开始就可以明显发现一个故障或多个故障是由一个重大问题所引起,因此可以立即建立问题记录。
● 技术支持小组在进行故障分析时,揭示了存在或可能存在的问题。
● 自动检测基础设施或应用故障,事件/报警工具软件自动地发起故障并提示需要进行问题记录。
● 供应商或厂商通知存在问题,需要解决。
● 对故障进行主动式问题管理分析,这需要建立问题记录,以便可以进一步调查根本原因。
无论通过哪种检测手段,所有问题的相关信息都必须进行记录,以便保留完整的历史记录。
一般包括以下信息:
● 用户详细情况
● 服务详细情况
● 设备详细情况
● 最初记录的日期/时间
● 优先级和分类详细情况
● 故障描述
● 所有诊断或企图采取的恢复措施的详细情况
2.2 问题分类和优先级
问题的分类,可使用和故障相同的分类编码系统,以便将来容易跟踪问题的真正本质,并容易获得有意义的管理信息。
问题的优先级类似于故障的优先级,但是需要考虑问题的相关故障的频率和影响,并设计关于为什么这是一个问题的定义、解决问题的支持人员、与问题相关联的服务等。
问题优先级应该考虑问题的严重性。
这里的严重性是指从基础架构角度看问题有多严重。
比如:
● 系统能够恢复吗?
或它需要替换吗?
● 它要花费多少?
● 修复这个问题需要多少人?
需要哪些技能?
● 修复这个问题需要多少时间?
● 问题的扩展性如何?
(受影响的CI有多少?
)
由IT组织中的职能部门进行问题的分类并评估其紧急程度和影响程度,进而确定优先级。
2.3 问题调查和诊断
需要进行调查以诊断问题的根本原因,调查的速度和性质会随问题的影响、严重性和紧急性而不同。
但应投入适当的资源和专门技术查找与优先级及相应的服务目标相称的解决方案。
配置管理系统(CMS)帮助确定影响程度并帮助查明和诊断故障的确切部位。
如果该问题曾经出现过,还要访问KEDB(已知错误数据库)并使用问题匹配技术(比如关键字搜索)查找解决方案。
尝试重现此故障通常很有效,这样能知道发生什么错误,然后通过不同的方法去寻找最合适的和最经济的解决方案。
为了避免引起进一步的中断,需要一个与生产环境镜像的测试系统。
很多问题分析、诊断和解决技术可用,并且都已经进行过研究。
一些比较有用且用的较多的技术如下:
● 时序分析(ChronologicalAnalysis):
在处理一个困难问题时,通常会针对具体发生情况和发生时间建立冲突报告。
因此按时序简要记录所有事件,即提供事件发生时间表是非常有帮助的。
通常这可以支持查看哪些事件被其他事件触发,或者忽视了哪些与事件发生顺序不符的声明。
● 痛值分析(PainValueAnalysis):
这不只是分析特定时期特殊类型故障/问题的数量,而是进行更深入地分析,来确定这些故障/问题具体给组织和业务带来哪种级别的痛值。
可以设计一个公式来计算痛值级别。
一般这可能包括要考虑:
✓ 受影响人员的数量
✓ 引起的中断持续时间
✓ 企业耗费的成本
● 头脑风暴(Brainstorming):
通常,有效的办法是将所有相关人员实地或通过电子方式聚集到一起对问题展开“头脑风暴”,即所有人员就潜在原因和潜在的问题解决措施提出自己的想法。
头脑风暴会议具有很大的建设性和创新性,但同样重要的是一些人,或许是问题经理会记录结果和任何约定的措施,并在会议中保持一定的程度控制。
● 排列(帕累托)分析(ParetoAnalysis):
这是一种用于在很多琐碎问题中区分出重要潜在原因的技术。
一般采取以下步骤:
✓ 建立一个表,列出原因以及发生的频率(百分比);
✓ 按原因重要性的降序安排,即发生频率最高的原因列在前面;
✓ 在表中添加样本累积百分比栏。
如表1(ITIL原书ServiceOperation 的Table4.2),阐述了某组织中出现网络故障的十大原因。
表1Pareto原因排行表
网络故障
原因
占总数的百分比
计算
累积%
网络控制器
35
0+35%
35
文件破坏
26
35%+26%
61
解决冲突
19
61%+19%
80
服务器操作系统
6
80%+6%
86
脚本错误
5
86%+5%
91
未测试的变更
3
91%+3%
94
操作员错误
2
94%+2%
96
备份故障
2
96%+2%
98
入侵尝试
1
98%+1%
99
磁盘故障
1
99%+1%
100
✓ 按照原因占总数的百分比,创建原因条形图。
✓ 叠加累积百分比线性图。
如图2(ITIL原书ServiceOperation 的Figure4.5)显示了完整图表。
✓ 在y轴80%的点,画一条与x轴平行的线。
一直画到与x轴曲线交叉的地方。
X轴上的这一点将将重要原因与非重要原因区分开来。
这一线条在图2中以虚线显示。
从图2中可以看出有三个主要原因导致了组织中的网络故障。
因此这些原因应得到最先解决。
2.4 规避措施
有时候可能需要为由问题引起的故障找出一种规避措施,作为临时问题解决方法。
比如,手工输入一个文件使得程序能够成功运行。
但是,仍需要继续寻找永久性解决方案。
在找到规避措施的情况下,还需要做的一项工作是,保持问题记录处于开放状态,并且确保在问题记录中详细记录规避措施的信息。
2.5 创建已知错误记录
诊断一旦完成,特别是规避措施已找到(即使不是一个永久性解决方案)的情况下,应该创建一条已知错误记录,并记录到已知错误数据库(KEDB,KnownErrorsDatabase),这样如果以后继续出现同样的故障和问题,它们就能被快速识别,服务也能更快地恢复。
2.6 问题解决
理想地,一旦找到解决方案,就应该马上用于解决问题,但现实中需要采取一定的安全保护措施以免导致进一步出现问题。
如果需要进行功能方面的变更,这就需要在实施解决方案之前发起和批准RFC。
如果问题很严重或者由于业务原因需要紧急修复,则紧急变更申请(RFC)需要得到CAB/EC(ChangeAdvisoryBoardEmergencyCommittee)的处理。
否则,RFC应该按照既定的变更管理流程处理,并且只有在变更得到批准和排期后,变更才能得到实施。
同时,KEDB用于帮助快速解决故障/问题的再次发生。
2.7 问题关闭
当变更实施完成(并已完成审查),且应用了解决方案,问题记录应正式关闭,其他相关的、打开的故障记录也应该关闭。
这时,应该进行检查以确保记录包含所有事件的完整的历史描述。
所有已知错误记录的状态也应该更新,以显示已应用了解决方案。
2.8 主要问题审查
在每个主要问题完成后(由组织的优先级系统确定),当大脑还记忆犹新时,应该进行回顾以便为将来吸取一些教训。
特别地,回顾应该包括:
● 哪些事情做对了
● 哪些事情做错了
● 什么事情将来可以做的更好
● 如何防止再次发生
● 是否存在第三方责任、是否需要采取后续的行动
这种回顾可以作为员工培训和意识教育的一部分,任何经验教训都可以记录到适当的过程、工作指引、诊断脚本和已知错误记录中。
问题经理应该推动这些工作并记录所同意采取的行动。
回顾中学习的知识应该在服务回顾会议上向业务客户汇报,使客户知道为了防止主要故障再次发生而采取了什么行动和计划。
这有助于提高客户满意度,并使业务部门知道服务运营部门正在负责地处理主要故障,并积极地进行工作以防再次发生。
2.9 开发环境中的错误监测
新应用、系统或软件发布时完全没有错误是不大可能的。
鉴于组织一方面需要在最短的时间内向企业交付新的功能,另一方面需要确保代码或组件不含错误。
为了在这二者之间取得平衡,通常在测试此类新应用、系统或软件期间,组织会根据优先级根除最严重的错误,但一些微小错误可能未被纠正。
当决定向生产环境发布某些仍存在缺陷的组件时,应该将这些作为已知错误记录到KEDB中,并提供详细的规避措施或解决方案。
在测试完毕时,组织应采取一个正式步骤来确保进行移交。
经验表明,如果不这样做,当用户开始遇到这个故障且不得不重新诊断和解决这个故障时,将导致很高的支持成本。
3.0 点评
故障管理的目的是快速解决故障,在很多情况下为了快速恢复那些产生故障的服务,我们会利用一切可能的手段,例如变通的解决办法。
而问题管理的目标是寻找出故障背后的真正原因,主要目的是找到故障产生的原因,并防止故障的再次发生。
在很多企业中,花费了很多精力去建立和推行问题管理流程,却面临这样的问题,即问题管理流程建立了,可是创建的问题数却非常少,要么因为流程运作成本太高或者因为分工不明确导致流程无法执行下去,要么就是运行一段时间后没有起到降低故障发生率的预期效果,甚至到后来,故障管理和问题管理逐渐地混成一个流程了,往往导致问题管理流程名存实亡,从而没有充分实现问题管理流程本该发挥的作用。
结合众多企业实施问题管理实践经验来看,可以归纳以下因素为确保问题管理流程被有效地执行的关键成功因素:
● 明确定义问题管理流程中的角色及其职责;
● 对问题记录单进行合理的设计,保证问题被有效地记录,并便于后面对问题单进行跟踪、反馈和汇总;
● 建立什么情况下触发问题管理的规则,确保问题能被及时地识别并创建问题记录;
● 明确问题管理和故障管理流程的接口和协同工作习惯;
● 确保在问题管理中积累的问题及其解决方案能够被重复利用,理清问题管理和知识管理之间的关系;
● 确保所有处理问题管理的人员了解相关业务影响;
● 进行主动问题管理。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ITIL v3核心读物 图解集之问题管理流程 v3 核心 读物 图解 问题 管理 流程
![提示](https://static.bdocx.com/images/bang_tan.gif)