Wiki源代码16 某电网XX市供电局ITIL问题管理策略
由 superadmin 于 2024/10/15, 16:40 最后修改
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | [[返回本章节索引>>http://www.itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E9%97%AE%E9%A2%98%E7%AE%A1%E7%90%86/]] [[阅读下一章>>http://itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E9%97%AE%E9%A2%98%E7%AE%A1%E7%90%86/17%20%E6%9F%90%E7%BD%91%E7%BB%9C%E5%B7%A5%E7%A8%8B%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8%E4%BF%A1%E6%81%AF%E6%8A%80%E6%9C%AF%E6%9C%8D%E5%8A%A1%E7%AE%A1%E7%90%86%E4%BD%93%E7%B3%BB%E9%97%AE%E9%A2%98%E6%B5%81%E7%A8%8B%E7%AE%A1%E7%90%86%E5%8A%9E%E6%B3%95/]] | ||
2 | |||
3 | |||
4 | **文件历史控制记录** | ||
5 | |||
6 | |**版本号**|**修订人**|**修订日期**|**修订内容**|**审核人** | ||
7 | |V1.0|郭X|2010-9-30|文档新建|戴X | ||
8 | | | | | | | ||
9 | | | | | | | ||
10 | | | | | | | ||
11 | | | | | | | ||
12 | |||
13 | = **1文档介绍** = | ||
14 | |||
15 | |||
16 | == **1.1文档简介** == | ||
17 | |||
18 | 本文介绍了问题管理的基本情况,阐述了问题管理流程的基本管理思想、管理范围以及具体的实施策略。 | ||
19 | |||
20 | == == | ||
21 | |||
22 | == **1.2文档目标** == | ||
23 | |||
24 | 本文档为XX市供电局建立并实施问题管理流程提供依据和准则,文档中已明确的策略必须在问题管理流程中得以落实和贯彻执行。对本文档所描述内容的学习和执行有助于问题管理流程的成功实施,提高XX供电局的问题分析和解决能力,降低问题响应和处理时间,提高IT服务的质量、连续性和客户满意度。 | ||
25 | |||
26 | = = | ||
27 | |||
28 | = **2概述** = | ||
29 | |||
30 | 问题管理流程是负责查找IT服务中事件根本原因的管理过程,它的目的是通过识别和管理事件的根本原因,使之成为已知错误来避免该事件的再次发生。由于它的特点不像事件一样以解决表面现象为主,因此问题的生命周期往往较事件的生命周期长得多。 | ||
31 | |||
32 | 由于存在投入和产出的问题,并不是所有的问题都可以找到根本原因,或者根本原因的方法无法被接受,因此也可能使用变通的方案或者让该问题继续存在。 | ||
33 | |||
34 | = = | ||
35 | |||
36 | = **3范围** = | ||
37 | |||
38 | 问题管理流程的范围是对IT生产环境中的应用系统及相关的基础设施所发生的问题进行管理,以采取主动性预防措施来降低事件数量。 | ||
39 | |||
40 | 涉及的领域有: | ||
41 | |||
42 | * 桌面设备维护 | ||
43 | * 业务系统维护 | ||
44 | * 机房环境维护 | ||
45 | * 信息平台维护 | ||
46 | |||
47 | **不包括:**处于开发或测试环境的应用系统和基础设施。 | ||
48 | |||
49 | = = | ||
50 | |||
51 | = **4定义** = | ||
52 | |||
53 | == == | ||
54 | |||
55 | == **4.1问题** == | ||
56 | |||
57 | 问题指未查明根源的一次或多次事件。问题定义有两个途径。一类是由一系列显示共同特征的事件导致的;二是由某个原因不明的重要事件导致的。 | ||
58 | |||
59 | == == | ||
60 | |||
61 | == **4.2已知错误** == | ||
62 | |||
63 | 当问题管理调查出事件发生的根本原因同时找到临时变通处置方案或永久解决方案时,问题就可以被定义为已知错误。 | ||
64 | |||
65 | == == | ||
66 | |||
67 | == **4.3知识库** == | ||
68 | |||
69 | 当问题被定义为已知错误时,需要将之告知所有相关的支持人员,以便支持人员作为解决错误时的参考。 | ||
70 | |||
71 | == == | ||
72 | |||
73 | == **4.4问题状态** == | ||
74 | |||
75 | 为了记录问题处理的生命周期,需要设置不同的状态加以描述,如下所示: | ||
76 | |||
77 | |**编号**|**代码**|**描述** | ||
78 | |1|已登记|问题登录到系统中 | ||
79 | |2|已分派|问题已由问题主管分派给问题分析专家 | ||
80 | |3|分析中|问题分析专家正在分析问题过程中 | ||
81 | |4|已定位原因|问题根本原因已找出 | ||
82 | |5|已有解决方案|解决方案已找到 | ||
83 | |6|等待资源|解决方案已找到,但需等待资源 | ||
84 | |7|已提出RFC|已提交变更请求(RFC) | ||
85 | |8|实施中|解决方案处于实施中 | ||
86 | |9|监控中|实施完成,需要监控一段时间 | ||
87 | |10|已解决|问题得到解决 | ||
88 | |11|结束|问题结束 | ||
89 | |||
90 | = **5问题处理** = | ||
91 | |||
92 | 问题管理流程中的主要活动包括: | ||
93 | |||
94 | * 问题的控制; | ||
95 | * 错误的控制; | ||
96 | * 问题的主动预防; | ||
97 | * 趋势的分析和明确; | ||
98 | * 从问题管理数据中获取实用管理信息; | ||
99 | * 主要和重大问题的检查回顾。 | ||
100 | |||
101 | 问题管理流程从事件管理流程中接收关于事件及其变通方案(若存在)的信息和报告,对问题进行识别、定义和调查,并最终确定引发问题的根本原因,制定解决或改进方案。 | ||
102 | |||
103 | == == | ||
104 | |||
105 | == **5.1问题控制** == | ||
106 | |||
107 | 问题控制的三个主要活动包括: | ||
108 | |||
109 | * 问题的识别和记录; | ||
110 | * 根据问题对业务活动的影响进行分析; | ||
111 | * 问题的调查和诊断。 | ||
112 | |||
113 | === === | ||
114 | |||
115 | === **5.1.1问题识别** === | ||
116 | |||
117 | 问题的识别和确认可以通过以下方法实现: | ||
118 | |||
119 | * 事件管理流程直接报告(如无法解决的事件); | ||
120 | * 分析已发生的事件,包括已有和没有变通方案的; | ||
121 | * 定期回顾并分析事件报告; | ||
122 | * 分析和检查IT基础设施及其运行状况; | ||
123 | * 获取来自服务运维管理人员或供应商的相关报告。 | ||
124 | |||
125 | 为协助问题管理识别出问题的根本原因,需要问题管理流程参照现有的问题、已知错误和变更对问题进行归类。 | ||
126 | |||
127 | === === | ||
128 | |||
129 | === **5.1.2问题的分类** === | ||
130 | |||
131 | |(% colspan="3" %)**事件分类代码**|**说明** | ||
132 | |(% rowspan="2" %)((( | ||
133 | UNIX | ||
134 | |||
135 | 服务器 | ||
136 | )))|(% colspan="2" %)硬件|(% rowspan="4" %)与服务器相关 | ||
137 | |(% colspan="2" %)系统软件 | ||
138 | |(% rowspan="2" %)((( | ||
139 | Windows | ||
140 | |||
141 | 服务器 | ||
142 | )))|(% colspan="2" %)硬件 | ||
143 | |(% colspan="2" %)系统软件 | ||
144 | |(% rowspan="3" %)数据库|(% colspan="2" %)Oracle|(% rowspan="3" %)((( | ||
145 | |||
146 | |||
147 | 与数据库相关 | ||
148 | ))) | ||
149 | |(% colspan="2" %)MS SQLServer | ||
150 | |(% colspan="2" %)Sybase | ||
151 | |(% colspan="3" %)防火墙|与防火墙有关 | ||
152 | |(% rowspan="4" %)网络|(% colspan="2" %)交换机|(% rowspan="4" %)与网络相关 | ||
153 | |(% colspan="2" %)路由 | ||
154 | |(% colspan="2" %)线路 | ||
155 | |(% colspan="2" %)PC端网卡 | ||
156 | |(% rowspan="8" %)客户端|(% colspan="2" %)PC硬件|(% rowspan="8" %)与客户端相关 | ||
157 | |(% colspan="2" %)系统软件 | ||
158 | |(% colspan="2" %)其他应用软件 | ||
159 | |(% colspan="2" %)Office软件 | ||
160 | |(% colspan="2" %)打印机 | ||
161 | |(% colspan="2" %)PKI应用安全插件(口令助手、CSP程序等) | ||
162 | |(% colspan="2" %)USB读卡器及其相关程序 | ||
163 | |(% colspan="2" %)智能卡口令问题 | ||
164 | |(% rowspan="5" %)((( | ||
165 | 应用 | ||
166 | |||
167 | 系统 | ||
168 | )))|(% colspan="2" %)进程|(% rowspan="5" %)与应用系统相关 | ||
169 | |(% colspan="2" %)数据 | ||
170 | |(% colspan="2" %)参数 | ||
171 | |(% colspan="2" %)代码 | ||
172 | |(% colspan="2" %)接口 | ||
173 | |(% colspan="3" %)机房环境|与环境相关 | ||
174 | |(% colspan="2" rowspan="4" %)服务请求|业务系统权限申请|(% rowspan="4" %)服务请求 | ||
175 | |其他请求服务 | ||
176 | |设备耗材申请 | ||
177 | |软件安装申请 | ||
178 | |(% colspan="3" %)投诉|和投诉相关的事件 | ||
179 | |(% colspan="3" %)其他|其他 | ||
180 | |||
181 | == **5.2错误控制** == | ||
182 | |||
183 | === === | ||
184 | |||
185 | === **5.2.1问题的调查和诊断** === | ||
186 | |||
187 | 对问题进行识别和分类后,问题管理流程应组织力量对引发问题的根本原因进行调查和分析。应该保证问题调查诊断团队拥有较为全面的能力和可靠的工具。 | ||
188 | |||
189 | 当问题的根本原因尚未确定,而变通方案已经准备就绪时,问题管理流程应该在继续问题诊断的同时,公布变通方案的操作程序和细节并对其进行维护,以供事件管理流程参考。当类似事件再次发生时,事件管理流程通过事件匹配,应用相关变通方案,并对事件细节进行记录并汇报给问题管理流程。要保证事件管理流程和问题管理流程之间信息沟通和文档传递的畅通和有效。 | ||
190 | |||
191 | 在问题诊断的过程中,要保证诊断人员能够获得充足的信息和数据资源,包括: | ||
192 | |||
193 | * IT基础设施组件说明文档; | ||
194 | * 配置项信息; | ||
195 | * 流程操作信息等。 | ||
196 | |||
197 | === === | ||
198 | |||
199 | === **5.2.2已知问题的控制** === | ||
200 | |||
201 | 当导致问题发生的根本原因已明确且制定了相应的解决方案后,问题被标识为已知错误。所有已知错误的生命周期都应被严格控制,在可行并成本合理的前提下消除错误并关闭。 | ||
202 | |||
203 | 除了记录发生故障的配置项外,所有已知错误均应根据其已影响和可能影响的服务进行记录。如果正被引入运行环境中的服务出现已知错误,有关已知错误的信息应被传递给服务管理人员,同时与针对该错误的变通方案一起记录在知识库中。 | ||
204 | |||
205 | 问题管理通过变更管理流程落实错误解决方案,纠正已知错误,消除产生问题的根本原因。在通过变更的方式永久解决已知错误之前,已知错误一直存在。只有在一项纠正性变更成功实施后,已知错误才可以被终止。其他特殊的终止原因还包括由于服务不再使用,错误不再发生等。 | ||
206 | |||
207 | 如果问题管理流程提出的已知错误解决方案没有得到客户或供应商的同意(如果出于成本上考虑或者愿意接受服务中断的损失风险等)时,要保持已知错误记录的开放状态,因为它完全有可能导致新的事件和问题的出现,变通方案需要做好记录备用。在这种情况下,问题管理流程有责任对解决方案进行重新研究和评估。 | ||
208 | |||
209 | === === | ||
210 | |||
211 | === **5.2.3沟通** === | ||
212 | |||
213 | 问题及已知错误控制的过程中,问题管理人员应该就变通方案、问题根本原因以及问题处理进展等与受影响的人员和部门保持沟通。 | ||
214 | |||
215 | 在必要的时候,客户和支持人员都应该了解问题的原因和解决方案。问题或事件的最终解决与否应由客户来确认,如果暂时未解决,也应该及时将原因和下一步的计划安排告知客户。 | ||
216 | |||
217 | === === | ||
218 | |||
219 | === **5.2.4跟踪与升级** === | ||
220 | |||
221 | 所有问题的进展应该被跟踪,并恰当地升级到相关方面。跟踪和升级流程应该涵盖以下方面: | ||
222 | |||
223 | * 记录在问题生命周期中负责人员的变动; | ||
224 | * 识别违反服务级别目标的事件; | ||
225 | * 向客户和同事传递信息,使他们能采取行动减轻未解决问题所造成的影响; | ||
226 | * 定义问题升级点; | ||
227 | * 记录使用的资源和采取的行动。 | ||
228 | |||
229 | === === | ||
230 | |||
231 | === **5.2.5记录与关闭** === | ||
232 | |||
233 | 在问题关闭之前需要对问题管理流程中的相关行动进行记录,并且将记录输入到服务级别改进计划中。改进信息应该被记录到问题管理知识库中。所有相关文档应被更新,例如用户指南、系统文档。记录完成之后,由问题经理关闭问题管理流程。 | ||
234 | |||
235 | 记录与关闭过程需要检查下列项目: | ||
236 | |||
237 | * 解决方案的细节都已经详细记录; | ||
238 | * 对原因进行分类来帮助分析; | ||
239 | * 必要时,客户和支持员工都应该了解解决方案; | ||
240 | * 客户认可解决方案已经成功; | ||
241 | * 如果解决方案没成功或者不可能实现,应该告诉客户; | ||
242 | * 知识库更新。 | ||
243 | |||
244 | = **6问题报告** = | ||
245 | |||
246 | |||
247 | == **6.1问题报告** == | ||
248 | |||
249 | 问题处理人员需要向问题经理提交问题报告,该报告应该通报给相关流程负责人(如事件、变更),如有必要,也应该通报体系管理负责人。在问题报告当中应对问题进行描述,并记录问题的解决过程以及问题解决之后系统的运行情况。 | ||
250 | |||
251 | == == | ||
252 | |||
253 | == **6.2问题管理报告** == | ||
254 | |||
255 | 每年应该对整体问题解决方案的有效性进行监控、检查和报告,可以从较高的层面对流程整体进行重新审视,以便发现流程的可改进之处,采取主动的问题预防管理,避免事件和错误的发生。同时,还有助于确定和分析趋势,为其它流程或管理活动(比如客户教育)提供输入。 | ||
256 | |||
257 | 问题管理报告主要应包含以下内容: | ||
258 | |||
259 | * 对主要的一些问题进行回顾; | ||
260 | * 事件/问题出现频率; | ||
261 | * 问题趋势分析及措施。 | ||
262 | |||
263 | = = | ||
264 | |||
265 | = **7流程接口** = | ||
266 | |||
267 | == == | ||
268 | |||
269 | == **7.1事件管理** == | ||
270 | |||
271 | 所有已定义为已知错误的问题都应该通报给事件流程相关人员,更新知识库作为事件处理的参考。 | ||
272 | |||
273 | == == | ||
274 | |||
275 | == **7.2变更管理/配置管理** == | ||
276 | |||
277 | 所有已定义的已知错误的解决方案都应该遵循变更管理的解决流程,需要更新配置项的由配置管理相关人员在变更方案实施后统一更新配置项。 | ||
278 | |||
279 | 变更未通过的(可能出于成本的考虑或者客户愿意接受服务中断风险)也应该保持该问题与变更的关联性以便于查阅。 | ||
280 | |||
281 | = = | ||
282 | |||
283 | = **8持续改进** = | ||
284 | |||
285 | **改进的原因:** | ||
286 | |||
287 | * 流程执行过程中发现的不足; | ||
288 | * 流程自检过程中发现的不足; | ||
289 | * 内部审核及外部审核中,发现的与ISO20000服务管理体系标准的不符合项; | ||
290 | * 管理评审过程中发现的服务/流程改进点。 | ||
291 | |||
292 | **改进方法:** | ||
293 | |||
294 | * 组织流程改进讨论会议,与各方就改进需求、改进目标、改进方案沟通讨论; | ||
295 | * 组织人员根据讨论结果提出服务管理改进计划及方案; | ||
296 | * 服务管理体系负责人审批改进计划; | ||
297 | * 对服务改进过程进行监控,对人事和资源做出合理安排; | ||
298 | * 向管理体系负责人汇报改进结果; | ||
299 | * 根据服务改进结果安排相应的知识转移工作,包括文档的更新发放、培训课程的安排等。 | ||
300 | |||
301 |