由 superadmin 于 2024/10/15, 16:41 最后修改
Show last authors
1 [[返回本章节索引 >>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/]] [[阅读下一章>>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/20%20%E6%9F%90%E5%B8%82%E5%95%86%E5%93%81%E4%BA%A4%E6%98%93%E6%89%80%E9%97%AE%E9%A2%98%E7%AE%A1%E7%90%86%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E8%AF%B4%E6%98%8E%E4%B9%A6/]]
2
3
4 **版本记录**
5
6 |**文档名称**|**变更说明**|**版本号**|**日期**|**编写人**|**审核人**
7 |问题管理程序|新建文档|V1.0|2017年12月25日|董XX|
8 |问题管理程序|新建文档|V1.1|2018年1月11日|董XX|
9 |问题管理程序|新建文档|V1.2|2018年1月17日|董XX|
10 |问题管理程序|新建文档|V1.3|2018年2月1日|董XX|
11 | | | | | |
12 | | | | | |
13
14 注：本表记录本文档的变更记录。
15
16
17 = 1文档介绍 =
18
19 == 1.1文档简介 ==
20
21 本文档是XX信息化中心调度室(以下简称调度室)制定的问题管理程序文件。通过制定该流程，可以帮助交付中心的IT运维有效降低或消除事件、重复事件的数量，提高IT系统和服务的质量,向业务人员和相关用户提供更优质的IT服务，并且可以有效地帮助技术部的IT运行管理从被动管理转向主动管理。
22
23 == ==
24
25 == 1.2文档用途 ==
26
27 本文档作为问题管理流程的策略文件，读者对象为与问题管理流程相关的所有技术与管理人员。
28
29 本文档所描述的流程在IT服务管理中有许多作用，举例如下：
30
31 * 找出问题的根本原因，并确定永久性解决方案
32 * 防止同类事件的重复发生，改进IT部门的服务可用性
33 * 降低突发事件的数量，提高IT人员的效率
34 * 提高IT资源的使用率，降低支持成本
35 * 可减少关键业务系统的停机时间和中断现象，提高业务人员的工作效率
36 * 提高客户的满意度
37
38 = =
39
40 = 2概述 =
41
42 问题管理流程的根本目的是消除或减少生产环境中事件发生的数量和严重程度，从而为客户建立一个稳定的IT环境，提高IT服务的可用性。此流程对发生的事件进行分析，确定最常发生或具有重大影响但没有根本解决的事件，找出产生这些事件的根本原因，然后根据需要通过变更请求(RFC)、变通方法或建议的预防性措施来防止事件的再次发生。问题管理流程常常需要和变更管理流程一起来实施找出的解决方案，以便从根本上解决问题。
43
44 问题管理流程中的问题通常具有如下特征：
45
46 * 一个没有从根本上解决的重大或紧急事件(事件处理结束后定义为问题，由问题管理找出根本解决方案)；
47 * 一组具有一定关系或相似特征的已关闭的事件。
48
49 问题管理的输入有：
50
51 * 从事件管理中得到的事件详细信息
52
53 * 事件现象
54 * 事件的处理方法和解决方案
55 * 事件发生影响程度及紧急程度
56 * 事件的变通解决办法
57
58 * 从配置管理数据库中得到的配置详细信息
59
60 * 相关的配置信息
61 * 配置项之间的关联关系
62
63 问题管理流程的输出有：
64
65 * 已知错误/知识条目
66 * 变更请求
67 * 变通方法/预防性措施/解决方案
68
69 == ==
70
71 == 2.1流程目的 ==
72
73 问题管理流程的主要目的是分析已被列为问题的事件（一组或一个）的根本原因，然后找出和建议根本解决方案。其目的包括：
74
75 * 分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生
76 * 确保问题分派了正确问题分析员，提高解决率
77 * 根据问题优先级合理分派IT资源
78 * 对事件记录做趋势性分析，主动提供预防性措施
79 * 提高IT服务的可靠性
80 * 降低IT支持成本
81
82 == ==
83
84 == 2.2问题策略 ==
85
86 === 2.2.1问题分类 ===
87
88 |**类别**|**子类**|**维护所属**|**备注**
89 |(% rowspan="5" %)三网业务系统|家庭宽带|信息站|
90 |办公宽带|信息站|
91 |家庭电话|信息站|
92 |办公电话|信息站|
93 |数字电视|数字电视部|
94 |(% rowspan="11" %)安全生产类系统|调度电话|基础网络部|
95 |安全监测数据联网系统|自动化部|
96 |综合自动化系统|自动化部|
97 |机房监控系统|自动化部|
98 |工业电视系统|自动化部|
99 |应急指挥系统|自动化部|
100 |综合调度系统|自动化部|
101 |综合调度显示系统|自动化部|
102 |煤化工能源管理系统|自动化部|
103 |煤化工生产联网监测系统|自动化部|
104 |安防监控系统|自动化部|
105 |(% rowspan="24" %)经营管理类系统|兖矿集团财务公司资金集中管理信息系统|应用系统部|
106 |兖矿云考勤系统|应用系统部|
107 |呼叫中心系统运维|应用系统部|
108 |短信平台系统|应用系统部|
109 |电子招投标系统|应用系统部|
110 |物资商城系统|应用系统部|
111 |MDM主数据系统|应用系统部|
112 |SRM系统|应用系统部|
113 |ERP系统|应用系统部|
114 |合同管理系统|应用系统部|
115 |计划生育系统|应用系统部|
116 |人力资源管理系统|应用系统部|
117 |养老保险系统|应用系统部|
118 |国资监管系统|应用系统部|
119 |坚果云系统|应用系统部|
120 |三网融合系统（综合电信系统）|应用系统部|
121 |总医院PACS系统|应用系统部|
122 |计划统计系统|应用系统部|
123 |经营调度系统|应用系统部|
124 |煤炭交易系统|应用系统部|
125 |审计系统|应用系统部|
126 |OA系统|应用系统部|
127 |网站系统|应用系统部|
128 |电邮系统|应用系统部|
129 |(% rowspan="7" %)其他业务系统|骨干网络|基础网络部|
130 |专网系统|基础网络部|
131 |运营商专线|基础网络部|
132 |公安国安审计系统|基础网络部|
133 |视频会议系统|基础网络部|
134 |机房基础环境|基础网络部和信息站|
135 |云系统|应用系统部|
136
137 表2-2-1 问题分类表
138
139
140 === 2.2.2问题分级 ===
141
142 |**影响范围**|**定义示例**
143 |1级  严重|造成多站点整体通信故障，大面积骨干传输网中断，多个集团级应用系统整体瘫痪，主要通信枢纽节点多点断线等情况之一的故障级别。
144 |2级  高|造成个别站点整体通信故障，单个集团级应用系统瘫痪，主要通信枢纽个别节点断线，骨干传输网络个别节点故障等情况之一的故障级别。
145 |3级  中|造成个别站点区域内部网络、通信、数字电视系统多点故障，个别被服务单位内部多个应用系统瘫痪等情况之一的故障级别。
146 |4级  低|造成个别站点区域内局部网络、通信、数字电视故障，个别被服务单位内部个别系统故障等情况之一的故障级别。
147
148 |**紧急程度**|**定义示例**
149 |1级 紧急|故障发生突然，需要恢复，紧急
150 |2级 高|系统功能受到影响，部分功能不可用，高
151 |3级 中|系统仍可使用或无需马上解决，中
152 |4级 低|系统仍可使用或任何时候解决都行，低
153
154 问题分级结论
155
156 |(((
157 **~ 影响范围**
158
159 **紧急程度**
160 )))|**1级 严重**|**2级 高**|**3级 中**|**4级 低**
161 |**1级 紧急**|紧急（级别1）
162 S1|紧急（级别1）
163 S1|严重（级别2）
164 S2|重大（级别3）
165 S3
166 |**2级 高**|紧急（级别1）
167 S1|紧急（级别1）
168 S1|严重（级别2）
169 S2|重大（级别3）
170 S3
171 |**3级 中**|严重（级别2）
172 S2|严重（级别2）
173 S2|一般（级别4）
174 S4|一般（级别4）
175 S4
176 |**4级 低**|重大（级别3）
177 S3|重大（级别3）
178 S3|一般（级别4）
179 S4|无故障（级别5）
180 S4
181
182 S1为最高级需优先处理，S2为次高级第二处理，S3为严重级第三处理，S3为一般级第四处理，S5为最低级最后处理。
183
184
185 [[image:1728805530115-551.png]]
186
187
188 === 2.2.3问题解决时间 ===
189
190 |**优先级**|**处理时间**|**问题单关闭**
191 |S1|2小时|1天
192 |S2|4小时|2天
193 |S3|8小时|3天
194 |S4|24小时|7天
195
196 === ===
197
198 === 2.2.4问题升级 ===
199
200 |**问题升级**|**问题提交人**|**问题分析员**|**问题管理岗**|**技术总监**
201 |S1|2小时|1小时|2小时|4小时
202 |S2|4小时|2小时|4小时|8小时
203 |S3|8小时|4小时|8小时|——
204 |S4|24小时|12小时|24小时|——
205
206 达到以上要求时限，按照列表进行对应的通知。
207
208
209 = 3流程范围 =
210
211 交付中心问题管理范围是对用户的IT生产环境中发生的问题进行管理，并采取主动性预防措施来降低事件数量。
212
213 = =
214
215 = 4流程详述 =
216
217 == 4.1问题管理的主要流程 ==
218
219 [[image:1728805581131-729.png]]
220
221
222 问题管理触发后，首先应由指定的责任工程师编制合理的问题解决计划，如果需要协调配合，还应将问题分解成多个任务，分别指派给合适的工程师去分步解决。当问题所涉及的全部任务均完成后，应当由该问题的责任工程师汇总详细解决方案并归档，关闭问题并使之成为一个已知问题，从而结束问题管理的全部流程。
223
224 在问题管理流程中，如涉及配置及业务变更，还应当发起相应的变更请求，由变更管理小组负责实施相关变更。
225
226 问题管理流程同时也受到服务水平协议和服务可用性协议的监督。当问题被成功解决成为已知问题后，还可以将问题发布为公告，以告之用户问题的处理结果和详细的解决方案。
227
228 == ==
229
230 == 4.2问题的创建 ==
231
232 问题的创建分为主动问题和被动问题，主动问题是问题提交人根据对事件、监控告警、采集数据等资料的分析，根据自身的判断直接申报新的问题。主动式问题如果能够在事件发生之前得到解决方案，规避或者预防事件的发生，将大幅提升服务质量，体现更高的服务价值。
233
234 被动问题主要是来源于事件的问题，一般是指在事件处理过程中没有根本解决，从而申报的新问题。
235
236 问题创建的输入包括：问题分类、问题的描述、问题发生的环境、问题提交人、相关客户和项目、期望解决的时限、问题的紧急程度和影响范围。
237
238 问题创建的输出结果为待确认的问题单。
239
240 |**活动**|**描述**|**责任人**|**输入**|**输出**
241 |提交新的问题|申报新的问题|问题提交人|新的问题|待确认的问题
242 |问题分类|对问题进行分类|问题提交人|新的问题|待确认的问题(分类确定)
243 |确定问题优先级|对问题进行业务影响度分析，初步确定影响范围和紧急程度|问题提交人|新的问题|待确认的问题(优先级确定)
244 |如有必要关联相关事件和配置项|关联相关事件和所涉及配置|问题提交人|新的问题|待确认的问题(关联了事件和配置)
245
246 == ==
247
248 == 4.3问题的确认与分析 ==
249
250 新建的问题提交到问题协调员（服务台），由问题协调员进行确认，检查各个字段信息填写是否符合规范。如果信息需要补充的，退回提交人进行完善。如果确认没问题，然后问题进行初步分析，判断分类信息、严重程度紧急程度填写是否准确，必要时进行调整，然后指派合适的问题分析员（一般是二线工程师）进行跟踪处理。
251
252
253 |**活动**|**描述**|**责任人**|**输入**|**输出**
254 |问题确认|(((
255 是否属于问题管理范畴
256
257 问题填写内容是否规范，完整
258 )))|问题协调员 |待确认的问题|已确认的问题
259 |问题退回|(((
260 对需要补充、完善的问题单
261
262 不属于问题范畴的问题单
263 )))|问题协调员|待确认的问题|退回的问题
264 |问题分类调整|对问题的分类进行调整|问题协调员|已确认的问题|已确认的问题(分类确定)
265 |问题优先级调整|对问题的紧急程度、影响范围、优先级进行调整|问题协调员|已确认的问题|已确认的问题(严重度确定)
266
267 == ==
268
269 == 4.4问题的调度与分派 ==
270
271 问题协调员在对问题分析之后，没有合适的解决方案。需要对问题单进行合理的分派。分派原则优先本项目组内对应的工程师/二线工程师，其次本交付团队内的二线工程师，然后是全国二线工程师。如果需要费本项目组的二线工程出到现场支持，需要通过对应的交付经理协调调度。
272
273
274 |**活动**|**描述**|**责任人**|**输入**|**输出**
275 |分派问题|(((
276 对于已确认但没有找到解决方案的问题，问题协调员根据问题的描述和分类，分派合适的分析员进行处理。
277
278 如果需要异地二线工程师出现场，那么需要和工程师所在的交付经理进行沟通，由交付经理协调调度
279 )))|问题协调员|已确认的问题|已分派的问题
280
281 == ==
282
283 == 4.5问题的协调调度 ==
284
285 根据公司的组织结构，如果涉及异地的二线工程师或二线专家去现场，需要由二线经理，安排出差的时间计划，同时需要工程师发起出差申请。
286
287 |**活动**|**描述**|**责任人**|**输入**|**输出**
288 |协调调度二线支持人员|(((
289 问题管理岗和对应的责任人协调后，安排出差时间、计划。审批出差流程。
290
291 行政配合订票和住宿等相关事宜。
292 )))|交付经理、二线专家经理|已确认的问题|已分派的问题
293
294 == ==
295
296 == 4.6问题的调查诊断和恢复 ==
297
298 本阶段的内容就是问题分析员对问题进行处理解决。
299
300 |**活动**|**描述**|**责任人**|**输入**|**输出**
301 |调查诊断|根据自身经验对问题进行深入分析，采取各种手段进行尝试解决。|问题分析员|处理中的问题|处理中的问题
302 |创建变更请求|(((
303 若明确问题原因，需要通过实施变更才能解决，则为解决问题创建RFC。
304
305 任务：创建变更单
306 )))|问题分析员|处理中的问题|(((
307 处理中的问题
308
309 （新建变更请求）
310 )))
311 |监控变更请求|跟踪变更请求的状态，一旦变更成功实施既可以解决问题。|问题分析员|处理中的问题|(((
312 处理中的问题
313
314 （实施完毕的变更）
315 )))
316 |问题恢复|(((
317 问题恢复有几种情况：
318
319 1、找到了问题解决方案，不需要变更。
320
321 2、找到了问题解决方案，需要依赖变更实施，并且变更已经实施完毕。
322
323 3、找到了问题根源，但是由于其他客观条件，目前无法消除。通过变通方案临时解决。
324 )))|问题分析员|处理中的问题|已解决的问题
325
326 == ==
327
328 == 4.7问题的解决确认 ==
329
330 由问题分析员对问题进行了恢复或者提供了解决方案之后，问题提交人需要对问题处理结果进行确认。
331
332 |**活动**|**描述**|**责任人**|**输入**|**输出**
333 |问题解决确认|(((
334 1、对已经恢复的问题，进行解决确认。
335
336 2、对于提供了解决方案、或者变更方案的，进行方案执行，验证方案解决结果。
337
338 任务1：确认问题解决达到要求，进入下一环节。
339
340 任务2：问题解决未达到要求、协调问题分析员继续处理。
341 )))|问题提交人|已解决的问题|已确认的问题
342
343 == ==
344
345 == 4.8问题的提炼与关闭 ==
346
347 本环节的目标在于将完善的解决方案提炼为知识条目，或者已知错误。
348
349 |**活动**|**描述**|**责任人**|**输入**|**输出**
350 |问题提炼|(((
351 对问题解决方案或者变通方案进行梳理，结合问题的现象描述，创建知识条目。
352
353 任务：新建知识。
354 )))|问题分析员|已确认的问题|已关闭的问题（新建的知识）
355
356 == ==
357
358 == 4.9问题的取消 ==
359
360 根据问题程序规则，有些问题可以不经过解决直接取消。
361
362 |**活动**|**描述**|**责任人**|**输入**|**输出**
363 |问题取消|(((
364 问题取消有两种情况：
365
366 1、在创建问题之后，故障现象自行消除，经分析没有必要进行深入研究的。
367
368 2、由问题协调员退回后，提交人确认确实不属于问题范畴的单子。
369 )))|问题提交人|新建或者退回的问题|已取消的问题
370
371 = =
372
373 = =
374
375 = 5人员和角色 =
376
377 == 5.1问题流程负责人（项目经理） ==
378
379 问题流程负责人从总体上对问题管理流程的设计、实施、执行及优化负责，确保问题管理流程被正确的执行。当流程不能够适应实际运维情况时，流程负责人必须及时的对此进行分析，找出缺陷，进行改进，从而实现可持续提高。
380
381 职责：
382
383 * 确保问题流程的设计、实施及执行，能够取得管理层的参与和支持
384 * 确保问题流程符合公司实际状况和公司 IT发展战略
385 * 整体上对问题流程负责，建立流程实施、评估和持续优化机制
386 * 确保问题流程的有效执行，定期评估流程，制定流程改进计划
387 * 保持与其他流程负责人的定期沟通
388
389 == ==
390
391 == 5.2部门负责人 ==
392
393 职责：
394
395 * 定期组织相关人员对事件记录进行分析，发现潜在问题
396 * 确认和审核问题
397 * 必要时对问题进行上报
398 * 监视问题的诊断、分析和处理过程
399 * 必要时与帮助台及问题请求者沟通问题的相关信息
400 * 必要时协调所需资源
401 * 定期产生问题报表，提供正确决策信息
402 * 提交变更请求并监控变更实施
403
404 == ==
405
406 == 5.3问题提交人 ==
407
408 职责：
409
410 * 接受问题主管分派的问题
411 * 分析和诊断问题，确定根本原因
412 * 确定和测试解决方案
413 * 对与问题相关的事件解决提供协助和支持
414 * 需要时协调第三方的资源来帮助诊断和改正问题
415
416 = =
417
418 = =
419
420 = 6与其他流程的关系 =
421
422
423 **事件管理**
424
425 事件管理对问题管理来说是一个重要信息提供者。有效的事件记录对成功地进行问题管理来说非常重要，因为这些信息是用于发现问题的。
426
427 问题管理支持事件管理流程的工作。问题管理对问题进行分析，直到找到问题的解决方案；同时问题管理还能为事件管理提供应急措施（通常是在对问题进行研究时找到）来对事件进行处理。
428
429 一旦确定了问题的原因并且定义了一个已知错误，那么提供一个临时修复以阻止事件的再次发生并降低事件的影响。理想的情况下，问题管理还可提供一个变更请求，这会使问题得到最终的解决。
430
431
432 **变更管理**
433
434 变更管理负责控制执行变更，包括有问题管理为消除问题而发出的变更请求（RFC）。变更管理负责预测所需变更产生的影响，同时估算在对其进行计划、协调、评价时所需的资源。他还通知问题管理了解关于纠错性变更的进展和完成情况。这些纠正性变更的评价需要与问题管理进行磋商。这样能产生一个实施后评审，如果变更成功进行，此后所有相关事件和问题记录（已知错误）都可以终结了。
435
436
437 **配置管理**
438
439 配置管理提供关于基础设施、结构图、硬件和软件配置及服务等组件的重要信息。配置管理流程还描述这些组件之间的关系。这些关系对问题管理的调查至关重要，因为它们定义了整个IT基础设施之间的相互关系。
440
441
442 **服务级别管理**
443
444 服务级别管理包括就是是IT服务时的服务质量问题进行协商和谈判。服务级别问题为问题管理提供用于定义问题的信息，而问题管理流程应当遵守、支持规定的服务级别。问题管理与财务管理和IT服务持续性管理之间也有类似的关系。
445
446 = =
447
448 = =
449
450 = 7衡量指标 =
451
452 为了较好地控制问题管理流程的质量，必须为问题管理流程设置考核指标，通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。
453
454 问题管理流程的关键衡量指标如下：
455
456 |**编号**|**衡量指标**|**计算方法描述**
457 |1|问题总数|(((
458 数量：在问题单中根据以下条件过滤，
459
460 1. 【重复问题标记】为空
461 1. 【问题结束代码】不等于‘取消’
462 1. 【登记时间】在统计周期内
463 )))
464 |2|关闭的问题数量|【问题关闭时间】在统计周期内，【问题状态】=‘已关闭’的问题个数
465 |3|问题成功解决率|(((
466 数量：在关闭问题数量中，【问题结束代码】=‘根本解决’的问题个数
467
468 比率：数量 /关闭问题数量  × 100 %
469 )))
470 |4|通过变通方法解决的问题数量|数量：在关闭问题数量中，【问题结束代码】=‘变通方法’的问题个数
471 |5|事件衍生问题所占比率|(((
472 数量：在问题总数中，【问题来源】=‘事件管理’ 的问题个数
473
474 比率：数量 / 问题总数  × 100 %
475 )))
476 |6|趋势分析问题所占比率|(((
477 数量：在问题总数中，【问题来源】=‘趋势分析’ 的问题个数
478
479 比率：数量 / 问题总数  × 100 %
480 )))
481 |7|维护中提出的问题比率|(((
482 数量：在问题总数中，【问题来源】=‘维护中提出’ 的问题个数
483
484 比率：数量 / 问题总数  × 100 %
485 )))
486 |8|提出过变更的问题数量|数量：变更管理流程中，【变更来源】=‘问题’的变更数量
487
488 = =
489
490 = =
491
492 = 8流程持续改进 =
493
494 每个流程的改进计划由流程经理初步整理后，与业主沟通协商，了解业主的新需求。运用运维工具，提高问题处理的解决率，加强工具的投入，提高问题的平均解决时间，将报告汇总到服务改进计划中。
深圳市艾拓先锋企业管理咨询有限公司