Wiki源代码03 ITIL问题管理流程需求说明书
由 superadmin 于 2024/10/10, 21:02 最后修改
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | [[返回本章节索引>>url: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://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/04%20%E6%9F%90%E7%BD%91%E7%AE%A1%E4%B8%AD%E5%BF%83ITIL%E4%BA%8B%E4%BB%B6%E7%AE%A1%E7%90%86%E6%B5%81%E7%A8%8B%E8%AF%A6%E7%BB%86%E8%AE%BE%E8%AE%A1%E8%AF%B4%E6%98%8E%E4%B9%A6/]] | ||
2 | |||
3 | |||
4 | = ** ITIL问题管理流程需求说明书** = | ||
5 | |||
6 | |||
7 | === **1. 流程目的** === | ||
8 | |||
9 | ★问题管理流程的主要功能是消除或减少事件的发生,对于重复发生的事件以及原因不明的事件、以及工作中主动发现的问题须使用问题管理流程进行解决,保持中国XX南方基地 IDC 业务支撑系统的健康性,其目的包括: | ||
10 | |||
11 | * 在成本允许的范围内尽快降低关联事件的重复发生 | ||
12 | * 关联重复发生的事件 | ||
13 | * 管理原因不明的事件 | ||
14 | * 沟通解决问题需要的资源(软件、硬件、网络供应商) | ||
15 | * 和事件经理确认同类事件带来的风险和隐患 | ||
16 | |||
17 | ★进行问题控制 | ||
18 | |||
19 | * 按规范关联重复发生的事件和原因不明的事件并生成问题 | ||
20 | * 分析并诊断问题的根本原因 | ||
21 | * 建立已知错误列表并制订解决方案 | ||
22 | * 制订解决问题的变更方案 | ||
23 | * 监控并跟踪解决方案的实施结果 | ||
24 | * 进行定期的服务流程回顾 | ||
25 | |||
26 | === === | ||
27 | |||
28 | === **2. 流程主要内容** === | ||
29 | |||
30 | |||
31 | 问题(Problem)是导致事件产生的根源。问题管理流程是事件管理流程的延展部分,用于处理大量重复发生的事件以及原因不明的事件,要求独立使用资源进行解决,并根据中国XX南方基地 IDC 现实运维情况排程实施问题的解决方案。该流程包含下述主要内容: | ||
32 | |||
33 | ★问题的生成和记录 | ||
34 | |||
35 | 这个环节是问题管理流程的起点。此步骤的目的是为了能够在中国XX南方基地 IDC 运维事件中发现具有隐患或风险的环节,以协助问题管理人员通知相应厂商或第三方公司进行解决,在此步骤中将会收集重复发生的事件或原因不明的事件的记录信息。 | ||
36 | |||
37 | 该环节的关键是事件记录的准确性和完整性。 | ||
38 | |||
39 | ★问题的分类与支持 | ||
40 | |||
41 | 问题可以是来自中国XX南方基地 IDC 业务环节中的任何一个部分,对每个问题都需要进行分类与分级,并区分来自业务逻辑的问题与来自业务系统的问题。对于没有找到解决方案的问题,需要自动累计关联的事件用以提高问题的严重程度,同时将问题分配给合适的厂商或第三方公司进行调查。 | ||
42 | |||
43 | ★问题的诊断和调查 | ||
44 | |||
45 | 问题常常会表现为具体的技术难题,中国XX南方基地运维团队须支持并协助相关厂商或第三方公司寻求解决方案。 | ||
46 | |||
47 | ★问题的解决与回顾 | ||
48 | |||
49 | 问题在得到解决方案并且通过变更管理流程实施后,须跟踪是否继续出现相应的事件。 | ||
50 | |||
51 | 此环节的关键在于如何更好的识别相应的事件。 | ||
52 | |||
53 | ★已知错误与解决方案 | ||
54 | |||
55 | 已知错误是指找到解决方案但还未通过变更管理流程进行实施的问题处理方法。已知错误应当在变更管理流程中排程实施。 | ||
56 | |||
57 | ★问题的关闭 | ||
58 | |||
59 | 当最终确认问题被解决后,可结束该问题。 | ||
60 | |||
61 | |||
62 | === **3. 与其他流程的关系** === | ||
63 | |||
64 | ★和事件管理流程的关系 | ||
65 | |||
66 | 问题管理流程提供对事件管理流程的统计、分析与优化。合理执行问题管理流程能够降低事件的发生几率,将事件管理逐步导向到平稳运行的状态。 | ||
67 | |||
68 | ★和变更管理流程的关系 | ||
69 | |||
70 | 问题管理流程为变更管理流程提供触发,问题的解决方案会成为执行变更管理流程的动因。 | ||
71 | |||
72 | ★和配置管理流程的关系 | ||
73 | |||
74 | 问题的解决方案通常都会涉及到 IT 基础架构方面的变化,所以,不仅问题的解决过程需要读取配置管理的数据,在实施问题的解决方案的时候也会成为执行配置管理流程的动因。 | ||
75 | |||
76 | |||
77 | === **4. 问题管理服务组织架构概述** === | ||
78 | |||
79 | |||
80 | ===== **4.1.问题经理** ===== | ||
81 | |||
82 | 问题经理从总体上对问题管理流程的设计、实施、执行及优化负责,确保问题管理流程被正确的执行。当流程不能够适应运维实际情况时,问题经理必须及时对此进行分析,找出原因,加以改进,从而实现持续提高。 | ||
83 | |||
84 | 1) 确定并协调必要资源来处理所有(潜在)影响服务级别的所有类型问题,最小化问题的负面影响; | ||
85 | |||
86 | 2) 领导问题管理小组,确保员工的积极性、技能水平和绩效表现; | ||
87 | |||
88 | 3) 保持与其他流程负责人的定期沟通。 | ||
89 | |||
90 | 4) 将问题分派给所属相关专业的问题专家(团队)进行处理; | ||
91 | |||
92 | 5) 跟踪问题解决的过程,必要时进行升级以及问题升级后的协调工作; | ||
93 | |||
94 | 6) 对问题解决方案进行评审; | ||
95 | |||
96 | 7) 将关键问题的解决状态及时地通报给相应的人员和管理层; | ||
97 | |||
98 | 8) 确保制定清晰有效的工作流程和准则; | ||
99 | |||
100 | 9) 确保所有相关人员都足够程度地引入到问题管理的流程中,定期度量问题管理流程执行情况和团队绩效,召开问题管理会议,改进问题管理流程。 | ||
101 | |||
102 | (% class="wikigeneratedid" %) | ||
103 | ===== ===== | ||
104 | |||
105 | ===== **4.2.问题专家(团队)** ===== | ||
106 | |||
107 | 1) 接受问题负责人分派的问题; | ||
108 | |||
109 | 2) 通过在某一方面的专业知识和技能(网络或应用)来支持问题管理经理,确保事件的快速解决和 IT 服务的快速恢复; | ||
110 | |||
111 | 3) 分析诊断问题的根本原因; | ||
112 | |||
113 | 4) 提出解决方案并落实执行; | ||
114 | |||
115 | 5) 提供问题的正确状态、进展和历史信息。 | ||
116 | |||
117 | 6) 必要时协调外部专家团队或供应商参与诊断和解决问题; | ||
118 | |||
119 | 7) 协调变更管理功能,实施解决方案; | ||
120 | |||
121 | 8) 整理常见或典型的问题记录,提交知识申请。 | ||
122 | |||
123 | (% class="wikigeneratedid" %) | ||
124 | ===== ===== | ||
125 | |||
126 | ===== **4.3.问题分析员** ===== | ||
127 | |||
128 | 1) 主动分析,发现和识别问题,并填写问题记录; | ||
129 | |||
130 | 2) 必要时配合问题专家诊断和解决问题; | ||
131 | |||
132 | 3) 关闭问题,确保问题各项记录的完整性。 | ||
133 | |||
134 | 4) 利用现有 IT 环境分析历史数据来改善 IT 系统和工作方法从而避免潜在问题的发生; | ||
135 | |||
136 | 5) 在必要时修正事件或问题的影响度和分类编码; | ||
137 | |||
138 | 6) 在服务中断时,尽快提供临时解决方案,帮助客户尽快恢复正常工作状态; | ||
139 | |||
140 | |||
141 | === **5. 流程执行原则** === | ||
142 | |||
143 | |||
144 | ===== **5.1.常规原则** ===== | ||
145 | |||
146 | ★中国XX南方基地 IDC 业务范围内发生的问题,都应该记录在 IT 服务管理平台中,记录的信息应足够详细,包括与其他流程的关联、问题处理交互过程,详细的解决方案和相应的附件、相应的资产信息。 | ||
147 | |||
148 | ★ 应鼓励事件管理流程相关人员主动提出问题,增加问题的来源渠道,问题分析员应按照专业领域对接收到的问题申请认真分析和识别,进行初步筛选; | ||
149 | |||
150 | ★ 并非所有问题都需立即彻底解决,问题经理应综合考虑成本效益原则,评估问题解决的合适时机; | ||
151 | |||
152 | ★常见和典型的问题解决方案应申请纳入知识库; | ||
153 | |||
154 | ★问题的分类与事件的分类应尽量保持一致; | ||
155 | |||
156 | ★每月应召集问题管理会议,产生和回顾问题管理报表,以改进问题管理流程。对于未解决的问题,每月举行的问题管理会议进行讨论与分析。 | ||
157 | |||
158 | ★中国移动南方基地所有 IT 支持人员须有效响应问题专家(团队)、厂商或第三方公司为解决问题而进行的技术性工作。 | ||
159 | |||
160 | ★半年对流程进行回顾,回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性,以改进问题管理流程。 | ||
161 | |||
162 | (% class="wikigeneratedid" %) | ||
163 | ===== ===== | ||
164 | |||
165 | ===== **5.2.流程关联原则** ===== | ||
166 | |||
167 | ★和事件管理的关联 | ||
168 | |||
169 | * 事件处理工程师、问题分析员、事件经理需要对多次重复发生的事件在恢复服务后,创建问题;并将同类事件的信息与问题进行关联。 | ||
170 | * 事件管理对问题管理来说是重要的信息来源,多次重复发生的事件在恢复服务后,都应创建问题; | ||
171 | * 问题管理一旦找到问题的根本原因,将为以后相关事件的解决提供解决方案; | ||
172 | |||
173 | ★和变更管理的关联 | ||
174 | |||
175 | * 所有 IT 资源发生的变更记录在问题管理流程中需要能够根据资源进行查询。 | ||
176 | * 所有问题的解决方案都必须通过变更管理流程实施; | ||
177 | * 失败的变更应该发起问题流程调查失败原因; | ||
178 | * 变更管理负责控制执行变更。变更完成后,应向问题管理反馈变更执行的结果; | ||
179 | |||
180 | ★ 和配置管理的关联 | ||
181 | |||
182 | * 问题管理流程中须能够关联与产生问题相关的 IT 资源的配置数据。 | ||
183 | * 所有问题的解决方案都必须在配置管理流程中记录。 | ||
184 | |||
185 | (% class="wikigeneratedid" %) | ||
186 | ===== ===== | ||
187 | |||
188 | ===== **5.3.所有权原则** ===== | ||
189 | |||
190 | 所有权原则用来确保每个问题都能有适当的人员在进行解决方案的分析与验证。 | ||
191 | |||
192 | * 问题分析员负责问题的发起与审核,并对问题单负责,并且辅助问题专家进行信息搜集及分析; | ||
193 | * 问题经理负责对整个问题的监督工作; | ||
194 | |||
195 | (% class="wikigeneratedid" %) | ||
196 | ===== ===== | ||
197 | |||
198 | ===== **5.4.关闭原则** ===== | ||
199 | |||
200 | * 问题处理人员在解决方案分析与验证过程中,必须提供备用的应急处理方法供事件处理使用。 | ||
201 | * 在解决方案实施后一个月内不再发生与问题相关的重复事件则可认为问题已经解决。 | ||
202 | * 在问题关闭前,应确保问题单相关信息的完整性; | ||
203 | * 在问题经理充分评估问题后,对于哪些无法找到根本原因或解决方案的问题以及根据现状无需现阶段立即解决的问题,在得到领导批准后后,可以将问题关闭,并备注原因。 | ||
204 | * 在解决方案验证后可将问题关闭。 | ||
205 | * 在问题关闭后,如再次出现相应事件,则须重新打开问题继续验证解决方案的正确性 | ||
206 | |||
207 | (% class="wikigeneratedid" %) | ||
208 | === === | ||
209 | |||
210 | === **6. 流程相关定义** === | ||
211 | |||
212 | |||
213 | ===== **6.1.问题信息项** ===== | ||
214 | |||
215 | 问题单必须包含如下图表 2 问题信息项: | ||
216 | |||
217 | [[image:微信图片_20240708145358.png]] | ||
218 | |||
219 | |||
220 | [[image:微信图片_20240708145443.png]] | ||
221 | |||
222 | |||
223 | [[image:微信图片_20240708145527.png]] | ||
224 | |||
225 | |||
226 | [[image:微信图片_20240708145611.png]] | ||
227 | |||
228 | |||
229 | [[image:微信图片_20240708145650.png]] | ||
230 | |||
231 | |||
232 | ===== **6.2.问题来源** ===== | ||
233 | |||
234 | **问题来源** | ||
235 | |||
236 | 问题来源代码用来标明问题的提出方式,问题来源可以包括以下几种: | ||
237 | |||
238 | [[image:微信图片_20240708145746.png]] | ||
239 | |||
240 | [[image:微信图片_20240708145816.png]] | ||
241 | |||
242 | |||
243 | ===== **6.3.问题处理概要流程** ===== | ||
244 | |||
245 | 从问题的生命周期出发,将问题管理过程分解为以下 6 个一级过程,形成问题管理过程的概要过程。对该 6 个过程所包含的活动,将在后续的章节中做进一步的细化和说明。流程图表 1-1 是问题处理概要流程图。 | ||
246 | |||
247 | 1) 问题的识别和记录 | ||
248 | |||
249 | 确定和记录问题; | ||
250 | |||
251 | 2) 问题分类和分派 | ||
252 | |||
253 | 设定问题优先级、分类等,并且将问题安排给合适的问题处理组; | ||
254 | |||
255 | 3) 问题调查和诊断 | ||
256 | |||
257 | 调查分析问题的根本原因; | ||
258 | |||
259 | 4) 问题解决 | ||
260 | |||
261 | 根据问题分析的根本原因,提供问题解决方案或变通措施; | ||
262 | |||
263 | 5) 问题关闭 | ||
264 | |||
265 | 如果问题得到了解决,则遵循问题关闭过程结束该问题; | ||
266 | |||
267 | 6) 问题监视 | ||
268 | |||
269 | 监视问题的处理过程,必要时进行管理升级并负责和相关方沟通 | ||
270 | |||
271 | |||
272 | [[image:微信图片_20240708145930.png]] | ||
273 | |||
274 | |||
275 | ===== **6.4.问题识别和记录** ===== | ||
276 | |||
277 | 问题的识别和记录过程是对如何识别和记录问题所进行具体的描述,参见流程图表 1-2 问题识别和记录流程图。 | ||
278 | |||
279 | [[image:微信图片_20240708150018.png]] | ||
280 | |||
281 | |||
282 | **6.4.1 发现问题** | ||
283 | |||
284 | 问题的来源: | ||
285 | |||
286 | 1) 事件分析总结,没有解决方案的事件、重复发生的事件; | ||
287 | |||
288 | 2) 事件经理审核事件报告时,认为根本原因没有得到识别或解决的事件; | ||
289 | |||
290 | 3) 事件经理通过主动式分析(如事件发生的趋势),认为有必要作为问题进行分析的异常现象; | ||
291 | |||
292 | 4) 变更失败后,可能需要生成一个问题进入后续的解决过程。 | ||
293 | |||
294 | 问题记录的基本信息应包括: | ||
295 | |||
296 | 1) 问题创建人; | ||
297 | |||
298 | 2) 问题创建人电话及电子邮件; | ||
299 | |||
300 | 3) 问题创建时间; | ||
301 | |||
302 | 4) 问题报告人及联系方式; | ||
303 | |||
304 | 5) 问题描述; | ||
305 | |||
306 | 6) 问题编号; | ||
307 | |||
308 | 7) 问题状态,系统自动成为“新建”; | ||
309 | |||
310 | |||
311 | **6.4.2 查询知识库** | ||
312 | |||
313 | 问题经理或问题分析员发现问题后,查询知识库确认此问题是否已有解决方案。如果有解决方案,转到(1.2.3)解决问题,否则转到(1.2.4)创建问题单。 | ||
314 | |||
315 | |||
316 | **6.4.3 应用解决方案** | ||
317 | |||
318 | 问题分析员或问题经理在找到问题解决方案后,要尽快实施解决方案,解决 | ||
319 | |||
320 | 问题。在问题得到解决后,则转入(1.6.2)填写问题关闭代码,关闭问题。 | ||
321 | |||
322 | 问题基本信息应包括: | ||
323 | |||
324 | 1) 问题解决方案; | ||
325 | |||
326 | 2) 问题处理过程及方法; | ||
327 | |||
328 | 3) 问题实际开始时间; | ||
329 | |||
330 | 4) 问题实际完成时间; | ||
331 | |||
332 | 5) 问题状态(已解决); | ||
333 | |||
334 | |||
335 | **6.4.4 创建问题单** | ||
336 | |||
337 | 问题分析员或问题经理根据问题具体情况,填写问题单。问题经理判断是否能够构成一个问题,如果构成问题,则转入(1.3)问题分类和分派,否则关闭问题。具体信息包括: | ||
338 | |||
339 | 1) 问题描述; | ||
340 | |||
341 | 2) 问题汇报时间; | ||
342 | |||
343 | 3) 预计开始时间; | ||
344 | |||
345 | 4) 预计完成时间; | ||
346 | |||
347 | 5) 问题状态(新建或已分派); | ||
348 | |||
349 | |||
350 | **6.4.5 注明原因后关闭问题** | ||
351 | |||
352 | 问题经理认为不能构成一个问题,或者没有价值、资源来进行问题处理的,则注明原因后关闭问题。具体信息包括: | ||
353 | |||
354 | 1) 问题描述; | ||
355 | |||
356 | 2) 问题状态(已取消); | ||
357 | |||
358 | (% class="wikigeneratedid" %) | ||
359 | ===== ===== | ||
360 | |||
361 | ===== **6.5.问题分类和分派** ===== | ||
362 | |||
363 | 问题分类和分派过程是问题经理接受和安排相应的问题处理组以进行处理的过程,参见流程图表 1-3 问题分类和分派流程图。 | ||
364 | |||
365 | [[image:微信图片_20240708150909.png]] | ||
366 | |||
367 | |||
368 | **6.5.1 完善问题信息** | ||
369 | |||
370 | 问题经理收到问题单后,应与问题联络人沟通,确定问题性质,以安排合理的资源对问题进行处理。具体信息包括: | ||
371 | |||
372 | 1) 问题报告人; | ||
373 | |||
374 | 2) 问题报告人联系方式及电子邮件; | ||
375 | |||
376 | 3) 问题报告人; | ||
377 | |||
378 | 4) 关联事件编号; | ||
379 | |||
380 | 5) 关联 CI; | ||
381 | |||
382 | |||
383 | **6.5.2 判断严重等级与分类** | ||
384 | |||
385 | 问题的优先级是问题分析员解决问题的参照标准,对于关键优先级的问题,问题经理应该优先协调资源进行这些问题的解决。问题的优先级定义如下图表 5 | ||
386 | |||
387 | [[image:微信图片_20240708151018.png]] | ||
388 | |||
389 | |||
390 | [[image:微信图片_20240708151103.png]] | ||
391 | |||
392 | |||
393 | **问题分类:** | ||
394 | |||
395 | 问题分类是针对问题所属的专业类型进行划分的,通过问题分类可以定位解决问题的人,并针对问题分类进行分类统计,参见图表 6。 | ||
396 | |||
397 | [[image:微信图片_20240708151145.png]] | ||
398 | |||
399 | [[image:微信图片_20240708151215.png]] | ||
400 | |||
401 | |||
402 | 问题记录基本信息包括: | ||
403 | |||
404 | 1) 问题描述,症状描述和任何错误代码(可以通过附加文件的方式予以描述); | ||
405 | |||
406 | 2) 问题的分类(参见图表 6); | ||
407 | |||
408 | 3) 问题的分级(参见图表 5); | ||
409 | |||
410 | 4) 问题状态(新建)。 | ||
411 | |||
412 | |||
413 | **6.5.3 进行关联** | ||
414 | |||
415 | 问题经理判断此问题是否与其他问题相关,如果相关,则进行问题关联,并且更新问题相关信息。需要记录信息包括: | ||
416 | |||
417 | 1) 问题描述; | ||
418 | |||
419 | 2) 关联问题编号。 | ||
420 | |||
421 | |||
422 | **6.5.4 分派问题** | ||
423 | |||
424 | 问题经理根据设置的问题分类和优先级,协调合适的问题专家(团队)进行处理,并进行派单。为降低问题派单后被退单以及派单后问题专家未能及时获得派单信息(如在开会或不在座位),建议: | ||
425 | |||
426 | 1) 当前每次在问题的分派前电话通知被分派人员,同时发送短信或邮件; | ||
427 | |||
428 | 2) 如果发现人员安排紧张时,应优先安排优先级高的问题。 | ||
429 | |||
430 | 派单后应在系统中记录的信息包括: | ||
431 | |||
432 | 1) 描述信息; | ||
433 | |||
434 | 2) 派单时间; | ||
435 | |||
436 | 3) 被派单人; | ||
437 | |||
438 | 4) 问题的状态; | ||
439 | |||
440 | |||
441 | **6.5.5 接受分配** | ||
442 | |||
443 | 问题专家(团队)接受到派单后,应立即着手对问题进行调查和分析。 | ||
444 | |||
445 | 1) 如果问题派单错误,则立即告知问题经理重新派单,并阐述理由; | ||
446 | |||
447 | 2) 如果接受该派单,则开始问题调查与分析; | ||
448 | |||
449 | 3) 接单后,确认问题单信息是否足够、描述是否清楚,否则联系相关人员搜集信息; | ||
450 | |||
451 | 受单时应在系统中记录的信息包括: | ||
452 | |||
453 | 1) 受单人; | ||
454 | |||
455 | 2) 受单时间; | ||
456 | |||
457 | 3) 问题状态(已分派); | ||
458 | |||
459 | (% class="wikigeneratedid" %) | ||
460 | ===== ===== | ||
461 | |||
462 | ===== **6.6.问题调查与诊断** ===== | ||
463 | |||
464 | 问题调查和诊断过程是问题专家(团队),对问题进行分析和诊断的过程,参见下图 1-4 问题调查与诊断流程图 | ||
465 | |||
466 | [[image:微信图片_20240708151633.png]] | ||
467 | |||
468 | |||
469 | **6.6.1 分析诊断问题** | ||
470 | |||
471 | 问题专家接受到派单后,应立即着手对问题进行调查和分析,提供问题解决方案、方法。 | ||
472 | |||
473 | |||
474 | **6.6.2 确认问题根源** | ||
475 | |||
476 | 问题专家对问题进行分析和诊断,找出可能的原因列表。如果不能找到问题根源,则转入(1.3.4)问题经理重新分派问题。 | ||
477 | |||
478 | |||
479 | **6.6.3 记录问题根源** | ||
480 | |||
481 | 问题专家对确认的问题的原因进行记录,判断此问题是否是已知问题。如果是已知问题,则进行已知问题关联,否则转入(1.5.)问题解决。 | ||
482 | |||
483 | 确认根本原因阶段应记录的信息包括: | ||
484 | |||
485 | 1) 问题原因描述; | ||
486 | |||
487 | 2) 解决方案、方法描述; | ||
488 | |||
489 | 3) 问题状态(处理中)。 | ||
490 | |||
491 | 6.6.4 关联已知问题 | ||
492 | |||
493 | 问题专家关联已知问题,需要记录信息包括: | ||
494 | |||
495 | 1) 问题描述; | ||
496 | |||
497 | 2) 关联已知问题编号; | ||
498 | |||
499 | (% class="wikigeneratedid" %) | ||
500 | ===== ===== | ||
501 | |||
502 | ===== **6.7.问题解决** ===== | ||
503 | |||
504 | 根据问题分析的根本原因,提供问题解决方案或变通措施,参见图表 1-5 问题解决流程图 | ||
505 | |||
506 | [[image:微信图片_20240708151820.png]] | ||
507 | |||
508 | |||
509 | **6.7.1 搜索已有解决方案** | ||
510 | |||
511 | 问题专家搜索已有的解决方案,判断已有的解决方案能否解决问题。如果已有解决方案能解决问题,则转入(1.5.2),否则转入(1.5.4)尝试解决。需要记录的信息包括: | ||
512 | |||
513 | 1) 问题解决方案; | ||
514 | |||
515 | 2) 问题状态(处理中)。 | ||
516 | |||
517 | |||
518 | **6.7.2 发起变更流程解决问题** | ||
519 | |||
520 | 问题专家分析问题的解决办法,判断实施解决方案是否对生产系统产生影响。如果对生产系统有影响,则转入变更管理进行变更请求与解决。 | ||
521 | |||
522 | 创建变更请求需要记录的信息包括: | ||
523 | |||
524 | 1) 问题解决方案; | ||
525 | |||
526 | 2) 创建变更单; | ||
527 | |||
528 | 3) 问题状态(等待); | ||
529 | |||
530 | |||
531 | **6.7.3 尝试解决** | ||
532 | |||
533 | 如果已有的解决方案不能解决现有问题,问题专家就要尝试解决问题。如果问题专家认为可以解决,则转入(1.5.2)开始解决问题,否则转入(1.5.3)问题经理重新分配问题。 | ||
534 | |||
535 | |||
536 | **6.7.4 解决问题** | ||
537 | |||
538 | 问题专家制定完成问题解决方案后,开始实施问题解决方案。问题解决后,按(1.6)关闭事件。 | ||
539 | |||
540 | 记录的信息包括: | ||
541 | |||
542 | 1) 处理人; | ||
543 | |||
544 | 2) 实际开始时间; | ||
545 | |||
546 | 3) 实际完成时间; | ||
547 | |||
548 | 4) 问题解决方案; | ||
549 | |||
550 | 5) 事件状态(已解决); | ||
551 | |||
552 | |||
553 | **6.7.5 重新分配** | ||
554 | |||
555 | 对于问题专家不能解决的问题,问题经理要重新分配。 | ||
556 | |||
557 | 如果问题经理分析认为其他的问题专家可以解决此问题,则转入(1.3.4)重新分配问题。 | ||
558 | |||
559 | 如果问题经理判断没必要解决此问题,则转入(1.6.2)填写关闭代码。 | ||
560 | |||
561 | (% class="wikigeneratedid" %) | ||
562 | ===== ===== | ||
563 | |||
564 | ===== **6.8.问题关闭** ===== | ||
565 | |||
566 | 问题关闭过程是问题得到解决后,应该遵循问题关闭的具体过程,下图是问题关闭的流程图 | ||
567 | |||
568 | [[image:微信图片_20240708151951.png]] | ||
569 | |||
570 | |||
571 | **6.8.1 验证问题解决结果** | ||
572 | |||
573 | 在问题的解决方案得到实施后,发起问题的问题分析员对实施结果进行验证,以确认问题得到妥善解决。 | ||
574 | |||
575 | 如果问题分析员判断问题是正常解决并且有价值,更新知识库,转入(3.6.2)填写关闭代码。 | ||
576 | |||
577 | 如果问题是通过变通方法解决,问题分析员判断是否接受,否则重新分配问题。 | ||
578 | |||
579 | |||
580 | **6.8.2 填写关闭代码** | ||
581 | |||
582 | 问题关闭代码如下表所示: | ||
583 | |||
584 | [[image:微信图片_20240708152040.png]] | ||
585 | |||
586 | 该阶段应该记录的信息包括: | ||
587 | |||
588 | 1) 描述信息; | ||
589 | |||
590 | 2) 问题预关闭时间; | ||
591 | |||
592 | 3) 问题关闭状态; | ||
593 | |||
594 | |||
595 | **6.8.3 关闭工单** | ||
596 | |||
597 | 关闭后的问题即为“已知错误”,在问题被关闭的同时将问题以及相应的解决方案应用到事件管理流程当中。 | ||
598 | |||
599 | 该阶段应该记录的信息包括: | ||
600 | |||
601 | 1) 问题关闭时间; | ||
602 | |||
603 | 2) 问题关闭状态(已关闭)。 | ||
604 | |||
605 | (% class="wikigeneratedid" %) | ||
606 | ===== ===== | ||
607 | |||
608 | ===== **6.9.问题监视** ===== | ||
609 | |||
610 | 问题在创建后,问题经理应对对这些问题的状态进行监视,如下图所示: | ||
611 | |||
612 | [[image:微信图片_20240708152125.png]] | ||
613 | |||
614 | |||
615 | **6.9.1 定期确认问题状态** | ||
616 | |||
617 | **问题经理负责定期确认和跟踪问题的处理状态。** | ||
618 | |||
619 | |||
620 | **6.9.2 发送提醒** | ||
621 | |||
622 | 问题管理流程中,具体问题处理一般不对解决时限作严格的时间要求。但为保证问题得到必要的重视,问题经理将根据问题的优先级别,通过短信/Email方式定期提醒问题分析员。 | ||
623 | |||
624 | |||
625 | === **7.工单状态迁移表** === | ||
626 | |||
627 | **[[image:微信图片_20240708152229.png]]** | ||
628 | |||
629 | |||
630 | === **8. 问题管理过程的 KPI** === | ||
631 | |||
632 | 为保证问题管理过程更好的得到执行,定义以下关键指标。问题管理经理应每半年度对所定义的指标进行统计和分析。 | ||
633 | |||
634 | 特别说明:问题管理过程涉及到对内对外服务的 KPI 指标,部分指标仅适用于内部服务。 | ||
635 | |||
636 | 1) 每一类问题数量占问题总量的比例(%) | ||
637 | |||
638 | 了解 IT 基础设施在哪些方面(网络、服务器等)存在问题较多 | ||
639 | |||
640 | 2) 问题成功得到解决的比例(%) | ||
641 | |||
642 | 在一定时间范围内,成功得到关闭的问题数量占总问题量的百分比 | ||
643 | |||
644 | 3) 优先级为高的问题所占比例(%) | ||
645 | |||
646 | 当前处理的任务中,有多少是优先级最高的问题,代表着 IT 基础架构和管理中的薄弱环节 | ||
647 | |||
648 | 4) 已处理问题的平均时间统计 | ||
649 | |||
650 | 成功得到关闭的问题平均处理时间,了解问题整体处理的效率。 | ||
651 | |||
652 | 5) 申请变更的问题~(%) | ||
653 | |||
654 | 统计问题处理过程中涉及到 CI 变更的问题比例 | ||
655 | |||
656 | 6) 各类别重复问题~(%) | ||
657 | |||
658 | 统计各类问题处理过程中问题为重复问题占总问题数量的百分比 | ||
659 | |||
660 | 7) 已知错误问题~(%) | ||
661 | |||
662 | 统计问题处理过程中问题为已知错误问题占总问题数量的百分比 | ||
663 | |||
664 | |||
665 | [[返回本章节索引>>url: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://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/04%20%E6%9F%90%E7%BD%91%E7%AE%A1%E4%B8%AD%E5%BF%83ITIL%E4%BA%8B%E4%BB%B6%E7%AE%A1%E7%90%86%E6%B5%81%E7%A8%8B%E8%AF%A6%E7%BB%86%E8%AE%BE%E8%AE%A1%E8%AF%B4%E6%98%8E%E4%B9%A6/]] |