返回本章节索引      阅读下一篇

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

1、综述

1.1 设计目的

本文档的目的是：

1. 建立基于ITIL的业务支撑网事件管理的基本框架，提升业务支撑网的IT服务可用性
2. 对集团公司和各省公司业务支撑网的事件管理进行规范化、统一化管理
3. 指导业务支撑系统服务管理平台的建设 

1.2 适用范围

本文档作为本次项目的事件管理流程详细设计的交付物，读者对象为与事件管理流程相关的所有技术与管理人员。

1.3 相关术语

◆ ITIL（IT Infrastructure Library ）

◆ 帮助台（Service Desk）

帮助台从根本上来说是提供了用户和IT部门的唯一接口。此项功能常通过集中方式提供服务。帮助台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。

◆ 事件管理（ Incident Management）

ITIL流程之一，事件管理负责解决所有的IT事件、问题和用户请求。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。

◆ 问题管理（Problem Management）

ITIL流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件的根本原因，并通过解除该根本原因从而防止类似事件的再次发生。同时问题管理流程也负责预防事件的发生。

◆ 配置管理（Configuration Management）

ITIL 流程之一，配置管理负责描述，跟踪和汇报所有IT基础架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置项(CI) 。每一个CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。

◆配置管理数据库（CMDB - Configuration Management Database）

是在配置管理流程中用于记录企业所有IT相关配置项信息及其相互关系而建立的数据库。

◆变更管理（Change Management）

ITIL流程之一，变更管理通过控制和管理IT相关的变更， 使变更对生产环境可能的影响和风险降到最小，从而提高IT环境的整体稳定性。

2 事件管理流程设计

2.1 流程目的

事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：

◆在成本允许的范围内尽快恢复IT服务

• 快速响应服务请求（电话/Web/邮件等）
• 用户在线获得帮助（知识库共享）
• 沟通事件解决的状态
• 和客户确认事件的解决

◆进行事件控制

• 按规范记录事件
• 就事件的优先级，影响度 进行分类
• 分析，诊断，必要时进行升级
• 监视并结束事件
• 进行定期服务流程回顾

◆提供IT管理信息

• 人力资源利用情况
• 故障处理情况
• 支持效率

2.2 流程主要内容

◆ 事件接收和记录

◆ 分类和在线支持

事件可以是一个申告/故障/告警/咨询/业务处理/维护作业，对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。

◆调查和诊断

◆ 解决和恢复

◆结束事件

2.3 与其他流程的关系

◆ 和问题管理流程的关系

事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。

◆ 和配置管理流程的关系

需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。

◆ 和变更管理流程的关系

帮助台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。

2.4 流程范围

业务支持中心的事件管理范围包括与BOSS、客服、经分、容灾、BOSS网管相关的所有IT生产环境所产生的申告、故障、告警、咨询、业务处理和维护作业。

本事件管理范围不包括尚处于开发或测试环境的系统和应用引发的事件。

2.5 流程执行原则

2.5.1 常规原则

1. 所有业务支撑部门事件管理范围内发生的事件，都应该记录在服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件
2. 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别
3. 应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估
4. 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程

2.5.2 流程关联原则

◆ 和问题管理的关联

• 所有优先级为紧急的事件在恢复服务后，都应该创建问题单（问题单必须和事件单建立关联）
• 一线支持在解决事件的过程中，可以通过问题记录查找相应的解决方案

◆ 和变更管理的关联

• 事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和事件单建立关联），变更完成后，继续事件单的处理
• 紧急事件（优先级为紧急的事件，下同）的处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和紧急事件单建立关联

◆ 和配置管理的关联

• 事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位

• 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联

2.5.3 所有权原则

所有权原则用来确保每个事件在任何时段都有适当的人员负责，帮助台是事件的负责人。

• 由IT用户申报的事件单，帮助台员工是该事件的责任人，必须确保事件得到有效跟踪与解决，并负责事件单的关闭

2.5.4 再分派原则

事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分配到个人，或者分配到组（帮助台，一线支持，二线支持），再由组内的支持人员处理。事件单的重分派次数不应该超过5次。

1. 帮助台可以将事件单分配给一线支持，如果找不到合适的一线支持，可以直接分配到二线支持
2. 一线支持可以将事件单重新分配给帮助台，其他一线支持人员，二线支持
3. 二线支持可以将事件单重新分配给帮助台，一线支持，其他二线支持人员

2.5.5 重复事件原则

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

1. 监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台
2. 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标
3. 如果帮助台可以判断到重复事件，则由帮助台对重复事件标识，否则由一线支持人员负责重复事件的处理

2.5.6 关闭原则

由IT用户申报的事件单，关闭必须由帮助台完成。

◆ 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为“变通方法解决”。帮助台负责和IT用户再次确认事件的解决

• 由IT用户认可获得关闭的事件单的结束代码为“成功解决”关闭
• 已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为“不成功”，同时创建一个新的事件单重新分配到原处理人员继续处理

◆已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单

1. 业务支撑部门的维护人员（一线或二线）自行创建的事件单，本着“谁开单，谁负责关闭”的原则
2. 监控平台自动发送的事件单，第一次接收的维护人员负责关闭
3. 对于IT用户（例如客服）申报的事件单，可以实现由IT用户自行确认事件是否解决，超过一定期限（例如3－5天）不确认的事件单由系统自动关闭或由帮助台协助关闭 

2.5.7 升级原则

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

1. 优先级为紧急的事件，帮助台应立即升级到相应一线支持，由一线支持再次确认，如果确认了优先级为紧急，则立即升级到事件经理，并通知相应的管理层（通过服务管理平台），由事件经理启动紧急事件处理流程
2. 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理
3. 帮助台和一线支持应及时将不能解决的事件升级到下一级，若未及时升级，事件经理应及时介入，负责协调升级处理

2.6 流程相关定义

2.6.1 事件信息项

事件单必须包含如下事件信息项，各省可以在此基础上扩充：

2.6.2 事件性质

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

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

2.6.3 事件来源

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

2.6.4 事件所属系统类型

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

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

2.6.5 事件分类

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

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

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

2.6.6 事件优先级

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

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

注：

1. 如果某些业务模块没有反映在优先级映射表中，各省可以根据实际需要添加
2. 优先级映射表中空的字段，各省在细化流程中自行定义。

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

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

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

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

注：

◆ 事件通告定义

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

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

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

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

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

2.6.8 事件影响度

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

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

1. 是否影响了核心业务
2. 所影响的用户数
3. 服务失效的影响范围和时长

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

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

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

2.6.9 事件状态

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

2.6.10 事件结束代码

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

2.6.11 事件解决人角色

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

2.6.12 处理是否超时

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

2.6.13 故障厂商

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

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

2.6.14 投诉分类

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

2.6.15 投诉条目

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

2.7 流程概要设计

事件管理概要设计流程图如下：

事件管理概要设计流程说明

2.8 流程详细设计

2.8.1（100.1）事件记录和分类

流程描述如下：

2.8.2 （100.2）初始支持

流程描述如下：

2.8.3 （100.3）一线尝试解决

流程描述如下：

2.8.4 （100.4）二线尝试解决

流程描述如下：

2.8.5 （100.5）紧急事件再确认

流程描述如下：

2.8.6 （100.6）记录解决方案细节

流程描述如下：

2.8.7 （100.7）关闭事件

流程描述如下：

2.8.8 （100.8）事件处理的监控

流程描述如下：

2.8.9（101）紧急事件处理子流程

制定紧急事件处理子流程的目标：

1. 当紧急事件发生时，尽可能采取措施减少对于业务带来的影响
2. 确保对紧急情况的有效管理

• 加快紧急事件的响应和处理速度
• 对紧急情况中的人员及采取的行动加强管理
• 加强处理人员与用户之间的沟通和反馈
• 对紧急情况妥善处理

2.8.9.1流程原则

◆ 制定各系统应急处理预案

为了确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障，各系统应该建立相应的应急处理预案，建议预案中的内容至少应涵盖以下方面：

• 应急预案启动条件
• 应急处理小组负责人和成员联系名单和联系方式
• 应急处理步骤
• 应急信息通报
• 应急善后处理
• 应急保障措施（人员、培训、演习、场地等）

◆ 紧急事件上报集团公司

为切实掌握各省公司业务支撑系统紧急事件情况，要求各省公司在紧急事件发生时立即上报，并在紧急事件处理过程中的关键点将处理情况上报，具体上报内容和方式参见2.12集团、省公司两级交互。

2.8.9.2 紧急事件处理子流程概要说明

紧急事件处理子流程说明如下：

2.8.10 （102）维护作业子流程

维护作业子流程用来描述如何处理来自集团公司下发的维护作业和省中心制定的维护作业计划。维护作业子流程在事件管理流程中属于相对独立的模块，处理流程和相关信息项的填写与故障或申告不同，以下内容主要说明维护作业的流程原则和概要流程图。

各省在细化维护作业流程时，可以在流程原则的基础上扩展和细化以满足各省中心对维护作业的具体要求。

2.8.10.1 流程原则

◆ 维护作业事件单的产生

• 帮助台负责接收集团下发的维护作业，分配到相应的一线/二线支持人员
• 负责执行维护作业的支持人员在服务管理平台录入维护作业单
• 负责执行维护作业的支持人员在维护作业单中录入维护作业的执行结果

◆ 维护作业的事件信息项的填写说明

◆集团维护作业执行情况上报

• 集团下发的维护作业执行情况在省公司定期的上报报表中体现

2.8.10.2 维护作业子流程概要说明

维护作业子流程说明如下：

2.8.11 （103）业务处理子流程

业务处理子流程用来描述各省业务支撑部门根据特定的需求，对业务运营支撑系统的数据进行查询或修改的操作流程，例如：

1. 根据业务部门或业务支撑部门内部人员提出的业务处理需求单进行的业务操作
2. 系统原因造成的批量数据差错修复、分公司支撑中心提出的批量数据修改要求
3. 新业务上线测试、故障恢复测试所必须的业务操作

2.8.11.1 流程原则

◆ 业务处理的安全性原则

• 业务处理操作必须符合各省公司关于业务操作制定的相关规范
• 业务处理操作的执行人和复核人原则上不能是同一个人

◆ 业务处理的事件信息项的填写说明

 2.8.11.2 业务处理子流程概要说明

业务处理子流程说明如下：

2.9 事件状态迁移图

事件状态变迁图用来标明：当一个事件单处于某个状态时，它可以去到的下一个状态。

◆ 当前状态为‘已登记’状态时，可迁移的状态

◆当前状态为‘分配到帮助台’状态时，可迁移的状态

◆ 当前状态为‘分配到一线’状态时，可迁移的状态

◆ 当前状态为‘分配到二线’状态时，可迁移的状态

◆ 当前状态为‘一线处理中’状态时，可迁移的状态

◆ 当前状态为‘二线处理中’状态时，可迁移的状态

◆ 当前状态为‘已解决’状态时，可迁移的状态

◆当前状态为‘已关闭’状态时，可迁移的状态

• 不迁移至任何状态。

2.10 关键角色、职责定义

流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满足流程所需角色的基础上，为具体的实现提供足够的灵活性。具体的角色职责和岗位对应在《事件管理细化流程说明书》中体现。

事件管理流程主要分为以下几个职责/角色，分别简述如下：

2.10.1 事件管理流程负责人

事件管理流程负责人从宏观上监控流程，确保事件流程在业务支持中心范围内被正确的执行。当流程不能够适应业务支持中心的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。

职责：

1. 确定管理流程的衡量指标
2. 确保事件流程能够取得管理层的参与和支持
3. 确保事件流程符合公司实际状况和公司 IT发展战略
4. 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制
5. 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进(假如增加或合并流程的角色)，从而实现可持续提高
6.  保持与其他流程负责人的定期沟通

技能要求：

1. 深刻理解事件管理流程；
2. 充分理解业务支撑网运维管理流程梳理项目的其他流程，能够进行流程接口设计；
3. 能够很好地理解业务对于事件管理的需求；
4. 对质量控制与保障有很深入的了解；
5. 有决策权，能够确保事件管理流程设计要求在实施项目中得到贯彻和执行；
6. 具有很好的沟通技能，能够取得公司高层的支持，获得所需资源。

2.10.2 事件经理

事件经理负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。

职责：

1. 负责对事件的解决协调资源，保证故障的最终排除
2. 当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协调资源，促进支持工程师快速恢复正常服务
3. 确保和问题管理流程经理的有效合作
4. 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题

技能要求：

1. 了解技术架构和技术环境
2. 较强的口头表达能力和与用户沟通技巧
3. 处理纠纷的能力
4. 深刻了解事件管理流程
5. 较强的领导能力

2.10.3 帮助台人员

帮助台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的一线支持工程师或者二线支持工程师。

职责：

1. 在指定的响应时间内响应所有帮助台热线电话、邮件、传真等事件报告
2. 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等
3. 为事件进行适当的分类、为事件分配优先级等属性
4. 尝试使用工具、初步诊断、分析相关信息等方式解决问题
5. 如果帮助台不能解决这个事件，应当将事件分配给最合适的一线支持小组/人员来处理
6. 检查事件记录的处理进度，保持与事件报告人的联系，适时通知事件处理进展
7. 与用户确认事件解决方案，关闭事件
8. 负责24×7的值班和系统监控

技能要求：

1. 熟悉技术平台和技术环境
2. 较强的沟通能力
3. 对简单的故障要有快速诊断和解决的能力
4. 熟悉事件处理流程

2.10.4 一线支持人员

一线支持人员负责对帮助台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。

职责:

1. 验证事件的描述和信息，进一步收集相关信息
2. 决定需要采取何种措施恢复服务并实施有效的行动
3. 必要时提供现场支持
4. 根据优先级提供有效的解决方案
5. 实施事件解决方案
6. 更新事件解决信息，已解决的事件转回帮助台，由帮助台关闭事件
7. 如果一线不能解决这个事件，应当决定选择最合适的二线支持小组/人员来处理

技能要求：

1. 熟悉技术平台和技术环境
2. 较强的沟通能力
3. 快速诊断事件和解决事件的能力
4. 熟悉事件处理流程

2.10.5 二线支持人员

二线支持人员是相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。各省可以考虑按照所维护的应用、系统进行分组，如：网络组、主机组、应用组等。

职责:

1. 进行事件的深入调查研究
2. 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动
3. 必要时引入供应商的支持
4. 更新事件根源和最终解决方案
5. 更新事件记录，确保事件状态代码真实反映事件状态
6. 及时提供有效解决方案
7. 与其他小组合作，确定解决方案
8. 已解决的事件转回帮助台，由帮助台关闭事件
9. 如果二线不能在解决时限内解决这个事件，应当将事件进行升级

技能要求：

1. 深厚的技术背景，对所维护范畴的技术深入掌握
2. 熟悉事件处理流程

2.10.6 流程角色和人员对应表

注：在系统实施时由某通信公司根据实际运维架构在此表基础上完成具体的人员映射。

2.11 关键流程衡量指标

为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。

2.12 集团、省公司两级交互

省公司在紧急事件发生时，必须在第一时间上报集团公司业务支撑系统部，并在事件处理过程中的每个状态变化点将最新事件记录上传到集团公司。

2.13 省公司报表

省公司报表定义如下，同时，上报集团报表也可以供省公司使用。

2.13.1 按事件来源分类的统计报表

指标说明：

2.14 省公司上报报表

2.14.1按业务系统和优先级分类统计报表

指标说明：

2.14.2 按业务系统细分的故障和优先级分类统计报表

指标说明：

2.14.3 按业务系统和影响度分类统计报表

指标说明：

2.14.4 按业务系统细分的故障和影响度分类统计报表

指标说明：

2.14.5 按业务系统统计故障和申告处理效率指标报表

指标说明：

2.14.6 按事件分类的故障和优先级统计报表

指标说明：

2.14.7 按业务中断时长分类的统计报表

注： 业务中断时长＝业务恢复时间－事件发生时间， 单位为分钟

指标说明：

2.14.8 故障厂商统计

注：该报表中的厂商按照各省实际情况上报。

指标说明：

2.14.9 业务处理统计

指标说明：

2.14.10 维护作业按业务系统分类统计

指标说明：

2.14.11 维护作业按事件分类统计

指标说明：

返回本章节索引      阅读下一篇