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