Version 23.1 by superadmin on 2024/04/13, 10:38
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 ====== **2.6.2 事件性质** ======
247
248
249 根据系统的业务要求和管理要求，定义如下六类事件：
250
251 |**编号**|**代码**|**描述**
252 |1|故障|(((
253 指因业务支撑系统错误或反映支撑系统部分或全部功能不能正常使用的报障；
254
255 监控管理平台上报的影响系统正常使用的告警
256 )))
257 |2|申告|与业务支撑系统相关的用户投诉，如1860、营业厅等面向客户的业务受理部门转来的因支撑系统问题引发的投诉
258 |3|告警|监控平台自动产生的没有影响到系统正常使用的告警
259 |4|咨询|指对系统操作、业务流程等方面的求助和询问
260 |5|业务处理|指需要运维人员进行后台数据处理的请求，主要指业务参数、资费参数的修改和批量数据的处理
261 |6|维护作业|(((
262 指运维人员的日常维护作业或临时进行的维护作业；
263
264 总部下发的维护作业
265 )))
266
267 **注：业务处理和维护作业的处理流程见流程概要设计相关子章节。**
268
269
270
271
272
273 ====== **2.6.3 事件来源** ======
274
275 事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种：
276
277 |**编号**|**代码**|**描述**
278 |1|用户报告|用户或地市维护人员通过电话/邮件/传真报告的事件，帮助台人员手工创建事件单
279 |2|自助开单|地市等IT用户通过服务台自助系统直接提交的事件
280 |3|自动转单|通过客服系统自动转发的事件
281 |4|内部开单|省公司业务支撑部门内部提交的事件
282 |5|监控告警|监控工具自动转发过来的事件
283
284 ====== **2.6.4 事件所属系统类型** ======
285
286 根据目前业务支撑系统和子类的划分定义事件所属系统类型，当事件发生时，应该由帮助台初步定位是哪个系统及子类出现问题，由一线、二线进行进一步的明确。
287
288 注：各省在细化设计时不能修改此表中现有定义，第一层业务系统和第二层子类不能修改和扩充(注：第一层为”其它系统”的话，对应的子类可以扩充)，但可以有选择的基于第二层子类定义扩充进行第三层条目的细化。对没有覆盖到的业务系统用”其它系统”表示。
289
290 |**业务系统**|**子类**
291 |(% rowspan="18" %)BOSS系统|(% rowspan="2" %)营销管理
292 |
293 |渠道管理
294 |客户服务
295 |产品管理
296 |客户管理
297 |资源管理
298 |订单管理
299 |服务开通
300 |综合采集
301 |融合计费
302 |综合帐务
303 |综合结算
304 |合作伙伴管理
305 |系统管理
306 |统计报表
307 |一级BOSS
308 |其它
309 |(% rowspan="9" %)客服系统|电话呼叫中心
310 |互联网呼叫中心
311 |短信呼叫中心
312 |工单管理
313 |知识管理
314 |人力资源
315 |质量管理
316 |数据统计分析
317 |其它
318 |(% rowspan="3" %)经营分析|通用分析
319 |专题分析
320 |其它
321 |(% rowspan="3" %)容灾系统|BOSS数据保护
322 |BOSS业务接管
323 |BOSS资源复用
324 | |其它
325 |(% rowspan="3" %)BOSS网管|监控管理
326 |服务管理
327 |其它
328 |其它系统|
329
330 ====== **2.6.5 事件分类** ======
331
332 事件分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。在制作统计报表时，可以通过和事件所属系统类型代码的结合来统计分析故障或申告。
333
334 事件的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为”子类”，第三级分类，称之为”条目”。
335
336 注：各省可以在此表的基础上扩展子类和自定义条目，针对一个子类，可以定义多个条目。
337
338 |**类别**|**子类**
339 |(% rowspan="8" %)系统硬件|路由器
340 |网络交换机
341 |小型机
342 |PC服务器
343 |磁盘阵列
344 |存储光纤交换机
345 |磁带库
346 |光盘库
347 |(% rowspan="4" %)客服设备|排队机
348 |CTI服务器
349 |CCS
350 |IVR服务器
351 |(% rowspan="5" %)安全设施|防火墙
352 |IDS入侵监测系统
353 |IPS入侵防护系统
354 |防毒墙
355 |安全软件
356 |(% rowspan="6" %)系统软件|操作系统
357 |数据库
358 |中间件
359 |集群软件
360 |备份软件
361 |系统管理软件
362 |(% rowspan="3" %)配套设施|UPS
363 |空调
364 |其它
365 |(% rowspan="5" %)应用软件|进程
366 |数据
367 |参数
368 |代码
369 |接口
370
371 ====== **2.6.6 事件优先级** ======
372
373 优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级（紧急、高、中、低）。
374
375 |**编号**|**优先级代码**|**描述**
376 |1|紧急|(((
377 1. BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为全省或至少包括一个关键地市
378 1. 客服系统的电话呼叫中心业务不可用，影响面为全省或至少包括一个关键地市
379 1. 因系统原因数据处理错误，导致大量用户投诉
380 1. 来自新闻媒体、消费者协会、国家行政机关（工商、物价等）的反映或申告
381 1. 部分重要数据丢失，且无法全部恢复
382 )))
383 |2|高|(((
384 1. BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为全省一个或多个非关键地市
385 1. BOSS系统中综合采集、融合计费、产品管理、资源管理、一级BOSS、营销管理、渠道管理、合作伙伴管理、综合结算、系统管理、统计报表任一业务不可用，影响面为全省或至少包括一个关键地市
386 1. 客服系统的电话呼叫中心业务不可用，影响面为全省一个或多个非关键地市
387 1. 客服系统中互联网呼叫中心、短信呼叫中心、工单管理、知识管理、人力资源、质量管理、数据统计分析任一业务不可用，影响面为全省或至少包括一个关键地市
388 1. 经分系统的通用分析不可用，影响面为全省
389 1. 容灾系统的BOSS数据保护不可用，影响面为全省
390 1. BOSS网管系统的服务管理或监控管理不可用，影响面为全省
391 1. 用户在营业现场反应激烈
392 1. 监控管理平台严重告警
393 )))
394 |3|中|(((
395 1. 一般性系统故障
396 1. 监控管理平台主要告警
397 )))
398 |4|低|(((
399 1. 一般单个用户申告
400 1. 业务咨询
401 1. 监控管理平台一般告警
402 )))
403
404 当故障发生时，为了在判断优先级时增强实际可操作性，可以根据故障的影响范围和业务系统的关键程度在优先级映射表中定位优先级。故障的影响范围可以根据配置项中定义的‘影响范围’和用户报障描述来确定。
405
406 |(% colspan="2" %)**系统 影响范围**|**全省**|**至少包括一个关键地市**|**全省多个非关键地市**|**一个非关键地市**
407 |(% rowspan="3" %)(((
408 BOSS
409
410 （任意一个模块）
411 )))|客户服务、客户管理、服务开通、综合帐务、订单管理|紧急|紧急|高|高
412 |综合采集、融合计费、产品管理、资源管理、一级BOSS|高|高|中|中
413 |营销管理、渠道管理、合作伙伴管理、综合结算、系统管理、统计报表|高|高|中|中
414 |(((
415 客服
416
417 （任意一个模块）
418 )))|电话呼叫中心|紧急|紧急|高|高
419 |(% rowspan="2" %)(((
420 客服
421
422 （任意一个模块）
423 )))|电话呼叫中心|紧急|紧急|高|高
424 |互联网呼叫中心、短信呼叫中心、工单管理、知识管理、人力资源、质量管理、数据统计分析|高|高|中|中
425 |(% rowspan="2" %)经分|通用分析|高|中|中|低
426 |专题分析| |中|中|低
427 |(% rowspan="2" %)容灾|BOSS数据保护|高|高|中|中
428 |BOSS业务接管、BOSS资源复用|高|中|中|中
429 |BOSS网管|服务管理、监控管理|高|中|低|低
430
431 注：
432
433 1. 如果某些业务模块没有反映在优先级映射表中，各省可以根据实际需要添加
434 1. 优先级映射表中空的字段，各省在细化流程中自行定义。
435
436 ====== **2.6.7 事件响应时限和解决时限** ======
437
438 在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制，一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念，同时，也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理，同时，如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。
439
440 响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间，如果帮助台直接分配到二线支持，响应时限指的是事件状态从“已登记”到“二线处理中”经过的时间；
441
442 解决时限指的是事件状态从“已登记”到“已解决”经过的时间；
443
444
445 |**编号**|**优先级代码**|**响应时限要求**|**解决时限要求**
446 |1|紧急|30分钟|4小时
447 |2|高|1小时|8小时
448 |3|中|4小时|48小时
449 |4|低|8小时|96小时
450
451 注：
452
453 **◆ 事件通告定义**
454
455 * 通知人员列表的用途：当优先级为高或紧急的事件发生时，则按表中的人员列表发出邮件或短信通知。
456
457 |**优先级别**|**通知人员列表**
458 |紧急|事件经理，分管领导
459 |高|事件经理，分管领导
460
461 **◆ 超出响应时间的通告定义**
462
463 * 通知人员列表的用途：当服务管理平台判断到响应时限已经超出，则自动按照表中的人员列表发出邮件或短信通知。
464
465 |**优先级别**|**通知人员列表**|**事件响应时限**
466 |紧急|事件经理，分管领导，部门领导|30分钟
467 |高|事件经理，分管领导|1小时
468 |中|事件经理|4小时
469 |低|事件经理|8小时
470
471 **◆超出和即将超出解决时限的通告定义**
472
473 * 通知人员列表的用途：当服务管理平台判断到解决时限已经或即将超出，则自动按照表中的人员列表发出邮件或短信通知。
474
475 |**优先级别**|**通知时间**|**通知人员列表**|**事件解决时限**
476 |(% rowspan="2" %)紧急|3小时|事件经理，分管领导，部门领导|(% rowspan="2" %)4小时
477 |4小时|事件经理，分管领导，部门领导
478 |(% rowspan="2" %)高|7小时|事件经理，分管领导|(% rowspan="2" %)8小时
479 |8小时|事件经理，分管领导
480 |(% rowspan="2" %)中|47小时|事件经理|(% rowspan="2" %)48小时
481 |48小时|事件经理
482 |(% rowspan="2" %)低|95小时|事件经理|(% rowspan="2" %)96小时
483 |96小时|事件经理
484
485 ====== **2.6.8 事件影响度** ======
486
487 事件影响度用于衡量事件所影响业务的严重程度。严重程度通常通过事件所影响的人数、关键系统数以及服务故障所造成的损失来设定。
488
489 定义事件影响度等级的因素有：
490
491 1. 是否影响了核心业务
492 1. 所影响的用户数
493 1. 服务失效的影响范围和时长
494
495 事件影响度在事件的生命周期中是可以改变的，例如，初始等级为严重的故障会随着服务失效的时间变成重大故障，所以事件的影响度应在事件得到解决（服务恢复）后重新确认。
496
497 事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。
498
499 |**编号**|**影响度代码**|**事件性质**|**描述**
500 |(% rowspan="2" %)1|(% rowspan="2" %)重大|故障|(((
501 1. 全省半数以上地市或关键地市的融合计费业务中断超过6小时；
502 1. 全省半数以上地市或关键地市的营业、综合帐务、客服中任一业务中断超过3小时；
503 1. 全省半数以上地市或关键地市的综合结算业务处理中断超过24小时；
504 1. 半数以下地市全业务中断超过6小时；
505 )))
506 |申告|(((
507 1. 对移动公司造成巨大损失产生严重后果和不良影响的；
508 1. 来自新闻媒体、消费者协会、国家行政机关的反映或申告；
509 )))
510 |(% rowspan="2" %)2|(% rowspan="2" %)严重|故障|(((
511 1. 全省半数以上地市或关键地市的融合计费业务中断大于10分钟、小于6小时；
512 1. 全省半数以上地市或关键地市的营业、综合帐务、客服等业务中断均大于10分钟、小于3小时；
513 1. 全省半数以上地市或关键地市的综合结算业务处理中断大于2小时、小于24小时；
514 1. 半数以下地市全业务中断大于10分钟、小于6小时。
515 )))
516 |申告|(((
517 1. 局数据错误导致产生大量的错单；
518 1. 涉及到高额问题的申告；
519 1. 用户在营业现场反映激烈
520 )))
521 |(% rowspan="3" %)3|(% rowspan="3" %)一般|故障|(((
522 1. 系统内局部出现问题，不影响整个系统运行，不影响业务处理的故障
523 )))
524 |申告|(((
525 1. 不属于重大申告和严重申告的用户申述
526 )))
527 |告警|(((
528 1. 不影响系统的监控平台告警
529 )))
530 |4|无|咨询|(((
531 1. 一般数据查询或者使用指导
532 )))
533
534 注：各省根据自己业务情况扩展或修改本表格的描述，对于重大级别的事件，应严格按照集团公司的定义。
535
536
537
538
539 ====== **2.6.9 事件状态** ======
540
541 事件状态代码表明事件所处的处理状态，事件状态如下：
542
543 |**编号**|**代码**|**描述**
544 |1|已登记|新开事件记录或事件已创建
545 |2|分配到帮助台|事件已分配给帮助台人员
546 |3|分配到一线|事件已分配到一线支持，一线还未响应
547 |4|分配到二线|事件已分配到二线支持，二线还未响应
548 |5|一线处理中|一线支持人员已接手处理事件
549 |6|二线处理中|二线支持人员已接手处理事件
550 |7|已解决|事件已解决，支持人员联系用户验证事件是否获得解决
551 |8|关闭|事件已关闭
552
553 ====== **2.6.10 事件结束代码** ======
554
555 事件结束代码说明了事件是在何种情况下关闭的，结束代码如下：
556
557 |1|成功解决|事件获得成功解决
558 |2|变通方法解决|事件已通过变通方法或者临时措施获得解决，但是需要进行更进一步的根源分析
559 |3|不成功|事件没有获得解决（用户没有认可解决时使用）
560 |4|消失|事件自行消失
561 |5|误报|不属于业务支撑部门管理范围的事件
562 |6|可忽略|如通过其它系统接口或监控系统提交的垃圾信息，经确认属于无效信息
563
564 ====== **2.6.11 事件解决人角色** ======
565
566 事件解决人角色用来标明该事件单最终解决的角色是帮助台、一线还是二线。
567
568 |**编号**|**代码**|**描述**
569 |1|帮助台|帮助台最终解决事件
570 |2|一线|一线支持最终解决事件
571 |3|二线|二线支持最终解决事件
572
573 ====== **2.6.12 处理是否超时** ======
574
575 每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。
576
577 |**编号**|**代码**|**描述**
578 |1|未超时|未超时
579 |2|超时|事件已超出规定的解决时限
580
581 ====== **2.6.13 故障厂商** ======
582
583 用来在事件单中记录是哪个厂商的设备/系统，或者哪个集成商的应用软件发生故障(针对事件分类中的”应用软件”故障)。代码定义参见下表厂商和集成商名称标准（可以根据情况从厂商和集成商两个表中选择一个合适的故障厂商）。
584
585 各省可以根据实际情况对厂商名称标准表和集成商名称标准表进行扩充。
586
587 |**编号**|**厂商名称**
588 |(((
589 1.
590 )))|3COM
591 |(((
592 2.
593 )))|AVAYA
594 |(((
595 3.
596 )))|BEA
597 |(((
598 4.
599 )))|BMC
600 |(((
601 5.
602 )))|Borland
603 |(((
604 6.
605 )))|CA
606 |(((
607 7.
608 )))|Cisco
609 |(((
610 8.
611 )))|DB2
612 |(((
613 9.
614 )))|EMC
615 |(((
616 10.
617 )))|HDS
618 |(((
619 11.
620 )))|HP
621 |(((
622 12.
623 )))|IBM
624 |(((
625 13.
626 )))|Informix
627 |(((
628 14.
629 )))|McDATA
630 |(((
631 15.
632 )))|Microsoft
633 |(((
634 16.
635 )))|NCR
636 |(((
637 17.
638 )))|NETAPP
639 |(((
640 18.
641 )))|Oracle
642 |(((
643 19.
644 )))|Quantum ATL
645 |(((
646 20.
647 )))|STK
648 |(((
649 21.
650 )))|SUN
651 |(((
652 22.
653 )))|Sybase
654 |(((
655 23.
656 )))|TERADATA
657 |(((
658 24.
659 )))|北电
660 |(((
661 25.
662 )))|东方通
663 |(((
664 26.
665 )))|中兴
666 |(((
667 27.
668 )))|华为
669 |(((
670 28.
671 )))|SYMANTEC
672 |(((
673 29.
674 )))|QUEST
675 |(((
676 30.
677 )))|REDHAT
678 |(((
679 31.
680 )))|BROCADE
681
682 |**编号**|**集成商名称**
683 |(((
684 1.
685 )))|亚信
686 |(((
687 2.
688 )))|联创
689 |(((
690 3.
691 )))|斯特奇
692 |(((
693 4.
694 )))|神州数码
695 |(((
696 5.
697 )))|华为
698 |(((
699 6.
700 )))|新大陆
701 |(((
702 7.
703 )))|亿阳
704 |(((
705 8.
706 )))|神州泰岳
707 |(((
708 9.
709 )))|创我
710 |(((
711 10.
712 )))|新宇
713 |(((
714 11.
715 )))|从兴
716
717 ====== **2.6.14 投诉分类** ======
718
719 对于投诉类事件，帮助台可初步定位是哪类投诉，由一线、二线进行进一步的明确。
720
721 |**编号**|**分类           **
722 |1|营业类
723 |2|计费类
724 |3|帐务类
725 |4|资费类
726 |5|SP类
727 |6|开关机类
728 |7|冲值类
729 |8|接口类
730 |9|其它类
731
732 ====== **2.6.15 投诉条目** ======
733
734 对于投诉类事件，帮助台可初步定位投诉属于哪个条目，由一线、二线进行进一步的明确。
735
736 |**编号**|**条目                  **
737 |1|程序问题
738 |2|系统故障
739 |3|理解问题
740 |4|用户数据
741 |5|话单延迟
742 |6|三批问题
743 |7|操作失误
744 |8|流程问题
745 |9|处理积压
746 |10|同步问题
747 |11|查询问题
748 |12|数据问题
749 |13|彩铃功能
750 |14|彩铃费用
751 |15|彩铃其它
752 |16|其它SP
753 |17|指令延迟
754 |18|HLR问题
755 |19|SCP问题
756 |20|接口问题
757 |21|到帐延迟
758 |22|网上营业厅
759 |23|短信营业厅
760 |24|自助终端
761 |25|银行联网
762 |26|智能网
763 |27|V网
764 |28|天府卡
765 |29|客服系统类
766 |30|需求类
767 |31|查询类
768 |32|误操作类
769 |33|其它类
770
771 ===== **2.7 流程概要设计** =====
772
773 事件管理概要设计流程图如下：
774
775 [[image:微信图片_20240412192813.png||height="398" width="438"]]
776
777
778 事件管理概要设计流程说明
779
780 |**序号**|**步骤名称**|**责任人**|**说明**
781 |100.1|事件记录和分类|帮助台|(((
782 1. 帮助台对来自用户和系统自动产生的事件进行详细记录，其中包括申告/咨询/告警/故障/维护作业/业务处理
783 1. 帮助台负责在接收到事件后进行分类转发，维护作业/业务处理转相应子流程处理，对申告/咨询/告警/故障类事件进行分类转发
784 1. 对于初步判断为紧急的事件马上升级到一线人员处理
785 1. 对于非业务支撑维护职责范围的事件转给其它相关责任部门
786 )))
787 |100.2|初始支持|帮助台|(((
788 1. 属于帮助台技能范围内可以处理的事件，帮助台应尝试解决，如果无法解决需及时升级到一线支持
789 1. 不属于帮助台职责范围的事件，立即分派到相应的一线支持
790 )))
791 |100.3|一线尝试解决|一线支持|(((
792 1. 一线支持人员在接受到由帮助台派发的事件后，进行调查诊断，尝试解决
793 1. 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案
794 1. 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
795 1. 不能解决的事件，转100.4二线尝试解决
796 )))
797 |100.4|二线尝试解决|二线支持|(((
798 1. 二线支持人员接受事件，进行调查诊断，尝试解决方案，在必要时根据服务协议联系厂商帮助解决并负责核查
799 1. 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解决方案
800 1. 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
801 1. 指定时限内不能解决的事件，通告事件经理，由事件经理负责协调资源
802 )))
803 |100.5|紧急事件再确认|一线支持|(((
804 1. 一线支持人员接受到来自帮助台的紧急事件后，根据事件优先级别标准再次确认事件是否为紧急事件
805 1. 如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理，转101紧急事件处理子流程
806 1. 如不是，转100.3一线尝试解决，开始正常事件解决流程
807 )))
808 |100.6|记录解决方案细节|(((
809 帮助台
810
811 一线支持
812
813 二线支持
814 )))|(((
815 1. 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息
816 1. 针对故障，一线/二线支持必须记录业务恢复时间
817 )))
818 |100.7|关闭事件|(((
819 帮助台
820
821 一线支持
822
823 二线支持
824 )))|(((
825 1. 帮助台与申报用户确认事件是否已得到解决，如果解决，事件以成功解决或变通方法解决而关闭；否则，事件以不成功关闭，重新开事件记录，并与原记录做关联，分派到原处理人员继续处理
826 1. 帮助台在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确
827 1. 其它由一线或二线人员自行创建的事件单，则由开单人负责关闭
828 )))
829 |100.8|事件处理的监控|事件经理|(((
830 1. 负责监控所有未关闭的事件的处理状况，对接收到的超时告警应及时关注，并负责协调资源，保证事件的最终解决
831 1. 当事件优先级为紧急时，应按照紧急事件处理流程处理紧急事件
832 )))
833 |101|紧急事件处理流程|事件经理|(((
834 1. 事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程
835 )))
836 |102|维护作业子流程|(((
837 一线支持
838
839 二线支持
840 )))|(((
841 1. 根据业务支撑部门核准后的年度维护作业计划/月维护作业计划，集团公司下发的维护作业请求执行相应的维护作业。
842 1. 维护作业执行人员负责维护作业的关闭
843 )))
844 |103|业务处理子流程|(((
845 一线支持
846
847 二线支持
848 )))|(((
849 1. 业务处理子流程主要处理业务参数、资费参数的修改和批量数据的修改
850 1. 基本的处理过程应该包含制定方案、执行、复核，各省可以根据自己的运作情况具体细化
851 )))
852
853 ===== **2.8 流程详细设计** =====
854
855
856 ====== **2.8.1（100.1）事件记录和分类** ======
857
858 **[[image:20.png||height="453" width="525"]]**
859
860
861 流程描述如下：
862
863 |**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
864 |100.1.1|从任务队列中接受事件|帮助台|事件队列|需要处理的事件|(((
865 事件任务队列的来源：
866
867 1. 监控系统自动发送的告警
868 1. 业务部门通过其它接口（客服等）转发的事件单
869 1. IT用户通过服务台自助系统提交的事件单
870
871 帮助台负责检查事件任务队列中的新事件单，开始处理
872
873
874 )))
875 | |是否为本中心职责范围？|帮助台|事件单| |(((
876 帮助台判断是否属于本中心职责范围：
877
878 1. 是，进行事件分类的处理；
879 1. 否，转100.1.3回复和关闭
880 )))
881 |100.1.2|新建事件|帮助台|电话/OA/传真|新建的事件记录|(((
882 属于本中心职责范围，帮助台负责创建新的事件单，填写详细情况描述，不属于本中心处理的，直接电话回复。
883
884 事件单填写的详细内容如下：
885
886 1. 报告人姓名、联系电话、邮件、分公司、部门
887 1. 事件标题和描述
888 1. 必要的附件
889 1. 事件发生时间和地点
890 1. 事件来源和事件性质
891 1. 进行事件分类
892 1. 设定事件状态为“新建”
893 )))
894 |100.1.3|回复和关闭|帮助台|误报的事件单|关闭的事件单|联系申报用户，说明情况，将该事件单状态置为“关闭”，结束代码为“误报”，保存关闭
895 | |是否为重复事件？|帮助台|事件记录|相应的处理流程|(((
896 帮助台根据重复事件原则，判断该事件单是否属于重复事件：
897
898 1. 是，转100.1.4重复事件处理；
899 1. 否，事件分类的判断
900 )))
901 |100.1.4|重复事件处理|帮助台|重复事件| |在重复事件单的“重复事件标记”中记录正在处理的事件单的流水号，状态置为“XX处理中”，保存退出。
902 | |事件性质区分？|帮助台|事件性质|相应的处理流程|(((
903 根据事件性质区分不同的处理流程：
904
905 1. 如果是业务处理，走103业务处理子流程；
906 1. 如果是维护作业，走102维护作业子流程；
907 1. 其它事件，走100.1.5事件影响度、优先级设定
908
909
910 )))
911 |100.1.5|事件影响度、优先级设定|帮助台|事件记录|确定了影响度和优先级的事件|根据上报的事件描述，判断对业务的影响程度，并对照优先级代码表，确定事件的优先级，以及初始确定的影响度
912 | |优先级为紧急吗？|帮助台|事件优先级|相应的处理流程|(((
913 帮助台根据业务的影响程度和事件优先级判定的条件，初步判断优先级别：
914
915 1. 优先级为紧急，转100.5紧急事件再确认；
916 1. 其它优先级否，转100.2初始支持
917 )))
918
919 **2.8.2 （100.2）初始支持**
920
921 **[[image:28.png]]**
922
923 流程描述如下：
924
925 |**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
926 | |帮助台技能可以处理吗？|帮助台|事件记录|处理方式|(((
927 帮助台根据事件分类和事件描述，判断处理职责是否在帮助台： 
928
929 1. 是，转100.2.1尝试处理；
930 1. 否，转100.2.2分配到一线支持
931 )))
932 |100.2.1|尝试处理|帮助台|事件记录| |帮助台运用知识库和自身技能在规定的时限内尝试解决，将事件状态置为“分配到帮助台”，如果不能处理应及时将事件单分配到一线支持
933 |100.2.2|分配到一线支持|帮助台|事件记录|分配到一线的事件单|选择相关的一线处理组和处理人员分派，并将事件状态置为“分配到一线”
934 | |解决了吗？|帮助台| | |(((
935 将解决方案和用户沟通，判断是否可以解决；
936
937 1. 可以解决，转100.6记录解决方案细节
938 1. 无法解决，转100.2.2分配到一线支持
939 )))
940
941 ====== **2.8.3 （100.3）一线尝试解决** ======
942
943
944 **[[image:32.png||height="465" width="524"]]**
945
946
947 流程描述如下：
948
949 |序号|步骤名称|责任人|输入|输出|说明
950 |(% rowspan="5" %)100.3.1|(% rowspan="5" %)创建事件/接受事件分配|(% rowspan="5" %)一线支持|(% rowspan="5" %)事件记录|(% rowspan="5" %)一线处理|一线支持人员根据需要，可以自己创建事件单，并详细填写事件单信息；
951 |对于帮助台分派的事件：
952 |如属于分派错误，则转派到负责该业务的岗位，在转派时，必须将报障的详细内容、排除本部门原因等内容告知责任岗位；
953 |如接受，则将事件状态置为“一线处理中”；
954 |如果判断到接收的事件是一个重复事件，则在重复事件单的“重复事件标记”中记录目前正在处理的事件单的流水号，状态置为“一线处理中”，继续原事件单的处理
955 |(% rowspan="3" %) |(% rowspan="3" %)需要代维处理？|(% rowspan="3" %)一线支持|(% rowspan="3" %)N/A|(% rowspan="3" %)N/A|一线支持判断是否需要直接找代维解决？
956 |1.需要代维解决，转100.3.4联系代维
957 |2.不需要，转100.3.2尝试找出解决方案
958 |100.3.2|尝试找出解决方案|一线支持|事件记录|解决方案|一线工程师借助工具或运用自己技能尝试找出解决方案
959 |(% rowspan="3" %) |(% rowspan="3" %)有解决方案吗？|(% rowspan="3" %)一线支持|(% rowspan="3" %)N/A|(% rowspan="3" %)N/A|一线支持判断能否在规定的时限内找到解决方案？
960 |1.找到解决方案，根据解决方案的内容判断是否发起变更
961 |2.不能找到，转100.3.6分配到二线支持
962 |(% rowspan="3" %) |(% rowspan="3" %)发起变更吗？|(% rowspan="3" %)一线支持|(% rowspan="3" %)N/A|(% rowspan="3" %)N/A|一线支持根据解决方案的内容和变更管理流程对变更范围的定义，判断是否需要发起变更？
963 |1.需要发起变更，创建变更请求，提交到变更管理流程，解决方案的实施由变更管理完成
964 |2.不需要发起变更，转100.3.3应用解决方案
965 |(% rowspan="2" %)100.3.3|(% rowspan="2" %)应用解决方案|(% rowspan="2" %)一线支持|(% rowspan="2" %)事件记录|解决方案|一线支持实施解决方案
966 |变更请求|实施解决方案的过程，需要和相关申告方共同确认解决方案是否有效
967 |(% rowspan="2" %)100.3.4|(% rowspan="2" %)联系代维人员|(% rowspan="2" %)一线支持|事件记录|(% rowspan="2" %)代维|(% rowspan="2" %)根据和代维的服务协议，联系代维
968 |服务协议
969 |100.3.5|代维尝试解决|代维|事件记录|解决方案|代维尝试解决
970 |(% rowspan="3" %) |(% rowspan="3" %)解决了吗？|(% rowspan="3" %)一线支持|(% rowspan="3" %)N/A|(% rowspan="3" %)N/A|代维处理的事件，一线支持必须负责复核结果，通过和事件申告方的沟通，确认事件是否得到解决；
971 |1.已解决，转100.6记录解决方案细节
972 |2.无法解决，转100.3.6分配到二线支持
973 |100.3.6|分配到二线支持|一线支持|事件记录|分配到二线的事件单|一线支持选择相应的二线支持人员分派事件单，状态置为“分配到二线”
974
975
976 ====== **2.8.4 （100.4）二线尝试解决** ======
977
978 **[[image:07.png||height="557" width="547"]]**
979
980
981 流程描述如下：
982
983
984 |序号|步骤名称|责任人|输入|输出|说明
985 |(% rowspan="4" %)100.4.1|(% rowspan="4" %)创建事件/接受事件分配|(% rowspan="4" %)二线支持|(% rowspan="4" %)事件记录|(% rowspan="4" %)二线处理中的事件单|二线支持根据需要创建事件，并详细填写事件单的信息；
986 |对于分派来的事件：
987 |如属于分派错误，则转派到负责该业务的岗位，在转派时，必须将报障的详细内容、排除本部门原因等内容告知责任岗位；
988 |如接受，则将事件状态置为“二线处理中”
989 |(% rowspan="3" %) |(% rowspan="3" %)优先级为紧急吗？|(% rowspan="3" %)二线支持|(% rowspan="3" %)N/A|(% rowspan="3" %)N/A|根据预先定义的优先级判别标准（优先级映射表），再次确定事件优先级是否为紧急？
990 |1.优先级为紧急，判断是否能够独立处理？
991 |2.优先级不等于紧急，转100.4.3尝试找出解决方案
992 |(% rowspan="3" %) |(% rowspan="3" %)能独立处理吗？|(% rowspan="3" %)二线支持|(% rowspan="3" %)N/A|(% rowspan="3" %)N/A|根据业务影响的严重程度和自身技能，判断自己能否独立处理或需要通知事件经理启动紧急处理流程？
993 |1.能独立处理，转100.4.3尝试找出解决方案
994 |2.不能独立处理，转101紧急事件处理流程
995 |100.4.2|通知事件经理和管理层|二线支持|优先级紧急的事件|事件通知|将事件单的优先级别修改为“紧急”，服务管理平台自动将优先级为紧急的事件通知事件经理和管理层，并上报集团公司
996 |100.4.3|尝试找出解决方案|二线支持|事件记录|解决方案|二线工程师借助工具或运用自己技能尝试找出解决方案，在解决事件的过程中根据需要联系供应商（三线）共同参与制定解决方案
997 |100.4.4|供应商提供解决方案|供应商|事件记录|解决方案|供应商和二线支持共同研究解决方案，提供解决方案
998 |(% rowspan="3" %) |(% rowspan="3" %)发起变更吗？|(% rowspan="3" %)二线支持|(% rowspan="3" %)解决方案|(% rowspan="3" %)N/A|二线支持根据解决方案的内容和变更管理流程对变更范围的定义，判断是否需要发起变更？
999 |1.需要发起变更，创建变更请求，提交到变更管理流程，解决方案的实施由变更管理完成
1000 |2.不需要发起变更，转100.4.5应用解决方案
1001 |100.4.5|应用解决方案|二线支持|解决方案|解决方案|二线支持实施解决方案，实施解决方案的过程，需要和相关申告方共同确认解决方案是否有效
1002 |(% rowspan="3" %) |(% rowspan="3" %)解决了吗？|(% rowspan="3" %)二线支持|(% rowspan="3" %)N/A|(% rowspan="3" %)N/A|判断事件是否得到解决？
1003 |1.是，转到100.6记录解决方案细节
1004 |2.否，判断是否需要协调处理？
1005 |(% rowspan="3" %) |(% rowspan="3" %)需要协调处理吗？|(% rowspan="3" %)二线支持|(% rowspan="3" %)N/A|(% rowspan="3" %)N/A|根据事件的处理状况判断是否需要其它资源介入？
1006 |1.是，转到100.4.6事件经理协调解决
1007 |2.否，转到100.4.3尝试找出解决方案
1008 |100.4.6|事件经理协调解决|事件经理|事件记录|解决方案|事件经理负责将事件通报到管理层，通过高层寻求更多的资源介入，共同商讨和制定解决方案
1009
1010 ====== **2.8.5 （100.5）紧急事件再确认** ======
1011
1012
1013 **[[image:50.png||height="322" width="591"]]**
1014
1015
1016 流程描述如下：
1017
1018
1019 |序号|步骤名称|责任人|输入|输出|说明
1020 |100.5.1|确认优先级|一线支持|事件记录|确认紧急的事件|一线支持根据该事件相关的业务或IT系统/设备的实际故障情况，并结合其他相关因素，再次确定事件优先级
1021 |(% rowspan="3" %) |(% rowspan="3" %)优先级为紧急吗？|(% rowspan="3" %)一线支持|(% rowspan="3" %)N/A|(% rowspan="3" %)N/A|判断优先级＝紧急吗？
1022 |1.是，通知事件经理，由事件经理负责紧急事件子处理的处理，转101紧急事件处理子流程
1023 |2.否，转100.3一线尝试解决
1024 |(% rowspan="3" %) |(% rowspan="3" %)可以独立处理吗？|(% rowspan="3" %)一线支持|(% rowspan="3" %)紧急事件|(% rowspan="3" %) |根据业务影响的严重程度和自身技能，判断自己能否独立处理或需要通知事件经理启动紧急处理流程？
1025 |3.能独立处理，转100.3一线尝试解决
1026 |4.不能独立处理，转100.5.2通知相关管理层和事件经理
1027 |100.5.2|通知相关管理层和事件经理|一线支持|紧急事件|事件通知|通过服务管理平台通知（邮件、短信等）事件经理和相应的管理人员
1028
1029
1030
1031 ====== **2.8.6 （100.6）记录解决方案细节** ======
1032
1033 **[[image:44.png||height="243" width="594"]]**
1034
1035
1036
1037 流程描述如下：
1038
1039
1040 |序号|步骤名称|责任人|输入|输出|说明
1041 |(% rowspan="11" %)100.6.1|(% rowspan="11" %)记录详细的解决方案|(% rowspan="11" %)一线支持/二线支持/帮助台|(% rowspan="11" %)事件记录|(% rowspan="11" %)更新的事件记录|根据事件的处理状况填写事件信息项
1042 |1．填写“解决方案”
1043 |2．确定“事件分类”和“事件所属系统类型”是否正确
1044 |3．填写“结束代码”
1045 |4．对于故障，应填写“业务恢复时间”以及确定“故障厂商”
1046 |5．确定“事件影响度”的等级是否正确
1047 |6．根据自己所处岗位填写“事件解决人角色”
1048 |7．对于故障和告警，应该明确是哪个配置项发生的，关联正确的配置项
1049 |8．填写事件的“实际完成时间”并将状态改为“已解决”
1050 |9．如果有自己处理的重复事件单，则简单填写重复事件单的信息项，状态改为“已解决”
1051 |一线支持和二线支持接到的由帮助台分配的事件单，应该转回帮助台，由帮助台和用户确认关闭
1052
1053 ====== **2.8.7 （100.7）关闭事件** ======
1054
1055 **[[image:54.png||height="406" width="563"]]**
1056
1057
1058 流程描述如下：
1059
1060 |**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
1061 | |自动转单/自动告警？|帮助台|事件记录|事件记录|(((
1062 帮助台判断是否是客服等系统自动转单或监控系统自动产生的告警；
1063
1064 1. 是，转100.7.1更新事件状态
1065 1. 否，转100.7.2与用户处确认事件解决
1066 )))
1067 |100.7.1|更新事件状态及结束代码，关闭事件|帮助台|已解决的事件记录|关闭的事件|(((
1068 更新事件记录，状态为“已关闭”，结束代码根据实际处理结果或用户反馈填写；
1069
1070 如果该事件单有相关联的重复事件，应该将重复事件单一起关闭，重复事件的结束代码和该事件保持一致
1071 )))
1072 |100.7.2|与用户处确认事件解决|帮助台|用户反馈|反馈结果|从事件请求人处确认所提供的解决方案是否有效
1073 | |是否解决？|帮助台| | |(((
1074 判断是否解决方案是否有效？
1075
1076 1. 是，转100.7.1
1077 1. 否，转100.7.3重开单处理
1078 )))
1079 |100.7.3|重开单处理|帮助台|未解决的事件记录|新的事件记录|(((
1080 帮助台将该事件单的的结束代码置为“不成功”，关闭保存；
1081
1082 创建一个新的事件单，事件信息可以复制，分配到原处理人员处理，新事件单状态“分配到一线”或“分配到二线”
1083
1084 注：帮助台应该和原处理人员沟通事件的确认结果和后续的处理方式
1085 )))
1086 | |是帮助台分派吗？|一线支持/二线支持| | |如果是帮助台分派的事件单，需要返回到帮助台，否则直接到100.7.4
1087 |100.7.4|更新事件状态及结束代码，关闭事件|一线支持/二线支持|已解决的事件记录|关闭的事件|(((
1088 更新事件记录，状态为“已关闭”，结束代码根据实际处理结果填写；
1089
1090 如果该事件单有相关联的重复事件，应该将重复事件单一起关闭，重复事件的结束代码和该事件保持一致
1091 )))
1092
1093 ====== **2.8.8 （100.8）事件处理的监控** ======
1094
1095
1096 **[[image:22.png]]**
1097
1098
1099 [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml9504\wps1.png]]
1100
1101 流程描述如下：
1102
1103 |**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
1104 |100.8.1|事件队列的监控|事件经理|(((
1105 当前打开的事件单
1106
1107 服务管理平台的超时告警
1108 )))| |(((
1109 事件经理可以从以下途径获取事件处理的信息
1110
1111 1. 服务台系统自动发送的告警通知
1112 1. 查询服务台系统的当前处理中的事件列表
1113 )))
1114 | |需要介入吗？|事件经理| | |(((
1115 事件经理根据处理时限和该事件对业务的影响程度，判断是否需要及时介入，帮助协调资源解决
1116
1117 1. 需要介入，转100.8.2
1118 1. 不需要，则继续监控
1119
1120
1121 )))
1122 |100.8.2|召集资源协商解决|事件经理|(((
1123 告警事件
1124
1125 支持人员的电话通知
1126 )))|解决方案|由于处理不及时而可能导致用户满意度下降的事件或疑难事件，事件经理负责召集相应二线专家，共同商讨并制定解决方案，并实施解决方案
1127 | |可以解决吗？|事件经理| | |(((
1128 1. 如果解决，转100.7关闭事件
1129 1. 无法解决，转100.8.3升级到管理层解决
1130 )))
1131 |100.8.3|升级到管理层解决|事件经理|升级的事件记录|解决方案|事件经理负责将升级事件通报到管理层，通过高层寻求更多的资源介入，共同商讨和制定解决方案
1132
1133 **2.8.9（101）紧急事件处理子流程**
1134
1135 制定紧急事件处理子流程的目标：
1136
1137 1. 当紧急事件发生时，尽可能采取措施减少对于业务带来的影响
1138 1. 确保对紧急情况的有效管理
1139
1140 * 加快紧急事件的响应和处理速度
1141 * 对紧急情况中的人员及采取的行动加强管理
1142 * 加强处理人员与用户之间的沟通和反馈
1143 * 对紧急情况妥善处理
1144
1145 **2.8.9.1流程原则**
1146
1147 ◆ 制定各系统应急处理预案
1148
1149 为了确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障，各系统应该建立相应的应急处理预案，建议预案中的内容至少应涵盖以下方面：
1150
1151 * 应急预案启动条件
1152 * 应急处理小组负责人和成员联系名单和联系方式
1153 * 应急处理步骤
1154 * 应急信息通报
1155 * 应急善后处理
1156 * 应急保障措施（人员、培训、演习、场地等）
1157
1158 ◆ 紧急事件上报集团公司
1159
1160 为切实掌握各省公司业务支撑系统紧急事件情况，要求各省公司在紧急事件发生时立即上报，并在紧急事件处理过程中的关键点将处理情况上报，具体上报内容和方式参见2.12集团、省公司两级交互。
1161
1162
1163 ====== **2.8.9.2 紧急事件处理子流程概要说明** ======
1164
1165 **[[image:14.png]]**
1166
1167
1168 紧急事件处理子流程说明如下：
1169
1170 |**序号**|**步骤名称**|**说明**
1171 |101.1|召集应急小组，协调应急会议|事件经理主持应急会议，并组织讨论、协调各方资源，分析紧急事件处理方案，并将紧急事件情况通报省中心相关领导和集团公司
1172 |101.2|判断是否属于应急预案中的事件？|(((
1173 应急小组和相关厂商根据紧急事件现象和影响程度，判断是否需要启动相应系统的应急预案？
1174
1175 1. 如果没有应急预案，则进入101.4组织相关厂商共同分析紧急事件，制定处理方案并处理；
1176 1. 如果有应急预案，则进入101.3按照应急预案处理
1177 )))
1178 |101.3|按照应急预案处理|根据各系统制定的应急预案中的实施步骤，处理紧急事件
1179 |101.4|组织相关厂商共同分析，制定处理方案并处理|(((
1180 应急小组负责组织相关厂商共同分析紧急事件，制定相应的处理方案，如果需要集团中心介入处理，则向集团中心申请介入；
1181
1182 处理方案在实施前应得到应急小组和相关领导的认可；
1183
1184 事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求
1185 )))
1186 |101.5|紧急事件解除确认？|(((
1187 在紧急事件处理方案实施后，应急小组、相关厂商和相关部门对紧急事件是否解除进行确认
1188
1189 1. 紧急事件如果没有解除，则重新进入101.4组织相关厂商共同分析紧急事件，制定处理方案并处理；
1190 1. 如果解除，则进入101.6紧急事件善后处理和总结分析
1191 )))
1192 |101.6|善后处理和通报|(((
1193 紧急事件解除后，应急小组向申告方、公司相关领导简要报告紧急事件处理过程，解决方法，事件解除时间，业务恢复情况，并将该信息汇报到集团公司
1194
1195 对于影响度为重大的紧急事件，必须通过服务管理平台提交《重大事件报告》，报告内容和提交方式见2.12集团、省公司两级交互
1196
1197 紧急事件的处理人需要创建一个新问题，将紧急事件处理过程的详细信息记录到问题单中，提交到问题经理，由问题经理组织相关专家进行问题根源的分析
1198 )))
1199
1200 ====== **2.8.10 （102）维护作业子流程** ======
1201
1202 维护作业子流程用来描述如何处理来自集团公司下发的维护作业和省中心制定的维护作业计划。维护作业子流程在事件管理流程中属于相对独立的模块，处理流程和相关信息项的填写与故障或申告不同，以下内容主要说明维护作业的流程原则和概要流程图。
1203
1204 各省在细化维护作业流程时，可以在流程原则的基础上扩展和细化以满足各省中心对维护作业的具体要求。
1205
1206
1207
1208
1209
1210 **2.8.10.1 流程原则**
1211
1212 ◆ 维护作业事件单的产生
1213
1214 * 帮助台负责接收集团下发的维护作业，分配到相应的一线/二线支持人员
1215 * 负责执行维护作业的支持人员在服务管理平台录入维护作业单
1216 * 负责执行维护作业的支持人员在维护作业单中录入维护作业的执行结果
1217
1218 ◆ 维护作业的事件信息项的填写说明
1219
1220 |**序号**|**信息项**|**是否需要填写**|**维护作业填写内容**
1221 |1|事件ID|是|系统自动产生
1222 |2|请求人信息|否|
1223 |3|登记时间|是|系统自动产生
1224 |4|地点|否|
1225 |5|事件发生时间|否|
1226 |6|业务恢复时间|否|
1227 |7|事件性质|是|参见“事件性质”定义，选择‘维护作业’
1228 |8|事件来源|是|参见“事件来源”定义，选择‘内部开单’
1229 |9|事件影响度|否|
1230 |10|事件优先级|否|
1231 |11|事件完成期限|是|维护作业的计划完成时间
1232 |12|事件所属系统类型|是|参见“事件所属系统类型”定义
1233 |13|事件分类|是|参见“事件分类”定义
1234 |14|事件标题|是|维护作业内容简述
1235 |15|事件描述|是|维护作业内容详细描述
1236 |16|事件解决人|是|维护作业的完成人
1237 |17|事件状态|是|参见“事件状态”定义
1238 |18|分配对象|是|维护作业的执行人
1239 |19|事件日志|是|系统自动产生
1240 |20|解决方案描述|是|维护作业的执行结果
1241 |21|事件结束代码|是|参见“事件结束代码”定义，选择‘成功解决’
1242 |22|重复事件标记|否|
1243 |23|处理是否超时|是|系统自动产生
1244 |24|事件解决人角色|是|参见“事件解决人角色”定义，选择‘一线’或‘二线’
1245 |25|实际开始时间|是|维护作业实际开始执行的时间，系统自动填写
1246 |26|实际完成时间|是|维护作业事件状态变为‘已解决’的时间，系统自动填写
1247 |27|故障厂商|否|
1248 |28|关联配置项|否|
1249 |29|关联的问题单号|否|
1250 |30|关联的变更单号|否|
1251
1252 ◆集团维护作业执行情况上报
1253
1254 * 集团下发的维护作业执行情况在省公司定期的上报报表中体现
1255
1256 **2.8.10.2 维护作业子流程概要说明**
1257
1258
1259 [[image:52.png]]
1260
1261
1262 维护作业子流程说明如下：
1263
1264 |**序号**|**步骤名称**|**说明**
1265 |102.1|根据制定的维护作业计划创建维护作业|(((
1266 处理人员根据制定的维护作业计划，在服务管理平台创建维护作业单，并输入维护作业的详细信息
1267
1268 对于集团下发的维护作业，直接进入102.2执行维护作业
1269 )))
1270 |102.2|执行维护作业|根据维护作业内容，执行维护作业
1271 |102.3|记录执行结果|在服务管理平台中详细记录维护作业的执行结果
1272 | |发现异常吗？|(((
1273 如果在执行过程中发现异常，则转102.4创建新事件；
1274
1275 维护作业记录关闭保存
1276 )))
1277 |102.4|创建新事件|创建新的事件单，进入事件管理流程
1278
1279 ====== **2.8.11 （103）业务处理子流程** ======
1280
1281 业务处理子流程用来描述各省业务支撑部门根据特定的需求，对业务运营支撑系统的数据进行查询或修改的操作流程，例如：
1282
1283 1. 根据业务部门或业务支撑部门内部人员提出的业务处理需求单进行的业务操作
1284 1. 系统原因造成的批量数据差错修复、分公司支撑中心提出的批量数据修改要求
1285 1. 新业务上线测试、故障恢复测试所必须的业务操作
1286
1287 **2.8.11.1 流程原则**
1288
1289 ◆ 业务处理的安全性原则
1290
1291 * 业务处理操作必须符合各省公司关于业务操作制定的相关规范
1292 * 业务处理操作的执行人和复核人原则上不能是同一个人
1293
1294 ◆ 业务处理的事件信息项的填写说明
1295
1296 |**序号**|**信息项**|**是否需要填写**|**业务处理填写内容**
1297 |1|事件ID|是|系统自动产生
1298 |2|请求人信息|是|业务需求的提出者
1299 |3|登记时间|是|系统自动产生
1300 |4|地点|否|
1301 |5|事件发生时间|否|
1302 |6|业务恢复时间|否|
1303 |7|事件性质|是|参见“事件性质”定义，选择‘业务处理’
1304 |8|事件来源|是|参见“事件来源”定义
1305 |9|事件影响度|否|
1306 |10|事件优先级|否|
1307 |11|事件完成期限|是|业务处理的计划完成时间
1308 |12|事件所属系统类型|是|参见“事件所属系统类型”定义
1309 |13|事件分类|是|参见“事件分类”定义
1310 |14|事件标题|是|业务处理内容简述
1311 |15|事件描述|是|业务处理内容详细描述
1312 |16|事件解决人|是|业务处理的完成人
1313 |17|事件状态|是|参见“事件状态”定义
1314 |18|分配对象|是|业务处理的执行人
1315 |19|事件日志|是|系统自动产生
1316 |20|解决方案描述|是|业务处理的执行结果
1317 |21|事件结束代码|是|参见“事件结束代码”定义，选择‘成功解决’
1318 |22|重复事件标记|否|
1319 |23|处理是否超时|是|系统自动产生
1320 |24|事件解决人角色|是|参见“事件解决人角色”定义，选择‘一线’或‘二线’
1321 |25|实际开始时间|是|业务处理实际开始执行的时间，系统自动填写
1322 |26|实际完成时间|是|业务处理事件状态变为‘已解决’的时间，系统自动填写
1323 |27|故障厂商|否|
1324 |28|关联配置项|否|
1325 |29|关联的问题单号|否|
1326 |30|关联的变更单号|否|
1327
1328 **2.8.11.2 业务处理子流程概要说明**
1329
1330 **[[image:27.png]]**
1331
1332
1333 业务处理子流程说明如下：
1334
1335 |**序号**|**步骤名称**|**说明**
1336 |103.1|受理并制定业务处理方案|(((
1337 一线和二线人员都可以做为业务处理人员
1338
1339 业务处理人员接受业务处理单，检查业务处理请求单是否符合省公司的规定，如果不符合，则回复相应部门
1340
1341 业务处理人员根据业务处理单的内容制定处理方案
1342 )))
1343 | |需要发起RFC吗？|(((
1344 1. 如果业务处理方案中涉及到应用系统的变更，则提交变更请求，走变更管理流程
1345 1. 如果不涉及变更，则进入103.2业务处理执行
1346 )))
1347 |103.2|业务处理执行|业务处理人员按照处理方案执行
1348 |103.3|创建变更请求|提交变更请求，转入变更管理流程
1349 |103.4|执行结果复核|业务处理执行结果的复核，原则上执行人和复核人必须分开，如果复核出现异常，则回到103.1受理并制定业务处理方案
1350 |103.5|记录详细信息|在服务管理平台记录详细的业务处理步骤和结果
1351 |103.6|回复并关闭|通过服务管理平台或其它接口回复相关发起人，关闭业务处理单
1352
1353 ===== **2.9 事件状态迁移图** =====
1354
1355 事件状态变迁图用来标明：当一个事件单处于某个状态时，它可以去到的下一个状态。
1356
1357 [[image:39.png]]
1358
1359
1360
1361 ◆ 当前状态为‘已登记’状态时，可迁移的状态
1362
1363 |**状态**|**合法**|**描述**
1364 |已登记|否|已登记为事件单初始状态
1365 |分配到帮助台|是|用户提交事件请求，首先分派到帮助台
1366 |分配到一线|否|
1367 |分配到二线|否|
1368 |一线处理中|否|
1369 |二线处理中|否|
1370 |已解决|否|
1371 |已关闭|否|
1372
1373 ◆当前状态为‘分配到帮助台’状态时，可迁移的状态
1374
1375 |**状态**|**合法**|**描述**
1376 |已登记|否|
1377 |分配到帮助台|是|帮助台的人员将分配给本人的事件单分配给帮助台或者帮助台的其他人员
1378 |分配到一线|是|帮助台组人员将事件单分配给一线支持组
1379 |分配到二线|是|帮助台组人员将事件单分配给二线支持组
1380 |一线处理中|否|
1381 |二线处理中|否|
1382 |已解决|否|
1383 |已关闭|是|当事件处理范围不在计费业务中心或误报或可忽略时，可直接关闭
1384
1385 ◆ 当前状态为‘分配到一线’状态时，可迁移的状态
1386
1387 |**状态**|**合法**|**描述**
1388 |已登记|否|
1389 |分配到帮助台|是|一线支持人员将分配给本人的事件单分配给帮助台或者帮助台组内的其他人
1390 |分配到一线|是|一线支持人员将分配给本人的事件单分配给一线支持组或组内的其他人
1391 |分配到二线|是|一线支持人员将事件单分配给二线支持组或二线支持组内的其他人
1392 |一线处理中|是|一线支持人员，接受分配的事件单，并开始处理
1393 |二线处理中|否|
1394 |已解决|否|
1395 |已关闭|否|
1396
1397 ◆ 当前状态为‘分配到二线’状态时，可迁移的状态
1398
1399 |**状态**|**合法**|**描述**
1400 |已登记|否|
1401 |分配到帮助台|是|二线支持人员将分配给本人的事件单分配给帮助台或者帮助台组内的其他人
1402 |分配到一线|是|二线支持人员将分配给本人的事件单分配给一线支持组或组内的其他人
1403 |分配到二线|是|二线支持人员将事件单分配给二线支持组或二线支持组内的其他人
1404 |一线处理中|否|
1405 |二线处理中|是|二线支持人员，接受分配的事件单，并开始处理
1406 |已解决|否|
1407 |已关闭|否|
1408
1409 ◆ 当前状态为‘一线处理中’状态时，可迁移的状态
1410
1411 |**状态**|**合法**|**描述**
1412 |已登记|否|
1413 |分配到帮助台|否|
1414 |分配到一线|是|一线支持人员无法处理该事件单，将事件单重新分配给一线支持组或一线支持组内其他人员
1415 |分配到二线|是|一线支持人员无法处理该事件单，将事件单重新分配给二线支持组或二线支持组内其他人员
1416 |一线处理中|否|
1417 |二线处理中|否|
1418 |已解决|是|一线支持找到解决方案或者变通方法，解决了分配的事件单
1419 |已关闭|否|
1420
1421 ◆ 当前状态为‘二线处理中’状态时，可迁移的状态
1422
1423 |**状态**|**合法**|**描述**
1424 |已登记|否|
1425 |分配到帮助台|否|
1426 |分配到一线|否|
1427 |分配到二线|是|二线支持人员无法处理该事件单，或者分配错误，将事件单重新分配给二线支持组或二线支持组内其他人员
1428 |一线处理中|否|
1429 |二线处理中|否|
1430 |已解决|是|二线支持找到解决方案或者变通方法，解决了分配的事件单
1431 |已关闭|否|
1432
1433 ◆ 当前状态为‘已解决’状态时，可迁移的状态
1434
1435 |**状态**|**合法**|**描述**
1436 |已登记|否|
1437 |分配到帮助台|否|
1438 |分配到一线|否|
1439 |分配到二线|否|
1440 |一线处理中|否|
1441 |二线处理中|否|
1442 |已解决|否|
1443 |已关闭|是|帮助台在关闭事件单的时候，需要填写客户反馈和结束代码
1444
1445 ◆当前状态为‘已关闭’状态时，可迁移的状态
1446
1447 * 不迁移至任何状态。
1448
1449 ===== **2.10 关键角色、职责定义** =====
1450
1451 流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满足流程所需角色的基础上，为具体的实现提供足够的灵活性。具体的角色职责和岗位对应在《事件管理细化流程说明书》中体现。
1452
1453 事件管理流程主要分为以下几个职责/角色，分别简述如下：
1454
1455
1456
1457
1458 ====== **2.10.1 事件管理流程负责人** ======
1459
1460 事件管理流程负责人从宏观上监控流程，确保事件流程在业务支持中心范围内被正确的执行。当流程不能够适应业务支持中心的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。
1461
1462 **职责：**
1463
1464 1. 确定管理流程的衡量指标
1465 1. 确保事件流程能够取得管理层的参与和支持
1466 1. 确保事件流程符合公司实际状况和公司 IT发展战略
1467 1. 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制
1468 1. 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进(假如增加或合并流程的角色)，从而实现可持续提高
1469 1. 保持与其他流程负责人的定期沟通
1470
1471 **技能要求：**
1472
1473 1. 深刻理解事件管理流程；
1474 1. 充分理解业务支撑网运维管理流程梳理项目的其他流程，能够进行流程接口设计；
1475 1. 能够很好地理解业务对于事件管理的需求；
1476 1. 对质量控制与保障有很深入的了解；
1477 1. 有决策权，能够确保事件管理流程设计要求在实施项目中得到贯彻和执行；
1478 1. 具有很好的沟通技能，能够取得公司高层的支持，获得所需资源。
1479
1480 ====== **2.10.2 事件经理** ======
1481
1482 事件经理负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。
1483
1484 **职责：**
1485
1486 1. 负责对事件的解决协调资源，保证故障的最终排除
1487 1. 当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协调资源，促进支持工程师快速恢复正常服务
1488 1. 确保和问题管理流程经理的有效合作
1489 1. 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题
1490
1491 **技能要求：**
1492
1493 1. 了解技术架构和技术环境
1494 1. 较强的口头表达能力和与用户沟通技巧
1495 1. 处理纠纷的能力
1496 1. 深刻了解事件管理流程
1497 1. 较强的领导能力
1498
1499 ====== **2.10.3 帮助台人员** ======
1500
1501 帮助台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的一线支持工程师或者二线支持工程师。
1502
1503 **职责：**
1504
1505 1. 在指定的响应时间内响应所有帮助台热线电话、邮件、传真等事件报告
1506 1. 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等
1507 1. 为事件进行适当的分类、为事件分配优先级等属性
1508 1. 尝试使用工具、初步诊断、分析相关信息等方式解决问题
1509 1. 如果帮助台不能解决这个事件，应当将事件分配给最合适的一线支持小组/人员来处理
1510 1. 检查事件记录的处理进度，保持与事件报告人的联系，适时通知事件处理进展
1511 1. 与用户确认事件解决方案，关闭事件
1512 1. 负责24×7的值班和系统监控
1513
1514 **技能要求：**
1515
1516 1. 熟悉技术平台和技术环境
1517 1. 较强的沟通能力
1518 1. 对简单的故障要有快速诊断和解决的能力
1519 1. 熟悉事件处理流程
1520
1521 ====== **2.10.4 一线支持人员** ======
1522
1523 一线支持人员负责对帮助台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。
1524
1525 **职责:**
1526
1527 1. 验证事件的描述和信息，进一步收集相关信息
1528 1. 决定需要采取何种措施恢复服务并实施有效的行动
1529 1. 必要时提供现场支持
1530 1. 根据优先级提供有效的解决方案
1531 1. 实施事件解决方案
1532 1. 更新事件解决信息，已解决的事件转回帮助台，由帮助台关闭事件
1533 1. 如果一线不能解决这个事件，应当决定选择最合适的二线支持小组/人员来处理
1534
1535 **技能要求：**
1536
1537 1. 熟悉技术平台和技术环境
1538 1. 较强的沟通能力
1539 1. 快速诊断事件和解决事件的能力
1540 1. 熟悉事件处理流程
1541
1542 ====== **2.10.5 二线支持人员** ======
1543
1544 二线支持人员是相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。各省可以考虑按照所维护的应用、系统进行分组，如：网络组、主机组、应用组等。
1545
1546 **职责:**
1547
1548 1. 进行事件的深入调查研究
1549 1. 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动
1550 1. 必要时引入供应商的支持
1551 1. 更新事件根源和最终解决方案
1552 1. 更新事件记录，确保事件状态代码真实反映事件状态
1553 1. 及时提供有效解决方案
1554 1. 与其他小组合作，确定解决方案
1555 1. 已解决的事件转回帮助台，由帮助台关闭事件
1556 1. 如果二线不能在解决时限内解决这个事件，应当将事件进行升级
1557
1558 **技能要求：**
1559
1560 1. 深厚的技术背景，对所维护范畴的技术深入掌握
1561 1. 熟悉事件处理流程
1562
1563 ====== **2.10.6 流程角色和人员对应表** ======
1564
1565 |(% colspan="2" %)**角色**|**成员**
1566 |事件管理流程负责人| |刘三苏
1567 |事件经理A| |刘三苏
1568 |事件经理B| |周晓伟
1569 |帮助台| |王军、杨晋波、詹梅、杨红梅、吴国平、杨卫红
1570 |(% rowspan="3" %)一线支持|一线基础平台组|白洪瑜
1571 |一线应用—计费结算、营业账务、客服|代学平、陈勤、陈锐
1572 |一线应用—经营分析|徐文英、张航友、何畏
1573 |(% rowspan="5" %)二线支持|二线基础平台组|郑水华、乔迎春、卢定、高松、高雄英
1574 |二线应用—计费结算|苏伟杰、罗芳、祝颢、龚楠、杨莉、宋琳、陶琳、杨智
1575 |二线应用—客服|温健军、傅华、魏亚菲、涂天禄
1576 |二线应用—经营分析|亚信
1577 |二线应用—营业账务|陈伟、许雷、张波、胡鹏、董晓勇、李琪、杜敏
1578
1579 注：在系统实施时由某通信公司根据实际运维架构在此表基础上完成具体的人员映射。
1580
1581
1582
1583 ===== **2.11 关键流程衡量指标** =====
1584
1585 为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。
1586
1587 |**序号**|**衡量指标**|**指标计算说明**
1588 |1|事件总数|(((
1589 数量：在事件单中根据以下条件过滤
1590
1591 1. 【重复事件标记】为空
1592 1. 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
1593 1. 【事件发生时间】在统计周期内
1594 )))
1595 |2|事件关闭的数量|数量 ：在事件总数中过滤【事件状态】＝‘关闭’
1596 |3|事件成功关闭的数量/比率|(((
1597 数量：在事件总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’
1598
1599 比率：数量 / 事件总数 × 100 %
1600 )))
1601 |4|规定时间内解决的事件数量/百分比|(((
1602 数量：在事件总数中过滤【处理是否超时】＝‘未超时’and 【事件结束代码】＝‘成功解决’or‘变通方法解决’
1603
1604 比率：数量/事件总数 × 100 %
1605 )))
1606 |5|规定时间内响应的事件数量/百分比|(((
1607 数量：在事件总数中过滤（【实际开始时间】－【登记时间】）< 优先级对应的响应时限
1608
1609 比率：数量/事件总数 × 100 %
1610 )))
1611 |6|平均解决时间|(((
1612 完成的事件：在事件总数中过滤所有【事件状态】＝‘已解决’or ‘关闭’的事件
1613
1614 平均解决时间：累加完成事件的（【实际完成时间】－【登记时间】）/ 完成的事件数量
1615 )))
1616 |7|一线解决率|(((
1617 数量：在事件总数中过滤所有【事件解决人角色】＝‘一线’
1618
1619 比率：数量 / 事件总数 × 100 %
1620 )))
1621 |8|超时未解决的事件数量|数量：在事件总数中过滤【处理已超时】＝‘超时’and 【事件状态】！＝‘关闭’or ‘已解决’
1622 |9|事件的一次解决率|(((
1623 数量1：在事件总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’
1624
1625 数量2：在事件总数中过滤【事件结束代码】＝‘不成功’
1626
1627 比率：（数量1－数量2 ） / 数量1  × 100 %
1628 )))
1629
1630 ===== **2.12 集团、省公司两级交互** =====
1631
1632 省公司在紧急事件发生时，必须在第一时间上报集团公司业务支撑系统部，并在事件处理过程中的每个状态变化点将最新事件记录上传到集团公司。
1633
1634 |(% rowspan="2" %)**上报方式**|(% rowspan="2" %)**触发条件**|(% colspan="2" %)**上报内容**
1635 |**事件信息项**|**附件内容**
1636 |(% rowspan="4" %)服务管理平台|事件状态进入一线处理中，并得到一线支持的确认|所有事件信息项|N/A
1637 |处理中的事件信息项发生改变|所有事件信息项|N/A
1638 |事件状态转入已解决|所有事件信息项|N/A
1639 |(((
1640 事件状态转入关闭
1641
1642 （如果影响度为重大，必须有重大事件报告做为附件）
1643 )))|所有事件信息项|(((
1644 《重大事件报告》内容包含：
1645
1646 包括事件的发生时间、事件现象、影响的主要系统、影响度、处理过程、解决方法、业务恢复时间等
1647 )))
1648
1649 ===== **2.13 省公司报表** =====
1650
1651 省公司报表定义如下，同时，上报集团报表也可以供省公司使用。
1652
1653
1654
1655
1656 ====== **2.13.1 按事件来源分类的统计报表** ======
1657
1658 |**时间来源**|**总数**|**完成的数量**|**完成及时率**
1659 |用户报告| | |
1660 |自助开单| | |
1661 |自动转单| | |
1662 |内部开单| | |
1663 |监控告警| | |
1664
1665 指标说明：
1666
1667 |**序号**|**指标名称**|**指标计算说明**
1668 |1|总数|(((
1669 数量：在事件单中按事件不同来源根据以下条件过滤：
1670
1671 【重复事件标记】为空
1672
1673 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
1674
1675 【事件发生时间】在统计周期内
1676 )))
1677 |1|完成的数量|数量：事件单中按不同事件来源，统计【实际完成时间】在统计周期内的事件数量
1678 |2|完成及时率|(((
1679 数量：事件单中按不同事件来源，统计【处理是否超时】＝‘未超时’and 【实际完成时间】在统计周期内的事件数量
1680
1681 比率：数量/完成的数量 × 100 %
1682 )))
1683
1684 ===== **2.14 省公司上报报表** =====
1685
1686
1687 ====== **2.14.1按业务系统和优先级分类统计报表** ======
1688
1689 |(% rowspan="2" %)**业务系统**|(% rowspan="2" %)**事件性质**|(% rowspan="2" %)**总数**|(% colspan="4" %)**优先级**
1690 |**紧急**|**高**|**中**|**低**
1691 |(% rowspan="3" %)BOSS系统|故障| | | | |
1692 |申告| | | | |
1693 |告警| | | | |
1694 |(% rowspan="3" %)客服系统|故障| | | | |
1695 |申告| | | | |
1696 |告警| | | | |
1697 |(% rowspan="3" %)经营分析|故障| | | | |
1698 |申告| | | | |
1699 |告警| | | | |
1700 |(% rowspan="2" %)容灾系统|故障| | | | |
1701 |告警| | | | |
1702 |(% rowspan="2" %)BOSS网管|故障| | | | |
1703 |告警| | | | |
1704
1705 指标说明：
1706
1707 |**序号**|**指标名称**|**指标计算说明**
1708 |1|故障总数|(((
1709 数量：在事件单中根据以下条件过滤：
1710
1711 【重复事件标记】为空
1712
1713 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
1714
1715 【事件发生时间】在统计周期内
1716
1717 【事件性质】＝‘故障’
1718 )))
1719 |2|申告总数|(((
1720 数量：在事件单中根据以下条件过滤：
1721
1722 【重复事件标记】为空
1723
1724 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
1725
1726 【事件发生时间】在统计周期内
1727
1728 【事件性质】＝‘申告’
1729 )))
1730 |3|告警总数|(((
1731 数量：在事件单中根据以下条件过滤：
1732
1733 【重复事件标记】为空
1734
1735 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
1736
1737 【事件发生时间】在统计周期内
1738
1739 【事件性质】＝‘告警’
1740 )))
1741 |4|紧急、高、中、低|在故障、申告、告警中分别过滤【事件优先级】
1742 |5|业务系统|分别过滤【事件所属系统类型】的业务系统
1743
1744 ====== **2.14.2 按业务系统细分的故障和优先级分类统计报表** ======
1745
1746 |(% rowspan="2" %)**业务系统**|(% rowspan="2" %)**子类**|(% rowspan="2" %)**故障数量**|(% colspan="4" %)**优先级**
1747 |**紧急**|**高**|**中**|**低**
1748 |(% rowspan="16" %)BOSS系统|营销管理| | | | |
1749 |渠道管理| | | | |
1750 |客户服务| | | | |
1751 |产品管理| | | | |
1752 |客户管理| | | | |
1753 |资源管理| | | | |
1754 |订单管理| | | | |
1755 |服务开通| | | | |
1756 |综合采集| | | | |
1757 |融合计费| | | | |
1758 |综合帐务| | | | |
1759 |综合结算| | | | |
1760 |合作伙伴管理| | | | |
1761 |系统管理| | | | |
1762 |统计报表| | | | |
1763 |一级BOSS| | | | |
1764 |(% rowspan="8" %)客服系统|电话呼叫中心| | | | |
1765 |互联网呼叫中心| | | | |
1766 |短信呼叫中心| | | | |
1767 |工单管理| | | | |
1768 |知识管理| | | | |
1769 |人力资源| | | | |
1770 |质量管理| | | | |
1771 |数据统计分析| | | | |
1772 |(% rowspan="2" %)经营分析|通用分析| | | | |
1773 |专题分析| | | | |
1774 |(% rowspan="3" %)容灾系统|BOSS数据保护| | | | |
1775 |BOSS业务接管| | | | |
1776 |BOSS资源复用| | | | |
1777 |(% rowspan="2" %)BOSS网管|监控管理| | | | |
1778 |服务管理| | | | |
1779
1780 指标说明：
1781
1782 |**序号**|**指标名称**|**指标计算说明**
1783 |1|故障总数|(((
1784 数量：在事件单中根据以下条件过滤：
1785
1786 【重复事件标记】为空
1787
1788 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
1789
1790 【事件发生时间】在统计周期内
1791
1792 【事件性质】＝‘故障’
1793 )))
1794 |2|紧急、高、中、低|在故障、申告、告警中分别过滤【事件优先级】
1795 |3|业务系统|分别过滤【事件所属系统类型】的子类
1796
1797 ====== **2.14.3 按业务系统和影响度分类统计报表** ======
1798
1799 |(% rowspan="2" %)**业务系统**|(% rowspan="2" %)**事件性质**|(% rowspan="2" %)**总数**|(% colspan="4" %)**影响度**
1800 |**重大**|**严重**|**一般**|**无**
1801 |(% rowspan="2" %)BOSS系统|故障| | | | |
1802 |申告| | | | |
1803 |(% rowspan="2" %)客服系统|故障| | | | |
1804 |申告| | | | |
1805 |(% rowspan="2" %)经营分析|故障| | | | |
1806 |申告| | | | |
1807 |容灾系统|故障| | | | |
1808 |BOSS网管|故障| | | | |
1809
1810 指标说明：
1811
1812 |**序号**|**指标名称**|**指标计算说明**
1813 |1|故障总数|(((
1814 数量：在事件单中根据以下条件过滤：
1815
1816 【重复事件标记】为空
1817
1818 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
1819
1820 【事件发生时间】在统计周期内
1821
1822 【事件性质】＝‘故障’
1823 )))
1824 |2|申告总数|(((
1825 数量：在事件单中根据以下条件过滤：
1826
1827 【重复事件标记】为空
1828
1829 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
1830
1831 【事件发生时间】在统计周期内
1832
1833 【事件性质】＝‘申告’
1834 )))
1835 |3|重大、严重、一般、无|在故障、申告总数分别过滤【事件影响度】
1836 |4|业务系统|分别过滤【事件所属系统类型】的业务系统
1837
1838 ====== **2.14.4 按业务系统细分的故障和影响度分类统计报表** ======
1839
1840 |(% rowspan="2" %)**业务系统**|(% rowspan="2" %)**子类**|(% rowspan="2" %)**故障数量**|(% colspan="4" %)**影响度**
1841 |**重大**|**严重**|**一般**|**无**
1842 |(% rowspan="16" %)BOSS系统|营销管理| | | | |
1843 |渠道管理| | | | |
1844 |客户服务| | | | |
1845 |产品管理| | | | |
1846 |客户管理| | | | |
1847 |资源管理| | | | |
1848 |订单管理| | | | |
1849 |服务开通| | | | |
1850 |综合采集| | | | |
1851 |融合计费| | | | |
1852 |综合帐务| | | | |
1853 |综合结算| | | | |
1854 |合作伙伴管理| | | | |
1855 |系统管理| | | | |
1856 |统计报表| | | | |
1857 |一级BOSS| | | | |
1858 |(% rowspan="8" %)客服系统|电话呼叫中心| | | | |
1859 |互联网呼叫中心| | | | |
1860 |短信呼叫中心| | | | |
1861 |工单管理| | | | |
1862 |知识管理| | | | |
1863 |人力资源| | | | |
1864 |质量管理| | | | |
1865 |数据统计分析| | | | |
1866 |(% rowspan="2" %)经营分析|通用分析| | | | |
1867 |专题分析| | | | |
1868 |(% rowspan="3" %)容灾系统|BOSS数据保护| | | | |
1869 |BOSS业务接管| | | | |
1870 |BOSS资源复用| | | | |
1871 |(% rowspan="2" %)BOSS网管|监控管理| | | | |
1872 |服务管理| | | | |
1873
1874 指标说明：
1875
1876 |**序号**|**指标名称**|**指标计算说明**
1877 |1|故障总数|(((
1878 数量：在事件单中根据以下条件过滤：
1879
1880 【重复事件标记】为空
1881
1882 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
1883
1884 【事件发生时间】在统计周期内
1885
1886 【事件性质】＝‘故障’
1887 )))
1888 |2|重大、严重、一般、无|在故障总数分别过滤【事件影响度】
1889 |3|业务系统|分别过滤【事件所属系统类型】的子类
1890
1891 ====== **2.14.5 按业务系统统计故障和申告处理效率指标报表** ======
1892
1893 |(% rowspan="2" %)**业务系统**|(% rowspan="2" %)**事件性质**|(% rowspan="2" %)**总数**|(% rowspan="2" %)**帮助台解决率**|(% rowspan="2" %)**一线解决率**|(% rowspan="2" %)**二线解决率**|(% rowspan="2" %)**及时解决率**|(% rowspan="2" %)**一次解决率**|(% rowspan="2" %)**超时未解决数**|(% colspan="4" %)**平均解决时间**
1894 |**紧急**|**高**|**中**|**低**
1895 |(% rowspan="4" %)BOSS系统|故障| | | | | | | | | | |
1896 |申告| | | | | | | | | | |
1897 |咨询| | | | | | | | | | |
1898 |告警| | | | | | | | | | |
1899 |(% rowspan="4" %)客服系统|故障| | | | | | | | | | |
1900 |申告| | | | | | | | | | |
1901 |咨询| | | | | | | | | | |
1902 |告警| | | | | | | | | | |
1903 |(% rowspan="4" %)经营分析|故障| | | | | | | | | | |
1904 |申告| | | | | | | | | | |
1905 |咨询| | | | | | | | | | |
1906 |告警| | | | | | | | | | |
1907 |(% rowspan="2" %)容灾系统|故障| | | | | | | | | | |
1908 |告警| | | | | | | | | | |
1909 |(% rowspan="2" %)BOSS网管|故障| | | | | | | | | | |
1910 |告警| | | | | | | | | | |
1911
1912 指标说明：
1913
1914 |**序号**|**指标名称**|**指标计算说明**
1915 |1|(((
1916 故障总数
1917
1918 申告总数
1919
1920 咨询总数
1921
1922 告警总数
1923 )))|(((
1924 数量：在事件单中根据以下条件过滤
1925
1926 【重复事件标记】为空
1927
1928 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
1929
1930 【事件发生时间】在统计周期内
1931
1932 分别统计【事件性质】＝‘故障’、‘申告’、‘咨询’、‘告警’
1933 )))
1934 |2|帮助台解决率|(((
1935 数量：在（故障、申告、咨询、告警）总数中过滤所有【事件解决人角色】＝‘帮助台’
1936
1937 比率：数量 / 总数 × 100 %
1938 )))
1939 |3|一线解决率|(((
1940 数量：在（故障、申告、咨询、告警）总数中过滤所有【事件解决人角色】＝‘一线’
1941
1942 比率：数量 / 总数 × 100 %
1943 )))
1944 |4|二线解决率|(((
1945 数量：在（故障、申告、咨询、告警）总数中过滤所有【事件解决人角色】＝‘二线’
1946
1947 比率：数量 / 总数 × 100 %
1948 )))
1949 |5|及时解决率|(((
1950 数量：在（故障、申告、咨询、告警）总数中过滤【处理是否超时】＝‘未超时’and 【事件结束代码】＝‘成功解决’or‘变通方法解决’
1951
1952 比率：数量/总数 × 100 %
1953 )))
1954 |6|一次解决率|(((
1955 数量1：在（故障、申告、咨询、告警）总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’
1956
1957 数量2：在（故障、申告、咨询、告警）总数中过滤【事件结束代码】＝‘不成功’
1958
1959 比率：（数量1 － 数量2） / 数量1  × 100 %
1960 )))
1961 |7|超时未解决数|数量：在（故障、申告、咨询、告警）总数中过滤【处理已超时】＝‘超时’and 【事件状态】！＝（‘关闭’or ‘已解决’）
1962 |8|平均解决时间|(((
1963 完成的事件：在（故障、申告、咨询、告警）总数中过滤所有【事件状态】＝‘已解决’or ‘关闭’的事件
1964
1965 平均解决时间：累加完成事件的（【实际完成时间】－【登记时间】）/ 完成的事件数量
1966 )))
1967
1968 ====== **2.14.6 按事件分类的故障和优先级统计报表** ======
1969
1970 |(% rowspan="2" %)**类别**|(% rowspan="2" %)**子类**|(% rowspan="2" %)(((
1971 **故障**
1972
1973 **数量**
1974 )))|(% colspan="4" %)**优先级**
1975 |**紧急**|**高**|**中**|**低**
1976 |(% rowspan="8" %)系统硬件|路由器| | | | |
1977 |网络交换机| | | | |
1978 |小型机| | | | |
1979 |PC服务器| | | | |
1980 |磁盘阵列| | | | |
1981 |存储光纤交换机| | | | |
1982 |磁带库| | | | |
1983 |光盘库| | | | |
1984 |(% rowspan="4" %)客服设备|排队机| | | | |
1985 |CTI服务器| | | | |
1986 |CCS| | | | |
1987 |IVR服务器| | | | |
1988 |(% rowspan="5" %)安全设施|防火墙| | | | |
1989 |IDS入侵监测系统| | | | |
1990 |IPS入侵防护系统| | | | |
1991 |防毒墙| | | | |
1992 |安全软件| | | | |
1993 |(% rowspan="6" %)系统软件|操作系统| | | | |
1994 |数据库| | | | |
1995 |中间件| | | | |
1996 |集群软件| | | | |
1997 |备份软件| | | | |
1998 |系统管理软件| | | | |
1999 |(% rowspan="3" %)配套设施|UPS| | | | |
2000 |空调| | | | |
2001 |其它| | | | |
2002 |(% rowspan="5" %)应用软件|进程| | | | |
2003 |数据| | | | |
2004 |参数| | | | |
2005 |代码| | | | |
2006 |接口| | | | |
2007
2008 指标说明：
2009
2010 |**序号**|**指标名称**|**指标计算说明**
2011 |1|故障总数|(((
2012 数量：在事件单中根据以下条件过滤：
2013
2014 【重复事件标记】为空
2015
2016 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
2017
2018 【事件发生时间】在统计周期内
2019
2020 【事件性质】＝‘故障’
2021 )))
2022 |2|紧急、高、中、低|在故障总数分别过滤【事件优先级】
2023 |3|事件分类|分别过滤【事件分类】的子类
2024
2025 ====== **2.14.7 按业务中断时长分类的统计报表** ======
2026
2027 |**业务系统**|**子类**|**故障数量**|**业务中断时长**
2028 |(% rowspan="16" %)BOSS系统|营销管理| |
2029 |渠道管理| |
2030 |客户服务| |
2031 |产品管理| |
2032 |客户管理| |
2033 |资源管理| |
2034 |订单管理| |
2035 |服务开通| |
2036 |综合采集| |
2037 |融合计费| |
2038 |综合帐务| |
2039 |综合结算| |
2040 |合作伙伴管理| |
2041 |系统管理| |
2042 |统计报表| |
2043 |一级BOSS| |
2044 |(% rowspan="8" %)客服系统|电话呼叫中心| |
2045 |互联网呼叫中心| |
2046 |短信呼叫中心| |
2047 |工单管理| |
2048 |知识管理| |
2049 |人力资源| |
2050 |质量管理| |
2051 |数据统计分析| |
2052 |(% rowspan="2" %)经营分析|通用分析| |
2053 |专题分析| |
2054 |(% rowspan="3" %)容灾系统|BOSS数据保护| |
2055 |BOSS业务接管| |
2056 |BOSS资源复用| |
2057 |(% rowspan="2" %)BOSS网管|监控管理| |
2058 |服务管理| |
2059
2060 注： 业务中断时长＝业务恢复时间－事件发生时间， 单位为分钟
2061
2062 指标说明：
2063
2064 |**序号**|**指标名称**|**指标计算说明**
2065 |1|故障数量|(((
2066 数量：在事件单中根据以下条件过滤：
2067
2068 【重复事件标记】为空
2069
2070 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
2071
2072 【事件发生时间】在统计周期内
2073
2074 【事件性质】＝‘故障’
2075 )))
2076 |2|业务中断时长|【业务恢复时间】－【事件发生时间】
2077 |3|业务系统分类|分别过滤【事件所属系统类型】的子类
2078
2079 ====== **2.14.8 故障厂商统计** ======
2080
2081 |**系统分类**|**厂商名称**|**故障数量**|**重大**|**严重**|**一般**
2082 |(% rowspan="4" %)小型机|HP| | | |
2083 |IBM| | | |
2084 |SUN| | | |
2085 |NCR| | | |
2086 |(% rowspan="4" %)路由器|Cisco| | | |
2087 |中兴| | | |
2088 |3COM| | | |
2089 |华为| | | |
2090 |(% rowspan="4" %)网络交换机|Cisco| | | |
2091 |中兴| | | |
2092 |3COM| | | |
2093 |华为| | | |
2094 |(% rowspan="7" %)磁盘阵列|HP| | | |
2095 |EMC| | | |
2096 |IBM| | | |
2097 |NCR| | | |
2098 |HDS| | | |
2099 |NETAPP| | | |
2100 |SUN| | | |
2101 |(% rowspan="5" %)存储光纤交换机|HP| | | |
2102 |IBM| | | |
2103 |McDATA| | | |
2104 |BROCADE| | | |
2105 |EMC| | | |
2106 |(% rowspan="5" %)磁带库|HP| | | |
2107 |SUN| | | |
2108 |IBM| | | |
2109 |STK| | | |
2110 |Quantum ATL| | | |
2111 |(% rowspan="6" %)数据库|Oracle| | | |
2112 |DB2| | | |
2113 |Microsoft| | | |
2114 |TERADATA| | | |
2115 |Informix| | | |
2116 |Sybase| | | |
2117 |(% rowspan="3" %)操作系统|HP| | | |
2118 |IBM| | | |
2119 |SUN| | | |
2120 |(% rowspan="4" %)系统管理软件|CA| | | |
2121 |HP| | | |
2122 |BMC| | | |
2123 |IBM| | | |
2124 |(% rowspan="4" %)中间件|BEA| | | |
2125 |IBM| | | |
2126 |东方通科技| | | |
2127 |Borland| | | |
2128 |(% rowspan="3" %)客服设备|华为| | | |
2129 |AVAYA| | | |
2130 |北电| | | |
2131
2132 注：该报表中的厂商按照各省实际情况上报。
2133
2134 指标说明：
2135
2136 |**序号**|**指标名称**|**指标计算说明**
2137 |1|故障数量|(((
2138 数量：在事件单中根据以下条件过滤：
2139
2140 【重复事件标记】为空
2141
2142 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’
2143
2144 【事件发生时间】在统计周期内
2145
2146 【事件性质】＝‘故障’
2147 )))
2148 |2|重大、严重、一般|在故障数量分别过滤【事件影响度】
2149 |3|故障厂商|分别过滤【故障厂商】
2150
2151 ====== **2.14.9 业务处理统计** ======
2152
2153 |**业务系统类别**|**子类**|**业务处理数量**|**完成及时率**
2154 |(% rowspan="16" %)BOSS系统|营销管理| |
2155 |渠道管理| |
2156 |客户服务| |
2157 |产品管理| |
2158 |客户管理| |
2159 |资源管理| |
2160 |订单管理| |
2161 |服务开通| |
2162 |综合采集| |
2163 |融合计费| |
2164 |综合帐务| |
2165 |综合结算| |
2166 |合作伙伴管理| |
2167 |系统管理| |
2168 |统计报表| |
2169 |一级BOSS| |
2170 |(% rowspan="8" %)客服系统|电话呼叫中心| |
2171 |互联网呼叫中心| |
2172 |短信呼叫中心| |
2173 |工单管理| |
2174 |知识管理| |
2175 |人力资源| |
2176 |质量管理| |
2177 |数据统计分析| |
2178 |(% rowspan="2" %)经营分析|通用分析| |
2179 |专题分析| |
2180
2181 指标说明：
2182
2183 |**序号**|**指标名称**|**指标计算说明**
2184 |1|业务处理数量|(((
2185 数量：在业务处理单中根据以下条件过滤：
2186
2187 【事件发生时间】在统计周期内
2188
2189 【事件性质】＝‘业务处理’
2190 )))
2191 |2|完成及时率|(((
2192 数量：在业务处理数量中过滤【处理是否超时】＝‘未超时’and 【实际完成时间】在统计周期内
2193
2194 比率：数量/业务处理数量 × 100 %
2195 )))
2196
2197 ====== **2.14.10 维护作业按业务系统分类统计** ======
2198
2199 |**业务系统**|**完成的数量**|**完成及时率**
2200 |BOSS系统| |
2201 |客服系统| |
2202 |经营分析| |
2203 |容灾系统| |
2204 |BOSS网管| |
2205
2206 指标说明：
2207
2208 |**序号**|**指标名称**|**指标计算说明**
2209 |1|完成的数量|(((
2210 数量：在维护作业单中根据以下条件过滤：
2211
2212 【实际完成时间】在统计周期内
2213
2214 【事件性质】＝‘维护作业’
2215 )))
2216 |2|完成及时率|(((
2217 数量：在完成的数量中过滤【处理是否超时】＝‘未超时’and 【实际完成时间】在统计周期内
2218
2219 比率：数量/完成的数量 × 100 %
2220 )))
2221
2222 ====== **2.14.11 维护作业按事件分类统计** ======
2223
2224 |**类别**|**子类**|**完成的数量**|**完成及时率**
2225 |(% rowspan="8" %)系统硬件|路由器| |
2226 |网络交换机| |
2227 |小型机| |
2228 |PC服务器| |
2229 |磁盘阵列| |
2230 |存储光纤交换机| |
2231 |磁带库| |
2232 |光盘库| |
2233 |(% rowspan="4" %)客服设备|排队机| |
2234 |CTI服务器| |
2235 |CCS| |
2236 |IVR服务器| |
2237 |(% rowspan="5" %)安全设施|防火墙| |
2238 |IDS入侵监测系统| |
2239 |IPS入侵防护系统| |
2240 |防毒墙| |
2241 |安全软件| |
2242 |(% rowspan="6" %)系统软件|操作系统| |
2243 |数据库| |
2244 |中间件| |
2245 |集群软件| |
2246 |备份软件| |
2247 |系统管理软件| |
2248 |(% rowspan="3" %)配套设施|UPS| |
2249 |空调| |
2250 |其它| |
2251 |(% rowspan="5" %)应用软件|进程| |
2252 |数据| |
2253 |参数| |
2254 |代码| |
2255 |接口| |
2256
2257 指标说明：
2258
2259 |**序号**|**指标名称**|**指标计算说明**
2260 |1|完成的数量|(((
2261 数量：在维护作业单中根据以下条件过滤：
2262
2263 【实际完成时间】在统计周期内
2264
2265 【事件性质】＝‘维护作业’
2266 )))
2267 |2|完成及时率|(((
2268 数量：在完成的数量中过滤【处理是否超时】＝‘未超时’and 【实际完成时间】在统计周期内
2269
2270 比率：数量/完成的数量 × 100 %
2271 )))
2272
2273 == ==
深圳市艾拓先锋企业管理咨询有限公司