Version 14.1 by superadmin on 2024/04/12, 19:54
Show last authors
1
2
3 ==== **1、综述** ====
4
5
6 ===== **1.1 设计目的** =====
7
8
9 本文档的目的是：
10
11 1. 建立基于ITIL的业务支撑网事件管理的基本框架，提升业务支撑网的IT服务可用性
12 1. 对集团公司和各省公司业务支撑网的事件管理进行规范化、统一化管理
13 1. 指导业务支撑系统服务管理平台的建设
14
15 ===== **1.2 适用范围** =====
16
17
18 本文档作为本次项目的事件管理流程详细设计的交付物，读者对象为与事件管理流程相关的所有技术与管理人员。
19
20
21
22 ===== **1.3 相关术语** =====
23
24
25 ◆ ITIL（IT Infrastructure Library ）
26
27 ◆ 帮助台（Service Desk）
28
29 帮助台从根本上来说是提供了用户和IT部门的唯一接口。此项功能常通过集中方式提供服务。帮助台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。
30
31 ◆ 事件管理（ Incident Management）
32
33 ITIL流程之一，事件管理负责解决所有的IT事件、问题和用户请求。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。
34
35 ◆ 问题管理（Problem Management）
36
37 ITIL流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件的根本原因，并通过解除该根本原因从而防止类似事件的再次发生。同时问题管理流程也负责预防事件的发生。
38
39 ◆ 配置管理（Configuration Management）
40
41 ITIL 流程之一，配置管理负责描述，跟踪和汇报所有IT基础架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置项(CI) 。每一个CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。
42
43 ◆配置管理数据库（CMDB - Configuration Management Database）
44
45 是在配置管理流程中用于记录企业所有IT相关配置项信息及其相互关系而建立的数据库。
46
47 ◆变更管理（Change Management）
48
49 ITIL流程之一，变更管理通过控制和管理IT相关的变更， 使变更对生产环境可能的影响和风险降到最小，从而提高IT环境的整体稳定性。
50
51
52 ==== **2 事件管理流程设计** ====
53
54
55 ===== **2.1 流程目的** =====
56
57 事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：
58
59 ◆在成本允许的范围内尽快恢复IT服务
60
61 * 快速响应服务请求（电话/Web/邮件等）
62 * 用户在线获得帮助（知识库共享）
63 * 沟通事件解决的状态
64 * 和客户确认事件的解决
65
66 ◆进行事件控制
67
68 * 按规范记录事件
69 * 就事件的优先级，影响度 进行分类
70 * 分析，诊断，必要时进行升级
71 * 监视并结束事件
72 * 进行定期服务流程回顾
73
74 ◆提供IT管理信息
75
76 * 人力资源利用情况
77 * 故障处理情况
78 * 支持效率
79
80 ===== **2.2 流程主要内容** =====
81
82
83 ◆ 事件接收和记录
84
85 ◆ 分类和在线支持
86
87 事件可以是一个申告/故障/告警/咨询/业务处理/维护作业，对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。
88
89
90
91 ◆调查和诊断
92
93 ◆ 解决和恢复
94
95 ◆结束事件
96
97
98
99 ===== **2.3 与其他流程的关系** =====
100
101
102 ◆ 和问题管理流程的关系
103
104 事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。
105
106 ◆ 和配置管理流程的关系
107
108 需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。
109
110 ◆ 和变更管理流程的关系
111
112 帮助台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。
113
114
115
116 ===== **2.4 流程范围** =====
117
118
119 业务支持中心的事件管理范围包括与BOSS、客服、经分、容灾、BOSS网管相关的所有IT生产环境所产生的申告、故障、告警、咨询、业务处理和维护作业。
120
121 本事件管理范围不包括尚处于开发或测试环境的系统和应用引发的事件。
122
123
124
125 ===== **2.5 流程执行原则** =====
126
127 ====== **2.5.1 常规原则** ======
128
129 1. 所有业务支撑部门事件管理范围内发生的事件，都应该记录在服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件
130 1. 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别
131 1. 应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估
132 1. 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程
133
134 ====== **2.5.2 流程关联原则** ======
135
136 ◆ 和问题管理的关联
137
138 * 所有优先级为紧急的事件在恢复服务后，都应该创建问题单（问题单必须和事件单建立关联）
139 * 一线支持在解决事件的过程中，可以通过问题记录查找相应的解决方案
140
141 ◆ 和变更管理的关联
142
143 * 事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和事件单建立关联），变更完成后，继续事件单的处理
144 * 紧急事件（优先级为紧急的事件，下同）的处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和紧急事件单建立关联
145
146 ◆ 和配置管理的关联
147
148 * 事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位
149
150 * 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联
151
152 ====== **2.5.3 所有权原则** ======
153
154 所有权原则用来确保每个事件在任何时段都有适当的人员负责，帮助台是事件的负责人。
155
156 * 由IT用户申报的事件单，帮助台员工是该事件的责任人，必须确保事件得到有效跟踪与解决，并负责事件单的关闭
157
158 ====== **2.5.4 再分派原则** ======
159
160 事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分配到个人，或者分配到组（帮助台，一线支持，二线支持），再由组内的支持人员处理。事件单的重分派次数不应该超过5次。
161
162 1. 帮助台可以将事件单分配给一线支持，如果找不到合适的一线支持，可以直接分配到二线支持
163 1. 一线支持可以将事件单重新分配给帮助台，其他一线支持人员，二线支持
164 1. 二线支持可以将事件单重新分配给帮助台，一线支持，其他二线支持人员
165
166 ====== **2.5.5 重复事件原则** ======
167
168 重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。
169
170 1. 监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台
171 1. 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标
172 1. 如果帮助台可以判断到重复事件，则由帮助台对重复事件标识，否则由一线支持人员负责重复事件的处理
173
174 ====== **2.5.6 关闭原则** ======
175
176 由IT用户申报的事件单，关闭必须由帮助台完成。
177
178 ◆ 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为“变通方法解决”。帮助台负责和IT用户再次确认事件的解决
179
180 * 由IT用户认可获得关闭的事件单的结束代码为“成功解决”关闭
181 * 已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为“不成功”，同时创建一个新的事件单重新分配到原处理人员继续处理
182
183 ◆已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单
184
185 1. 业务支撑部门的维护人员（一线或二线）自行创建的事件单，本着“谁开单，谁负责关闭”的原则
186 1. 监控平台自动发送的事件单，第一次接收的维护人员负责关闭
187 1. 对于IT用户（例如客服）申报的事件单，可以实现由IT用户自行确认事件是否解决，超过一定期限（例如3－5天）不确认的事件单由系统自动关闭或由帮助台协助关闭
188
189 ====== **2.5.7 升级原则** ======
190
191 制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。
192
193 1. 优先级为紧急的事件，帮助台应立即升级到相应一线支持，由一线支持再次确认，如果确认了优先级为紧急，则立即升级到事件经理，并通知相应的管理层（通过服务管理平台），由事件经理启动紧急事件处理流程
194 1. 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理
195 1. 帮助台和一线支持应及时将不能解决的事件升级到下一级，若未及时升级，事件经理应及时介入，负责协调升级处理
196
197 ===== **2.6 流程相关定义** =====
198
199
200 ====== **2.6.1 事件信息项** ======
201
202
203 事件单必须包含如下事件信息项，各省可以在此基础上扩充：
204
205 |**序号**|**信息项**|**说明**
206 |1|事件ID|事件单流水号（系统自动产生）
207 |2|请求人信息|事件申报人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写）
208 |3|登记时间|在帮助台生成事件记录的时间（系统自动产生）
209 |4|地点|事件发生的地点 （手工填写）
210 |5|事件发生时间|(((
211 针对故障：指的是业务中断的实际时间 （可能早于登记时间，需要手工填写）
212
213 针对其它：缺省值等于登记时间
214 )))
215 |6|业务恢复时间|针对故障的业务恢复实际时间（手工填写）
216 |7|事件性质|参见“事件性质”定义
217 |8|事件来源|参见“事件来源”定义
218 |9|事件影响度|参见“事件影响度”定义
219 |10|事件优先级|参见“事件优先级”定义
220 |11|事件完成期限|对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限 （系统自动产生）
221 |12|事件所属系统类型|参见“事件所属系统类型”定义
222 |13|事件分类|参见“事件分类”定义
223 |14|事件标题|事件的简要描述（手工填写）
224
225 |15|事件描述|对于整个事件内容的详细描述（手工填写）
226 |16|事件解决人|事件的最终解决人（手工填写）
227 |17|事件状态|参见“事件状态”定义
228 |18|分配对象|被分配的技术支持组和人员（手工填写）
229 |19|事件日志|反映事件信息项的变化历史，如一个事件在处理过程中事件状态变化的时间点等信息（系统自动产生）
230 |20|解决方案|事件解决方案的描述（手工填写）
231 |21|事件结束代码|参见“事件结束代码”定义
232 |22|重复事件标记|标记为重复事件（手工填写）
233 |23|处理是否超时|参见“处理是否超时”定义（系统自动产生）
234 |24|事件解决人角色|参见“事件解决人角色”定义
235 |25|实际开始时间|记录事件状态到XX处理中的时间（系统自动产生）
236 |26|实际完成时间|记录事件已解决的时间（系统自动产生）
237 |27|故障厂商|记录故障厂商或集成商信息（手工填写）
238 |28|关联配置项|记录出现故障的配置项代码（手工填写）
239 |29|关联的问题单号|记录由事件引发问题时，关联的问题单号（手工填写）
240 |30|关联的变更单号|记录由事件引发变更时，关联的变更单号（手工填写）
241 |31|外部系统工单号|记录事件来自的外部系统的单号
242 |32|超时原因|记录事件处理超时的原因描述
243 |33|投诉分类|记录投诉类事件的所属投诉分类
244 |34|投诉条目|记录投诉类事件的所属投诉条目
245
246
247
248 ====== **2.6.2 事件性质** ======
249
250
251 根据系统的业务要求和管理要求，定义如下六类事件：
252
253 |**编号**|**代码**|**描述**
254 |1|故障|(((
255 指因业务支撑系统错误或反映支撑系统部分或全部功能不能正常使用的报障；
256
257 监控管理平台上报的影响系统正常使用的告警
258 )))
259 |2|申告|与业务支撑系统相关的用户投诉，如1860、营业厅等面向客户的业务受理部门转来的因支撑系统问题引发的投诉
260 |3|告警|监控平台自动产生的没有影响到系统正常使用的告警
261 |4|咨询|指对系统操作、业务流程等方面的求助和询问
262 |5|业务处理|指需要运维人员进行后台数据处理的请求，主要指业务参数、资费参数的修改和批量数据的处理
263 |6|维护作业|(((
264 指运维人员的日常维护作业或临时进行的维护作业；
265
266 总部下发的维护作业
267 )))
268
269 **注：业务处理和维护作业的处理流程见流程概要设计相关子章节。**
270
271
272
273
274
275 ====== **2.6.3 事件来源** ======
276
277 事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种：
278
279 |**编号**|**代码**|**描述**
280 |1|用户报告|用户或地市维护人员通过电话/邮件/传真报告的事件，帮助台人员手工创建事件单
281 |2|自助开单|地市等IT用户通过服务台自助系统直接提交的事件
282 |3|自动转单|通过客服系统自动转发的事件
283 |4|内部开单|省公司业务支撑部门内部提交的事件
284 |5|监控告警|监控工具自动转发过来的事件
285
286
287 ====== **2.6.4 事件所属系统类型** ======
288
289 根据目前业务支撑系统和子类的划分定义事件所属系统类型，当事件发生时，应该由帮助台初步定位是哪个系统及子类出现问题，由一线、二线进行进一步的明确。
290
291 注：各省在细化设计时不能修改此表中现有定义，第一层业务系统和第二层子类不能修改和扩充(注：第一层为”其它系统”的话，对应的子类可以扩充)，但可以有选择的基于第二层子类定义扩充进行第三层条目的细化。对没有覆盖到的业务系统用”其它系统”表示。
292
293 |**业务系统**|**子类**
294 |(% rowspan="18" %)BOSS系统|(% rowspan="2" %)营销管理
295 |
296 |渠道管理
297 |客户服务
298 |产品管理
299 |客户管理
300 |资源管理
301 |订单管理
302 |服务开通
303 |综合采集
304 |融合计费
305 |综合帐务
306 |综合结算
307 |合作伙伴管理
308 |系统管理
309 |统计报表
310 |一级BOSS
311 |其它
312 |(% rowspan="9" %)客服系统|电话呼叫中心
313 |互联网呼叫中心
314 |短信呼叫中心
315 |工单管理
316 |知识管理
317 |人力资源
318 |质量管理
319 |数据统计分析
320 |其它
321 |(% rowspan="3" %)经营分析|通用分析
322 |专题分析
323 |其它
324 |(% rowspan="3" %)容灾系统|BOSS数据保护
325 |BOSS业务接管
326 |BOSS资源复用
327 | |其它
328 |(% rowspan="3" %)BOSS网管|监控管理
329 |服务管理
330 |其它
331 |其它系统|
332
333
334 ====== **2.6.5 事件分类** ======
335
336 事件分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。在制作统计报表时，可以通过和事件所属系统类型代码的结合来统计分析故障或申告。
337
338 事件的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为”子类”，第三级分类，称之为”条目”。
339
340 注：各省可以在此表的基础上扩展子类和自定义条目，针对一个子类，可以定义多个条目。
341
342 |**类别**|**子类**
343 |(% rowspan="8" %)系统硬件|路由器
344 |网络交换机
345 |小型机
346 |PC服务器
347 |磁盘阵列
348 |存储光纤交换机
349 |磁带库
350 |光盘库
351 |(% rowspan="4" %)客服设备|排队机
352 |CTI服务器
353 |CCS
354 |IVR服务器
355 |(% rowspan="5" %)安全设施|防火墙
356 |IDS入侵监测系统
357 |IPS入侵防护系统
358 |防毒墙
359 |安全软件
360 |(% rowspan="6" %)系统软件|操作系统
361 |数据库
362 |中间件
363 |集群软件
364 |备份软件
365 |系统管理软件
366 |(% rowspan="3" %)配套设施|UPS
367 |空调
368 |其它
369 |(% rowspan="5" %)应用软件|进程
370 |数据
371 |参数
372 |代码
373 |接口
374
375
376
377
378 ====== **2.6.6 事件优先级** ======
379
380 优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级（紧急、高、中、低）。
381
382 |**编号**|**优先级代码**|**描述**
383 |1|紧急|(((
384 1. BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为全省或至少包括一个关键地市
385 1. 客服系统的电话呼叫中心业务不可用，影响面为全省或至少包括一个关键地市
386 1. 因系统原因数据处理错误，导致大量用户投诉
387 1. 来自新闻媒体、消费者协会、国家行政机关（工商、物价等）的反映或申告
388 1. 部分重要数据丢失，且无法全部恢复
389 )))
390 |2|高|(((
391 1. BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为全省一个或多个非关键地市
392 1. BOSS系统中综合采集、融合计费、产品管理、资源管理、一级BOSS、营销管理、渠道管理、合作伙伴管理、综合结算、系统管理、统计报表任一业务不可用，影响面为全省或至少包括一个关键地市
393 1. 客服系统的电话呼叫中心业务不可用，影响面为全省一个或多个非关键地市
394 1. 客服系统中互联网呼叫中心、短信呼叫中心、工单管理、知识管理、人力资源、质量管理、数据统计分析任一业务不可用，影响面为全省或至少包括一个关键地市
395 1. 经分系统的通用分析不可用，影响面为全省
396 1. 容灾系统的BOSS数据保护不可用，影响面为全省
397 1. BOSS网管系统的服务管理或监控管理不可用，影响面为全省
398 1. 用户在营业现场反应激烈
399 1. 监控管理平台严重告警
400 )))
401 |3|中|(((
402 1. 一般性系统故障
403 1. 监控管理平台主要告警
404 )))
405 |4|低|(((
406 1. 一般单个用户申告
407 1. 业务咨询
408 1. 监控管理平台一般告警
409 )))
410
411 当故障发生时，为了在判断优先级时增强实际可操作性，可以根据故障的影响范围和业务系统的关键程度在优先级映射表中定位优先级。故障的影响范围可以根据配置项中定义的‘影响范围’和用户报障描述来确定。
412
413 |(% colspan="2" %)**系统 影响范围**|**全省**|**至少包括一个关键地市**|**全省多个非关键地市**|**一个非关键地市**
414 |(% rowspan="3" %)(((
415 BOSS
416
417 （任意一个模块）
418 )))|客户服务、客户管理、服务开通、综合帐务、订单管理|紧急|紧急|高|高
419 |综合采集、融合计费、产品管理、资源管理、一级BOSS|高|高|中|中
420 |营销管理、渠道管理、合作伙伴管理、综合结算、系统管理、统计报表|高|高|中|中
421 |(((
422 客服
423
424 （任意一个模块）
425 )))|电话呼叫中心|紧急|紧急|高|高
426 |(% rowspan="2" %)(((
427 客服
428
429 （任意一个模块）
430 )))|电话呼叫中心|紧急|紧急|高|高
431 |互联网呼叫中心、短信呼叫中心、工单管理、知识管理、人力资源、质量管理、数据统计分析|高|高|中|中
432 |(% rowspan="2" %)经分|通用分析|高|中|中|低
433 |专题分析| |中|中|低
434 |(% rowspan="2" %)容灾|BOSS数据保护|高|高|中|中
435 |BOSS业务接管、BOSS资源复用|高|中|中|中
436 |BOSS网管|服务管理、监控管理|高|中|低|低
437
438 注：
439
440 1. 如果某些业务模块没有反映在优先级映射表中，各省可以根据实际需要添加
441 1. 优先级映射表中空的字段，各省在细化流程中自行定义。
442
443 ====== **2.6.7 事件响应时限和解决时限** ======
444
445 在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制，一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念，同时，也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理，同时，如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。
446
447 响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间，如果帮助台直接分配到二线支持，响应时限指的是事件状态从“已登记”到“二线处理中”经过的时间；
448
449 解决时限指的是事件状态从“已登记”到“已解决”经过的时间；
450
451
452 |**编号**|**优先级代码**|**响应时限要求**|**解决时限要求**
453 |1|紧急|30分钟|4小时
454 |2|高|1小时|8小时
455 |3|中|4小时|48小时
456 |4|低|8小时|96小时
457
458 注：
459
460 **◆ 事件通告定义**
461
462 * 通知人员列表的用途：当优先级为高或紧急的事件发生时，则按表中的人员列表发出邮件或短信通知。
463
464 |**优先级别**|**通知人员列表**
465 |紧急|事件经理，分管领导
466 |高|事件经理，分管领导
467
468 **◆ 超出响应时间的通告定义**
469
470 * 通知人员列表的用途：当服务管理平台判断到响应时限已经超出，则自动按照表中的人员列表发出邮件或短信通知。
471
472 |**优先级别**|**通知人员列表**|**事件响应时限**
473 |紧急|事件经理，分管领导，部门领导|30分钟
474 |高|事件经理，分管领导|1小时
475 |中|事件经理|4小时
476 |低|事件经理|8小时
477
478 **◆超出和即将超出解决时限的通告定义**
479
480 * 通知人员列表的用途：当服务管理平台判断到解决时限已经或即将超出，则自动按照表中的人员列表发出邮件或短信通知。
481
482 |**优先级别**|**通知时间**|**通知人员列表**|**事件解决时限**
483 |(% rowspan="2" %)紧急|3小时|事件经理，分管领导，部门领导|(% rowspan="2" %)4小时
484 |4小时|事件经理，分管领导，部门领导
485 |(% rowspan="2" %)高|7小时|事件经理，分管领导|(% rowspan="2" %)8小时
486 |8小时|事件经理，分管领导
487 |(% rowspan="2" %)中|47小时|事件经理|(% rowspan="2" %)48小时
488 |48小时|事件经理
489 |(% rowspan="2" %)低|95小时|事件经理|(% rowspan="2" %)96小时
490 |96小时|事件经理
491
492
493 ====== **2.6.8 事件影响度** ======
494
495 事件影响度用于衡量事件所影响业务的严重程度。严重程度通常通过事件所影响的人数、关键系统数以及服务故障所造成的损失来设定。
496
497 定义事件影响度等级的因素有：
498
499 1. 是否影响了核心业务
500 1. 所影响的用户数
501 1. 服务失效的影响范围和时长
502
503 事件影响度在事件的生命周期中是可以改变的，例如，初始等级为严重的故障会随着服务失效的时间变成重大故障，所以事件的影响度应在事件得到解决（服务恢复）后重新确认。
504
505 事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。
506
507 |**编号**|**影响度代码**|**事件性质**|**描述**
508 |(% rowspan="2" %)1|(% rowspan="2" %)重大|故障|(((
509 1. 全省半数以上地市或关键地市的融合计费业务中断超过6小时；
510 1. 全省半数以上地市或关键地市的营业、综合帐务、客服中任一业务中断超过3小时；
511 1. 全省半数以上地市或关键地市的综合结算业务处理中断超过24小时；
512 1. 半数以下地市全业务中断超过6小时；
513 )))
514 |申告|(((
515 1. 对移动公司造成巨大损失产生严重后果和不良影响的；
516 1. 来自新闻媒体、消费者协会、国家行政机关的反映或申告；
517 )))
518 |(% rowspan="2" %)2|(% rowspan="2" %)严重|故障|(((
519 1. 全省半数以上地市或关键地市的融合计费业务中断大于10分钟、小于6小时；
520 1. 全省半数以上地市或关键地市的营业、综合帐务、客服等业务中断均大于10分钟、小于3小时；
521 1. 全省半数以上地市或关键地市的综合结算业务处理中断大于2小时、小于24小时；
522 1. 半数以下地市全业务中断大于10分钟、小于6小时。
523 )))
524 |申告|(((
525 1. 局数据错误导致产生大量的错单；
526 1. 涉及到高额问题的申告；
527 1. 用户在营业现场反映激烈
528 )))
529 |(% rowspan="3" %)3|(% rowspan="3" %)一般|故障|(((
530 1. 系统内局部出现问题，不影响整个系统运行，不影响业务处理的故障
531 )))
532 |申告|(((
533 1. 不属于重大申告和严重申告的用户申述
534 )))
535 |告警|(((
536 1. 不影响系统的监控平台告警
537 )))
538 |4|无|咨询|(((
539 1. 一般数据查询或者使用指导
540 )))
541
542 注：各省根据自己业务情况扩展或修改本表格的描述，对于重大级别的事件，应严格按照集团公司的定义。
543
544
545
546
547 ====== **2.6.9 事件状态** ======
548
549 事件状态代码表明事件所处的处理状态，事件状态如下：
550
551 |**编号**|**代码**|**描述**
552 |1|已登记|新开事件记录或事件已创建
553 |2|分配到帮助台|事件已分配给帮助台人员
554 |3|分配到一线|事件已分配到一线支持，一线还未响应
555 |4|分配到二线|事件已分配到二线支持，二线还未响应
556 |5|一线处理中|一线支持人员已接手处理事件
557 |6|二线处理中|二线支持人员已接手处理事件
558 |7|已解决|事件已解决，支持人员联系用户验证事件是否获得解决
559 |8|关闭|事件已关闭
560
561
562 ====== **2.6.10 事件结束代码** ======
563
564 事件结束代码说明了事件是在何种情况下关闭的，结束代码如下：
565
566 |1|成功解决|事件获得成功解决
567 |2|变通方法解决|事件已通过变通方法或者临时措施获得解决，但是需要进行更进一步的根源分析
568 |3|不成功|事件没有获得解决（用户没有认可解决时使用）
569 |4|消失|事件自行消失
570 |5|误报|不属于业务支撑部门管理范围的事件
571 |6|可忽略|如通过其它系统接口或监控系统提交的垃圾信息，经确认属于无效信息
572
573
574 ====== **2.6.11 事件解决人角色** ======
575
576 事件解决人角色用来标明该事件单最终解决的角色是帮助台、一线还是二线。
577
578 |**编号**|**代码**|**描述**
579 |1|帮助台|帮助台最终解决事件
580 |2|一线|一线支持最终解决事件
581 |3|二线|二线支持最终解决事件
582
583
584 ====== **2.6.12 处理是否超时** ======
585
586 每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。
587
588 |**编号**|**代码**|**描述**
589 |1|未超时|未超时
590 |2|超时|事件已超出规定的解决时限
591
592
593 ====== **2.6.13 故障厂商** ======
594
595 用来在事件单中记录是哪个厂商的设备/系统，或者哪个集成商的应用软件发生故障(针对事件分类中的”应用软件”故障)。代码定义参见下表厂商和集成商名称标准（可以根据情况从厂商和集成商两个表中选择一个合适的故障厂商）。
596
597 各省可以根据实际情况对厂商名称标准表和集成商名称标准表进行扩充。
598
599 |**编号**|**厂商名称**
600 |(((
601 1.
602 )))|3COM
603 |(((
604 2.
605 )))|AVAYA
606 |(((
607 3.
608 )))|BEA
609 |(((
610 4.
611 )))|BMC
612 |(((
613 5.
614 )))|Borland
615 |(((
616 6.
617 )))|CA
618 |(((
619 7.
620 )))|Cisco
621 |(((
622 8.
623 )))|DB2
624 |(((
625 9.
626 )))|EMC
627 |(((
628 10.
629 )))|HDS
630 |(((
631 11.
632 )))|HP
633 |(((
634 12.
635 )))|IBM
636 |(((
637 13.
638 )))|Informix
639 |(((
640 14.
641 )))|McDATA
642 |(((
643 15.
644 )))|Microsoft
645 |(((
646 16.
647 )))|NCR
648 |(((
649 17.
650 )))|NETAPP
651 |(((
652 18.
653 )))|Oracle
654 |(((
655 19.
656 )))|Quantum ATL
657 |(((
658 20.
659 )))|STK
660 |(((
661 21.
662 )))|SUN
663 |(((
664 22.
665 )))|Sybase
666 |(((
667 23.
668 )))|TERADATA
669 |(((
670 24.
671 )))|北电
672 |(((
673 25.
674 )))|东方通
675 |(((
676 26.
677 )))|中兴
678 |(((
679 27.
680 )))|华为
681 |(((
682 28.
683 )))|SYMANTEC
684 |(((
685 29.
686 )))|QUEST
687 |(((
688 30.
689 )))|REDHAT
690 |(((
691 31.
692 )))|BROCADE
693
694 |**编号**|**集成商名称**
695 |(((
696 1.
697 )))|亚信
698 |(((
699 2.
700 )))|联创
701 |(((
702 3.
703 )))|斯特奇
704 |(((
705 4.
706 )))|神州数码
707 |(((
708 5.
709 )))|华为
710 |(((
711 6.
712 )))|新大陆
713 |(((
714 7.
715 )))|亿阳
716 |(((
717 8.
718 )))|神州泰岳
719 |(((
720 9.
721 )))|创我
722 |(((
723 10.
724 )))|新宇
725 |(((
726 11.
727 )))|从兴
728
729
730 ====== **2.6.14 投诉分类** ======
731
732 对于投诉类事件，帮助台可初步定位是哪类投诉，由一线、二线进行进一步的明确。
733
734 |**编号**|**分类           **
735 |1|营业类
736 |2|计费类
737 |3|帐务类
738 |4|资费类
739 |5|SP类
740 |6|开关机类
741 |7|冲值类
742 |8|接口类
743 |9|其它类
744
745
746 ====== **2.6.15 投诉条目** ======
747
748 对于投诉类事件，帮助台可初步定位投诉属于哪个条目，由一线、二线进行进一步的明确。
749
750 |**编号**|**条目                  **
751 |1|程序问题
752 |2|系统故障
753 |3|理解问题
754 |4|用户数据
755 |5|话单延迟
756 |6|三批问题
757 |7|操作失误
758 |8|流程问题
759 |9|处理积压
760 |10|同步问题
761 |11|查询问题
762 |12|数据问题
763 |13|彩铃功能
764 |14|彩铃费用
765 |15|彩铃其它
766 |16|其它SP
767 |17|指令延迟
768 |18|HLR问题
769 |19|SCP问题
770 |20|接口问题
771 |21|到帐延迟
772 |22|网上营业厅
773 |23|短信营业厅
774 |24|自助终端
775 |25|银行联网
776 |26|智能网
777 |27|V网
778 |28|天府卡
779 |29|客服系统类
780 |30|需求类
781 |31|查询类
782 |32|误操作类
783 |33|其它类
784
785
786 ===== **2.7 流程概要设计** =====
787
788 事件管理概要设计流程图如下：
789
790 [[image:微信图片_20240412192813.png||height="398" width="438"]]
791
792
793 事件管理概要设计流程说明
794
795 |**序号**|**步骤名称**|**责任人**|**说明**
796 |100.1|事件记录和分类|帮助台|(((
797 1. 帮助台对来自用户和系统自动产生的事件进行详细记录，其中包括申告/咨询/告警/故障/维护作业/业务处理
798 1. 帮助台负责在接收到事件后进行分类转发，维护作业/业务处理转相应子流程处理，对申告/咨询/告警/故障类事件进行分类转发
799 1. 对于初步判断为紧急的事件马上升级到一线人员处理
800 1. 对于非业务支撑维护职责范围的事件转给其它相关责任部门
801 )))
802 |100.2|初始支持|帮助台|(((
803 1. 属于帮助台技能范围内可以处理的事件，帮助台应尝试解决，如果无法解决需及时升级到一线支持
804 1. 不属于帮助台职责范围的事件，立即分派到相应的一线支持
805 )))
806 |100.3|一线尝试解决|一线支持|(((
807 1. 一线支持人员在接受到由帮助台派发的事件后，进行调查诊断，尝试解决
808 1. 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案
809 1. 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
810 1. 不能解决的事件，转100.4二线尝试解决
811 )))
812 |100.4|二线尝试解决|二线支持|(((
813 1. 二线支持人员接受事件，进行调查诊断，尝试解决方案，在必要时根据服务协议联系厂商帮助解决并负责核查
814 1. 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案
815 1. 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
816 1. 指定时限内不能解决的事件，通告事件经理，由事件经理负责协调资源
817 )))
818 |100.5|紧急事件再确认|一线支持|(((
819 1. 一线支持人员接受到来自帮助台的紧急事件后，根据事件优先级别标准再次确认事件是否为紧急事件
820 1. 如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理，转101紧急事件处理子流程
821 1. 如不是，转100.3一线尝试解决，开始正常事件解决流程
822 )))
823 |100.6|记录解决方案细节|(((
824 帮助台
825
826 一线支持
827
828 二线支持
829 )))|(((
830 1. 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息
831 1. 针对故障，一线/二线支持必须记录业务恢复时间
832 )))
833 |100.7|关闭事件|(((
834 帮助台
835
836 一线支持
837
838 二线支持
839 )))|(((
840 1. 帮助台与申报用户确认事件是否已得到解决，如果解决，事件以成功解决或变通方法解决而关闭；否则，事件以不成功关闭，重新开事件记录，并与原记录做关联，分派到原处理人员继续处理
841 1. 帮助台在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确
842 1. 其它由一线或二线人员自行创建的事件单，则由开单人负责关闭
843 )))
844 |100.8|事件处理的监控|事件经理|(((
845 1. 负责监控所有未关闭的事件的处理状况，对接收到的超时告警应及时关注，并负责协调资源，保证事件的最终解决
846 1. 当事件优先级为紧急时，应按照紧急事件处理流程处理紧急事件
847 )))
848 |101|紧急事件处理流程|事件经理|(((
849 1. 事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程
850 )))
851 |102|维护作业子流程|(((
852 一线支持
853
854 二线支持
855 )))|(((
856 1. 根据业务支撑部门核准后的年度维护作业计划/月维护作业计划，集团公司下发的维护作业请求执行相应的维护作业。
857 1. 维护作业执行人员负责维护作业的关闭
858 )))
859 |103|业务处理子流程|(((
860 一线支持
861
862 二线支持
863 )))|(((
864 1. 业务处理子流程主要处理业务参数、资费参数的修改和批量数据的修改
865 1. 基本的处理过程应该包含制定方案、执行、复核，各省可以根据自己的运作情况具体细化
866 )))
867
868
869
870 ===== **2.8 流程详细设计** =====
871
872
873 ====== **2.8.1（100.1）事件记录和分类** ======
874
875 **[[image:20.png||height="453" width="525"]]**
876
877
878 流程描述如下：
879
880 |**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
881 |100.1.1|从任务队列中接受事件|帮助台|事件队列|需要处理的事件|(((
882 事件任务队列的来源：
883
884 1. 监控系统自动发送的告警
885 1. 业务部门通过其它接口（客服等）转发的事件单
886 1. IT用户通过服务台自助系统提交的事件单
887
888 帮助台负责检查事件任务队列中的新事件单，开始处理
889
890
891 )))
892 | |是否为本中心职责范围？|帮助台|事件单| |(((
893 帮助台判断是否属于本中心职责范围：
894
895 1. 是，进行事件分类的处理；
896 1. 否，转100.1.3回复和关闭
897 )))
898 |100.1.2|新建事件|帮助台|电话/OA/传真|新建的事件记录|(((
899 属于本中心职责范围，帮助台负责创建新的事件单，填写详细情况描述，不属于本中心处理的，直接电话回复。
900
901 事件单填写的详细内容如下：
902
903 1. 报告人姓名、联系电话、邮件、分公司、部门
904 1. 事件标题和描述
905 1. 必要的附件
906 1. 事件发生时间和地点
907 1. 事件来源和事件性质
908 1. 进行事件分类
909 1. 设定事件状态为“新建”
910 )))
911 |100.1.3|回复和关闭|帮助台|误报的事件单|关闭的事件单|联系申报用户，说明情况，将该事件单状态置为“关闭”，结束代码为“误报”，保存关闭
912 | |是否为重复事件？|帮助台|事件记录|相应的处理流程|(((
913 帮助台根据重复事件原则，判断该事件单是否属于重复事件：
914
915 1. 是，转100.1.4重复事件处理；
916 1. 否，事件分类的判断
917 )))
918 |100.1.4|重复事件处理|帮助台|重复事件| |在重复事件单的“重复事件标记”中记录正在处理的事件单的流水号，状态置为“XX处理中”，保存退出。
919 | |事件性质区分？|帮助台|事件性质|相应的处理流程|(((
920 根据事件性质区分不同的处理流程：
921
922 1. 如果是业务处理，走103业务处理子流程；
923 1. 如果是维护作业，走102维护作业子流程；
924 1. 其它事件，走100.1.5事件影响度、优先级设定
925
926
927 )))
928 |100.1.5|事件影响度、优先级设定|帮助台|事件记录|确定了影响度和优先级的事件|根据上报的事件描述，判断对业务的影响程度，并对照优先级代码表，确定事件的优先级，以及初始确定的影响度
929 | |优先级为紧急吗？|帮助台|事件优先级|相应的处理流程|(((
930 帮助台根据业务的影响程度和事件优先级判定的条件，初步判断优先级别：
931
932 1. 优先级为紧急，转100.5紧急事件再确认；
933 1. 其它优先级否，转100.2初始支持
934 )))
935
936
937
938 **2.8.2 （100.2）初始支持**
939
940 **[[image:28.png||height="301" width="617"]]**
941
942
943 流程描述如下：
944
945 |**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
946 | |帮助台技能可以处理吗？|帮助台|事件记录|处理方式|(((
947 帮助台根据事件分类和事件描述，判断处理职责是否在帮助台： 
948
949 1. 是，转100.2.1尝试处理；
950 1. 否，转100.2.2分配到一线支持
951 )))
952 |100.2.1|尝试处理|帮助台|事件记录| |帮助台运用知识库和自身技能在规定的时限内尝试解决，将事件状态置为“分配到帮助台”，如果不能处理应及时将事件单分配到一线支持
953 |100.2.2|分配到一线支持|帮助台|事件记录|分配到一线的事件单|选择相关的一线处理组和处理人员分派，并将事件状态置为“分配到一线”
954 | |解决了吗？|帮助台| | |(((
955 将解决方案和用户沟通，判断是否可以解决；
956
957 1. 可以解决，转100.6记录解决方案细节
958 1. 无法解决，转100.2.2分配到一线支持
959 )))
960
961 ====== **2.8.3 （100.3）一线尝试解决** ======
962
963 **[[image:32.png||height="465" width="524"]]**
964
965
966 流程描述如下：
967
968
969 ====== **2.8.4 （100.4）二线尝试解决** ======
970
971 **[[image:07.png||height="557" width="547"]]**
972
973
974
深圳市艾拓先锋企业管理咨询有限公司