Version 35.1 by superadmin on 2024/10/15, 15:57
Hide last authors
superadmin 10.2 1 [[返回本章节索引>>url:http://www.itil4hub.cn/bin/view/G %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/]]  阅读下一章
2
3
4 文件状态：
5
6 [ ] 草稿
7
8 [√] 正式发布
9
10 [ ] 正在修改
11
12
13 文件标识： GMXX-ITSM-PM
14
15 当前版本： 1.0
16
17 作 者： 叶XX
18
19 完成日期： 2010-12-28
20
21
22 版 本 历 史
23
24 [[image:1728890790717-573.png]]
25
26
27
28 = 1 概述 =
29
30
31 == 1.1 项目背景 ==
32
33 随着XX通信集团广东有限公司对 IT 管理工作的开展与深化，对网维中心 IT 管理部门的 IT 维护服务管理水平又提出了新的更高的要求，在认识到信息系统的对业务的推进作用后，网维支撑室着手了解、学习并参照国际上流行的 ITIL 运维管理模型对本单位内部开展运维管理。
34
35
36 本项目主要是将现有技术资源中的各类要素进行科学的组织管理，以达到合理调配人力资源、有效管理计算机设备、系统运行、提高管理工作水平的目标。
37
38
39 对于网维支撑室当前所面临的问题，因而如何进行全面而有效的 IT 管理已成为网维支撑室的主要工作。缺乏先进 IT 服务管理标准的 IT 管理只能是被动的、无序的、救火式的 IT服务管理，无法保障 IT 系统的无故障高效运行。只有利用先进的 IT 服务管理体系，对信息技术进行集中维护和集中管理，才能够形成主动的、具有优先级别及良好流程的、可管理的IT 服务模式，确保 IT 资源的高效运用、IT 服务的有效管理。
40
41
42 该改造过程不只是单纯地使用某种应用系统的改造，而是管理体制的改造，因而需要对IT 运营服务管理系统按照统一规划，分布实施的方式来推进，在内部逐步建立、推行一套先进的符合 ITIL 的 IT 运维管理体系。
43
44
45 本项目主要是对网维支撑室原有的 IT 服务管理进行符合 ITIL 标准的现状评估，根据评估的情况及结果对 IT 服务管理进行完善与改造，逐步建立 ITIL 模型中的服务台/事件管理、问题管理、变更管理、配置管理，做到“管理好 IT 基础设施”。
46
47
48 == 1.2 项目目标 ==
49
50 本文档是在《XX广东公司综合网维系统 IT 服务管理流程管理制度》基础上，结合广东XX网维支撑室维护管理的特点，制定的《问题管理流程详细设计文档》。
51
52
53 本文档具有如下目的：
54
55 * 查明事件或问题产生的根本原因，制定解决方案和防止事件再次发生的预防措施。
56 * 实施主动性问题管理，在事件发生之前发现和解决可能导致事件产生的潜在问题。
57 * 确保问题已分派正确的支持人员，提高问题解决率。
58 * 根据问题分类分级，科学合理地利用 IT 资源，降低 IT 支持成本。
59 * 通过问题管理，提高 IT 服务质量和服务的可用性，提高客户服务满意度。
60
61
62 == 1.3 适用范围 ==
63
64 本文档作为本次项目的问题管理流程详细设计的交付物，读者对象为与问题管理流程相关的所有技术与管理人员。
65
66
67 == 1.4 相关术语 ==
68
69 * ITIL（IT Infrastructure Library ）
70
71 是英国政府在 1987 年制定的有关 IT 服务管理的方法论，现已成为事实上的 IT 管理标准。
72
73 * 服务台（Service Desk）
74
75 服务台从根本上来说是提供了用户和 IT 部门的唯一接口。此项功能常通过集中方式提供服务。服务台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。
76
77 * 事件管理（ Incident Management）
78
79 ITIL 流程之一，事件管理负责解决所有的 IT 事件、问题和用户请求。它的目的是尽快恢复被中断或受到影响的 IT 服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。
80
81 * 问题管理（Problem Management）
82
83 ITIL 流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件的根本原因，并通过解除该根本原因从而防止类似事件的再次发生。同时问题管理流程也负责预防事件的发生。
84
85 * 配置管理（Configuration Management）
86
87 ITIL 流程之一，配置管理负责描述，跟踪和汇报所有 IT 基础架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置项(CI) 。每一个 CI 必须有效管理，跟踪和控制以支持移动的 IT 服务和基础设施成功运行。
88
89 * 配置管理数据库（CMDB - Configuration Management Database）
90
91 是在配置管理流程中用于记录企业所有 IT 相关配置项信息及其相互关系而建立的数据库。
92
93 * 变更管理（Change Management）
94
95 ITIL 流程之一， 通过控制和管理 IT 相关的变更， 使变更对生产环境可能的影响和风险将到最小，从而提高 IT 环境的整体稳定性。
96
97
98
99 = **2 问题管理流程设计** =
100
101
102 == **2.1 流程目的** ==
103
104 问题管理流程的根本目的是对发生在 IT 环境中的问题进行管理，找出产生问题的根本原 因，并通过变更请求(RFC)、变通方法或建议方案等预防措施消除引起事件的深层次根源以 防止事件再次发生，从而为客户提供更优质的 IT 服务，帮助网维中心的 IT 运维服务从被动 管理向主导管理转变。
105
106 == ==
107
108 == **2.2 问题来源** ==
109
110 问题来源包括但不限于以下情况：
111
112 * 一段时间内某一类事件频繁发生，占用大量人工。
113 * 一段时间内某一设备频繁报同类事件单。
114 * 对 IT 基础设施监控与分析，发现可能产生事件的薄弱环节。
115 * 服务级别协议可能会受到的威胁。
116 * 记录下来的事件不能与现有的问题或已知错误发生关联。
117 * 客户直接提起的具有深层次原因的服务请求。
118
119 问题管理范围不涉及尚处于开发或测试环境中的问题。
120
121
122 == 2.3 与其他流程的关系 ==
123
124 问题管理与事件管理、变更管理、配置管理、能力管理、可用性管理和服务级别管理都有关联关系，存在以下关联原则。
125
126
127 **和事件管理的关联**
128
129 * 事件管理对问题管理来说是一个重要的信息提供者，多次重复发生的事件在恢复服务后，都应创建问题。
130 * 问题管理对故障进行分析，找出问题的根本原因及解决方案，并与事件关联，为事件管理提供有效的事件解决方案或变通办法。
131 * 当明确了问题的原因并定义了一个已知错误后，也可提供事件管理一个临时修复办法以阻止事件的再次发生并降低事件的影响。
132
133
134 **和变更管理的关联**
135
136 * 问题处理过程中，如果需要进行变更，必须按照变更管理的流程，提交变更申请。
137 * 变更管理负责控制执行变更。变更完成后，可能产生一个实施后评审，如果变更成功，所有相关的事件和问题记录(包括已知错误)都可以终止了。
138
139 **和配置管理的关联**
140
141 * 问题处理过程中，可以通过配置管理查询相关的配置项信息。
142 * 问题处理过程中，如果可以将根本原因定位到某个配置项，则必须将问题与该配置项关联。
143
144
145 == 2.4 关键角色、职责定义 ==
146
147 流程的实现是通过不同的流程角色以及其所赋有的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责。
148
149
150 问题管理流程的角色为：问题管理流程负责人、问题经理、问题专家、
151
152 === ===
153
154 === 2.4.1 流程负责人 ===
155
156 **职责：**
157
158 问题管理流程负责人从总体上对问题管理流程的设计、实施、执行及优化负责，确保问题管理流程被正确的执行。当流程不能够适应实际情况时，流程负责人必须及时地进行分析诊断，找出缺陷，进行改进，从而实现问题管理流程的可持续提高。
159
160 * 确保问题管理流程的设计、实施及执行，能够取得管理层的参与和支持。
161 * 确保问题管理流程符合网维中心实际状况和网维中心 IT 服务发展思路。
162 * 整体上对问题管理流程负责，建立流程的实施、评估和持续优化机制。
163 * 确保问题管理流程的有效执行，定期评估流程，制定流程持续改进计划。
164
165 保持与其他流程负责人的定期沟通。
166
167
168 **技能要求：**
169
170 * 深刻理解问题管理流程
171 * 充分理解 IT 服务管理的其他流程，能够进行流程接口设计
172 * 能够很好地理解业务对于问题管理的需求
173 * 对质量控制与保障有深入的了解
174 * 有决策权，能够确保问题管理流程设计要求在实施项目中得到贯彻和执行
175
176
177 **人员安排说明：**
178
179 * 通常由负责决策权的人担任，一般为 IT 部门相关领导
180
181
182 === 2.4.2 问题经理 ===
183
184 问题经理主要负责问题解决过程中的分派、协调和监控，以及问题最终关闭。
185
186
187 **职责：**
188
189 * 定期组织问题专题会，组织问题专家对历史事件记录、各管理报告进行趋势分析，发现潜在问题。
190 * 定期组织问题专题会，组织问题专家识别来自事件升级的问题、日常维护发现的问题和历史遗留的问题。
191 * 确认和审核提出的问题，并进行问题分派。
192 * 监督问题的诊断、分析和处理过程。
193 * 必要时与问题申告者沟通问题的相关信息。
194 * 必要时协调所需资源。
195 * 定期产生问题管理报告，提供管理层正确的决策信息。
196 * 问题解决并关闭前，监督问题专家将其文档化，并申请纳入知识库中。
197 * 协助发现问题管理流程的不足，提出流程改进建议，并向问题管理流程负责人汇报。
198
199
200 **技能要求：**
201
202 * 了解技术架构和技术环境
203 * 处理纠纷的能力
204 * 深刻了解问题管理流程
205 * 较强的领导能力
206
207
208 **人员安排说明：**
209
210 * 网维中心支撑室 IT 管理的的资深人员
211
212
213 === 2.4.3 问题专家 ===
214
215 **职责：**
216
217 * 定期参加问题专题会，回顾事件管理、能力管理、可用性管理等流程的管理报告，进行事件趋势分析，发现潜在问题。
218 * 定期参加问题专题会，识别来自事件升级的问题、日常维护发现的问题和历史遗留的问题。
219 * 对于分派给自己的问题，负责问题的控制，对问题进行分析、诊断，确定问题的根本原因，形成已知错误。
220 * 负责错误的控制，对已知错误进行分析诊断，研究可行的解决方案或变通方法。
221 * 负责解决方案实施计划的制定与落实，并负责验证解决方案的实施效果，确保问题的根本解决。
222 * 负责记录问题解决的相关信息，确保问题描述准确、问题根本原因正确、解决方案完整。
223 * 编制问题分析报告，包括问题描述、问题根本原因、解决方案、实施效果、经验总结等。
224 * 及时与问题经理沟通，通报问题实施的进度、困难和结果。
225 * 负责问题的根本原因、问题的解决方案的整理与文档化，为申请纳入知识库做准备。
226
227
228 **技能要求：**
229
230 * 熟悉自己业务/技术范围内的技术平台和技术环境.
231 * 很强的问题分析、诊断能力和解决问题的能力
232 * 拥有一定的沟通和管理能力，对于涉及多个问题处理专家协同解决的问题能够和相关人员进行沟通并最终解决问题
233
234
235 **人员安排说明：**
236
237 * 技术专家的人担任
238
239
240 === 2.4.4 实际岗位与方案角色的映射 ===
241
242 [[image:1728891735673-770.png]]
243
244 [[image:1728891751563-959.png]]
245
246 [[image:1728891766967-349.png]]
247
248 [[image:1728891777916-913.png]]
249
250 说明：问题专家分组可进行扩充或合并。
251
252
253 == 2.5 执行原则 ==
254
255 === 2.5.1 常规原则 ===
256
257 * 要建立独立的问题管理流程。在整个网维中心范围内，应该与事件管理流程相对独立，事件经理与问题经理应尽可能的由不同的人员担任。
258 * 应该每半年对问题管理流程的流程关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾，以改进和优化流程。
259 * 应该每月定期回顾和产生问题管理报表，对没有解决的问题，应定期举行问题管理专题会评估这些问题。
260 * 问题经理应定期跟踪与检查问题的解决状态。
261 * 已明确的问题根本原因和问题解决方案应申请纳入知识库。
262 * 问题的分类与事件的分类应尽量保持一致。
263
264
265 === 2.5.2 重复问题原则 ===
266
267 重复问题存在两种处理情况，具体处理方式如下：
268
269 一是指经过分析之后，根本原因相同的问题。例如：问题专家提出了几个问题，但是经过分析之后，发现这几个问题的根本原因是相同的，则这几个问题就可以定义为重复问题。对于重复问题需要进行标志（重复问题标记上做重复标识），将相关问题记录进行关联，重复问题直接关闭。同时，当问题解决时，需进行回顾。
270
271 二是指发现重复的问题，但是有新的解决方案。此时需要将相关的问题记录进行关联，并记录新的解决方案。
272
273
274 === 2.5.3 问题重开原则 ===
275
276 已关闭的问题允许重开。当发起的问题已找到问题根本原因，但无法获得解决方案而关闭后，如果需要重新解决该问题，需重新创建一个新的问题申请单，走问题管理流程。
277
278
279 === 2.5.4 问题关闭原则 ===
280
281 通常，问题在实施解决方案之后，需要经过一段时间的回顾，由问题专家回顾解决方案是否达到了预期的效果，如果达到预期效果，则由问题经理确认问题信息记录完整，关闭问题。
282
283
284 === 2.5.5 趋势分析原则 ===
285
286 问题经理定期组织问题专题会，对事件历史记录及管理报告进行趋势分析：
287
288 * 参加者应包括事件经理及问题专家
289 * 会议应定期组织
290 * 应定义趋势分析规则
291
292
293 === 2.5.6 入口原则 ===
294
295 问题管理流程运作过程中需要输入的信息包括：
296
297 * 事件管理流程提供的相关事件信息，以及事件直接升级为问题的描述信息。
298 * 事件管理、可用性管理和能力管理定期提供的各类管理报告，是问题趋势分析的基础与依据。
299 * 问题处理过程中，与配置管理数据库(CMDB)相关的配置信息。
300 * 知识库提供的已知错误及解决方案信息
301 * 供应商提供的其产品信息，包括产品技术细节和产品本身存在的已知错误
302 * 服务目录和服务级别协议(SLA)。
303
304
305 [[image:1728891974337-684.png]]
306
307 [[image:1728891986596-711.png]]
308
309
310 === 2.5.7 出口原则 ===
311
312 问题管理流程输出的信息包括：
313
314 * 发现的已知错误，以及解决已知错误的解决方案或变通方案。
315 * 问题解决过程中，涉及变更时需向变更管理流程提出变更申请。
316 * 最新的问题信息，主要更新与已知错误、解决方案和应急措施相关的信息。
317 * 根据问题处理结果，形成相关的问题分析报告。
318 * 根据问题管理情况，定期提供问题管理的相关分析报告。
319
320
321 [[image:1728892018486-255.png]]
322
323 [[image:1728892027616-500.png]]
324
325
326
深圳市艾拓先锋企业管理咨询有限公司