某通信公司ITIL事件管理流程细化说明书

重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。

183

184

1. 监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台

185

1. 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标

186

1. 如果帮助台可以判断到重复事件，则由帮助台对重复事件标识，否则由一线支持人员负责重复事件的处理

====== **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天）不确认的事件单由系统自动关闭或由帮助台协助关闭

====== **2.5.7 升级原则** ======

208

209

制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。

210

211

1. 优先级为紧急的事件，帮助台应立即升级到相应一线支持，由一线支持再次确认，如果确认了优先级为紧急，则立即升级到事件经理，并通知相应的管理层（通过服务管理平台），由事件经理启动紧急事件处理流程

212

1. 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理

213

1. 帮助台和一线支持应及时将不能解决的事件升级到下一级，若未及时升级，事件经理应及时介入，负责协调升级处理

===== **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

针对故障：指的是业务中断的实际时间（可能早于登记时间，需要手工填写）

针对其它：缺省值等于登记时间

)))

|6|业务恢复时间|针对故障的业务恢复实际时间（手工填写）

|7|事件性质|参见“事件性质”定义

|8|事件来源|参见“事件来源”定义

|9|事件影响度|参见“事件影响度”定义

|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|投诉条目|记录投诉类事件的所属投诉条目

====== **2.6.2 事件性质** ======

271

272

273

根据系统的业务要求和管理要求，定义如下六类事件：

274

275

|**编号**|**代码**|**描述**

276

|1|故障|(((

277

指因业务支撑系统错误或反映支撑系统部分或全部功能不能正常使用的报障；

监控管理平台上报的影响系统正常使用的告警

)))

|2|申告|与业务支撑系统相关的用户投诉，如1860、营业厅等面向客户的业务受理部门转来的因支撑系统问题引发的投诉

282

|3|告警|监控平台自动产生的没有影响到系统正常使用的告警

283

|4|咨询|指对系统操作、业务流程等方面的求助和询问

284

|5|业务处理|指需要运维人员进行后台数据处理的请求，主要指业务参数、资费参数的修改和批量数据的处理

285

|6|维护作业|(((

286

指运维人员的日常维护作业或临时进行的维护作业；

总部下发的维护作业

)))

**注：业务处理和维护作业的处理流程见流程概要设计相关子章节。**

====== **2.6.3 事件来源** ======

298

299

事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种：

300

301

|**编号**|**代码**|**描述**

302

|1|用户报告|用户或地市维护人员通过电话/邮件/传真报告的事件，帮助台人员手工创建事件单

303

|2|自助开单|地市等IT用户通过服务台自助系统直接提交的事件

304

|3|自动转单|通过客服系统自动转发的事件

305

|4|内部开单|省公司业务支撑部门内部提交的事件

306

|5|监控告警|监控工具自动转发过来的事件

====== **2.6.4 事件所属系统类型** ======

312

313

根据目前业务支撑系统和子类的划分定义事件所属系统类型，当事件发生时，应该由帮助台初步定位是哪个系统及子类出现问题，由一线、二线进行进一步的明确。

314

315

注：各省在细化设计时不能修改此表中现有定义，第一层业务系统和第二层子类不能修改和扩充(注：第一层为”其它系统”的话，对应的子类可以扩充)，但可以有选择的基于第二层子类定义扩充进行第三层条目的细化。对没有覆盖到的业务系统用”其它系统”表示。

316

317

|**业务系统**|**子类**

318

|(% rowspan="18" %)BOSS系统|(% rowspan="2" %)营销管理

|

|渠道管理

|客户服务

|产品管理

|客户管理

|资源管理

|订单管理

|服务开通

|综合采集

|融合计费

|综合帐务

|综合结算

|合作伙伴管理

|系统管理

|统计报表

|一级BOSS

|其它

|(% rowspan="9" %)客服系统|电话呼叫中心

|互联网呼叫中心

|短信呼叫中心

|工单管理

|知识管理

|人力资源

|质量管理

|数据统计分析

|其它

|(% rowspan="3" %)经营分析|通用分析

346

|专题分析

347

|其它

348

|(% rowspan="3" %)容灾系统|BOSS数据保护

|BOSS业务接管

|BOSS资源复用

| |其它

|(% rowspan="3" %)BOSS网管|监控管理

|服务管理

|其它

|其它系统|

====== **2.6.5 事件分类** ======

361

362

事件分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。在制作统计报表时，可以通过和事件所属系统类型代码的结合来统计分析故障或申告。

363

364

事件的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为”子类”，第三级分类，称之为”条目”。

365

366

注：各省可以在此表的基础上扩展子类和自定义条目，针对一个子类，可以定义多个条目。

367

368

|**类别**|**子类**

369

|(% rowspan="8" %)系统硬件|路由器

|网络交换机

|小型机

|PC服务器

|磁盘阵列

|存储光纤交换机

|磁带库

|光盘库

|(% rowspan="4" %)客服设备|排队机

|CTI服务器

|CCS

|IVR服务器

|(% rowspan="5" %)安全设施|防火墙

|IDS入侵监测系统

|IPS入侵防护系统

|防毒墙

|安全软件

|(% rowspan="6" %)系统软件|操作系统

|数据库

|中间件

|集群软件

|备份软件

|系统管理软件

|(% rowspan="3" %)配套设施|UPS

393

|空调

394

|其它

395

|(% rowspan="5" %)应用软件|进程

|数据

|参数

|代码

|接口

====== **2.6.6 事件优先级** ======

407

408

优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级（紧急、高、中、低）。

409

410

|**编号**|**优先级代码**|**描述**

411

|1|紧急|(((

412

1. BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为全省或至少包括一个关键地市

413

1. 客服系统的电话呼叫中心业务不可用，影响面为全省或至少包括一个关键地市

414

1. 因系统原因数据处理错误，导致大量用户投诉

415

1. 来自新闻媒体、消费者协会、国家行政机关（工商、物价等）的反映或申告

1. 部分重要数据丢失，且无法全部恢复

)))

|2|高|(((

1. BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为全省一个或多个非关键地市

420

1. BOSS系统中综合采集、融合计费、产品管理、资源管理、一级BOSS、营销管理、渠道管理、合作伙伴管理、综合结算、系统管理、统计报表任一业务不可用，影响面为全省或至少包括一个关键地市

421

1. 客服系统的电话呼叫中心业务不可用，影响面为全省一个或多个非关键地市

422

1. 客服系统中互联网呼叫中心、短信呼叫中心、工单管理、知识管理、人力资源、质量管理、数据统计分析任一业务不可用，影响面为全省或至少包括一个关键地市

423

1. 经分系统的通用分析不可用，影响面为全省

424

1. 容灾系统的BOSS数据保护不可用，影响面为全省

425

1. BOSS网管系统的服务管理或监控管理不可用，影响面为全省

1. 用户在营业现场反应激烈

1. 监控管理平台严重告警

)))

|3|中|(((

1. 一般性系统故障

1. 监控管理平台主要告警

)))

|4|低|(((

1. 一般单个用户申告

1. 业务咨询

1. 监控管理平台一般告警

)))

当故障发生时，为了在判断优先级时增强实际可操作性，可以根据故障的影响范围和业务系统的关键程度在优先级映射表中定位优先级。故障的影响范围可以根据配置项中定义的‘影响范围’和用户报障描述来确定。

440

441

442

|(% rowspan="3" %)(((

BOSS

（任意一个模块）

)))|客户服务、客户管理、服务开通、综合帐务、订单管理|紧急|紧急|高|高

447

|综合采集、融合计费、产品管理、资源管理、一级BOSS|高|高|中|中

448

|营销管理、渠道管理、合作伙伴管理、综合结算、系统管理、统计报表|高|高|中|中

|(((

客服

（任意一个模块）

)))|电话呼叫中心|紧急|紧急|高|高

|(% rowspan="2" %)(((

客服

（任意一个模块）

)))|电话呼叫中心|紧急|紧急|高|高

|互联网呼叫中心、短信呼叫中心、工单管理、知识管理、人力资源、质量管理、数据统计分析|高|高|中|中

460

|(% rowspan="2" %)经分|通用分析|高|中|中|低

461

|专题分析| |中|中|低

462

|(% rowspan="2" %)容灾|BOSS数据保护|高|高|中|中

463

|BOSS业务接管、BOSS资源复用|高|中|中|中

464

|BOSS网管|服务管理、监控管理|高|中|低|低

注：

1. 如果某些业务模块没有反映在优先级映射表中，各省可以根据实际需要添加

469

1. 优先级映射表中空的字段，各省在细化流程中自行定义。

====== **2.6.7 事件响应时限和解决时限** ======

474

475

在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制，一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念，同时，也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理，同时，如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。

476

477

响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间，如果帮助台直接分配到二线支持，响应时限指的是事件状态从“已登记”到“二线处理中”经过的时间；

478

479

解决时限指的是事件状态从“已登记”到“已解决”经过的时间；

480

481

482

|**编号**|**优先级代码**|**响应时限要求**|**解决时限要求**

|1|紧急|30分钟|4小时

|2|高|1小时|8小时

|3|中|4小时|48小时

|4|低|8小时|96小时

注：

**◆ 事件通告定义**

* 通知人员列表的用途：当优先级为高或紧急的事件发生时，则按表中的人员列表发出邮件或短信通知。

|**优先级别**|**通知人员列表**

|紧急|事件经理，分管领导

|高|事件经理，分管领导

**◆ 超出响应时间的通告定义**

* 通知人员列表的用途：当服务管理平台判断到响应时限已经超出，则自动按照表中的人员列表发出邮件或短信通知。

503

504

|**优先级别**|**通知人员列表**|**事件响应时限**

505

|紧急|事件经理，分管领导，部门领导|30分钟

|高|事件经理，分管领导|1小时

|中|事件经理|4小时

|低|事件经理|8小时

**◆超出和即将超出解决时限的通告定义**

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小时

|96小时|事件经理

====== **2.6.8 事件影响度** ======

530

531

事件影响度用于衡量事件所影响业务的严重程度。严重程度通常通过事件所影响的人数、关键系统数以及服务故障所造成的损失来设定。

定义事件影响度等级的因素有：

1. 是否影响了核心业务

1. 所影响的用户数

1. 服务失效的影响范围和时长

事件影响度在事件的生命周期中是可以改变的，例如，初始等级为严重的故障会随着服务失效的时间变成重大故障，所以事件的影响度应在事件得到解决（服务恢复）后重新确认。

540

541

事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。

542

543

|**编号**|**影响度代码**|**事件性质**|**描述**

544

|(% rowspan="2" %)1|(% rowspan="2" %)重大|故障|(((

545

1. 全省半数以上地市或关键地市的融合计费业务中断超过6小时；

546

1. 全省半数以上地市或关键地市的营业、综合帐务、客服中任一业务中断超过3小时；

547

1. 全省半数以上地市或关键地市的综合结算业务处理中断超过24小时；

1. 半数以下地市全业务中断超过6小时；

)))

|申告|(((

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小时。

)))

|申告|(((

1. 局数据错误导致产生大量的错单；

1. 涉及到高额问题的申告；

1. 用户在营业现场反映激烈

)))

|(% rowspan="3" %)3|(% rowspan="3" %)一般|故障|(((

566

1. 系统内局部出现问题，不影响整个系统运行，不影响业务处理的故障

)))

|申告|(((

1. 不属于重大申告和严重申告的用户申述

)))

|告警|(((

1. 不影响系统的监控平台告警

)))

|4|无|咨询|(((

1. 一般数据查询或者使用指导

)))

注：各省根据自己业务情况扩展或修改本表格的描述，对于重大级别的事件，应严格按照集团公司的定义。

====== **2.6.9 事件状态** ======

584

585

事件状态代码表明事件所处的处理状态，事件状态如下：

586

587

|**编号**|**代码**|**描述**

588

|1|已登记|新开事件记录或事件已创建

589

|2|分配到帮助台|事件已分配给帮助台人员

590

|3|分配到一线|事件已分配到一线支持，一线还未响应

591

|4|分配到二线|事件已分配到二线支持，二线还未响应

592

|5|一线处理中|一线支持人员已接手处理事件

593

|6|二线处理中|二线支持人员已接手处理事件

594

|7|已解决|事件已解决，支持人员联系用户验证事件是否获得解决

|8|关闭|事件已关闭

====== **2.6.10 事件结束代码** ======

601

602

事件结束代码说明了事件是在何种情况下关闭的，结束代码如下：

603

604

|1|成功解决|事件获得成功解决

605

|2|变通方法解决|事件已通过变通方法或者临时措施获得解决，但是需要进行更进一步的根源分析

606

|3|不成功|事件没有获得解决（用户没有认可解决时使用）

607

|4|消失|事件自行消失

608

|5|误报|不属于业务支撑部门管理范围的事件

609

|6|可忽略|如通过其它系统接口或监控系统提交的垃圾信息，经确认属于无效信息

====== **2.6.11 事件解决人角色** ======

615

616

事件解决人角色用来标明该事件单最终解决的角色是帮助台、一线还是二线。

617

618

|**编号**|**代码**|**描述**

|1|帮助台|帮助台最终解决事件

|2|一线|一线支持最终解决事件

|3|二线|二线支持最终解决事件

====== **2.6.12 处理是否超时** ======

627

628

每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。

629

630

|**编号**|**代码**|**描述**

|1|未超时|未超时

|2|超时|事件已超出规定的解决时限

====== **2.6.13 故障厂商** ======

638

639

用来在事件单中记录是哪个厂商的设备/系统，或者哪个集成商的应用软件发生故障(针对事件分类中的”应用软件”故障)。代码定义参见下表厂商和集成商名称标准（可以根据情况从厂商和集成商两个表中选择一个合适的故障厂商）。

640

641

各省可以根据实际情况对厂商名称标准表和集成商名称标准表进行扩充。

|**编号**|**厂商名称**

|(((

1.

)))|3COM

|(((

2.

)))|AVAYA

|(((

3.

)))|BEA

|(((

4.

)))|BMC

|(((

5.

)))|Borland

|(((

6.

)))|CA

|(((

7.

)))|Cisco

|(((

8.

)))|DB2

|(((

9.

)))|EMC

|(((

10.

)))|HDS

|(((

11.

)))|HP

|(((

12.

)))|IBM

|(((

13.

)))|Informix

|(((

14.

)))|McDATA

|(((

15.

)))|Microsoft

|(((

16.

)))|NCR

|(((

17.

)))|NETAPP

|(((

18.

)))|Oracle

|(((

19.

)))|Quantum ATL

|(((

20.

)))|STK

|(((

21.

)))|SUN

|(((

22.

)))|Sybase

|(((

23.

)))|TERADATA

|(((

24.

)))|北电

|(((

25.

)))|东方通

|(((

26.

)))|中兴

|(((

27.

)))|华为

|(((

28.

)))|SYMANTEC

|(((

29.

)))|QUEST

|(((

30.

)))|REDHAT

|(((

31.

)))|BROCADE

|**编号**|**集成商名称**

|(((

1.

)))|亚信

|(((

2.

)))|联创

|(((

3.

)))|斯特奇

|(((

4.

)))|神州数码

|(((

5.

)))|华为

|(((

6.

)))|新大陆

|(((

7.

)))|亿阳

|(((

8.

)))|神州泰岳

|(((

9.

)))|创我

|(((

10.

)))|新宇

|(((

11.

)))|从兴

1.

11.

111. **投诉分类**

对于投诉类事件，帮助台可初步定位是哪类投诉，由一线、二线进行进一步的明确。

|**编号**|**分类 **

|1|营业类

|2|计费类

|3|帐务类

|4|资费类

|5|SP类

|6|开关机类

|7|冲值类

|8|接口类

|9|其它类

1.

11.

111. **投诉条目**

对于投诉类事件，帮助台可初步定位投诉属于哪个条目，由一线、二线进行进一步的明确。

|**编号**|**条目 **

|1|程序问题

|2|系统故障

|3|理解问题

|4|用户数据

|5|话单延迟

|6|三批问题

|7|操作失误

|8|流程问题

|9|处理积压

|10|同步问题

|11|查询问题

|12|数据问题

|13|彩铃功能

|14|彩铃费用

|15|彩铃其它

|16|其它SP

|17|指令延迟

|18|HLR问题

|19|SCP问题

|20|接口问题

|21|到帐延迟

|22|网上营业厅

|23|短信营业厅

|24|自助终端

|25|银行联网

|26|智能网

|27|V网

|28|天府卡

|29|客服系统类

|30|需求类

|31|查询类

|32|误操作类

|33|其它类

Wiki source code of 某通信公司ITIL事件管理流程细化说明书