Version 10.1 by superadmin on 2024/11/01, 21:17
Show last authors
1 = **1. 目标** =
2
3 事件管理流程的主要功能是尽快解决出现的事件，保持关键业务系统的稳定性，其目标包括：
4
5 * 在成本允许的范围内尽快恢复IT服务
6 ** 快速响应用户请求（通过电话）
7 ** 用户在线获得帮助
8 ** 沟通事件解决的状态
9 ** 和客户确认事件的解决
10 * 进行事件控制
11 ** 按规范记录事件
12 ** 就事件的优先级，影响度进行分类
13 ** 分析，诊断，必要时进行升级
14 ** 监视并结束事件
15 ** 进行定期服务流程回顾
16 * 提供IT管理信息
17 ** 人力资源利用情况
18 ** 故障处理情况
19 ** 支持效率
20
21
22 = **2. 流程范围** =
23
24 事件管理流程包括：
25
26 * 企业用户申报的故障或咨询
27
28 涉及的基础架构和业务系统包括：
29
30 1. 包括以下基础架构－－主机、存储、网络、PC、终端、打印机。
31 1. 包括以下业务系统――（参考服务目录）。
32
33 * 监控系统触发的告警事件
34 * 日常运维过程中发现的所有故障
35
36
37
38
39 = **3. 流程主要内容** =
40
41 事件管理流程主要活动包括以下几个方面：
42
43 事件管理流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容：
44
45 * 事件接受和记录
46
47 这个环节是事件管理流程的起点。所有通过用户交互或系统报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。
48
49 该环节的关键是信息的准确性和完整性。
50
51 * 分类和在线支持
52
53 事件可以是一个故障/告警/咨询，对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。
54
55 该环节的关键是必要的问题库支持和正确的事件分派。
56
57 * 调查和诊断
58
59 若支持人员无法解决事件，可运用自身技能、问题库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。
60
61 * 解决和恢复
62
63 支持人员实施事件的解决方案，书写解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。
64
65 * 结束事件
66
67 当用户确认事件解决后，此时可结束该事件。
68
69 * 事件升级
70
71 当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。
72
73 == ==
74
75 == ==
76
77 = **4. 流程执行原则** =
78
79 流程执行原则是流程实施的策略，它作用于各个流程活动，指导流程活动的正确执行。这些执行原则同时也协助流程设计，并作为流程执行的输入。若没有经过很好设计的流程执行原则，将会使流程既不能满足客户的期望，也不能满足服务实施的标准。
80
81 事件管理流程的执行原则包含了以下7个方面：
82
83 == ==
84
85 == 4.1 常规原则 ==
86
87 * 所有事件管理范围内发生的事件，都应该记录在IT服务管理平台中，记录的信息应足够详细，包括事件处理过程，详细的解决方案和相应的附件；
88 * 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别；
89 * 各支持组组长应该每周检查相关的事件记录，以确保事件记录的完整和合理；
90 * 事件经理应该每月产生事件管理报表。对反复发生的事件和变通方法解决的事件，举行定期的事件管理会议对这些事件进行评估，决定是否发起问题单以从根本上解决某些事件；
91 * 事件经理每半年对流程进行回顾，回顾内容包括流程关键衡量指标和流程执行效率，以改进事件管理流程。
92
93
94 == 4.2 流程关联原则 ==
95
96 * 和问题管理的关联
97 ** 对于根本原因未明、采用变通方法解决的事件，应该产生问题记录并建立关联，或者与现有的问题进行关联；
98 ** 远程员和二线支持在解决事件的过程中，可以通过问题记录查找相应的解决方案。
99 * 和变更管理的关联
100 ** 事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更申请单（变更单必须和事件单建立关联），变更完成后，继续事件单的处理。
101 * 和服务请求管理的关联
102 ** 事件处理过程中，如果需要提出服务请求，必须按照服务请求管理的定义，提交服务请求申请单（请求单必须和事件单建立关联），请求完成后，继续事件单的处理。
103 * 和配置管理的关联
104 ** 事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位；
105 ** 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联。
106
107
108 == 4.3 所有权原则 ==
109
110 * 所有权原则用来确保每个事件在任何时段都有适当的人员负责，协调员和事件经理必须确保事件得到有效跟踪与解决，并统一由质控员负责对事件单进行验证后关闭。
111
112
113 == 4.4 重分派原则 ==
114
115 * 事件的重分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单重分派的几率，事件单的重分派次数不应该超过3次。
116 ** 协调员可以将事件单重新分配给远程员或其他二线支持人员；
117 ** 事件重分派时要求协调员进行重分派原因的沟通。
118
119
120 == 4.5 重复事件原则 ==
121
122 重复事件是指在一个较短时间段（通常是1小时内），由监控平台上报的同一个配置项上现象相同的事件；或者一人/多人报告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单也获得解决。
123
124 * 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标；
125 * 由远程员或二线支持人员负责标识重复事件。
126
127
128 == 4.6 补单原则 ==
129
130 * 紧急事件在处理完成后必须补录事件单，记录详细解决过程及方案；
131 * 重大事件也要在处理完成后，总结回顾处理过程，在事件单补录详细的处理信息、解决方案及相关改进点。
132
133
134 == 4.7 关闭原则 ==
135
136 所有事件单必须由交互流程的质控员验证通过后关闭。
137
138 * 事件处理人员在解决完成事件时，根据实际解决情况填写事件解决代码。由交互流程质控员负责和最终用户确认事件的关闭；
139 ** 由最终用户认可获得关闭的事件单的结束代码为“已完成”；
140 ** 已解决的事件单如果没有得到最终用户的认可，则首先关闭该事件单，结束代码修改为“未完成”，同时创建一个新的事件单重新分配到原处理人员继续处理。
141 * 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单；
142 * 对于已解决事件单，如果在确认时如无法联系用户，由质控员判断并决定是否关闭交互并关闭该事件。
143
144
145 == 4.8 升级原则 ==
146
147 制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。
148
149 * 优先级为紧急的事件，协调员应立即升级到事件经理，由事件经理再次确认，如果优先级的确为紧急，则通知相应的管理层，并由事件经理启动紧急事件处理流程；
150 * 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，系统应自动将事件信息通报相关人员，由协调员负责协调资源，并督促事件能够及时被响应和处理；
151 * 远程员应及时将不能解决的事件升级到二线支持人员，若未及时升级，协调员应及时介入，负责协调升级处理；
152 * 远程员和二线支持人员在必要时通知协调员，将事件升级为紧急事件；
153 * 只有协调员和事件经理才能变更事件的优先级。
154
155
156 == ==
157
158 = **5. 流程详述** =
159
160 == 5.1 事件管理流程概要设计 ==
161
162 (% style="text-align:center" %)
163 [[image:1730466396820-943.png]]
164
165
166 流程活动：
167
168 |序号|活动|说明|输入|输出|负责部门|角色
169 |8.2.1|分派事件单|所有事件单首先分派到协调员，由协调员判断给远程员或二线支持人员进行解决|交互/监控告警/日常运维升级的事件单|待办事件单|IT运维部|协调员
170 |8.2.2|调查和诊断|(((
171 1. 接受事件单后，首先要根据自身经验对事件单信息进行更新，包括事件描述、事件分类、紧急度、影响度等；
172 1. 调查事件原因，查找相关的问题或变更，判断是否能独自解决故障；
173 )))|待办事件单|更新的事件单信息|IT运维部|(((
174 一线、
175
176 二线支持
177 )))
178 |8.2.3|记录解决方案|(((
179 1. 初步确定解决故障的方式
180 1. 如果需要借助问题管理流程才能找到解决方案，则写明分析情况并转单给协调员判断是否新建问题单；
181 1. 如果解决方案需要通过发起一个变更请求才能实施，则新建一个变更单转变更主管审批
182 1. 如果解决方案需要通过发起一个服务请求才能实施，则新建一个服务请求单转请求主管审批
183 1. 记录详细的解决方案；
184 )))|更新的事件单|事件解决方案|IT运维部|(((
185 一线、
186
187 二线支持
188 )))
189 |8.2.4|实施解决方案|(((
190 1. 实施解决方案
191 1. 由一二线支持人员对用户故障进行远程或现场处理，如果是应用类故障，则初步尝试解决；
192 1. 实施过程中如出现错误，需要判断是否转单给其他支持组处理；
193 )))|事件解决方案|事件处理结果|IT运维部|(((
194 一线、
195
196 二线支持
197 )))
198 |8.2.5|关闭事件|支持人员确认解决故障后，更新解决方案，然后关闭事件单|事件处理结果|关闭的事件单|IT运维部|(((
199 一线、
200
201 二线支持
202 )))
203
204
205 == 5.2 分派事件单 ==
206
207
208 (% style="text-align:center" %)
209 [[image:1730466442850-906.png]]
210
211 流程活动：
212
213 |序号|活动|说明|输入|输出|负责部门|角色
214 |8.2.1.1|初审事件信息|初审事件单的关键信息|交互/监控告警/日常运维升级的事件单|无|IT运维部|协调员
215 |8.2.1.2|信息是否完整？|检查事件单信息是否足够|事件单信息|无|IT运维部|协调员
216 |8.2.1.3|拒绝事件|如发现事件单信息不完整，可退回服务台完善。|事件单信息|拒绝事件单|IT运维部|协调员
217 |8.2.1.4|分派事件|根据实际情况分派事件单给一线或二线处理|事件单信息|分派事件|IT运维部|协调员
218
219
220
221 == 5.3 调查和诊断 ==
222
223
224 (% style="text-align:center" %)
225 [[image:1730466471229-405.png]]
226
227 流程活动：
228
229 |序号|活动|(% style="width:611px" %)说明|(% style="width:133px" %)输入|(% style="width:151px" %)输出|(% style="width:102px" %)负责部门|(% style="width:185px" %)角色
230 |8.2.2.1|是否接受|(% style="width:611px" %)是否接受事件单的分派？|(% style="width:133px" %)待办事件单|(% style="width:151px" %)无|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
231 |8.2.2.2|收集信息及调查原因|(% style="width:611px" %)收集事件的相关信息，检查事件单是否与其他问题单变更单有关联， |(% style="width:133px" %)事件单信息|(% style="width:151px" %)更新的事件单|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
232 |8.2.2.3|由变更引起？|(% style="width:611px" %)判断是否与其他正在处理的变更单相关|(% style="width:133px" %)更新的事件单|(% style="width:151px" %)无|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
233 |8.2.2.4|关联相关变更|(% style="width:611px" %)如果相关，需要把事件单与其关联|(% style="width:133px" %)事件单|(% style="width:151px" %)关联的变更单|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
234 |8.2.2.5|与未决问题匹配？|(% style="width:611px" %)判断是否与其他正在处理的问题单相关|(% style="width:133px" %)更新的事件单|(% style="width:151px" %)无|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
235 |8.2.2.6|关联相关问题|(% style="width:611px" %)如果相关，需要把事件单与其关联|(% style="width:133px" %)事件单|(% style="width:151px" %)关联的问题单|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
236 |8.2.2.7|是否超时？|(% style="width:611px" %)系统会实时自动判断事件单在支持人员处理的过程中是否超时，如超时会分派给协调员处理|(% style="width:133px" %)更新的事件单|(% style="width:151px" %)协调员待办事件单|(% style="width:102px" %)IT运维部|(% style="width:185px" %)系统
237 |8.2.2.8|是否能自行解决？|(% style="width:611px" %)在充分调研后，尽快判断是否能自行解决事件，如不能处理需要转派回协调员|(% style="width:133px" %)更新的事件单|(% style="width:151px" %)接受或拒绝事件单|(% style="width:102px" %)IT运维部|(% style="width:185px" %)一线二线支持
238
239
240
241 == 5.4 记录解决方案 ==
242
243
244 (% style="text-align:center" %)
245 [[image:1730466522660-947.png]]
246
247 流程活动：
248
249 |序号|活动|说明|输入|输出|负责部门|角色
250 |8.2.3.1|确定解决事件的方式|确定用什么方式解决事件|更新的事件单|无|IT运维部|一线二线支持
251 |8.2.3.2|借助问题管理？|判断是否要借助问题管理彻查原因|更新的事件单|无|IT运维部|一线二线支持
252 |8.2.3.3|注明转问题单原因|如果认为需要通过问题管理才能彻底解决故障，可以注明原因，转回协调员安排升级问题|更新的事件单|转问题单原因|IT运维部|一线二线支持
253 |8.2.3.4|发起变更？|判断是否要发起变更|更新的事件单|变更单|IT运维部|一线二线支持
254 |8.2.3.5|发起请求？|判断是否要发起请求|更新的事件单|请求单|IT运维部|一线二线支持
255 |8.2.3.6|记录解决方案|记录初步的故障解决方案|更新的事件单|解决方案|IT运维部|一线二线支持
256
257
258 == 5.5 实施解决方案 ==
259
260
261 (% style="text-align:center" %)
262 [[image:1730466550951-594.png]]
263
264 流程活动：
265
266 |序号|活动|说明|输入|输出|负责部门|角色
267 |8.2.4.1|是否有权实施？|判断是否有足够的权限独自实施解决方案|更新的事件单|无|IT运维部|一线二线支持
268 |8.2.4.2|实施解决方案|如权限足够，则直接实施解决方案|更新的事件单|实施解决方案|IT运维部|一线二线支持
269 |8.2.4.3|是否发生错误？|在实施解决方案的过程发生了错误？|实施解决方案过程|无|IT运维部|一线二线支持
270 |8.2.4.4|是否需要升级？|判断是否要对错误升级|实施解决方案|无|IT运维部|一线二线支持
271 |8.2.4.5|重分派给其他人或支持组|针对权限不足或者处理过程发生错误的情况，都应及时把事件单转回协调员处理|实施解决方案|转派的事件单|IT运维部|一线二线支持
272
273
274 == 5.6 关闭事件单 ==
275
276
277 (% style="text-align:center" %)
278 [[image:1730466575075-826.png]]
279
280 流程活动：
281
282 |序号|活动|说明|输入|输出|负责部门|角色
283 |8.2.5.1|确认并更新解决方案|确认已解决用户故障，更新解决方案内容|故障处理结果|更新的解决方案|IT运维部|一线二线支持
284 |8.2.5.2|关闭事件单|关闭事件单|更新的事件单|关闭的事件单|IT运维部|一线二线支持
285 |8.2.5.3|事件由监控系统引起？|事件单关闭后，系统会自动判断事件单是否来自监控系统告警|关闭的事件单|事件解决状态|IT运维部|系统
286 |8.2.5.4|事件由日常运维引起？|事件单关闭后，系统会自动判断事件单是否来自日常运维单，如果是则返回事件单状态给日常工单。|关闭的事件单|事件解决状态|IT运维部|系统
287
288
289 == 5.7 紧急/重大事件处理子流程 ==
290
291 制定紧急/重大事件处理子流程的目标：
292
293 * 当紧急/重大事件发生时，尽可能采取措施减少对于业务带来的影响
294 * 确保对紧急情况的有效管理
295 ** 加快紧急事件的响应和处理速度
296 ** 对紧急情况中的人员及采取的行动加强管理
297 ** 加强处理人员与用户之间的沟通和反馈
298 ** 对紧急情况妥善处理
299
300 流程原则：
301
302 * 制定各系统应急处理预案
303
304 为了确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障，各系统应该建立相应的应急处理预案，建议预案中的内容至少应涵盖以下方面：
305
306 1. 应急预案启动条件
307 1. 应急处理小组负责人和成员联系名单和联系方式
308 1. 应急处理步骤
309 1. 应急信息报告
310 1. 应急善后处理
311 1. 应急保障措施（人员、培训、演习、场地等）
312
313 * 紧急/重大事件需要及时上报信管部，II级或I级事件协调归口业务部门共同解决。
314 * 紧急/重大事件判断原则
315
316 根据应用系统的安全事件的分类及处置流程，只要达到此标准“导致Ⅳ级以上系统服务停止时间超过8小时，但能在24小时内恢复的事件”，均需启动紧急/重大事件子流程进行处理。详细说明参考“安全事件的分类及处置流程”及7.2事件影响度的描述。
317
318
319 (% style="text-align:center" %)
320 [[image:图片2.jpg]]
321
322
323 图7紧急/重大事件处理子流程
324
325
326 流程活动：
327
328 |序号|活动|(% style="width:894px" %)说明|(% style="width:240px" %)角色
329 |8.2.6.1|召集应急工作组，讨论决策|(% style="width:894px" %)事件经理主持会议，并组织讨论、分析紧急/重大事件的级别和处理方案|(% style="width:240px" %)(((
330 事件经理
331
332 重大事故评定委员会
333 )))
334 |8.2.6.2|是否有应急预案？|(% style="width:894px" %)根据紧急事件现象和所属系统，检查是否有相应系统的应急预案？|(% style="width:240px" %)重大事故评定委员会
335 |8.2.6.3|按照应急预案处理|(% style="width:894px" %)根据各系统制定的应急预案中的实施步骤，处理紧急事件|(% style="width:240px" %)重大事故评定委员会
336 |8.2.6.4|是否II级或I级事件？|(% style="width:894px" %)判断事件级别，确定是否需要归口业务部门参与处理。|(% style="width:240px" %)重大事故评定委员会
337 |8.2.6.5|组织信管部人员共同分析、制定恢复计划并实施方案|(% style="width:894px" %)(((
338 如III级、IV级事件，重大事故评定委员会负责组织管部与相关供应商共同分析紧急事件，制定相应的恢复计划和处理方案，处理方案在实施前应得到重大事故评定委员会和相关领导的认可；
339
340 事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求
341 )))|(% style="width:240px" %)(((
342 重大事故评定委员会
343
344 信管部归口人
345 )))
346 |8.2.6.6|组织信管部及归口业务部门人员共同分析、制定恢复计划并实施方案|(% style="width:894px" %)(((
347 如II级、I级事件，重大事故评定委员会负责组织信管部、归口业务部门与相关供应商共同分析紧急事件，制定相应的恢复计划和处理方案，处理方案在实施前应得到重大事故评定委员会和相关领导的认可；
348
349 事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求
350 )))|(% style="width:240px" %)(((
351 重大事故评定委员会
352
353 信管部归口人
354
355 归口业务部门
356 )))
357 |8.2.6.7|事件解除？|(% style="width:894px" %)确定故障是否已排除，如已解除，转善后处理流程；如未解除，则需要由事件经理继续协调研究解决方案。|(% style="width:240px" %)(((
358 事件经理
359
360 重大事故评定委员会
361 )))
362 |8.2.6.8|善后处理和通报|(% style="width:894px" %)(((
363 事件解决后，信管部和重大事故评定委员会应向用户、公司相关领导报告事件处理过程，解决方法，事件解除时间，业务恢复情况。
364
365 事件处理人在流程平台确定事件解决时间，填写解决方案。
366
367 事件处理人需要创建一个新问题，将紧急/重大事件处理过程的详细信息记录到问题单中，提交到问题经理，由问题经理组织相关专家进行问题根源的分析
368 )))|(% style="width:240px" %)(((
369 重大事故评定委员会
370
371 信管部归口人
372 )))
373
374
375
376
377 = **6. 关键角色、职责定义** =
378
379 |角色|职责|建议人员或岗位
380 |事件经理|(((
381 * 监控交互流程的运行状况；
382 * 监控事件流程的运行状况；
383 * 负责对事件解决过程中的资源协调，保证故障的最终排除；
384 * 当事件超时升级或重大事件升级时，负责或参与资源协调、解决事件；
385 * 确保和问题管理流程的有效合作；
386 * 基于事件处理状况，发现IT或业务相关的问题；
387 * 事件处理过程中，解决方案的审批及提出RFC。
388 * 技能要求：
389 ** 充分理解业务相关IT政策、操作过程和标准；
390 ** 基本了解业务系统环境；
391 ** 具有流程的知识；
392 ** 了解用户需求；
393 ** 分析技能；
394 ** 理解服务水平承诺；
395 ** 用户关系技能。
396 )))|
397 |一线(远程员)、二线支持人员|(((
398 * 验证事件的描述和处理状况，进一步收集相关信息；
399 * 根据专业技能和知识库等，确定并实施有效解决方案或临时变通方法；
400 * 更新事件记录和解决方案，确保事件状态代码真实反映事件状态；
401 * 远程员负责远程解决用户故障；
402 * 二线支持人员负责现场解决用户故障以及远程员无法解决的故障；
403 * 已解决的事件转回质控员，由质控员进行用户确认并关闭事件；
404 * 技能要求：
405 ** 基本理解业务相关IT政策、操作过程和标准；
406 ** 理解相关的操作过程和工作指导；
407 ** IT基础架构和操作环境中某一方面的较高的技术知识；
408 ** 用户关系技能；
409 ** 分析技能。
410 )))|
411 |协调员|(((
412 * 审核并接受或拒绝分配给支持组的突发事件
413 * 协调交互单及事件单的分派；
414 * 负责ITSM系统日常维护工作；
415 * 负责每周及每月通过ITSM系统及CTI系统进行运维数据收集和整理，向事件经理提交运维数据；
416 * 收集、整理和汇总各运维组提交的周报和月报，结合信息运维数据，撰写信息运维周报及信息运维月报，提交至事件经理审核。
417 * 每日对事件处理过程及事件状态（事件单是否受理、事件单是否响应超时、事件单是否处理超时、设备送修情况等）进行跟踪与检查，每天向事件经理提交检查日志。
418
419 * 技能要求：
420 ** 基本理解业务相关IT政策、操作过程和标准；
421 ** 理解相关的操作过程和工作指导；
422 ** IT基础架构和操作环境中某一方面的较高的技术知识；
423 ** 分析技能。
424 )))|
425 |重大事故评定委员会|(((
426 * 根据紧急/重大事件的现象和所属系统，检查相应的应急预案，并组织人员按照应急预案中的实施步骤，处理故障；
427 * 评定事件级别，负责组织信管部、归口业务部门与相关供应商共同分析紧急事件，共同制定相应的恢复计划和处理方案；
428 * 事件解决后，重大事故评定委员负责向用户、公司相关领导报告事件处理过程，解决方法，事件解除时间，业务恢复情况；
429 )))|IT运维部
430 |质控员|合并至交互流程质控员|
431
432
433
434
435 = **7. 流程相关定义** =
436
437 == 7.1 事件单信息项 ==
438
439 事件单必须包含如下信息项，可以在此基础上扩充：
440
441 |序号|信息项|说明
442 |1|事件ID|系统为此事件生成的唯一 ID。
443 |2|状态|(((
444 显示突发事件的状态。
445
446 建议以下预置状态：
447
448 • 打开 — 此突发事件已经打开，但目前没有得到处理。
449
450 • 关闭 — 此突发事件已得到解决，并且得到了客户的同意。
451
452 • 已解决 — 有一个解决方案，但未经客户验证。
453
454 • 正在处理 — 正在处理此突发事件。
455
456 • 待定变更 — 已打开一个相关紧急变更，正在等待关闭该变更。
457
458 • 暂停 — 客户同意将此突发事件暂停一段时间；记录单将不会在该时段出现在待办队列中。
459 )))
460 |3|联系人|联系人不一定是服务接收人。此字段可以确保合适的人员将会得到有关交互更新的通知。
461 |4|代理人|指定处理此突发事件的人员的姓名。此人是所分配的支持组的成员。代理人可以属于一个或多个分配组。
462 |5|分配组|指定处理此突发事件的支持组
463 |6|受影响的服务|该服务受此突发事件影响。此字段由交互记录中的数据填充。
464 |7|受影响的配置项|对服务产生负面影响的配置项 (CI)。此字段由交互记录中的数据填充。
465 |8|配置项可操作（服务不会中断）|如果已选择（设置为 true） ，则表示配置项当前正在操作中，而且服务不会中断。默认情况下，打开一个针对配置项的突发事件时，该配置项标记为出现故障。如果该配置项仍然正常工作，则应该标记此字段。
466 |9|事件来源|参见“事件来源”定义
467 |10|服务中断开始时间|(((
468 服务中断开始的日期和时间。服务中断的开始和结束时间用于衡量“服务级别协议” (SLA) 的可用性。如果配置项标记为出现故障，则可用性 SLA 将不再支持该配置项。可用性值默认为打开和关闭突发事件的时间，但打开或关闭突发事件之前可能会经历几分钟或几小时，因此，需要变更该值，以报告实际的服务中断开始和结束的时间。例如，设备可能在夜间出现了故障，而且必有人报告该问题
469
470 之后，突发事件才会打开。在此情况下，默认的打开时间不能准确反映服务中断时间。
471 )))
472 |11|服务中断结束时间|服务中断结束的日期和时间。服务中断的开始和结束时间用于衡量 SLA 的可用性。如果配置项标记为出现故障，则可用性 SLA 将不再支持该配置项。可用性值默认为打开和关闭突发事件的时间，但需要变更该值以报告实际的服务中断结束时间。例如，重新启动配置项之后，可以对其进行操作，但可能要花数分钟或数小时，才能更新记录，以报告突发事件已关闭。在此情况下，默认的关闭时间不能准确反映实际的服务中断时间。
473 |12|位置|报告突发事件的位置。此字段由已升级交互中的数据预先填充。此字段仅供参考。
474 |13|标题|(((
475 概述突发事件的简短描述。此字段由已升级交互中的数据预先填充。
476
477 此为必填字段。
478 )))
479 |14|描述|(((
480 突发事件的详细描述。此字段由已升级交互中的数据预先填充。
481
482 此为必填字段。
483 )))
484 |15|类别|描述突发事件类型，由已升级交互中的数据预先填充。
485 |16|区域|此字段由已升级交互中的数据预先填充。对此区域的选择取决于类别。
486 |17|子区域|第三级交互分类，主要用于进行报告。此字段由已升级交互中的数据预先填充。
487 |18|影响度|(((
488 此字段由已升级交互中的数据预先填充。它指明了突发事件对业务产生的影响。
489
490 影响和紧急程度用于计算优先级。
491 )))
492 |19|紧急度|(((
493 此字段由已升级交互中的数据预先填充。紧急程度表示此突发事件对于组织的紧
494
495 迫程度。紧急程度和影响用于计算优先级。
496 )))
497 |20|优先级|此突发事件相对其他突发事件的排列顺序。优先级值是根据初始影响和紧急程度来计算的。只有从交互更新或升级突发事件时，此字段才显示。
498 |21|SLA目标日期|下一个“服务级别目标”(SLO) 到期的日期和时间。此字段基于与突发事件信息相匹配的 SLO 进行填充，所用日期是违反协议之前即将到期的 SLO。
499 |22|解决代码|(((
500 指定一个预定义的解决代码，用于说明如何解决突发事件。此字段的预置选项基于客户的参考数据。
501
502 建议以下预置解决代码：
503
504 • 不可重现
505
506 • 超出范围
507
508 • 请求被拒
509
510 • 通过变更/ 服务请求解决
511
512 • 通过用户说明解决
513
514 • 通过应对措施解决
515
516 • 无法解决
517
518 • 被用户撤销
519 )))
520 |23|关闭代码|此项是在服务台质控员在回访时，同用户确定的最终结果
521 |24|解决方案|提供对突发事件解决方案的说明。
522
523
524
525 == 7.2 事件影响度 ==
526
527 |(% rowspan="2" %)**影响度**|(% rowspan="2" %)**定义**|(% colspan="5" %)**判断依据**
528 |**系统级别**|**停止时间**|**恢复时间**|**大面积报障类型**|**影响范围**
529 |(% rowspan="4" %)1级-特别重大|(% rowspan="2" %)造成系统完全损坏或严重损坏，数据全部或大部分损坏，且无法进行系统修复或容灾切换的，必须重建系统，备份恢复数据方可恢复正常服务|I级|N/A|N/A|N/A|N/A
530 |II级|N/A|N/A|N/A|N/A
531 |(% rowspan="2" %)信息系统数据丢失或被窃取、篡改、假冒，对公司形象造成负面影响，可能对社会稳定构成威胁的|I级|N/A|N/A|N/A|N/A
532 |II级|N/A|N/A|N/A|N/A
533 |(% rowspan="6" %)2-严重|(% rowspan="6" %)因重大系统故障引发的，造成系统服务停止，或系统大量重要数据损坏，且一定时间内无法恢复系统正常运行的|(% rowspan="2" %)I级|(% rowspan="2" %)>1小时|(% rowspan="2" %)>4小时|(% rowspan="2" %)网络故障|同一栋楼或五名以上用户
534 |同一线路有三个或以上车站
535 |(% rowspan="2" %)II级|(% rowspan="2" %)>2小时|(% rowspan="2" %)>8小时|I、II级系统故障|两个或以上用户
536 |III级系统故障|三个或以上用户
537 |III级|>4小时|>16小时|N/A|N/A
538 |IV级|>8小时|>24小时|N/A|N/A
539 |(% rowspan="2" %)3-一般|(% rowspan="2" %)(((
540 能够导致较小影响或破坏的事件；
541
542 影响少部分客户；
543
544 监控工具产生一般告警
545 )))|N/A|N/A|15天内|设备故障|三个或以上用户
546 |N/A|N/A|1天内|病毒问题|三个或以上用户
547 |(% rowspan="2" %)4-微小|(% rowspan="2" %)微小故障指的是不会影响业务连续性的故障。例如键盘鼠标损坏，无法连接INTERNET等故障。|N/A|N/A|二周内|桌面|五个或以上用户
548 |N/A|N/A|5分钟内|基础架构预警信号|一个或以上
549
550
551
552 == 7.3 事件紧急度 ==
553
554 |紧急度编码|紧急时间标准|描述
555 |1-非常紧急|8小时|服务需8小时内提供（恢复）
556 |2-紧急|24小时|服务需24小时内提供（恢复）
557 |3-一般|48小时|服务需48小时内提供（恢复）
558 |4-略微紧急|72小时|服务需72小时内提供（恢复）
559
560
561
562 == 7.4 事件优先级 ==
563
564 |(% colspan="2" rowspan="2" %)优先级|(% colspan="4" %)影响度
565 |1-特别重大|2-严重|3-一般|4-轻微
566 |(% rowspan="4" %)紧急度|1-非常紧急|1-最高|2|2|3
567 |2-紧急|2|2-高|3|3
568 |3-一般|2|3|3-中|4
569 |4-略微紧急|3|3|4|4-低
570
571
572
573 == 7.5 事件来源 ==
574
575 给事件分级是事件管理的一个关键要素，事件的分级决定处理这个事件的顺序及所提供的资源。
576
577 |编号|来源|描述
578 |1|用户报告|用户通过电话、邮件或WEB报告的事件，服务台人员手工创建事件单
579 |2|监控告警|监控工具发现的告警事件
580 |3|日常运维发现|IT运维部日常运维检查产生事件
581
582
583
584 == 7.6 事件性质 ==
585
586 |类别|信息项|说明
587 |突发事件|访问|授权错误
588 |突发事件|访问|登录失败
589 |突发事件|数据|数据或文件损坏
590 |突发事件|数据|数据或文件不正确
591 |突发事件|数据|数据或文件丢失
592 |突发事件|数据|超过存储限制
593 |突发事件|失败|错误消息
594 |突发事件|失败|不正常工作
595 |突发事件|失败|作业失败
596 |突发事件|失败|系统故障
597 |突发事件|硬件|硬件故障
598 |突发事件|硬件|丢失或被盗
599 |突发事件|性能|性能降低
600 |突发事件|性能|系统或应用程序挂起
601 |突发事件|安全|违反安全性
602 |突发事件|安全|安全事件/ 消息
603 |突发事件|安全|病毒警报
604
605
606
607 == 7.7 事件分类 ==
608
609 |类别|子类|一级模块
610 |(% rowspan="72" %)应用系统|(% rowspan="6" %)外部网站（含子公司网站）|招贤纳才
611 |招标投标
612 |乘客服务
613 |企业概况
614 |企业商务
615 |新闻中心
616 |(% rowspan="2" %)企业内部门户|UUV用户管理
617 |SSO应用系统管理
618 |(% rowspan="6" %)财务管理系统|总帐管理
619 |应付管理
620 |应收管理
621 |固定资产管理
622 |项目会计管理
623 |预转资管理
624 |资金管理系统|
625 |(% rowspan="7" %)合同管理系统|范本管理
626 |合同计划
627 |合同招标
628 |合同台账
629 |合同管理
630 |合同支付
631 |系统管理
632 |运营设备维修系统|
633 |运营施工调度管理系统|
634 |运营物流管理系统|需求管理
635 | |计划管理
636 | |采购寻源管理
637 | |采购订单管理
638 | |物资库存管理
639 |票务管理系统|
640 |GIS系统|
641 |(% rowspan="7" %)数字认证平台|部门管理
642 |用户管理
643 |系统日志查询
644 |验证选项
645 |证书管理
646 |印章制作
647 |证书审计查询
648 |SPS平台|
649 |IT运维系统|
650 |办公自动化系统（新）|
651 |办公自动化系统（旧）|
652 |合同管理系统（新）|
653 |档案管理系统（新）|
654 |P3E|
655 |档案管理系统（旧）|
656 |统一通讯平台|
657 |视频会议系统|
658 |基建物流管理系统|
659 |人力资源管理系统|
660 |财务管理系统|
661 |原OA系统|
662 |立项管理系统（原OA）|
663 |企业内部门户|
664 |工程设计管理系统|
665 |内部专家评标系统|
666 |内部网站（含信息专区）|
667 |交流园地|
668 |WCM|
669 |内部网站后台|
670 |外部网站后台|
671 |外部网站招聘管理|
672 |外部网站招投标管理|
673 |资产标识码系统|
674 |企业统计报表系统|
675 |运营日报|
676 |MAXIMO系统|
677 |施工调度管理系统|
678 |工作证管理系统|
679 |车站收益系统|
680 |系统开发服务|
681 |系统培训服务|
682 |桌面终端| |
683 |服务器| |
684 |存储和备份系统| |
685 |网络| |
686 |其他| |
687
688
689
690 == 7.8 事件关闭代码 ==
691
692 |编号|代码|描述
693 |1|已完成|设备、业务系统等故障已得到修复；
694 |2|未完成|(((
695 故障没有被修复，需要再次进行处理；
696
697 对于该类事件，需要重新开单，并分配给原来处理该事件的人员进行处理。
698 )))
699
700
701
702
703 = **8. 与其他流程的关系** =
704
705
706 (% style="text-align:center" %)
707 [[image:1730466916388-384.png]]
708
709 * 和交互管理流程的关系
710
711 用户交互流程作为事件管理流程的入口之一，统一由服务台接收用户各种需求如故障申报、服务请求等，然后再分别转到事件管理流程处理故障。
712
713 * 和问题管理流程的关系
714
715 事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。
716
717 * 和配置管理流程的关系
718
719 需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。
720
721 * 和变更管理流程的关系
722
723 在事件的解决过程中，必要时需要发起变更请求来解决事件。
724
725 * 和服务请求管理流程的关系
726
727 在事件的解决过程中，必要时需要发起服务请求来解决事件。
728
729 * 和日常运维管理流程的关系
730
731 在日常运维的过程中，如检测到有潜在风险或已发生的故障，需要发起事件单进行处理。
732
733 * 和服务级别管理流程的关系
734
735 事件管理流程中的优先级根据服务级别协议来确定，事件管理流程产生的故障中断时间等数据是服务级别管理的数据来源之一。
736
737
738
739
740
741 = **9. 关键流程衡量指标** =
742
743 流程的考核指标是为了判断流程的效率和有效性，利用整合的指标数据来确定流程改进的机会，以确保流程的有效性和效率。下面是有效测量用户交互管理流程输出的典型指标：
744
745 |衡量指标|统计方法
746 |事件总数|(((
747 数量：在事件单中根据以下条件过滤
748
749 【重复事件标记】为空
750
751 【事件解决代码】不等于‘消失’or‘误报’or‘可忽略’
752
753 【事件发生时间】在统计周期内
754 )))
755 |事件关闭的数量|数量 ：在事件总数中过滤【事件状态】＝‘关闭’
756 |事件成功关闭的数量/比率|(((
757 数量：在事件总数中过滤【事件关闭代码】＝‘已完成’
758
759 比率：数量 / 事件总数 × 100 %
760 )))
761 |规定时间内解决的事件数量/百分比|(((
762 数量：在事件总数中过滤(（【实际完成时间】－【登记时间】）<【事件完成期限】)and 【事件关闭代码】＝‘已完成’
763
764 比率：数量/事件总数 × 100 %
765 )))
766 |规定时间内响应的事件数量/百分比|(((
767 数量：在事件总数中过滤（【实际开始时间】－【登记时间】）< 优先级对应的响应时限
768
769 比率：数量/事件总数 × 100 %
770 )))
771 |平均解决时间|(((
772 完成的事件：在事件总数中过滤所有【事件状态】＝‘已解决’or ‘关闭’的事件
773
774 平均解决时间：累加完成事件的（【实际完成时间】－【登记时间】）/ 完成的事件数量
775 )))
776 |超时未解决的事件数量|数量：在事件总数中过滤(（【实际完成时间】－【登记时间】）<【事件完成期限】)and 【事件状态】！＝‘关闭’
777 |事件的一次解决率|(((
778 数量1：在事件总数中过滤【事件关闭代码】＝‘已完成’
779
780 数量2：在事件总数中过滤【事件关闭代码】＝‘未完成’
781
782 比率：（数量1－数量2 ） / 数量1  × 100 %
783 )))
784
785
786
787
788 = **10. 功能性需求** =
789
790 * ITSM平台与监控平台集成，监控系统生成的告警事件自动在ITSM平台生成事件单，并由协调员分派处理人员；
791 * 分派和转派事件单、创建变更单或请求单等人员转换的节点需要有短信通知提醒；
792
793
794 = =
795
796 = =
797
798 = **11. 流程质量控制** =
799
800
801 (% style="text-align:center" %)
802 [[image:1730466981326-640.png]]
803
804 流程活动：
805
806 |序号|(% style="width:126px" %)活动|(% style="width:1049px" %)说明|(% style="width:330px" %)角色
807 |1|(% style="width:126px" %)现有流程评估|(% style="width:1049px" %)通过对KPI的完成程度，事件历史记录等数据进行差距、趋势分析，定期对事件管理流程的实施有效性、服务质量和用户满意度进行回顾；生成差距分析评估报告、趋势分析报告|(% style="width:330px" %)流程经理、流程执行人员
808 |2|(% style="width:126px" %)制定改进计划|(% style="width:1049px" %)根据差距分析评估报告、趋势分析报告总结待改进项，制定改进计划，改进计划中包括：流程的待改进项和改进机会、改进收益、执行改进计划可能带来的影响和风险、所需资源、测试和培训计划、实施计划、相关的支持文档等内容|(% style="width:330px" %)流程经理、流程执行人员
809 |3|(% style="width:126px" %)审批改进计划|(% style="width:1049px" %)事件经理协调改进涉及到的相关人等对改进计划进行评估审批；提交RFC|(% style="width:330px" %)流程经理
810 |4|(% style="width:126px" %)执行改进计划|(% style="width:1049px" %)调动资源，组织相关人员执行被批准的改进计划|(% style="width:330px" %)流程经理、流程执行人员
811 |5|(% style="width:126px" %)回顾|(% style="width:1049px" %)对改进后的结果进行回顾，评估改进计划是否成功，存在哪些待改进项；依据PDCA方法论再次执行步骤1对现有流程进行评估，对流程进行持续改进，起到对流程质量控制的作用|(% style="width:330px" %)流程经理、流程执行人员
812
813
814 * 需要调整的既有文件及调整要求
815
816 |**序号**|**既有文件名**|**调整内容**
817 |1|《大面积报障定义》|
818
819
820
821
822 = **附录 评审修改记录** =
823
824
825 |(% colspan="2" %)(((
826 **文件收到时间：2012年7月18日**
827
828 **通过评审时间：2012年X月XXx日    **
829 )))
830 |(((
831 项目报告
832
833 名称：
834 )))|XX地铁XXXX年信息化基础架构平台建设项目_ ITIL咨询阶段成果
835 |报告内容摘要：|事件管理流程设计
836 |质量控制小组（含运维）评审意见及修改记录|(((
837 1.紧急/重大事件与应急预案的衔接关系
838
839 解答： 在紧急/重大事件子流程对应急预案的启动节点作了说明，同时简单描述了应急预案应涵盖的内容。
840
841
842 2.信管部在紧急/重大事件流程上的体现
843
844 解答：已重新制订紧急/重大事件流程图，明确标示信管部的活动节点。
845
846
847 3.大面积报障的优先级定义，要和事件管理流程的影响度匹配。
848
849 解答：已在7.2事件影响度加入了大面积报障的定义。
850
851
852 4.紧急、重大事件需要补单
853
854 解答：已增加补单原则。
855
856
857 )))
858 |项目总监评审意见及修改记录|
859 |(% colspan="2" %)(((
860 **评审结论：**
861
862 [√ ] 通过 [ ]不通过
863
864
865 质量控制小组组长签字：                           项目总监签字：
866
867 年 月 日 年 月 日
868 )))
869
870
871
深圳市艾拓先锋企业管理咨询有限公司