中国移动管理流程手册

中国移动通信企业标准

业务支撑网运营管理系统规范 版本号：V2.0.0

服务管理流程分册

QB-J-001-2007

中国移动通信有限公司 发布

目录

1 综述 ............................................................... 错误!未定义书签。

本期目标 ......................................................... 错误!未定义书签。 适用范围 ......................................................... 错误!未定义书签。 主要内容 ......................................................... 错误!未定义书签。 规范落实 ......................................................... 错误!未定义书签。 持续改进 ......................................................... 错误!未定义书签。 地市支持模式 ..................................................... 错误!未定义书签。 相关术语 ......................................................... 错误!未定义书签。

2 事件管理流程概要设计 ............................................... 错误!未定义书签。

流程目的 ......................................................... 错误!未定义书签。 流程主要内容 ..................................................... 错误!未定义书签。 与其他流程的关系 ................................................. 错误!未定义书签。 流程范围 ......................................................... 错误!未定义书签。 流程执行原则 ..................................................... 错误!未定义书签。 流程相关定义 ..................................................... 错误!未定义书签。 流程概要设计 ..................................................... 错误!未定义书签。 关键角色、职责定义 ............................................... 错误!未定义书签。 关键流程衡量指标 ................................................. 错误!未定义书签。 集团、省公司两级交互 ........................................... 错误!未定义书签。 省公司上报报表 ................................................. 错误!未定义书签。 实施指导 ....................................................... 错误!未定义书签。 本期规范的主要变化 ............................................. 错误!未定义书签。

3 问题管理流程概要设计 ............................................... 错误!未定义书签。

流程目的 ......................................................... 错误!未定义书签。 流程主要内容 ..................................................... 错误!未定义书签。 与其他流程的关系 ................................................. 错误!未定义书签。 流程范围 ......................................................... 错误!未定义书签。 流程执行原则 ..................................................... 错误!未定义书签。 流程相关定义 ..................................................... 错误!未定义书签。 流程概要设计 ..................................................... 错误!未定义书签。 关键角色、职责定义 ............................................... 错误!未定义书签。 关键流程衡量指标 ................................................. 错误!未定义书签。 集团、省公司两级交互 ........................................... 错误!未定义书签。 省公司上报报表 ................................................. 错误!未定义书签。 实施指导 ....................................................... 错误!未定义书签。 本期规范的主要变化 ............................................. 错误!未定义书签。

4 配置管理流程概要设计 ............................................... 错误!未定义书签。

流程目的 ......................................................... 错误!未定义书签。 流程主要内容 ..................................................... 错误!未定义书签。 与其他流程的关系 ................................................. 错误!未定义书签。 流程范围 ......................................................... 错误!未定义书签。 流程执行原则 ..................................................... 错误!未定义书签。 流程相关定义 ..................................................... 错误!未定义书签。 流程概要设计 ..................................................... 错误!未定义书签。 关键角色、职责定义 ............................................... 错误!未定义书签。

关键流程衡量指标 ................................................. 错误!未定义书签。 集团、省公司两级交互 ........................................... 错误!未定义书签。 省公司上报报表 ................................................. 错误!未定义书签。 实施指导 ....................................................... 错误!未定义书签。 本期规范的主要变化 ............................................. 错误!未定义书签。

5 变更管理流程概要设计 ............................................... 错误!未定义书签。

流程目的 ......................................................... 错误!未定义书签。 流程主要内容 ..................................................... 错误!未定义书签。 与其他流程的关系 ................................................. 错误!未定义书签。 流程范围 ......................................................... 错误!未定义书签。 流程执行原则 ..................................................... 错误!未定义书签。 流程相关定义 ..................................................... 错误!未定义书签。 流程概要设计 ..................................................... 错误!未定义书签。 关键角色、职责定义 ............................................... 错误!未定义书签。 关键流程衡量指标 ................................................. 错误!未定义书签。 集团、省公司两级交互 ........................................... 错误!未定义书签。 省公司上报报表 ................................................. 错误!未定义书签。 实施指导 ....................................................... 错误!未定义书签。 本期规范的主要变化 ............................................. 错误!未定义书签。

6 发布管理流程概要设计 ............................................... 错误!未定义书签。

流程目的 ......................................................... 错误!未定义书签。 流程主要内容 ..................................................... 错误!未定义书签。 与其他流程的关系 ................................................. 错误!未定义书签。 流程范围 ......................................................... 错误!未定义书签。 流程执行原则 ..................................................... 错误!未定义书签。 流程相关定义 ..................................................... 错误!未定义书签。 流程概要设计 ..................................................... 错误!未定义书签。 关键角色、职责定义 ............................................... 错误!未定义书签。 关键流程衡量指标 ................................................. 错误!未定义书签。 集团、省公司两级交互 ........................................... 错误!未定义书签。 省公司上报报表 ................................................. 错误!未定义书签。 发布管理流程细化指导 ........................................... 错误!未定义书签。

7 日常运维管理概要设计 ............................................... 错误!未定义书签。

作业计划管理 ..................................................... 错误!未定义书签。 值班管理 ......................................................... 错误!未定义书签。 公告 ............................................................. 错误!未定义书签。 知识库 ........................................................... 错误!未定义书签。 机房出入管理（可选） ............................................. 错误!未定义书签。

8 附件A: CI属性设计 ................................................. 错误!未定义书签。

硬件类CI ........................................................ 错误!未定义书签。 系统软件类CI .................................................... 错误!未定义书签。 客服设备类CI .................................................... 错误!未定义书签。 配套设施CI ...................................................... 错误!未定义书签。 业务应用类CI .................................................... 错误!未定义书签。 文档类CI ........................................................ 错误!未定义书签。 逻辑实体类CI .................................................... 错误!未定义书签。 安全设备类CI .................................................... 错误!未定义书签。

其他类CI ........................................................ 错误!未定义书签。

9 附录B: CI关系对照表 ............................................... 错误!未定义书签。 10 11

附录C: 厂商和集成商名称标准 ...................................... 错误!未定义书签。

厂商名称标准 ................................................... 错误!未定义书签。 集成商名称标准 ................................................. 错误!未定义书签。 附录D: 省公司上报报表 ............................................ 错误!未定义书签。

事件管理上报报表 ............................................... 错误!未定义书签。 配置管理上报报表 ............................................... 错误!未定义书签。 问题管理上报报表 ............................................... 错误!未定义书签。 变更管理上报报表 ............................................... 错误!未定义书签。 发布管理上报报表 ............................................... 错误!未定义书签。

1 综述

本规范是在一期《中国移动业务支撑网运营管理系统规范》和《附件一、业务支撑网网管规范-服务管理流程分册》基础上，收集整理并总结各省一期建设、使用经验及需求，结合《规范》、《经营分析系统规范》、《中国移动萨班斯法案.业务支撑网.改造指导意见》相关要求，参考ITIL 、ISO20000最新进展情况，综合分析形成。

本规范作为中国移动业务支撑网运营管理系统维护管理流程的统一核心版本，具有如下目的： 建立和健全基于ITIL的中国移动业务支撑网维护管理基本框架，提升运维管理效率。 对中国移动集团公司和各省公司业务支撑网的运行维护进行规范化、统一化管理。 指导各省业务支撑网维护管理细化流程的设计和业务支撑网运营管理系统的实施。

1.1 本期目标

服务管理应在保障“两个巩固、两个加强”的基础上，实现“两个落实、两个引入、两个固化”的目标。

“两个巩固”是指巩固事件管理成果、巩固变更管理成果。一期各省运维工作成效比较显着的是针对IT基础架构的系统支持工作中处理故障告警的事件管理和设备变化的变更管理，本期应坚持和巩固这些成果。

“两个加强”是指加强配置管理工作、加强问题管理工作。

本规范总结一期配置管理和问题管理工作的经验，精简配置管理CI范围和属性数量，形成关键CI。各省应坚决落实角色职责和配置维护和审核任务，保证核心数据的准确性和有效性。

各省应明确问题管理目的、来源以及与事件管理的区别，坚决把问题管理工作落实到问题管理流程中。

“两个落实”是指落实客户投诉管理工作、落实日常需求管理工作。

各省应建立和完善与客服投诉管理系统的接口，坚决把客户投诉处理工作纳入到事件管理流程和系统中去。

各省应把日常化业务需求的评估、实现、测试、培训、割接上线过程纳入到变更管理和发布管理流程中去。

“两个引入”是指引入日常运维管理，引入发布管理流程。

各省应按规范要求把机房值班，作业计划、机房进出等工作管理起来。 各省应利用发布管理流程管理系统测试、培训、部署、割接上线的过程。 “两个固化”是指固化角色职责映射、固化流程模型。

本规范根据各省实际情况对流程的角色职责进行了精简，提出了归并原则和建议，尽量避免同一流程中一人多角。各省应严格落实角色到人员岗位的映射，固化落实人员岗位的职责。 各省应结合事件和变更流程规范，逐步把日常工作中频发任务进行归类和抽象，固化处理环

节、人员和表单项，不断形成事件和变更流程模型。

1.2 适用范围

本规范适用于中国移动集团公司和各省公司的业务支撑系统维护管理工作，涉及BOSS(含客服)、经分和BOMC等系统的基础架构，以及业务应用的日常运维，包括日常值班、故障投诉处理、变更割接等维护业务过程的管理，不包括项目建设、软件开发等过程的管理。业务应用系统中日常化的需求申请、审批、实现、测试和上线过程的管理包括在本规范中。

1.3 主要内容

本规范包括对一期定义的事件管理、问题管理、配置管理和变更管理规范的优化和更新，同时增加了日常运维管理和发布管理规范，并特别强调流程的实用性和持续改进过程。

日常运维管理包括值班管理、作业计划管理、机房进出管理和知识经验管理等内容，主要定义和规范日程进行的常规任务和工作。

事件管理记录和管理故障从发生到业务恢复的过程，主要包括来自IT基础架构的故障告警、来自客服和业务部门的客户投诉，也包括来自其它业务部门的服务请求。

问题管理记录和管理故障根源分析和解决的过程，包括事件处理在业务恢复后仍需进行深入分析的故障、日程维护中发现的尚未影响业务的故障、工作例会上对事件进行趋势分析确定的潜在故障。

配置管理数据库CMDB记录和维护IT基础架构和业务应用的配置项CI、相关属性信息和CI的相互之间的关系。配置管理是对CMDB的规划、建立、维护和审核过程的管理，保证CMDB的完整性、实效性和权威性，为其它流程提供良好的支撑。

变更管理跟踪和记录变更评估、审批、实施和验证的过程，包括IT基础架构中设备、部件、板卡、配置的新增、变更和下线，也包括非项目性质、日常化业务需求的新增和变更。 发布管理跟踪和记录新系统测试、培训、部署、上线的过程，包括大版本测试上线发布和日常化需求变更的测试上线。

这些服务流程的总体构架和互相之间的关系如下：

图1. IT服务管理流程的关系

1.4 规范落实

本规范更加注重规范实用性和先进性的平衡，充分考虑流程角色与实际组织的映射、流程环节与实际工作的对应、ITIL术语与各省习惯用语的翻译，在保证流程实用性的前提下借鉴、ISO20000理念，保证规范的先进性。

1.4.1 规范角色和实际岗位的映射

综合各省业务支撑中心中各职能部门架构并进行抽象，与本规范相关的职能组织如下图所示： 系统支持：负责IT基础架构的支持维护。一般按照被管系统类型或范围进行分工，例如按照

机房、网络、主机、数据库、安全分工负责；

业务支持：负责BOSS、经分等业务应用的支持维护，一般按照业务模块分工，例如按照计费、结算、营业、帐务分工负责；

机房值班：负责机房值班，接听值班报障电话，使用BOMC系统监控IT基础架构和业务应用。一般由专门人员或系统支持轮流值班；

投诉受理：负责受理、处理和跟踪来自客服等部门的客户业务投诉； 设备和开发厂商：负责对所提供的设备或系统提供远程或现场支持。

图2. IT服务管理角色与岗位的对应关系

本规范各流程相关角色定义参见后续章节，与各省业务支撑中心典型的职能组织的对应关系如上图和下表所示。

表1． IT服务管理角色与岗位的对应关系

职能部门 规范流程 事件管理流程 问题管理流程 变更管理流程 配置管理流程 发布管理流程 机房值班 投诉受理 服务台 系统支持/业务支持 部门领导/主管 事件经理 问题经理 变更经理、CAB成员 配置经理 发布经理 系统支持/业务支持 专业管理人员 一线支持 二线支持 问题处理专家 变更请求者、变更主管、变更实施人员 配置管理员 发布主管、发布实施人员、培训主管 设备和开发厂商 三线支持 问题处理厂商 变更实施人员 发布实施人员 1.4.2 规范流程和实际工作的对应

本规范各流程是遵照ITIL术语和分类方式组织的，与各省业务支撑中心日常负责的主要工作是相互对应的，如下图及下表所示：

图3. IT服务管理流程与运维工作的对应关系 表2． IT服务管理流程与运维工作的对应关系

对应关系 规范定义的流程 事件管理 规范与实际基本对应的 目前实际工作 系统故障处理 客户投诉处理 变更管理 发布管理 日常运维 规范要求，实际工作未全面开展的 问题管理 配置管理 <无> 实际在做,不属于规范范围的 <无> 系统变更过程 需求实现过程 日常运维 故障分析 <无> 项目管理 开发管理 本规范明确定义日常化的需求实现过程属于变更和发布管理流程 包括值班、作业计划、机房进出、知识库等 日常根源分析工作是故障处理的一部分，没有明确的确定、评估和知识经验积累 没有基本的配置数据收集、维护和审核的业务过程 项目建设、管理和随工是各级员工的重要工作，但不在本规范范围内 项目性质的大型软件开发中的需求管理和开发管理是业务支撑中项目管理和随工人员参与的重要工作，但不在说明 其中客户投诉处理在本规范中有明确、细致的定义 本规范范围内 1.5 持续改进

各省运维管理体系需要不断调整和优化，以适应不断变化的实际环境。管理体系的规划、落实和改进优化遵循PDCA持续改进的质量控制原则，通过“计划、执行、检查和改进”的不断循环、螺旋上升的过程来持续提高运维管理体系的有效性。

运维管理水平的持续改进需要组织和流程的保障。组织上必须落实“流程负责人”角色，并赋予相应权限；流程上必须建立和落实日常化推广、落实、监督、检察制度和定期的流程改进优化制度。

本规范为每个流程都定义了流程经理角色，建议各流程经理由各职能部门经理或负责人分别担任，负责流程及对应维护任务的落实和管理工作。本规范专门定义了流程负责人角色，建议由业务支撑中心主任授权专人专职担任事件、问题、变更、配置、发布和日常运维的流程负责人，对流程的科学性、实用性和落实情况负责。

图4. IT服务管理各角色之间的对应关系

如图所示，如果把运维管理体系比作一部法典，那么流程负责人就是立法者和监督者，流程经理是执法者，而各省业务支撑中心专业技术人员是守法者。可见，流程负责人对保障服务体系的合理性和有效性是多么重要。

流程负责人对IT服务管理流程的合理性、有效性和落实情况负责，从整体上把握流程的计划、实施、监督和持续改进，其主要职责为:

规划

有义务参加集团公司运维管理策略、规范制定工作；

负责运维管理规范在本省的角色映射、流程细化和流程模型固化。 实施

负责撰写、维护和更新各种模版、操作规范、操作指南、检查表等； 负责宣贯运维管理体系的角色职责、服务流程和考评体系了； 负责执行运维管理体系持续优化流程。 监督

保证流程运作达到预期目标，对流程结果负责；

负责监督流程落实和运行情况，及时发现和解决问题，保障流程活动的落实； 负责监控流程绩效。 改进

负责组织召开流程运行情况分析例会，识别、分析流程改进需求，汇总、形成优化建议； 有义务参加集团公司流程优化研讨会，汇报、讨论和确定流程改进需求和优化方案。 流程日常的推广、落实、监督、检查制度和定期的流程改进优化制度的落实由持续改进流程实现，流程负责人主导该流程的运行，管理层和各级员工有义务参与该项活动。持续改进流程建议每半年执行一次。持续改进流程如下图所示：

图5. IT服务管理持续改进流程

1.6 地市支持模式

本规范面向用户包括总部、各省公司及地市公司业务支撑部门相关运行维护和管理人员。地市公司参与方式有如下几种，各省公司可以根据实际情况选择：

图6. 地市支持模式

模式一：本规范对地市运维工作不做强制要求。地市公司业务支撑人员作为本系统的客户，可以提出服务请求，得到业务支撑中心的服务。

模式二：省公司业务支撑运行维护工作涉及到地市公司的，地市公司业务支撑人员按照本规范要求执行；与省公司无关的本地运维维护工作不受规范约束。例如省公司统一的事件受理和处理、变更执行、发布测试、配置收集等工作，需要地市公司配合的，应把角色映射到地市公司，地市公司人员按需使用本系统。

模式三：地市业务支撑人员所有的运行维护工作均遵守本规范执行。例如：地市自己的日常运维、故障处理和设备维护等。地市业务支撑人员完全映射到本规范角色中并承担相应职责，每个地市业务支撑人员以帐户使用本系统。

1.7 相关术语

ITIL（IT Infrastructure Library ）

是英国在1987年制定的有关IT服务管理的方，其核心是服务支持和服务交付10个核心流程，现已成为事实上的IT管理标准。ITIL可以提供针对个人的从业资格认证。

ITIL

2007年发布的ITIL最新版本，把IT管理从“服务”层面上升到“业务”层面，更加强调服务的规划、设计、建设、运维全过程的持续改进。

图7. 框架

ISO20000

国际标准组织ISO/IEC在2005年底发布的全球IT服务管理标准，包括服务实施、控制、发布、解决、关系管理5个域13个流程，强调持续改进过程。ISO20000可以提供针对企业或部门的国际标准认证。

图8. ISO20000流程

运维职能（Operation Function）

ITIL 把运维职能部门概括为服务台、技术管理、应用管理和操作管理四类，对应于投诉热线受理、基础架构维护、业务应用维护和机房值班等职能分工。

图9. IT运维职能分工

服务台（Service Desk）

服务台提供用户和IT部门的唯一接口。目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。例如：值班组和投诉受理组往往充当服务台，省内或全国统一对内故障/业务受理电话往往是服务台成功建设的标志。

事件管理（ Incident Management）

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

问题管理（Problem Management）

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

应急预案（Work-around）

为迅速处理故障，快速恢复业务事先总结制定的临时处理措施。 配置管理（Configuration Management）

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

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

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

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

变更申请单（RFC， Request For Change）

变更请求的载体，是贯穿变更过程，在客户与变更处理相关人员之间进行信息沟通的媒体。 变更窗口

变更窗口是指定期将执行时间相近的变更，汇集在一个时间段内共同执行，这样可以减少因为中断业务、停机等对生产的影响。建议各省根据具体情况，制定固定的变更窗口。变更窗口只适用于标准变更。

流程模型（Process Model）

针对频发事件或变更提出的，预先建立固化处理过程的模型。例如板卡更换过程、口令复位流程等。流程模型中应包括处理的环节/步骤、每环节的负责人员、表单的预定于字段等。流程模型的不断建立、丰富和修正是流程落实和持续改进的重要内容。要建立新的流程模型，需要梳理日常实际工作流程，形成工作流程图；然后结合规范映射角色，补充完善工作步骤，形成固化的流程模型。

发布管理（Release Management）

ITIL流程之一， 发布管理通过规范的方法和流程，计划和监控新服务（包括软件和相关硬件）的部署和发布过程，提高上线成功率，降低可能的问题和风险。

最终软件配置库(DSL, Definitive Software Library）

用于保存生产环境中所有所需软件的最终权威版本的介质或映像的物理或逻辑存储空间，例如保存软件光盘的存储柜或保存软件映像的文件服务器。在中，DSL更新为DML(Definitive Media Library)

图10. 最终软件配置库

持续改进（Continuous Service Improvement）

服务管理体系的规划、落实和改进优化应遵循 “计划、执行、检查和改进”这样一个不断循环、螺旋上升的过程来持续提高监控管理体系的有效性，该过程符合PDCA持续改进的质量控制原则。

图11. 流程持续改进

RACI模型（Responsible, Accountable, Consulted, Informed）

ITIL 明确提出的责任模型，描述组织/个人/角色在某项任务/活动中承担的不同责任。R(有义务)表示在活动中务承担义务，A(负责任)表示需要对活动的结果负责，C(提建议)表示可以对活动提供咨询意见，D(需知晓)表示需要了解活动情况。

2 事件管理流程概要设计

2.1 流程目的

事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括： 在成本允许的范围内尽快恢复IT服务

快速响应服务请求（电话/Web/邮件等） 用户在线获得帮助 沟通事件解决的状态 和客户确认事件的解决 进行事件控制

按规范记录事件

就事件的优先级，影响度进行分类 分析，诊断，必要时进行升级 监视并结束事件 进行定期服务流程回顾 提供IT管理信息

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

2.2 流程主要内容

事件管理流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容： 事件检测和记录

这个环节是事件管理流程的起点。所有用户或系统报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。

该环节的关键是信息的准确性和完整性。 分类和初步支持

对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。

调查和诊断

若支持人员无法解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。

解决和恢复

支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。

优先级为紧急的事件（紧急事件）和事件升级

对于紧急事件，服务台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层，由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。

当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。

结束事件

当用户确认事件解决后，此时可结束该事件。

2.3 与其他流程的关系

和问题管理流程的关系

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

和配置管理流程的关系

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

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

和知识库的关系

事件得到解决后，解决的过程中所获得的经验以及相关解决方案可以进入知识库，作为知识保存，为后续的工作提供指导。

2.4 流程范围

事件管理范围包括与BOSS系统、经营分析系统、容灾系统和BOMC系统相关的所有IT生产环境所产生的申告、故障、告警、咨询和客户投诉。

不包括：

尚处于开发或测试环境的系统和应用引发的事件

2.5 流程执行原则

2.5.1 常规原则

所有业务支撑部门事件管理范围内发生的事件，都应该记录在服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件

所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别

应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估

应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程

2.5.2 所有权原则

所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。下表是事件管理中各角色在各环节中承担不同责任的RACI模型。

表3． 事件管理RACI模型

服务台人员 (值班/投诉受理) 检测和记录(detection and recording) 分类和支持(classification & initial support) 分析和诊断(investigation and diagnosis) 解决和恢复(resolution and recovery) 事件关闭(Incident closure) 监控和沟通(ownership, monitoring, tracking & communication) A A R R A A 事件经理 (职能经理) I C 一、二线支持 (员工) R R A C/I I R/C/I A R I 三线支持 (厂商) R R I RACI模型说明 A: 负全责; R: 有义务; C: 提建议; I: 需知会 2.5.3 再分派原则

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

服务台可以将事件单分配给一、二线支持

一、二线支持可以将事件单重新分配给服务台、其他一、二线支持人员和厂商人员

现场厂商人员直接使用系统记录处理情况，没有条件使用系统的厂商，由一、二线支持代为记录

2.5.4 重复事件原则

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

监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标

如果服务台可以判断到重复事件，则由服务台对重复事件标识，否则由一、二线支持人员负责重复事件的处理

2.5.5 关闭原则

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

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

已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为“不成功”，同时创建一个新的事件单重新分配到原处理人员继续处理 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单 一、二线人员自行创建的事件单，本着“谁开单，谁负责关闭”的原则 监控平台自动发送的事件单，第一次接收的维护人员负责关闭

2.5.6 升级原则

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

优先级为紧急的事件，服务台应立即派发到一、二线支持，由其再次确认，如果确认了优先级为紧急，则立即升级到事件经理，并通知相应的管理层，由事件经理启动紧急事件处理流程 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理

服务台应及时将不能解决的事件升级，若未及时升级，事件经理应及时介入，负责协调升级处理

2.6 流程相关定义

2.6.1 事件信息项

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

表4． 事件信息项

序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 25 26 27 28 29 30 31 32 信息项 事件ID 请求人信息 登记时间 地点 事件发生时间 业务恢复时间 事件性质 事件来源 事件影响度 事件优先级 事件完成期限 所属系统类型 事件分类 事件标题 事件描述 事件解决人 事件状态 分配对象 事件日志 解决方案 融合计费中断时长 综合帐务中断时长 客户服务中断时长 事件结束代码 重复事件标记 处理是否超时 事件解决人角色 实际开始时间 实际完成时间 故障厂商 关联配置项 关联的问题单号 关联的变更单号 说明 事件单流水号（系统自动产生） 事件申报人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写） 在服务台生成事件记录的时间（系统自动产生） 事件发生的地点 （手工填写） 针对故障：指的是业务中断的实际时间 （可能早于登记时间，需要手工填写） 针对其它：缺省值等于登记时间 针对故障的业务恢复实际时间（手工填写） 参见“事件性质”定义 参见“事件来源”定义 参见“事件影响度”定义 参见“事件优先级”定义 对应每一个事件优先级，系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限 （系统自动产生） 参见“所属系统类型”定义 参见“事件分类”定义 事件的简要描述（手工填写） 对于整个事件内容的详细描述（手工填写） 事件的最终解决人（手工填写） 参见“事件状态”定义 被分配的技术支持组和人员（手工填写） 反映事件信息项的变化历史，如一个事件在处理过程中事件状态变化的时间点等信息（系统自动产生） 事件解决方案的描述（手工填写） 造成融合计费业务计划外中断的时间长度(分钟，手工填写) 造成综合帐务业务计划外中断的时间长度(分钟，手工填写) 造成客户服务业务计划外中断的时间长度(分钟，手工填写) 参见“事件结束代码”定义 标记为重复事件（手工填写） 参见“处理是否超时”定义（系统自动产生） 参见“事件解决人角色”定义 记录事件状态到XX处理中的时间（系统自动产生） 记录事件已解决的时间（系统自动产生） 参见附录C厂商和集成商名称标准（手工填写） 记录出现故障的配置项代码（手工填写） 记录由事件引发问题时，关联的问题单号（手工填写） 记录由事件引发变更时，关联的变更单号（手工填写） 2.6.2 事件性质

事件性质定义为如下五类事件：

编号 1 代码 客户投诉 描述 与业务支撑系统相关的用户投诉，如1860、营业厅等面向客户的业务受理部门转来的因支撑系统问题引发的客户投诉 指因业务支撑系统错误或反映支撑系统部分或全部功能不能正常使用的报障 监控管理平台上报的影响系统正常使用的告警 2 系统故障 3 4 5 业务可用性告警 平台告警 服务咨询 业务服务管理平台上报的用户体验和业务影响告警 监控平台自动产生的没有影响到系统正常使用的告警 指对系统操作、业务流程等方面的求助和询问 2.6.3 事件来源

事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种： 编号 1 2 3 4 5 代码 用户报告 自助开单 自动转单 内部开单 监控告警 描述 用户或地市维护人员通过电话/邮件/传真报告的事件，服务台人员手工创建事件单 地市等IT用户通过服务台自助系统直接提交的事件 通过客服系统自动转发的事件 省公司业务支撑部门内部提交的事件 监控工具自动转发过来的事件 2.6.4 所属系统类型

定义业务系统。当事件发生时，应该由服务台初步定位是哪个系统及子类出现问题，由一、二线进行进一步的明确。

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

业务系统 子类 营销管理 渠道管理 客户服务 产品管理 客户管理 订单与服务请求管理 服务开通 资源管理 综合采集 融合计费 综合帐务 综合结算 合作伙伴管理 基础功能 统计报表 一级BOSS 其它 BOSS系统 客服系统 经营分析 容灾系统 BOMC 其它系统 2.6.5 事件分类

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

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

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

表5． 事件分类

类别 子类 小型机 PC服务器 路由器 系统硬件 网络交换机 磁盘阵列 存储光纤交换机 磁带库 安全设备 操作系统 数据库 中间件 系统软件 集群软件 备份软件 系统管理软件 条目 安全软件 进程 数据 应用软件 参数 代码 接口 排队机 客服设备 CTI服务器 CCS IVR服务器 UPS 配套设施 空调 其它 2.6.6 事件优先级

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

编号 优先级代码 描述 编号 优先级代码 描述 BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为全省或至少包括一个关键地市 客服系统的电话呼叫中心业务不可用，影响面为全省或至少包括一个关键地市 因系统原因数据处理错误，导致大量用户投诉 来自新闻媒体、消费者协会、国家行政机关（工商、物价等）的反映或申告 部分重要数据丢失，且无法全部恢复 BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为一个或多个非关键地市 BOSS系统中综合采集、融合计费、产品管理、资源管理、一级BOSS、营销管理、渠道管理、合作伙伴管理、综合结算、系统管理、统计报表任一业务不可用，影响面为全省或至少包括一个关键地市 客服系统的电话呼叫中心业务不可用，影响面为一个或多个非关键地市 客服系统中互联网呼叫中心、短信呼叫中心、工单管理、知识管理、人力资源、质量管理、数据统计分析任一业务不可用，影响面为全省或至少包括一个关键地市 经分系统的通用分析不可用，影响面为全省 容灾系统的BOSS数据保护不可用，影响面为全省 BOMC系统的服务管理或监控管理不可用，影响面为全省 用户在营业现场反应激烈 监控管理平台严重告警 一般性系统故障 监控管理平台主要告警 一般单个用户申告 业务咨询 监控管理平台一般告警 1 紧急 2 高 3 中 4 低 当故障发生时，为了在判断优先级时增强实际可操作性，可以根据故障的影响范围和业务系统的关键程度在优先级映射表中定位优先级。故障的影响范围可以根据配置项中定义的‘影响范围’和用户报障描述来确定。

系影响范围 统 客户服务、客户管理、服务开通、综合帐务、订单管理 综合采集、融合计费、产品管理、资源管理、一级BOSS 营销管理、渠道管理、合作伙伴管理、综合结算、系统管理、统计报表 电话呼叫中心 互联网呼叫中心、短信呼叫中心、工单管理、知识管理、人力资源、质量管理、数据统计分析 通用分析 专题分析 BOSS数据保护 容灾系统 BOMC BOSS业务接管、BOSS资源复用 服务管理、监控管理 全省 紧急 高 高 紧急 高 高 至少包括一个关键地市 紧急 高 高 紧急 高 全省多个非关键地市 高 一个非关键地市 高 BOSS （任意一个模块） 高 高 客服系统 （任意一个模块） 经营分析 高 高 高 注：

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

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

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

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

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

事件优先级对应的事件响应时限和解决时限参考下表（以下时间是24×7工作时间）： 编号 1 2 3 4 优先级代码 紧急 高 中 低 响应时限要求 30分钟 1小时 4小时 8小时 解决时限要求 4小时 8小时 48小时 96小时 注：各省根据自己的业务需要可以修改优先级对应的响应时限和解决时限，但应该小于这个范围，并且定义的时候应该考虑事件影响度的定义。

2.6.8 事件影响度

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

定义事件影响度等级的因素有： 是否影响了核心业务 所影响的用户数

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

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

事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。 编号 1 影响度代码 重大 事件性质 描述 全省半数以上地市或关键地市的融合计费业务中断超过6小时 全省半数以上地市或关键地市的营业、综合帐务、客服中任一业务中断超过3小时 全省半数以上地市或关键地市的综合结算业务处理中断超过24小时 故障 编号 影响度代码 事件性质 描述 半数以下地市全业务中断超过6小时 申告 故障 2 严重 申告 故障 申告 告警 咨询 3 4 一般 无 对移动公司造成巨大损失产生严重后果和不良影响的 来自新闻媒体、消费者协会、国家行政机关的反映或申告 全省半数以上地市或关键地市的融合计费业务中断大于10分钟、小于6小时 全省半数以上地市或关键地市的营业、综合帐务、客服等业务中断均大于10分钟、小于3小时 全省半数以上地市或关键地市的综合结算业务处理中断大于2小时、小于24小时 半数以下地市全业务中断大于10分钟、小于6小时 局数据错误导致产生大量的错单 涉及到高额问题的申告 用户在营业现场反映激烈 系统内局部出现问题，不影响整个系统运行，不影响业务处理的故障 不属于重大申告和严重申告的用户申述 不影响系统的监控平台告警 一般数据查询或者使用指导 注：各省根据自己业务情况扩展或修改本表格的描述，对于重大级别的事件，应严格按照集团公司的定义。

2.6.9 事件状态

事件状态代码表明事件所处的处理状态，事件状态如下： 编号 1 2 3 4 5 6 7 8 9 10 代码 已登记 分配到服务台 分配到一线 分配到二线 分配到三线 一线处理中 二线处理中 三线处理中 已解决 关闭 新开事件记录或事件已创建 事件已分配给服务台人员 描述 事件已分配到一线支持，一线还未响应 事件已分配到二线支持，二线还未响应 事件已分配到三线支持，三线还未响应 一线支持人员已接手处理事件 二线支持人员已接手处理事件 三线支持人员（厂商）已接手处理事件 事件已解决，支持人员联系用户验证事件是否获得解决 事件已关闭 2.6.10 事件结束代码

事件结束代码说明了事件是在何种情况下关闭的，结束代码如下： 编号 1 2 代码 成功解决 变通方法解决 事件获得成功解决 描述 事件已通过变通方法或者临时措施获得解决，但是需要进行更进一步的根源分析 编号 3 4 5 6 代码 不成功 消失 误报 可忽略 事件自行消失 描述 事件没有获得解决（用户没有认可解决时使用） 不属于业务支撑部门管理范围的事件 如通过其它系统接口或监控系统提交的垃圾信息，经确认属于无效信息 2.6.11 事件解决人角色

事件解决人角色用来标明该事件单最终解决的角色是服务台、一线还是二线。 编号 1 2 3 4 代码 服务台 一线 二线 三线 服务台最终解决事件 一线支持最终解决事件 二线支持最终解决事件 三线支持最终解决事件 描述 2.6.12 处理是否超时

每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。 编号 1 2 代码 未超时 超时 未超时 事件已超出规定的解决时限 描述 2.6.13 故障厂商

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

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

2.7 流程概要设计

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

图12. 事件管理流程

事件管理概要设计流程说明 序号 步骤名称 责任人 说明 服务台对来自用户和系统自动产生的事件进行详细记录，主要包括来自IT基础架构的故障告警、来自客服和业务部门的客户投诉，也包括来自其它业务部门的服务请求 事件记录和分类 服务台 服务台负责在接收到事件后进行分类转发，对申告/告警/咨询/故障类事件进行分类转发 对于初步判断为紧急的事件马上升级到一/二线人员处理 对于非业务支撑维护职责范围的事件转给其它相关责任部门 初始支持 服务台 属于服务台技能范围内可以处理的事件，服务台应尝试解决，如果序号 步骤名称 责任人 说明 无法解决需及时升级到一/二线支持 不属于服务台职责范围的事件，立即分派到相应的一/二线支持 一线/二线支持人员在接受到由服务台派发的事件后，进行调查诊断，尝试解决 在必要时根据服务协议联系厂商帮助解决并负责核查 对于需要通过变更解决的事件提出变更申请，通过变更流程实施解 一线/二线尝试解决 一线支持/二线支持 决方案 事件解决后，在事件管理平台记录事件解决方案并更新事件状态 不能解决的事件，转三线尝试解决 指定时限内不能解决的事件，通告事件经理，由事件经理负责协调资源 三线尝试解决 三线支持 三线支持人员接受事件，进行调查诊断，提出解决方案 一线支持人员接受到来自服务台的紧急事件后，根据事件优先级别 紧急事件再确认 一线支持 二线支持 标准再次确认事件是否为紧急事件 如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理，转101紧急事件处理子流程 如不是，转一线尝试解决，开始正常事件解决流程 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方服务台 记录解决方案细节 一线支持 二线支持 案并更新事件信息 针对故障，一线/二线支持必须记录业务恢复时间 服务台与申报用户确认事件是否已得到解决，如果解决，事件以成服务台 关闭事件 一线支持 二线支持 功解决或变通方法解决而关闭；否则，事件以不成功关闭，重新开事件记录，并与原记录做关联，分派到原处理人员继续处理 服务台在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确 其它由一线或二线人员自行创建的事件单，则由开单人负责关闭 处理过程对后续工作有指导或参考的，录入知识库 负责监控所有未关闭的事件的处理状况，对接收到的超时告警应及 事件处理的监控 服务台 事件经理 事件经理 时关注 事件经理负责协调资源，保证事件的最终解决 事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流101 紧急事件处理流程 程 下表以事件管理概要图中的关键流程活动为主线，与事件管理概要设计中的其它重要内容进行了关联，以帮助各省业务支撑维护部门更好地理解流程设计内容。 序号 步骤名称 子流程和流程相关定义 参考”事件性质”、”执行原则 参考”所有权原则”，流程关联 事件记录和分类 事件来源”、”所属系统类型”、”事件分类” 、”事件优先级”、”事件影响度”、”事件状态”确定以上代码内容 服务台是该事件的负责人 参考”再分派原则”， 配置管理：关联相关配置项 选择合适的支持组或人员进行分派 参考”重复事件原(* 参见”流程关联原则”，下同) 初始支持 参考”事件状态”确定代码内容 则”，对重复事件进行标识 参考”升级原则”，及 时对事件进行升级 一线/二线尝试解决 参考”事件状态”，并 参考”重复事件原 问题管理：参考问题管理记及时修改 则”，对重复事件进行标识 录中的根本原因、变通方法 变更管理：参考近期变更管序号 步骤名称 子流程和流程相关定义 执行原则 参考”升级原则”，及流程关联 理记录 变更管理：必要时提出变更时对事件进行升级 参考”再分派原则”，转派事件单 请求，走变更管理流程，一般为紧急变更请求；在变更完成后继续事件处理 配置管理：通过配置管理查询配置项的属性和关联信息定位故障原因 问题管理：参考问题管理记录中的根本原因、变通方法 变更管理：参考近期变更管 参考”升级原则”，及理记录 变更管理：必要时提出变更 三线尝试解决 参考”事件状态”，并时对事件进行升级 参考”再分派原则”，及时修改 转派事件单 请求，走变更管理流程，一般为紧急变更请求；在变更完成后继续事件处理 配置管理：通过配置管理查询配置项的属性和关联信息定位故障原因 参考并再次确定”事件 紧急事件再确认 优先级” 参考”紧急变更子流 参考”升级原则”，及时对紧急事件升级 程” 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息 针对故障，一线/二线支 记录解决方案细节 持必须记录业务恢复时间 参考”事件状态”、” 事件影响度”，根据影响度的定义重新确认影响度代码，及时更新事件状态代码 参考”事件结束代 参考”关闭原则”，和 关闭事件 事件处理的监控 紧急事件处理子流程 码”、”事件解决人角色” 参考”事件的响应时限用户确认事件的解决和分配相应的结束代码 参考”升级原则” 和解决时限”，关注所有处理中的事件单 参考”紧急事件处理子 问题管理：优先级为紧急的101 流程” 事件解决完后，需要创建新的问题单 2.7.1 紧急事件处理子流程

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

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

加快紧急事件的响应和处理速度

对紧急情况中的人员及采取的行动加强管理 加强处理人员与用户之间的沟通和反馈 对紧急情况妥善处理

紧急事件处理的特殊性包括各系统应急处理预案的制定和使用，及时的集团上报等。

应急处理预案是事先制定的针对某种特定故障的处理措施，可以确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障。预案中的内容至少应涵盖应急预案启动条件、应急处理小组负责人和成员联系名单和联系方式、应急处理步骤、应急信息通报、应急善后处理、应急保障措施（人员、培训、演习、场地）等。

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

图13. 紧急事件处理流程

紧急事件处理流程说明如下： 序号 步骤名称 召集应急小组，协调应急会议 说明 事件经理主持应急会议，并组织讨论、协调各方资源，分析紧急事件处理方案，并将紧急事件情况通报省中心相关领导和集团公司 应急小组和相关厂商根据紧急事件现象和影响程度，判断是否需要启动相应系 判断是否属于应急预案中的事件 统的应急预案 如果没有应急预案，则进入组织相关厂商共同分析紧急事件，制定处理方案并处理 如果有应急预案，则进入按照应急预案处理 按照应急预案处理 组织相关厂商共同分析，制定处理方案并处理 根据各系统制定的应急预案中的实施步骤，处理紧急事件 应急小组负责组织相关厂商共同分析紧急事件，制定相应的处理方案，如果需要集团中心介入处理，则向集团中心申请介入 处理方案在实施前应得到应急小组和相关领导的认可 事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧 急变更管理流程的定义和要求，提出紧急变更请求 在紧急事件处理方案实施后，应急小组、相关厂商和相关部门对紧急事件是否解除进行确认 紧急事件解除确认 紧急事件如果没有解除，则重新进入组织相关厂商共同分析紧急事件，制定处理方案并处理； 如果解除，则进入紧急事件善后处理和总结分析 紧急事件解除后，应急小组向申告方、公司相关领导简要报告紧急事件处理过程，解决方法，事件解除时间，业务恢复情况，并将该信息汇报到集团公司 善后处理和通报 对于影响度为重大的紧急事件，必须通过服务管理平台提交《重大事件报告》，报告内容和提交方式见集团、省公司两级交互 紧急事件的处理人需要创建一个新问题，将紧急事件处理过程的详细信息记录到问题单中，提交到问题经理，由问题经理组织相关专家进行问题根源的分析 2.7.2 客户投诉处理子流程

客户投诉处理是各省事件管理的重要组成部分，也是本期规范要求各省落实的重点之一。客户投诉处理的特殊性在于与客服系统的接口、和市场部对客户投诉处理的管理要求。

绝大多数客户投诉来自客服系统，各省均有专人专职负责客户投诉的受理处理和监督分析。由于业务量大，与客服系统的接口实现成为客户投诉能够在本系统记录和流转的必要条件。

图14. 客户投诉处理流程

客户投诉管理流程说明： 序号 步骤名称 事件记录和分类 初始支持 一线/二线尝试解决 三线尝试解决 记录解决方案细节 责任人 服务台 服务台 一线支持/二线支持 三线支持 服务台 一线支持 二线支持 服务台 说明 客服系统通过接口在本系统自动创建事件单 ”事件优先级”需由客服系统自动转换；”所属系统类型”、”事件分类”保持为空，客服系统中对应信息转变为字符串，保存在“事件描述”中；”事件标题”、”事件描述”需由客服系统填充 可启动”初步回复”接口，把当前的状态和初步解决方案传递给客服系统。 三线支持人员接受事件，进行调查诊断，提出解决方案 关闭事件 一线支持 二线支持 服务台 事件经理 事件关闭时，自动启动”回复”接口，把解决方案传递回客服系统。 按照市场部门对客户投诉的管理要求监督投诉处理过程 按市场部要求定期进行统计分析 事件处理的监控 固化流程的部分信息项由系统自动产生，从而降低重复录入信息，提高可用性。下表灰色背景字段表示固化字段。

序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 信息项 事件ID 请求人信息 登记时间 事件发生时间 业务恢复时间 事件性质 事件来源 事件优先级 事件标题 事件描述 事件解决人 事件状态 分配对象 事件日志 解决方案 事件结束代码 处理是否超时 实际开始时间 取固定值”客服系统” 说明 事件单流水号（系统自动产生） 缺省值等于登记时间 取固定值”客户投诉” 取固定值”自动转单” 由客服接口自动转换填写 由客服接口自动转换填写 由客服接口自动转换填写 序号 19 20 信息项 实际完成时间 关联客服系统单号 说明 记录客服系统中对应单号的索引，以便接口使用(自动记录) 2.8 关键角色、职责定义

事件管理流程主要分为以下角色：

2.8.1 事件经理

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

负责对事件的解决协调资源，保证故障的最终排除 确保和问题管理流程经理的有效合作

确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题

2.8.2 服务台人员

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

职责：

负责24×7的值班和系统监控

响应客户投诉工单、热线电话、邮件、传真等事件报告

完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等

为事件进行适当的分类、为事件分配优先级等属性 尝试使用工具、初步诊断、分析相关信息等方式解决问题 将事件分配给最合适的一线支持小组/人员来处理

检查事件记录的处理进度，保持与事件报告人的联系，适时通知事件处理进展 与用户确认事件解决方案，关闭事件

2.8.3 一、二线支持人员

在ITIL体系中，一线支持人员负责对服务台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。二线支持人员是相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。

部分省份实际情况中，技术人员按照所维护的应用、系统进行分工，如：网络支持、主机支持、应用支持等，除作为服务台的值班人员以外，没有统一、单独的一线支持机构。这种情况下各技术人员可以统称为一、二线人员，不用明确区分。

职责:

验证事件的描述和信息，进一步收集相关信息

进行深入调查研究或协调厂商支持，提供有效的解决方案 实施事件解决方案

更新事件解决信息，已解决的事件转回服务台

2.8.4 三线支持人员

包括现场支持的应用开发厂商和远程支持设备厂商。 职责:

必要时提供现场支持和深入调查研究，提供有效的解决方案 参与解决方案的实施

如果允许，更新事件解决信息，把事件单转回一、二线

2.9 关键流程衡量指标

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

表6． 事件管理KPI指标

序号 衡量指标 1. 2. 3. 2 事件成功关闭的数量/比率 指标计算说明 数量：在事件单中根据以下条件过滤 【重复事件标记】为空 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 【事件发生时间】在统计周期内 1 事件总数 数量：在事件总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’ 比率：数量 / 事件总数 × 100 % 数量：在事件总数中过滤【处理是否超时】＝‘未超时’and 【事件结束代码】＝‘成功解决’or‘变通方法解决’ 比率：数量/事件总数 × 100 % 数量：在事件总数中过滤（【实际开始时间】－【登记时间】）< 优先级对应的响应时限 比率：数量/事件总数 × 100 % 完成的事件：在事件总数中过滤所有【事件状态】＝‘已解决’or ‘关闭’的事件 平均解决时间：累加完成事件的（【实际完成时间】－【登记时间】）/ 完成的事件数量 数量：在事件总数中过滤所有【事件解决人角色】＝‘一线’ 比率：数量 / 事件总数 × 100 % 数量：在事件总数中过滤【处理已超时】＝‘超时’and 【事件状态】！＝‘关闭’or ‘已解决’ 数量1：在事件总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’ 数量2：在事件总数中过滤【事件结束代码】＝‘不成功’ 3 规定时间内解决的事件数量/百分比 规定时间内响应的事件数量/百分比 4 5 平均解决时间 6 7 一线解决率 超时未解决的事件数量 8 事件的一次解决率 序号 衡量指标 指标计算说明 比率：（数量1－数量2 ） / 数量1 × 100 % 完成的事件：在事件总数中过滤所有【事件状态】＝‘已解决’or ‘关闭’的事件 【中断时长】分别对应到融合计费、综合帐务、客户服业务系统的子类，进行分类统计 投诉总数：在事件总数中过滤所有【事件来源】＝‘客服转单’ 响应时间：【事件状态】变为’xx线处理中’的时间与建单时间的差值 数量：在投诉总数中过滤所有’响应时间 < 预定值’ 比率：数量 / 投诉总数 × 100 % 投诉总数：在事件总数中过滤所有【事件来源】＝‘客服转单’ 处理时间：【事件状态】变为’已解决’的时间与建单时间的差值 数量：在投诉总数中过滤所有’解决时间 < 预定值’ 比率：数量 / 投诉总数 × 100 % 9 计划外业务中断时长 10 客户投诉响应及时率 11 客户投诉处理及时率 2.10 集团、省公司两级交互

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

上报方式 触发条件 事件状态进入一线处理中，并得到一线支持的确认 处理中的事件信息项发生改变 服务管理平台 事件状态转入已解决 事件状态转入关闭 （如果影响度为重大，必须有重大事件报告做为附件） 所有事件信息项 事件信息项 所有事件信息项 所有事件信息项 所有事件信息项 上报内容 附件内容 N/A N/A N/A 《重大事件报告》内容包含： 包括事件的发生时间、事件现象、影响的主要系统、影响度、处理过程、解决方法、业务恢复时间等 2.11 省公司上报报表

参见附件D中事件管理上报报表章节。

2.12 实施指导

2.12.1 流程图、流程角色定义与映射

各省在细化时，一二线支持可以根据实际情况合并，可以增加省公司管理层等角色以及相关的流程活动描述

各省在进行流程角色映射时，可以根据实际情况设置多个事件经理，建议由各职能部门经理分别承担

各省在对进行流程角色映射时，服务台建议映射为值班组和投诉受理组 建议业务支撑中心统一对外部门服务热线电话，并在全公司范围内宣传

2.12.2 流程衡量指标和报表

各省在细化时，可以扩充流程衡量指标

各省在细化时，可以自定义省内使用的流程报表内容、计算方法和生成频度

2.12.3 事件信息项

各省在细化时可以增加新的信息项，但概要设计中已经定义的信息项不能修改和删除，对信息项的描述可以扩充说明，但不能违反现有描述 集团、省公司两级交互时不传递省内新增的事件信息项

2.12.4 流程相关定义

定义 事件性质 事件来源 章节号 2.6.2 2.6.3 细化原则 不能增加、修改或删除代码 不能增加、修改或删除代码 注：各省在细化设计时不能修改此表中现有定义，第一层业务系统和第二层子类不能修改和扩充(注：第一层为”其它系统”的话，对应的子类可以扩充)，但可以有选择的基于第二层子类定义扩充进行第三层条目的细化。 各省根据自己的业务需要可以在此基础上扩充子类，但不能修改或删除已经定义的类别和子类 其它说明 对各代码的描述可以扩充说明，但不能违反现有描述 所属系统类型 2.6.4 各省在细化时，对没有覆盖到的业务系统用”其它系统”表示，子类中没有覆盖到的业务用”其它”表示 各省可以在此表的基础上扩展子类和自定义条目，针对一个子类，可以定义多个条目 例如：对于小型机的条目，可以按照品牌细分或按照故障原因（配置参数、性能、硬件…） 如果某些业务模块没有反映在优先级映射表中，各省可以根据实际需要添加。 事件分类 2.6.5 事件优先级 2.6.6 不能增加、修改或删除优先级别代码，但每个优先级别对应的描述内容可以扩充 优先级映射表中已经定义的级别，各省在细化时只可以扩充不能减少。 优先级映射表中为空的字段，各省在细化流程中自行定义 事件响应时限和解决时限 2.6.7 各省根据自己的业务需要可以修改优先级对应的响应时限和解决时限，但应该小于这个范围 在省公司上报报表中需按概要设计中定义的标准进行相关数据统计和上报 对于影响度为重大的定义应严格按照集团公司的定义。 特别需要考虑的是：所有优先级为紧急而且影响度为重大的事件，在解决后需要将《重大事件报告》上报集团公司，各省在这个原则的基础上酌情考虑如何扩充和修改 各省在细化时，如果增加了角色定义，可以考虑对状态进行扩充，以反映该角色的处理动作 事件影响度 2.6.8 不能增加、修改或删除影响度代码，但每个影响度代码对应的描述内容可以扩充 事件状态 事件结束代码 处理是否超时 故障厂商 2.6.9 可以扩充 2.6.10 不能增加、修改或删除代码 2.6.11 不能增加、修改或删除代码 2.6.12 各省根据自己的业务需要可以在此基 定义 章节号 础上修改 细化原则 其它说明 2.13 本期规范的主要变化

与一期规范定义的事件管理流程相比，本期规范的主要变化包括：

明确把客户投诉处理作为重点之一纳入事件管理流程，细化客服系统接口业务要求，形成“客户投诉处理子流程”。

优化事件管理角色职责，明确把厂商作为三线支持纳入流程，并明确建议现场维护厂商直接使用本系统；修正一线支持和二线支持映射原则，明确建议可按实际工作分工归并映射到相同员工；归并和简化角色的职责。

3 问题管理流程概要设计

3.1 流程目的

事件管理主要是被动应付突发事件和故障，故障消除、业务恢复后事件管理应结束。如需进行进一步分析，找出故障深层原因和根本解决方案，通过变更请求(RFC)、变通方法或建议的预防性措施来防止同类故障的再次发生，应启动问题管理流程。

问题管理流程的根本目的是消除或减少生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的IT环境，提高IT服务的可用性。其目的包括：

分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生 提高IT服务的可靠性，降低IT支持成本

3.2 流程主要内容

问题管理流程着重于消除事件或减少事件发生，确定事件的根本原因。主要活动包括分析事件、找出问题、分派问题、确定根本原因以及找出解决方案、回顾及关闭，以消除事件或在其发生时降低对用户或业务的影响。其主要内容如下：

分析事件

定期分析事件，找出潜在问题。 生成问题记录

在系统中生成问题记录并把所有相关事件与此记录关联起来 分派

根据问题内容将问题记录分派给适当的技术小组。 根本原因分析

被分派的小组人员将调查问题以期找出其原因，提出解决方案、变通方法或预防性措施，以消除产生原因，或在重发时使其影响力最小化。 记录必须被更新以反映它是已定位原因状态，并且把任何变通方法、避免或最小化负面影响的动作行为也记录下来。

开发、确认、提出实施解决方案

对问题的解决方案进行评估、测试，提出变更请求（RFC）或实施具体的解决方案。 回顾及关闭

对问题的解决方案进行回顾，确认解决方案达到了预期的效果。 确认问题的信息记录填写完整，提交知识库，并关闭问题记录。

3.3 与其他流程的关系

和事件管理的关联

事件在恢复服务后仍需后续分析处理的，应结束事件单，创建问题单（问题单必须和事件单建立关联） 和变更管理的关联

问题处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和问题单建立关联），变更完成后，继续问题单的处理 和配置管理的关联

问题处理过程中，可以通过配置管理查询相关的配置项信息

问题处理过程中，如果可以将根本原因定位到某个配置项，则必须将问题单与该配置项关联 和知识管理的关联

问题处理完成后，均应整理提交到知识库中(问题单必须和知识单建立关联)，以便在省内和全国共享

3.4 流程范围

问题管理流程的范围是对BOSS系统、经营分析系统、容灾系统和BOMC的IT生产环境中发生的问题进行管理，以采取主动性预防措施来降低事件数量。

不包括：

处于开发或测试环境的系统和应用

3.5 流程执行原则

3.5.1 常规原则

问题管理流程应与事件管理流程相对，事件处理过程中故障消除、业务恢复后如需后续分析处理，应转问题管理流程

问题经理建议由系统和业务部门领导分别担任

应该每半年对问题管理流程的流程关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾，以改进和优化流程

应该每月定期回顾和产生问题管理报表，对没有解决的问题，应该举行定期的问题管理会议对这些问题进行评估

3.5.2 所有权原则

所有权原则用来确保每个问题在任何时段都有适当的人员负责，问题经理是每个问题的负责人。下表是各角色在各环节中承担不同责任的RACI模型。

表7． 问题管理RACI模型

问题确定与记录 问题确认与分派 分析并诊断问题/提供变通方法 开发、确认、实施解决方案 问题监控 问题回顾与关闭 问题经理 (主管) A A/R C/I C/I A R 问题处理专家 (员工) R C/I A/R A/R R A 问题处理厂商 (厂商) R/C I R/C R/C I C RACI模型说明 A: 负全责; R: 有义务; C: 提建议; I: 需知会 3.5.3 创建原则

事件在恢复服务后仍需后续分析处理的，应结束事件单，创建问题单 维护中发现的潜在故障，尚未影响业务的，应建立问题单。

工作分析会落实的潜在故障分析任务，应建立问题单。工作分析会应包括对所处理事件历史记录的趋势分析

3.5.4 退回和转派原则

事件处理专家或厂商认为问题分派错误时，可退回事件经理，由其进行再分派(转派)。为确保问题单不被过于频繁的相互转派、以至于无法在规定时间内得到解决，应当尽量减少问题单再分派的几率，一个问题单再分派的次数不应该超过两次。

3.5.5 重复问题原则

重复问题是指经过分析之后，根本原因相同的问题。例如：问题处理专家提出了几个问题，但是经过分析之后，发现这几个问题的根本原因是相同的，这几个问题就可以定义为重复问题。对于重复问题需要进行标志，将相关问题记录进行关联，当问题解决时同时进行回顾。

3.5.6 问题关闭原则

通常，问题单在实施了解决方案之后，需要经过一段时间的回顾，由问题处理专家和问题经理一起来回顾解决方案是否达到了预期的效果，如果成功的实施，由问题处理专家或问题经理确认问题信息记录完整，关闭问题。

问题关闭时必须整理经验，提交知识库。

3.5.7 问题单重开原则

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

3.6 流程相关定义

3.6.1 问题信息项

问题单包含如下信息项：

表8． 问题信息项

序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 27 28 29 30 信息项 问题ID 请求人信息 登记时间 地点 问题来源 问题优先级 所属系统类型 问题分类 问题标题 问题描述 问题拒绝原因 变通方法 问题原因 重复问题标记 问题状态 问题经理 问题处理专家 厂商人员 问题日志 实际开始诊断时间 实际诊断结束时间 解决方案 问题结束代码 问题无法解决原因 关联配置项 关联的事件单号 关联的变更单号 关联的知识号 问题关闭时间 描述 为每个问题分配一个唯一的序列号（系统自动产生） 问题请求人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写） 生成问题记录的时间（系统自动产生） 记录问题发生的地点（手工填写） 参见“问题来源”定义 参见“问题优先级”定义 参见“所属系统类型”定义 参见“问题分类”定义 简单描述问题（手工填写） 详细描述问题内容（手工填写） 详细描述拒绝问题原因，并推荐其他专家或专家组（手工填写） 详细记录问题的变通方法 详细记录问题产生的根本原因（手工填写） 标记为重复问题，用已有标题号标注（手工填写） 参见“问题状态”定义 该问题对应的问题经理 负责该问题的问题处理专家 负责该问题的厂商人员 反映问题处理过程中问题信息项的变化历史，包括分配的人员，状态等信息（系统自动产生） 问题状态更新为“分析中”的时间（手工填写） 问题状态更新为“已有解决方案”的时间（手工填写） 问题解决方案的详细描述（手工填写） 参见“问题结束代码”定义 解释问题无法解决的原因（手工填写） 记录问题的配置项代码（手工填写） 记录引发该问题的事件单号（手工填写） 记录由问题发变更时，关联的变更单号（手工填写） 记录问题对应的知识单号(系统自动填写) 当问题状态更新为“结束并关闭“的时间（手工填写） 3.6.2 问题来源

根据问题的不同来源对问题分类如下：

编号 代码 描述 事件恢复服务后提出的问题，以便进行事件的根本原因分析。业务恢复后，相应事件应结束关闭，以免影响事件处理时长。如果事件对应的潜在故障原因后后续规避措施仍需继续研究，应启动问题管理流程，创建问题单。 1 事件研究 例如：某日发生了一起集群无法切换的事件，导致某台主机发生故障后，没有切换到备用主机中去，从而影响了业务，事件处理人员在采取了手工切换的替代措施后，恢复了服务。为了分析为什么会发生该事件，以及查看其他的集群是否也存在类似的问题，此时可以提出一个问题记录，以便对该事件进行研究分析。 技术专家在日常维护工作中提出的问题。日常维护中发现的潜在故障如果没有影响到业务，应启动问题管理流程，创建问题单。 2 维护提出 例如：维护专家在日常维护中发现，目前的数据库版本可能会存在着死锁、心跳不一致等方面的问题，此时就可以提出一个问题记录，以便研究分析，避免日后发生故障。 分析事件记录找出的问题。常规的工作分析会上确定的、需要深入研究的任务落实到维护专家后，应启动问题管理流程，创建问题单。 3 趋势分析 例如：在定期的会议中，对计费类的事件进行分析后发现，上周该类型的事件比平常的时候多了30％，超过了规定的阀值，这表明计费系统有可能存在着一些潜在的隐患，此时就可以提出一个问题记录，以找出问题的原因并解决。 3.6.3 问题优先级

问题的优先级是问题处理专家解决问题的参照标准，对于关键优先级的问题，管理层应该优先协调资源进行这些问题的解决。结合中国移动的实际情况，问题的优先级定义如下：

编号 代码 从如下方面考虑，问题是否： 描述 影响到关键业务（如：综合帐务、定单管理、电话呼叫中心等） 影响范围极大（如：一个关键地区或半数以上非关键地区） 紧迫程度最高（如：必须马上着手处理） 问题处理后可大幅节省投资、人力，有效提高服务质量和维护效率 影响到较关键业务（如：综合采集、融合计费、产品管理等） 影响范围较大（如：一个以上非关键地区） 紧迫程度较高 问题处理后可有效节省投资、人力，一定程度提高维护质量 影响到非关键业务 有一定影响范围 问题处理后对维护质量和效率的提升有限 1 关键 从如下方面考虑，问题是否： 2 重要 从如下方面考虑，问题是否： 3 普通 3.6.4 问题状态

为了记录问题处理的生命周期，需要设置不同的状态加以描述，如下所示：

编号 1 2 3 4 5 6 代码 已登记 分析中 已定位原因 已有解决方案 已提出变更请求 已回顾 问题登录到系统中 描述 问题处理专家正在分析问题过程中 问题根本原因已找出 解决方案已找到 已提交变更请求（RFC） 已经对问题进行了回顾 7 结束并关闭 问题结束 3.6.5 所属系统类型

请参照事件管理”2.6.4 所属系统类型”。

3.6.6 问题分类

问题分类与事件分类相同，请参照事件管理”2.6.5 事件分类”。

3.6.7 问题结束代码

为了表明问题的不同解决方式，定义如下结束代码：

编号 1 2 3 4 代码 根本解决 变通方法 无法解决 取消 描述 找出问题的根本原因，并得到解决方案，成功解决 没有根本解决方案或目前没有办法实施根本解决方案，但有临时解决方案作为变通方法 未找到问题的根本原因，没有解决方案，或目前无法实施解决方案，也无变通方法 问题被问题经理拒绝 3.7 流程概要设计

问题管理概要设计流程图如下：

图15. 问题管理流程

问题管理概要流程描述如下： 序号 步骤名称 责任人 录，并对问题信息进行描述 问题处理专家创建的问题，如果需要，应提交给问题经理确认；否则应说明 对事件研究、维护提出以及趋势分析发现的潜在问题，在系统中进行记 问题确定与记录 问题处理专家/问题经理 抄送问题经理备案 问题经理创建的问题，可与环节合并，直接分派给问题处理专家 问题处理专家提交上来的问题，问题经理应对其进行审核确认，确定问 问题确认与分派 问题处理专家/问题经理 题是否需要继续处理。如果问题确认无效，则关闭问题，并通知请求者 问题经理创建或审核的问题，分派给相应问题处理专家；问题处理专家创建的问题，可以自行处理或分派给现场厂商 问题处理专家/厂商接受问题，更新问题状态及实际开始诊断时间 如需其他问题处理专家协助分析、诊断，则通知问题经理，由问题经理 分析并诊断问题/提供变通方法 问题处理专家/ 厂商 协调资源，成立问题分析小组，举行问题根本原因分析研讨会议，并确定问题的潜在原因，提供或更新问题变通方法，以降低问题在根本解决前对业务产生的影响 将问题产生根本原因及变通方法及时更新到问题记录中 将问题根本原因及变通方法通知问题经理 如果预计无法找到问题的根本原因，及时通报问题经理 开发、确认、实施解决方案 问题处理专家/ 厂商 对于已经找到根本原因的问题，需要确定解决方案，以便永久的解决 问题处理专家或厂商推荐并测试根本性解决方案，并确保这些方案彻底解决问题，更新问题记录中的实际诊断结束时间 问题处理专家判断实施上述解决方案/变通方法是否需要通过其他流程（如变更流程等） 如需要，提交到相应的流程，并和该流程人员保持沟通，了解问题的解决状况； 如不需要变更，计划并组织实施解决方案以解决问题。 如果需要第三方介入，则问题处理专家负责与第三方的接口与协调 如果问题处理专家预计在无法找到根本解决方案或虽有解决方案但目前无法实施（如实施的代价太大），通报问题经理 问题经理和问题处理专家负责问题分析、诊断、解决过程中的跟踪和监控： 问题监控 问题经理/ 问题处理专家 在问题找到根本原因或解决方案之后，根据需要，向服务台或问题请求人员通报该问题的解决情况，以帮助和提高事件的解决率 对于问题处理专家认为无法找到根本原因或虽有解决方案，但目前无法实施（如实施的代价太大等），问题经理协调问题处理专家进行分析判断，决定该问题是继续诊断、解决还是关闭该问题 问题处理专家和问题经理对问题进行回顾，确认问题是否被正确的解 问题回顾 问题经理/ 问题处理专家 决，如果没有解决，转到分析并诊断问题/提供变通方法 整理问题处理经验，提交到知识管理系统。 问题经理认为值得他省借鉴的问题解决经验，通过省部上传到集团，实现全国范围经验共享 问题关闭 问题处理专家 对问题记录的信息项进行总结，更新问题记录并关闭问题 下表以问题管理理概要图中的关键流程活动为主线，与问题管理概要设计中的其它重要内容进行了关联，以帮助各省业务支撑维护部门更好地理解流程设计内容。 序号 步骤名称 流程相关定义 填写”请求人信执行原则 流程关联 问题识别与记录 息”、”地点”、”问题标题”、”问题描述”各项 确定”问题来 参考”创建原则” 参考”问题单重开原 配置管理：关联相关配置则” 参考”问题单重开原项 事件管理：事件处理后，源”、”所属系统类型”、”问题分类” 、”问题优先级” 确认”问题来则” 创建问题 问题确认与分派 源”、”所属系统类型”、”问题分类” 、”问题优先级” 填写” 问题经 参考”重复问题原则”，对重复问题进行标识 参考”退回和转派原 理”、 ”问题处理专家”、 ”厂商人员” 分析并诊断问题/提供变通方法 填写\"变通方法\"、\"问则”，对问题进行分配 参考”退回和转派原 题原因\"、\"实际开始诊断时间\"、\"实际诊断结束时间\"各项 则”，对问题进行退回 参考”重复问题原 配置管理：查询相关的配则”，对重复问题进行标识 置项信息 变更管理：必要时提出变 开发、确认、实施解决方案 问题监控 更新” 解决方案”等项 参考”问题状态” 更请求，走变更管理流程，在变更完成后继续问题处理 事件管理：需要时及时将 参考”所有权原则”，序号 步骤名称 流程相关定义 执行原则 对问题处理过程进行监控 流程关联 问题的根本原因/变通方案/解决方案通报事件流程 知识管理：总结经验，提 问题回顾与关闭 填写”问题结束代码”、”问题无法解决原因”等项 参考”问题关闭原则”对问题进行总结关闭 交知识 3.8 关键角色、职责定义

问题管理流程主要包括问题经理、问题处理专家和厂商三个角色。

3.8.1 问题经理

问题经理负责协调日常的问题管理工作，包括对问题的审核、监控、所需资源的协调、定期产生报表等。问题经理通常由系统和业务部门主管领导分别担任。

职责:

定期组织相关人员对事件记录进行分析，发现潜在问题 确认、审核和监视问题处理过程 必要时协调所需资源

3.8.2 问题处理专家

问题处理专家通常由各专业组技术人员承担，负责协调、监督厂商进行问题诊断及解决，有时也会自行承担问题的诊断和解决。

职责：

根据事件处理和日常维护要求创建问题，启动问题管理流程 协调、监督厂商进行问题诊断、确定解决方案 自行进行问题诊断，确定解决方案 回顾问题、整理解决方案并提交知识库

3.8.3 问题处理厂商

厂商包括现场支持厂商和远程支持厂商，负责问题的诊断及解决工作。 职责：

应问题处理专家要求，进行问题诊断，提供解决方案

3.9 关键流程衡量指标

为了较好地控制问题管理流程的质量，必须为问题管理流程设置考核指标，通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。

问题管理流程的关键衡量指标如下：

表9． 问题管理KPI指标

序号 1 问题总数 衡量指标 指标计算说明 数量：在问题单中根据以下条件过滤， 1. 【重复问题标记】为空 2. 【问题结束代码】不等于‘取消’ 3. 【登记时间】在统计周期内 数量：在问题总数中，【问题状态】=‘已定位原因’ 的问题个数 数量：在问题总数中，【问题来源】=‘趋势分析’ 的问题个数 比率：数量 / 问题总数 × 100 % 数量：在关闭问题数量中，【问题结束代码】=‘变通方法’的问题个数 数量：在关闭问题数量中，【问题结束代码】=‘根本解决’的问题个数 比率：数量 /关闭问题数量 × 100 % 诊断完成问题数量：【实际诊断结束时间】在统计周期内的问题个数 平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量 2 3 5 已找到根本原因的问题数量 趋势分析问题所占比率 通过变通办法解决的问题数量 6 问题成功解决率 7 平均诊断时间 3.10 集团、省公司两级交互

问题处理需要较多智力资源，积累的经验具有较高价值。如果问题及解决方案对他省具有借鉴意义，问题处理专家应对解决方案进行加工整理、经问题经理审核确认后通过省部接口上传集团，形成全集团的知识，可以向其他省公司通报，在全国范围内共享，以提高各个省公司的支撑水平。

触发条件 问题关闭时 问题信息项 省份、所属系统类型、问题分类、问题标题、问题描述、解决方案、问题处理专家联系方式 3.11 省公司上报报表

参见附件D中问题管理上报报表章节。

3.12 实施指导

3.12.1 流程图、流程角色定义与映射

各省在进行流程角色映射时，问题经理建议由各技术负责人分别承担；问题处理专家由各专业技术人员分别担任；厂商包括现场维护厂商和远程支持厂商，建议现场维护厂商直接使用电子化系统记录问题处理情况，远程支持厂商的处理过程和结果由局方问题处理专家代为记录。

3.12.2 流程衡量指标和报表

各省在细化时，可以扩充流程衡量指标

各省在细化时，可以自定义省内使用的流程报表内容、计算方法和生成频度

3.12.3 问题信息项

各省在细化时可以增加新的信息项，但概要设计中已经定义的信息项不能修改和删除，对信息项的描述可以扩充说明，但不能违反现有描述 集团、省公司两级交互时不传递省内新增的问题信息项

3.12.4 流程相关定义

定义 问题来源 问题优先级 问题状态 章节号 4.6.2 4.6.3 4.6.4 细化原则 不能增加、修改或删除代码 不能增加、修改或删除问题优先级别代码，问题优先级对应的描述内容可以扩充 不能增加、修改或删除代码 注：各省在细化设计时不能修改此表中现有定义，第一层业务系统和第二层子类不能修改和扩充(注：第一层为”其它系统”的话，对应的子类可以扩充)，但可以有选择的基于第二层子类定义扩充进行第三层条目的细化。 不能修改或删除已经定义的类别和子类，各省在细化时，根据自己的业务需要可以在此基础上对子类进行扩充，并可针对每个子类定义多个条目 不能增加、修改或删除代码 其它说明 对代码的描述可以进行扩充 各省在细化时，对没有覆盖到的业务系统用”其它系统”表示，子类中没有覆盖到的业务用”其它”表示。 上报集团的问题统计报表，不对”其它系统”或”其它”进行统计 所属系统类型 4.6.5 问题分类 4.6.6 上报集团的问题统计报表，不对新增子类进行统计 问题结束代码 4.6.7 3.13 本期规范的主要变化

与一期规范定义的问题管理流程相比，本期规范的主要变化包括：

明确事件和问题的分界。事件处理业务恢复后如需进行进一步分析，应终止事件流程，启动问题管理流程。

归并、明确各角色职责，明确把厂商纳入问题管理流程，承担重要的问题分析解决任务 取消问题创建之初上传集团要求，问题解决后上传集团的目的修正为向他省共享经验。

4 配置管理流程概要设计

4.1 流程目的

配置管理流程的总体目的是提供一个统一、一致的流程来管理IT基础架构中的各个组成部份，以确保：

所有配置项被正确识别 配置项当前和历史状态得到记录 配置项记录的完整性得到维护和确认 IT生产环境的稳定性

确保IT设备的有效控制和管理

4.2 流程主要内容

配置管理流程着重于管理IT环境中所有必须控制的组成元素，并为其他相关流程(如事件管理等)提供相关信息，以使这些流程得到更有效的运行，从而保证IT环境的完整性和稳定性。其主要流程内容如下：

配置管理策略的制定

确定配置管理的范围，并确定CI类别、CI属性定义、CI关系类型和CI之间的关系等。 配置项定义和标识

定义CI的分类，识别物理环境中的CI并予以标识，确保只有被认可的和被标识的配置项才能接受和记录，同时识别配置项实体的关系，进行CI信息的收集。

CMDB初始化

根据CI分类以及识别结果，导入CI数据，初步建立CMDB。每次增加CI分类时，重复执行CMDB初始化动作。

CMDB的控制和维护

包括CMDB的新CI录入和日常监控维护，采用合适的控制权限以确保CI数据与实际环境保持一致。

定期审核和回顾

定期审核全部或部分CMDB数据，确认和物理环境的一致性，从而确保配置信息的完整性；定期回顾审核结果，找出改进机会，包括流程和CMDB。

定期生成配置管理报告

定期生成配置管理报告，为其他流程、配置管理回顾和领导提供管理报告。 定期向集团上报关键配置管理信息和统计报表

向集团上报关键配置项的详细信息和配置项的统计报表。

4.3 与其他流程的关系

与事件管理流程的关系

事件记录与CMDB中的配置项相关联，此外配置管理流程为事件管理提供配置项的具体信息。 与问题管理流程的关系

问题记录与CMDB中的配置项相关联，配置管理同时为问题管理的根本原因分析提供参考信息。 与变更管理流程的关系

变更管理与配置管理是紧密结合的，变更管理流程引发和控制对配置项的修改，此外配置管理为变更管理提供信息帮助变更的评估分析。

与发布管理流程的关系

配置管理通过定义CI间的关系和依赖性以及组件、服务功能和端到端服务的状态变化来帮助理解和评估发布测试对其它服务的影响。同时配置管理也提供产品版本的信息

4.4 流程范围

配置管理流程的范围是BOSS系统、经营分析系统、容灾系统和BOMC系统等IT生产环境下所包含的配置项（CI），包括生产环境的硬件、软件、文档、环境以及开发、测试环境中和备用的硬件以及系统软件，具体内容包括识别、控制、汇报和审核等行为。

不包括：

处于开发或测试环境中的应用软件

4.5 流程执行原则

4.5.1 常规原则

配置管理数据库将为所有IT运行及服务管理流程提供所需信息，特别是针对事件和变更管理流程；所有事件、问题、变更、发布流程触发后，均需要判断是否涉及到配置项信息的变化，如果涉及，则需要根据配置管理流程维护其信息和CMDB信息的一致性 所有配置项信息必须存储在一个数据库管理系统中 CMDB准确反映当前已知的IT架构状态

应该每半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进配置管理流程

4.5.2 所有权原则

所有权原则用来确保配置管理每类活动都有适当的人员负责。下表是配置管理中各角色在各活动中承担不同责任的RACI模型。

表10． 配置管理RACI模型

配置管理策略的制定 配置项定义和标识 CMDB初始化 CMDB控制和维护 CMDB审核和回顾 定期生成配置管理报告 集团 A C/I C/I I I I 实施厂商 C R R/C C C 配置经理 (指定人员) R/C A A R A A 配置管理员 (员工) C/I R R A R R RACI模型说明 A: 负全责; R: 有义务; C: 提建议; I: 需知会 4.5.3 流程关联原则

和变更管理的关联

变更主管在变更计划阶段必须制定配置项更新计划，对计划修改的配置项进行说明 变更实施完后，由变更主管汇总相应的配置项修改的情况，并通知相应的配置管理员，配置管理员接收到配置项修改请求后，与CI实体进行核对，核对无误后方可修改CI属性以及关系

对于风险等级为高和重大的变更，CAB中应该包括配置经理，以确保对CMDB的适当控制 CI应与变更记录建立关联，从而对CI的变化情况进行记录 和发布管理的关联

发布主管在制订发布计划阶段必须制定配置项更新计划，对计划修改的配置项进行说明 在发布实施完成且得到确认并关闭后，由变更主管汇总相应的配置项修改的情况，并通知相应的配置管理员，配置管理员接收到配置项修改请求后，与CI实体进行核对，核对无误后方可修改CI属性以及关系 和事件管理、问题管理的关联

CI应与事件记录、问题记录建立关联，从而确保对CI维护工作的统计和分析

4.5.4 控制原则

所有有关生产环境配置项的更改都需要通过变更管理流程进行控制

只有得到授权的人员（配置管理员）才能对CMDB中的配置项信息进行修改，修改之前需要对物理CI的属性进行核实

任何设备进机房前或系统投入使用前必须启动配置管理流程，以确保配置项信息与物理环境的一致

其他流程会引发对配置项的修改，日常使用中发现的配置项信息的不正确需要相应的修改，CMDB审核也会引发对配置项的修改，以上均需要通过变更管理流程的控制，发起配置项修改需求的人将作为变更请求者，通过变更管理流程进行相应的审批，实现对CI信息的修改控制（在变更结束阶段通知相关的配置管理员修改配置项）。

在CMDB建设的初期，由于数据仍然处于调整中，可以由配置经理定义一个时间段，该时间段内的数据调整可以不经过变更管理流程控制

当确认配置项信息不需要在CMDB中保留时，进行配置项的删除，配置项的删除不在CMDB中进行物理删除，通过删除状态属性来标识其被删除与否。

需要至少每季度通过计算配置项的“服务到期日期”来对配置项是否过保进行预警

4.5.5 审核原则

配置管理流程必须每半年对IT环境进行审核、跟踪监测，以保证CMDB的信息收集准确、完整，并与实际IT环境的状态高度统一。该工作由配置经理负责 应该定期根据变更的执行情况对变更引发的配置项的修改情况进行审核

4.6 流程相关定义

4.6.1 配置项种类

CMDB的层次按照三层设计，三层既保证CI可以被有效地分组，又可以保证层级不会过于复杂从而导致CMDB难以维护和管理。各省可以在此表基础上，自行扩充CMDB的层次结构和CI类别。

不同种类CI所具有的属性不同，具体定义参见附件A：CI属性设计。下表是本规范定义的配置项种类。

表11． 配置项种类

第一层 第二层 *小型机(EPS) *分区服务器(PRS) *PC服务器(ISS) *路由器(RUT) 系统硬件(HW) *网络交换机(SWT) *磁盘阵列(DKA) *存储光纤交换机(FST) *磁带库(TPL) 链路(LNK) 光盘库(OPL) 安全设备(SFD) 操作系统(OPS) *数据库(DBS) *中间件(MWR) 系统软件(SW) 集群软件(CLR) 存储备份软件(BKW) 系统管理软件(SMW) 工具软件(UTW) 安全软件(SFS) 排队机(ACD) 客服设备(CS) CTI(CTI) IVR(IVR) CCS(CCS) 第三层 第一层 配套设施(EF) UPS(UPS) 空调(ARC) 其它(OTS) 第二层 第三层 BOSS应用(BSA) 经营分析(BAY) 业务应用(AP) 容灾(DRY) BOMC(BOM) 客服应用(CSA) 其他应用(OTA) 文档(DC) 逻辑实体(LE) 手册(MAN) 合同(CTR) 进程(PRO) 中间件服务(MID) 数据库对象(DBO) IT人员(ITP) 其他信息(OT) 供应商(SUP) 机房(WKP) 关键地市(KCT) * 注: 星号标注的为关键CI。关键CI的日常维护和定期审核必须严格按照要求进行，必须保证关键CI的关键属性信息的准确性和时效性。在保证关键CI信息维护准确的前提下鼓励管理和维护非关键CI及非关键CI属性。

4.6.2 CI的通用属性

此处列举大部分CI均具有的属性、相关说明以及适用的CI类别：

表12． CI通用属性

属性名称 搜索代码 * 名称 * 系统名称 模块名称 子模块名称 说明 CI的唯一识别码，参见“搜索代码命名规则”定义（手工填写） CI的名称，参见”名称取值原则（手工填写） CI所属的系统名称，参见“配置项所属系统” 定义（手工填写） CI所属系统的模块名称，参见“配置项所属系统” 定义（手工填写） CI所属系统的子模块名称，参见“配置项所属系统” 定义（手工填写） 描述该CI失效后会影响到的范围，如果能够明确到地市，则需要注明地市名称；如果会影响全省业务，注明“全省”；如果仅对某一类型客户造成影响，则描述客户类型。CI的影响范围作为事件、问题和变更影响范围的判断依据之一（手工填写） CI所在的物理位置（手工填写） 使用该CI部门（手工填写） CI支持服务的服务合同开始日期YYYY-MM-DD（手工填写） CI支持服务的服务合同结束日期YYYY-MM-DD（手工填写） 适用CI类别 适用所有类别CI 适用所有类别CI 适用于除”其他信息”类之外的所有CI类别 适用于除”其他信息”类之外的所有CI类别 适用于除”其他信息”类之外的所有CI类别 * 影响范围 适用于除”其他信息”和”文档”类之外的所有CI类别 * 物理位置 使用部门 * 服务开始日期 * 服务到期日期 适用“硬件”、”客服设备”、”文档” 、”安全”类CI 适用于除”其他信息”类之外的所有CI类别I 适用于除”其他信息”和”文档”类之外的所有CI类别 适用于除”其他信息”和”文档”类之外的所有CI类别 * 服务级别 * 服务提供商 * 服务联系方式 审核状态 CI支持服务厂商提供的相应的服务级别（如5x8，7x24等）（手工填写） 为该CI提供服务的厂商名称（手工填写） CI支持服务厂商提供的支持服务的联系方式，密码等信息（手工填写） 配置审核活动中，CI的审核状态，参见“配置项审核” 定义（手工填写） 最近一次审核该CI的时间，即审核状态从”未审核”变为”已审核”/”不匹配”/”丢失”任一状态的时间；参见“配置审核” 定义YYYY-MM-DD hh:mm（系统自动产生） 该CI被创建的时间YYYY-MM-DD hh:mm（系统自动产生） 该CI是否被删除；正常/已删除，参见“配置项的删除状态” 定义（手工填写） 该CI被删除的时间，既删除状态从”正常”变为”已删除”的时间YYYY-MM-DD hh:mm（系统自动产生） 负责该CI实体的系统管理员（手工填写） 该CI的原始厂商（手工填写） 该CI的集成商（手工填写） 该CI的状态，参见“配置项状态” 定义（手工填写） 该CI的用途（手工填写） 该CI在服务管理平台中的管理人员，缺省为创建该CI的人员（系统自动产生） 最后更新该CI的人员（系统自动产生） 最后更新该CI的时间，既最后一次更新CI任一属性的时间；YYYY-MM-DD hh:mm（系统自动产生） 该配置项的其他描述信息（手工填写） 适用于除”其他信息”和”文档”类之外的所有CI类别 适用于除”其他信息”和”文档”类之外的所有CI类别 适用于除”其他信息”和”文档”类之外的所有CI类别 适用所有类别CI 最近审核时间 适用所有类别CI 创建时间 删除状态 删除时间 管理员 * 厂商 适用所有类别CI 适用所有类别CI 适用所有类别CI 适用于除”其他信息”类之外的所有CI类别 适用于除”其他信息”和”文档”类之外的所有CI类别 适用于”业务应用”类CI和”逻辑实体”类中的”进程”、”数据库对象”和”中间件服务”CI 适用所有类别CI 适用于除”其他信息”类之外的所有CI类别 适用所有类别CI 适用所有类别CI 适用所有类别CI 适用所有类别CI 集成商 * 状态 用途 CI管理员 最后更新人 最后更新时间 备注 * 注: 星号标注的为关键CI属性。关键CI的关键属性的日常维护和定期审核必须严格按照要求进行，必须保证关键CI的关键属性信息的准确性和时效性。在保证关键CI信息维护准确的前提下鼓励管理和维护非关键CI及非关键CI属性。

“搜索代码”命名规则 每个CI的搜索代码将作为CI的名称，在CMDB层次设计中，每个CI类均标注了简写，作为CI命名依据。例如：某一台小型机的命名为HW-EPS-ZZZ-123456。搜索代码的命名规则如下：

配置项的搜索代码组成共17位：XX-YYY-ZZZ-mmmmmm。其中XX-YYY-ZZZ是配置项种类的代码。

自行扩充CI时，CI简写（XX-YYY-ZZZ）要求为大写英文字母，mmmmmm为数字或小写字母。 XX代表被管理的配置项第一层，YYY代表配置项第二层，ZZZ代表配置项第三层(没有第三层的CI项的相应位置统一填写“ZZZ”)。

mmmmmm（六位）在同一类CI中应该保持唯一，可以是顺序编号，也可以是CI实体的名称等。

“名称”取值原则 CI的“名称”应具有易于理解、众所周知的含义，可帮助使用者直观、方便、快捷标识和定位到物理实体。“名称”取值应遵循如下原则：

“小型机”和“PC服务”本身的“名称”建议采用日常工作中大家熟知的方式，例如主机名或者是IP地址，例如“BOSS－JF1”。建议以“小型机”和“PC服务器”这两个物理实体作为其它CI命名的参照物。

凡是和小型机和PC服务器存在“安装在…..上”关系的硬件类配置项、系统软件配置项和业务应用配置项，我们均以小型机和PC服务器的“名称”＋“现有名称”的方式进行命名，例如：“BOSS－JF1－Oracle9i”

网络设备由于具有分布式的特点，建议其以“物理位置＋现有名称”的方式命名。

4.6.3 配置项间的关系

利用CI之间的关系可以有效地将相关的CI连接起来，从而为故障和问题的解决、变更和发布的计划和执行提供更好的参照，下表是常用的配置项之间的关系。 代码 1 2 3 4 5 关系分类 包含 包含 关联 关联 关联 关系 *安装在 … 上 *父/子 *连接关系 依赖关系 文档关联 说明 指软件包安装/运行于某硬件平台上。例如数据库安装在主机上 主要指某CI是其他CI一部分时的关系。例如营销管理CI是BOSS系统CI的子CI，反之BOSS系统CI是营销管理CI的父CI 指存在物理连接情况下的关系。例如主机连接到交换机上 主要指软件之间的依赖关系，指某CI的功能正常运行需要其他CI的功能正常运行时的关系；例如某业务应用依赖于中间件 主要描述文档类CI与其他CI之间的关系；例如某软件有某文档 * 注: 星号标注的为关键CI关系。关键CI之间的关键关系必须严格按照要求进行日常维护和定期审核，必须保证关键CI间关键关系信息的准确性和时效性。

配置项关系类型按照此定义，根据各个省的实际情况可以在此基础上进行扩充。 具体配置项之间的关系参见附件B。

4.6.4 配置项状态

配置项状态用于标识配置项管理的生命周期，各类配置项的状态代码和说明。

适用类别 硬件/客服设系统软件备/逻辑实体/业务应/安全类 用 √ √ √ √ √ √ √ 编号 1 2 3 4 5 6 状态 已安装 测试中 使用中 维护中 报废 备用 说明 设备/软件进入机房已完成安装但尚未正式使用 设备正在测试中 设备/软件处于运行状态，文档正处于有效期 设备正处于维护状态 设备已经被报废，或者软件和文档已经过期 设备处于备用状态 文档 √ 其他 √ √ √ √ 4.6.5 配置项审核

配置项属性以及配置项之间的关系必须被定期审核，以确保其与实际的物理环境保持一致，配置审核活动需要对配置项信息与配置项物理存在性进行双向验证。在审核的过程中，配置项有不同的审核状态。

配置审核工作可以按照各省自行定义的审核范围和周期来进行，当集团公司提出配置审核要求时，也需要发起配置审核工作。

考虑到实际的工作量，CI的审核范围不宜在整个CMDB中进行，建议每次按照CMDB的第一层进行，如单次审核仅审核所有硬件类CI及其相关关系；

对CMDB的审核同时可以参照变更的执行情况进行，根据一定时间内的变更记录，来检查这些变更中改变的CI属性是否被适当地修改，以确保CI属性和实际物理环境的一致。审核周期按照CMDB建设的情况和流程的完善程度在配置管理策略中制定并定期更新。

在审核前，将所有需要审核的CI状态设置为“未审核”，根据审核的结果，将CI的状态相应地改变为“已审核”/“不匹配”/“丢失”，同时记录更新审核时间；对“不匹配”/“丢失”审核状态的CI信息进行纠正后，相应地将其状态修改为“已审核”，至此一个审核周期结束。应该在在审核工作结束后，CI信息纠正之前统计流程衡量指标。

“审核状态”和“最后审核时间”都将作为配置项的通用属性。

代码 1 2 3 4 审核状态 已审核 未审核 不匹配 丢失 CI成功通过审核 CI尚未完成审核 说明 当审核时发现CI的信息或者CI关系与实际不符 审核时发现实际环境中找不到对应的CI 4.6.6 配置项的删除状态

配置项的删除状态用于标明该配置项是否被删除，删除状态定义如下： 配置项被置为“已删除”状态后，所有属性应该被冻结，不能修改。

代码 1 2 删除状态 正常 已删除 4.6.7 所属系统类型

请参照事件管理”2.6.4 所属系统类型”。

4.6.8 厂商

CI中定义了“厂商”属性，用于填写各个CI的原厂商。为了在填写过程中保证厂商名称的统一从而利于统计，在此定义厂商名称填写的标准，各省可以在此基础上进行扩充，其他流程的厂商填写也参照厂商名称标准。

厂商名称标准参见附件C。

4.6.9 集成商

部分CI中定义了“集成商”属性，用于填写相关CI的集成商。为了在填写过程中保证集成商名称的统一从而利于统计，在此定义集成商名称填写的标准，各省可以在此基础上进行扩充，其他流程的集成商填写也参照集成商名称标准。

集成商名称标准参见附件C。

4.7 流程概要设计

配置管理流程概要设计图如下：

图16. 配置管理流程

配置管理概要设计流程描述如下： 序号 步骤名称 配置管理策略的制定 配置项定义和标识 责任人 配置经理 说明 确定配置管理的具体范围；确定CI类别、CI属性和CI的命名规则；定义CI关系类型；定义各类配置项的审核周期 整理CI收集模板 对所要管理的IT环境的所有组成元素进行命名和说明 配置管理员 收集CI实体属性 明确CI实体之间关系 在CMDB开始建设或者新增CI类别时进行CMDB初始化 回收CI收集的结果 确保数据的准确性和有效性 建立配置管理数据库 接受变更或发布流程引发的正常CI更改要求，核实与物理CI变化的一致 CMDB初始化 配置管理员 CMDB控制和维护 性，执行CI的维护修改 配置管理员 接受监控管理平台发起的CI例外报告，核实与物理CI变化的一致性，执行CI的维护修改 接受定期审核结果引发的更改要求，执行CI的增删改 通过审核确认CMDB中配置项（CI）信息和其物理信息的一致性，确保惟有 CMDB审核和回顾 配置经理 授权配置项（CI）被使用，具体可通过定期审计、对最近的变更进行审计和随机抽查等方式 对配置管理工作执行的情况进行回顾，通常是通过召开回顾会议来完成；回顾工作可能会引发配置管理策略的调整 定期生成配置管理报告 定期向集团上报关键配置管理信息和统计报表 配置经理 定期地生产配置管理报告，为其他流程、配置管理回顾和领导提供管理报告 通过服务平台数据同步上报关键配置项信息 上报各类统计报表 配置经理 实际上，~涉及的工作往往会在规范和BOMC项目实施过程中完成。需配置管理员日常执行的任务主要是 CMDB控制和维护，需配置经理定期执行的任务主要是CMDB审核和回顾。

库维护的配置数据既相互关联、又有所区别。服务管理平台CI数据包括大量需人工维护信息，如维保数据、服务商数据等，主要作用是为事件、问题、变更和发布管理提供信息，

4.8 关键角色、职责定义

配置管理流程主要包括配置经理和配置管理员职责角色，分别简述如下：

4.8.1 配置经理

配置经理是配置管理具体活动的负责人，包括带领执行配置项的鉴别、监控、控制、维护、审计等工作。配置经理将从整个业务支撑部门的层面管理配置管理流程和配置管理数据库，建议在业务支撑部门设立一人作为配置经理。

职责：

定期对配置管理数据的内容进行审计和验证 定期主持配置管理回顾会议

4.8.2 配置管理员

配置管理员负责管理和维护配置管理系统和配置管理数据库系统。

建议由各专业技术人员分别担任配置管理员，维护各自所管的设备或应用。配置管理员可以按照基础架构的分类划分，也可以按照所属业务的类别进行划分。

职责:

通过手工或自动化操作增加及更改配置项，保证所负责的关键CI的关键属性、关键CI间的关键关系完整、准确

4.9 关键流程衡量指标

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

以下为配置管理流程的关键衡量指标：

表13． 配置管理KPI指标

序号 1 衡量指标 周期性审核中与物理环境一致的CI数量（已审核数量）及其比例 周期性审核中与物理环境不一致的CI数量（不匹配数量）及其比例 周期性审核中与发现物理环境中不存在的CI数量（丢失数量）及其比例 某时间周期内新增加的CI数量（新增数量） 指标计算说明 已审核数量：【删除状态】=‘正常‘and【审核状态】=‘已审核‘的CI数量; 比例：已审核数量/【删除状态】=‘正常‘的CI数量; 按照CI层次进行分组统计; 不匹配数量：【删除状态】=‘正常‘and【审核状态】=‘不匹配‘的CI数量; 比例：不匹配数量/【删除状态】=‘正常‘的CI数量; 按照CI层次进行分组统计; 丢失数量：【删除状态】=‘正常‘and【审核状态】=‘丢失‘的CI数量; 比例：丢失数量/【删除状态】=‘正常‘的CI数量; 按照CI层次进行分组统计; 新增数量：【删除状态】=‘正常‘and【 创建时间】在统计时间区间内的CI数量; 2 3 4 序号 衡量指标 按照CI层次进行分组统计; 指标计算说明 删除数量：【删除状态】=‘已删除‘and【删除时间】在统计时间区间内的CI数量; 按照CI层次进行分组统计; 5 某时间周期内删除的CI数量（删除数量） 4.10 集团、省公司两级交互

省公司应该定期将关键CI的信息上报集团公司； 触发条件

根据集团定义的周期定期上报。 上报方式和内容要求

通过定期CMDB同步实现数据上报，需要上报的CI和CI属性如下，各省细化时新增的属性不需上报： 序号 1 2 3 4 5 6 7 8 9 类别 小型机 PC服务器 路由器 网络交换机 磁带库 内容 小型机详细属性，参见附件A(仅包括星号标注的关键属性) PC服务器详细属性，参见附件A(仅包括星号标注的关键属性) 路由器详细属性，参见附件A(仅包括星号标注的关键属性) 网络交换机详细属性，参见附件A(仅包括星号标注的关键属性) 磁带库详细属性，参见附件A(仅包括星号标注的关键属性) 存储光纤交换机 存储光纤交换机详细属性，参见附件A(仅包括星号标注的关键属性) 磁盘阵列 数据库 中间件 磁盘阵列详细属性，参见附件A(仅包括星号标注的关键属性) 数据库详细属性，参见附件A(仅包括星号标注的关键属性) 中间件详细属性，参见附件A(仅包括星号标注的关键属性) 4.11 省公司上报报表

参见附件D中配置管理上报报表章节。

4.12 实施指导

4.12.1 流程图、流程角色定义与映射

各省在细化时，对现有角色和流程活动不可删除和修改 各省在细化时，可以增加流程角色和相关的流程活动描述 各省在进行流程角色映射时，配置经理建议只设置一人

对配置管理员可以按照基础架构分组设置，也可以按照应用系统分组设置，每组可以有一人或多人

4.12.2 流程衡量指标和报表

各省在细化时，可以扩充流程衡量指标

各省在细化时，可以自定义省内使用的流程报表内容、计算方法和生成频度

4.12.3 流程相关定义

定义 CI通用属性 配置项状态 配置项审核 配置项的删除状态 章节号 3.7.2 3.7.4 3.7.5 3.7.6 细化原则 其它说明 CI通用属性作为集团统一定义，各省对于各省需要的CI属性，可以自行增加，但在细化设计时不可修改通用属性的定义 不作为通用属性列出 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码 配置项所属系统由集团按照目前应用的划分统一定义，随着各省应用系统的上线，各省可以增加所属系统以及模块、子模块的定义，但不能删除和修改现有定义 厂商名称标准各省不可修改和删除，但可以在此基础上增加 集成商名称标准各省不可修改和删除，但可以在此基础上增加 本章节同时给出了审核的方式，各省可以在此基础上提出更好的审核方式 配置项所属系统 3.7.7 厂商 3.7.8 3.7.9 集成商 4.13 本期规范的主要变化

与一期规范定义的配置管理流程相比，本期规范的主要变化是设定关键CI、关键CI属性和关键CI关系。一期规范对配置项管理范围和配置项属性/关系所包含信息量的要求，各省需维护的CI数量较多，包含的信息量巨大。在各省工作任务繁重的实际情况下，保证所有CI完整、准确和实时的难度较大。本期规范对一期定义的CI范围和每类CI的属性进行了分析，筛选出数量合理的关键CI和关键CI属性，作为配置数据维护的基本要求。合理的维护信息量保证了维护工作量的合理性，本规范要求关键CI、关键CI属性的日常维护和定期审核必须严格按照要求进行，保证核心关键配置信息的准确性和时效性。

5 变更管理流程概要设计

5.1 流程目的

变更管理流程将通过标准统一的方法和步骤来管理和控制所有对IT生产环境有影响的变更。主要的目的包括：

IT部门可以管理和引导用户变更需求

通过对所有变更的正确评估，可以维护IT生产环境的完整性 变更和变更实施得到正确记录，并提供审核统计

减少或消除由于变更实施准备不当等原因出现的对IT环境的破坏作用 提高资源使用率

5.2 流程主要内容

变更管理流程始于变更的接收，结束于变更的实施和回顾。该流程包含下述主要内容： 提出RFC、评估、分类

变更申请人提出RFC，由变更主管负责检查和完善其内容，通过查询配置管理数据库，进行风险等级的初步评估；并尽量提出可能与业务发生的关联的影响，已供决策参考。变更主管并对变更进行分类；如为紧急变更，则按照紧急变更子流程执行；如为简单变更，直接制定变更计划，并安排实施。

变更主管负责组织制定变更计划、测试

变更主管安排并协调相应资源制定变更计划，包括实施计划、测试计划、回退计划、配置项更新计划等。应安排对实施计划和回退计划进行测试，随后将测试结果、实施计划、回退计划、配置项更新计划等提交给变更经理审核。

变更经理评估、审批

变更经理接受RFC，如果确定是紧急变更，则快速完成评估、审批。对标准变更，确定变更风险等级，审阅变更实施计划、测试报告、回退计划和配置项更新计划，批准或驳回变更申请，如需要更高级别管理层的审批，则根据不同风险级别报批。

变更委员会（CAB）/紧急变更委员会（ECAB）评估、审批

变更经理将根据特定的变更请求成立特定的CAB/ECAB，成员包括对该变更的评估和批准提供应有附加价值的技术人员和管理人员，审阅工作包括变更的风险、对现有服务的影响、实施计划、回退计划和配置项更新计划等，并做出批准与否的决定。如为紧急变更，则快速完成以上评估、审批。

管理层审批

对于风险等级为“重大”的变更，在变更委员会审批通过后，必须再由变更经理报请至管理层审批。

协调变更实施

变更主管负责协调资源，准备实施前相关工作，组织人员按计划实施变更，变更主管监控实施过程和结果，并在必要时进行协调或做出决定 。在这阶段可能需要变更经理和变更委员会成员的帮助。

回顾和关闭

实施变更后，变更主管确保配置项及时得到更新，并协同变更经理负责从技术、管理、业务角度去回顾变更，确保RFC得到了预期效果，并寻找改进机会或行动计划，在回顾过程中可能会需要得到变更委员会中相关领域的技术人员的帮助，随后更新变更记录并关闭RFC。

5.3 与其他流程的关系

变更管理流程可以从其他的服务管理流程接收到变更请求(RFC)。 和配置管理流程的关系

变更管理涉及到的配置改变应当在配置管理数据库中得到体现，改变的数据可能包括配置项、配置项间的关系或配置项的某些属性 ；

变更的评估需要从配置管理数据库中获取相关的信息进行分析。 和事件管理流程的关系

事件的解决可能需要触发变更管理流程来实现，变更成功实施后应当通知事件管理流程。

和问题管理流程的关系

问题管理流程中对于错误的修正可能需要触发变更管理流程，变更成功实施后应当通知问题管理流程。

和发布管理流程的关系

发布管理为变更管理提供支持，负责计划与实施变更，通过正规的实施变更流程及测试确保应用系统的质量。

5.4 流程范围

变更管理流程涵盖BOSS系统、经营分析系统、容灾系统和BOMC系统等生产环境中的下列变更活动：

IT基础架构的变更，如服务器、网络设备、存储、基础设施、系统软件、备件等的变更 日常化业务需求变更，可以应用软件的主版本、次版本升级、软件补丁等变更，或者导致应用系统参数的调整

相关文档的变更，如使用手册等 不包括：

在上线之前的软件开发、测试等活动 尚处于开发、测试环境的应用软件

日常业务需求管理包括需求讨论、跟踪、开发、测试、培训、审批和上线等环节。服务管理平台将用户需求管理融入到变更和发布管理流程中，具体如下图：

图17. 日常化需求管理与变更和发布管理流程的关系

5.5 流程执行原则

5.5.1 常规原则

所有影响生产环境配置项的变更都必须严格遵循变更管理流程 所有的变更请求记录都应被记录和追踪 所有变更实施过程都应记录在服务管理平台

应每月产生变更管理报表，对失败的变更和风险等级重大的变更进行回顾和检查，以更好地管理变更流程

应半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进变更管理流程

5.5.2 所有权原则

变更主管负责审核变更请求的有效性和正确性，制定相应的变更计划，并处理各种变更执行时的日程安排和协调，必要时可以得到变更经理的帮助 变更经理负责关闭紧急变更，变更主管负责关闭其他变更

对于不在变更经理审批权限内的变更，由变更经理负责提交至变更委员会审批

对风险等级为重大的变更，在变更委员会审批完成后，由变更经理负责提交至集团公司审批

5.5.3 流程关联原则

和配置管理的关联

在制定变更计划时通过查询配置管理数据库，评估变更可能影响的系统，制定变更计划时需制定配置项更新计划，变更实施完成后需确保配置项信息及时更新，只有配置项更新完成后，才能关闭变更请求单

配置项信息的变更需要通过变更管理流程控制 和事件管理的关联

解决事件的过程中可能会触发变更管理流程，如果变更管理流程是由事件管理流程触发，则事件记录必须与变更记录相关联 和问题管理的关联

解决问题的过程中可能会触发变更管理流程，如果变更管理流程是由问题管理流程触发，则问题记录必须与变更记录相关联 和发布管理的关联

变更计划实施的过程中涉及到软件版本更新会触发发布管理流程，如果发布管理流程是由变更管理流程触发，则发布记录必须与变更记录相关联

5.5.4 变更实施记录原则

所有变更实施过程都必须记录在服务管理平台，以体现出变更实施中的主要执行环节和执行情况，比如各关键步骤的起始时间、结束时间、执行人、执行结果、异常情况等。具体记录方式可采用在该变更请求单上增加填写信息项，或新增任务单等其他方式，记录的信息项参见变更实施单信息项定义

5.5.5 变更分类执行原则

简单变更采用预授权的方式，由变更主管直接安排实施，并通告变更经理

标准变更由变更经理总体负责，通过与各相关方面协同，采取多种方式（例如CAB会议），严格管理其计划、测试、评估、审批、实施 紧急变更提供变更快速实施处理的机制

5.5.6 审批上报原则

风险等级为重大的变更必须提前三个工作日提交集团公司审批，变更实施结束以后将变更执行结果上报至集团公司备案

风险等级为高的变更必须提前上报集团公司备案

变更委员会负责审批风险等级为高和重大的变更；对于风险等级重大的变更，变更委员会会议建议部门领导参加，对于风险等级高的变更，变更委员会会议建议维护主管参加 变更经理负责审批风险等级为中和低的变更

5.5.7 变更通知原则

对现有业务系统产生影响的变更，例如因实施变更而需要停机或者中止业务，均需在变更执行前提前通知有关人员做好业务调整，减少对业务的影响，待实施完成后再次通告

5.5.8 紧急变更处理原则

紧急变更必须通过E-MAIL等书面方式申请，但可以口头获得紧急变更委员会（EC）审批，事后必须在服务管理平台补变更申请单及相关测试和审批文档，其中变更申请单信息项中必须填写变更实施记录、变更测试记录和变更观察记录，这三项内容即为紧急变更操作日志

紧急变更应该制定变更计划，并快速审批和进行必要的评估，实施前需进行必要的测试，测试需包含完整的测试案例，只有测试成功后方可在生产环境进行变更。对由于紧急变更而无法完成的测试应在实施后安排补测

紧急变更委员会（ECAB）成员一般为公司领导、部门领导，各级主管等管理层人员，为了提高执行效率，需要事先制定紧急变更委员会(EC)的人员

紧急变更应越少越好，因为它们对业务的干扰最大，而且有很高的失败风险

5.5.9 变更测试原则

对生产系统进行变更时，需根据变更的性质、影响面等情况在变更请求单中选择是否需要在测试环境进行测试。如果需要，则按照测试计划进行测试，测试后需有相关测试人员确认并提供测试报告

5.5.10 变更文档控制原则

变更计划通常包括实施计划、测试计划、回退计划、配置项更新计划等

对应用软件版本上线类的变更，除变更计划外，还需包括变更功能说明文档、变更技术说明文档、包含完整测试用例的测试文档，并提供由执行测试人员确认的测试报告

对数据迁移类的变更，除变更计划外，还需包括转换方案，该方案一般包含数据转换策略、数据转换测试、数据备份及恢复方案、数据转换结果核对等方面的内容 对集团要求上报审批的变更，提交的文档具体内容说明如下:

变更总体方案（包括变更原因、变更前后系统拓扑、配置或功能对比、变更总体计划、具体方案、进度安排、人员分工、测试标准、风险评估等）

测试报告（提供系统在变更前的测试范围、测试步骤、测试项目、测试情况等） 变更回退/应急方案

5.6 流程相关定义

5.6.1 变更信息项

变更单必须包含如下变更信息项：

表14． 变更信息项

序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 变更ID 登记时间 实际请求人信息 变更标题 变更来源 关联的事件单号 关联的问题单号 变更类型 风险等级 所属系统类型 变更分类 变更描述 所影响的应用系统、部门 变更是否中断业务 变更是否需要测试 需通知部门 变更状态 变更主管 变更主管接受变更时间 变更计划 信息项 描述 为每个变更请求分配一个唯一的序列号（系统自动产生） 变更请求创建的时间（系统自动产生） 记录实际变更请求人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写） 简单描述变更请求（手工填写） 参见“变更来源”定义 如果变更来源是事件，则关联到相应的事件单（手工填写） 如果变更来源是问题，则关联到相应的问题单（由变更请求者手工填写） 参见“变更类型”定义 参见“风险等级”定义 参见“所属系统类型”定义 参见“变更分类”定义 详细描述变更的内容（手工填写） 实施该变更将对哪些应用、部门产生影响，用于评估变更（手工填写） 参见“ 变更是否中断业务“定义 参见“变更是否需要测试“定义 需要通知的部门名称（手工填写） 参见“变更状态”定义 变更主管姓名（手工填写） 变更主管接受变更请求的时间（手工填写） 使用附件形式。变更计划通常包括变更的实施计划、测试计划、回退计划、配置项更新计划等（手工填写） 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 计划开始时间 计划完成时间 变更审批记录 是否启动集团审批或备案 实际开始时间 变更实施记录 变更测试记录 实际完成时间 变更观察记录 融合计费中断时长 综合帐务中断时长 客户服务中断时长 回顾意见 回顾代码 变更结束代码 关闭人 关闭时间 关联的发布单号 变更计划开始时间 YYYY-MM-DD HH:MM（手工填写） 变更计划完成时间YYYY-MM-DD HH:MM（手工填写） 记录变更审批的历史记录，包括如下信息：审批人姓名、审批结果、原因、时间等（手工填写） 参见“ 是否启动集团审批或备案“定义 变更实际开始时间YYYY-MM-DD HH:MM（手工填写） 用于描述实施时的现场情况（手工填写） 描述测试的情况、测试结果（手工填写） 变更实际完成时间YYYY-MM-DD HH:MM（手工填写） 描述变更结束后，观察期间的情况（手工填写） 造成融合计费业务计划外中断的时间长度(分钟，手工填写) 造成综合帐务业务计划外中断的时间长度(分钟，手工填写) 造成客户服务业务计划外中断的时间长度(分钟，手工填写) 变更委员会对变更进行回顾后得出的意见（手工填写） 参见“回顾代码”定义（手工填写） 参见“变更结束代码”定义 关闭人的姓名（手工填写） 变更关闭的时间，关闭人手工填写。YYYY-MM-DD HH:MM 如果变更触发发布，则关联到相应的发布单 5.6.2 变更来源

变更来源用于区分触发变更的其他流程或需求，以便进行有效地关联。

编号 1 2 3 4 代码 事件 问题 配置 其他 描述 变更来源于事件 变更来源于问题 变更来源于配置项信息的调整 变更来源于其他方面，如项目建设等 5.6.3 变更类型

变更类型用于区分变更，提高变更处理的效率。 编号 1 代码 简单变更 描述 指频繁发生、影响范围较小、紧急程度较低、实施风险较小（不会带来重大后果）、实施较简单的变更，如库表大小的改动，crontab时间的修改，文件的删除等。 指涉及影响范围较大（影响客户、业务部门、分公司或者社会影响较大）、实施风险较大、实施较复杂的变更。这些变更可以进行充分的计划和测试。如业务割接、机房搬迁、软件升级等。 指如果不进行变更，会立即或正在严重影响业务运行、导致严重影响服务等级或者带来重大影响的变更，应当得到尽可能快速的处理，减少流程的复杂性，但是又要有良好的控制。如紧急事件引发的紧急变更。 2 标准变更 3 紧急变更 5.6.4 变更是否中断业务

变更可能会引起业务中断，需要在变更评估时加以说明。

编号 1 2 代码 是 否 描述 变更会引起业务中断 变更不会引起业务中断 5.6.5 变更是否需要测试

变更实施前需进行必要的测试。

编号 1 2 代码 是 否 描述 变更需要测试 变更不需要测试 5.6.6 风险等级

除简单变更外，变更主管、变更经理、变更委员会/紧急变更委员会对标准变更和紧急变更根据下表所列的衡量因素来量化评估实施变更可能带来的风险，该评估结果用于决定是否批准变更，是否需要更高级别的审批，以及实施完成后的观察期。该评估由变更主管进行初步评定，再由变更经理或变更委员会进行最终确定。

风险等级量化评估表如下：

衡量因素 地市/区域IT用户数量（受到实施或取消的影响） 条件 影响一个以上关键地区或半数以上地区 影响一个以上地区但未达到半数，并没有关键地区受影响 影响一个地区的全部用户 影响一个地区的部分用户 3个或更多支持小组 得分 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 准备/实施必需的资源 2个支持小组 超过1人，相同的支持小组 1人 无法测试，变更失败可能性很高 变更成功的可能性 能实现部分测试，变更失败可能性较高 有成熟的变更方案，变更失败可能低 无需测试，变更失败可能性没有 6天或更长 变更规划时间 2-6 天 1-2天 小于1天 超过2小时或在线/服务断供期 变更实施时间 1-2小时 不到1小时 衡量因素 不到30分钟 回退时间超过2小时 回退时间 条件 得分 4 1 2 3 4 回退难度中等以上（1-2小时） 回退难度适中（1小时或更短） 易于回退（30分钟或更短） 根据上表对每个变更进行评估，最终得出风险等级。风险分为四个等级：重大、高、中、低。不同的风险等级分别有对应的审批级别和实施完成后的观察期，具体定义如下表：

总得分 6 – 9 10 – 13 14 – 17 18 + 对应风险等级 重大 高 中 低 对应审批级别 变更委员会、集团公司 变更委员会 变更经理 变更经理 实施完后的观察周期 5-7天 4-5天 2-3天 1 天 5.6.7 所属系统类型

请参照事件管理”2.6.4 所属系统类型”。

5.6.8 变更分类

表15． 变更分类 变更分类 设备新购 设备入网 设备搬迁 设备部件更换 应用软件版本上线 应用软件配置变更 应用审计调整 应用随机调整 系统例行重启 系统其他重启 配套设施调整 数据迁移 文档变更 5.6.9 是否启动集团审批或备案

对风险等级为重大的变更，变更经理需启动集团审批 对风险等级为高的变更，变更经理需启动集团备案 编号 1 2 代码 是 否 描述 需要集团审批或备案 不需要集团审批或备案 5.6.10 变更状态

变更从提出到最后被关闭，会历经各个阶段。变更处于不同的处理阶段具有不同的状态，需要不同的角色参与。以下是变更请求从提出、实施到结束的整个生命周期中的不同状态：

编号 1 2 3 4 5 6 7 代码 已登记 计划中 等待审批 已批准 处理中 已完成 关闭 描述 变更请求已登记入系统，变更主管还未受理 变更主管对变更进行规划，检验变更单的分类和信息是否正确，提交必要的变更文档 变更请求提交给变更经理或变更委员会、或集团公司等待审批 变更单得到批准（或简单变更预先批准） 变更主管在此状态下，进行任务的创建、分发，变更实施者实施变更 变更实施完成，进入观察期 变更关闭，关闭变更时需指定关闭代码（成功，失败，已取消） 5.6.11 回顾代码

回顾代码用于描述变更计划和实施过程的质量，以便更好地改善未来的变更。

编号 1 2 3 4 代码 实施正常 计划不全 实施操作有误 不可预料情况 变更实施计划、操作没有问题 变更实施计划有缺陷，不完善 描述 变更实施人员在实施过程中操作有误 其他不可预料的意外情况，如系统突然无法启动 5.6.12 变更结束代码

变更结束代码用来描述其完结时的不同状态。 编号 1 2 3 代码 成功 失败 已取消 变更成功完成 描述 变更不成功，执行了回退计划 变更因为各种原因被取消 5.6.13 变更实施单信息项

表16． 变更实施单信息项

序号 1 2 3 4 5 6 7 信息项 实施单ID 变更请求单号 标题 实施内容 关联的配置项 记录登记时间 实施单状态 描述 为每个变更实施单分派一个唯一的序列号（系统自动产生） 该变更实施单所属的变更请求单号，来源于变更信息项（系统自动关联） 简单描述变更请求，来源于变更信息项 描述变更实施的内容（手工填写） 关联的配置项（手工关联） 变更实施单创建的时间（系统自动产生） 该变更实施单的状态，由各省自行定义 8 9 10 11 12 13 14 15 实施人员信息 核查人信息 计划开始时间 计划完成时间 实际开始时间 实际完成时间 实施任务记录 核查结论 姓名、手机、办公电话、邮件地址、联系方式、 地域、机构、部门 （手工填写） 姓名、手机、办公电话、邮件地址、联系方式、 地域、机构、部门（手工填写） 该实施单的计划开始时间（手工填写） 该实施单的计划完成时间（手工填写） 该实施单的实际开始时间（手工填写） 该实施单的实际完成时间（手工填写） 实施任务的工作日志、系统日志（手工填写） 实施任务的核查结论（手工填写） 5.7 流程概要设计

变更管理流程概要设计图：

图18. 变更管理流程

变更管理概要设计流程图如下： 序号 步骤名称 责任人 说明 变更申请人根据来自维护自发或其他IT人员、项目建设提出的、或 变更发起 变更请求者 事件、问题、配置管理流程提出的需求，收集信息，跟相关部门或用户确认 创建变更请求记录 初步为变更分配类型、风险等级等 保证变更信息项的完整性和正确性 变更主管负责对变更请求者提交的RFC进行检查，如有必要则对RFC相关信息完善或更正，以保证RFC的正确性和完整性 查询配置管理数据库 初步评估变更的类型、风险等，必须提出可能会影响哪些业务系统和部门，以供决策参考 对紧急变更，确认后立刻提交给变更经理按照401紧急变更子流程处理 检查、测试和计划 对简单变更，制定变更计划，直接转安排和分派任务 变更主管 对标准变更，协调资源，制定变更计划，包括实施计划、测试计划、回退计划、配置项更新计划等 实施计划要求有详细的操作命令，并包括实施变更的具体时间、操作执行人、核查人以及实施变更后观察期内的监控人员等 配置项更新计划包括配置项属性和关系的更新等 对变更进行必要的测试，即对实施计划以及回退计划进行测试，提供测试报告，确保系统变更的正常进行及回退的有效性 将实施计划、测试报告、回退计划、配置项更新计划等提交给变更经理审批 变更经理接受变更请求，评估和确定变更的类型、风险等级等 审阅所有提交的计划，包括实施计划、测试报告、回退计划、配置 评估、审批变更 变更经理 项更新计划等 变更经理将风险等级为重大或高的变更报送变更委员会审批，变更委员会的成员由变更经理确定 变更经理可以做出驳回或批准的意见 变更委员会 评估、审批 变更委员会 变更委员会由各领域的专家、领导、用户或相关厂商组成，对变更实施计划、测试报告、回退计划、配置项更新计划等审阅 变更委员会可以做出驳回或批准的意见 如果是重大变更，必须提前至少3个工作日报请集团审批，转由变更经理提交至集团公司审批 集团审批 集团公司 集团可以做出驳回或批准的意见 变更经理收集审批意见，驳回或批准变更。对于驳回的变更请求，可以建议变更主管取消变更或重新计划等 收集审批意见 变更经理 如果审批意见是批准，转安排和分派任务，并将高风险等级变更提交至集团公司备案 否则，转检查、测试和计划，可以取消或重新计划 变更主管负责日程安排和变更实施人员安排，分派任务给实施人员 提前向相关部门发出变更通告 安排和分派任务 变更主管 如取消变更，也需提前向相关部门或集团发出通告 对于经过测试并导入生产环境的新增或改进的配置项集合，通过发布管理流程实施 变更主管监控整个变更实施过程 变更实施人员按照实施计划，在生产环境实施变更 实施变更任务 变更主管 变更实施人员 在必要时启动恢复计划 实施完成后，通知变更主管，变更主管需填写由该变更所引起业务中断的关键系统名称和中断时长，最多填写三个关键系统的名称和各自的中断时长 变更经理、变更主管、变更委员会 变更主管负责准备回顾资料，对于重大变更（风险高、影响大、复 变更回顾 杂的变更），或执行了回退计划的变更，由变更主管通知变更经理，变更经理负责召集变更委员会成员参加会议 变更主管负责将回顾结果更新到变更记录中 变更主管分派配置项更新任务给相关配置管理员 配置管理员人据配置项更新计划更新相关配置项信息 如该变更是相关事件或问题流程发起，则通知事件或问题的当前处 关闭变更 变更主管 理人 对于风险等级为重大的变更，提交变更总结报告至集团备案 整理信息、更新变更记录，关闭变更 下表以变更管理概要图中的关键流程活动为主线，与变更管理概要设计中的其它重要内容进行了关联，以帮助各省业务支撑维护部门更好地理解流程设计内容。 序号 步骤名称 子流程和流程相关定义 参考并初步确定”变执行原则 流程关联 事件管理：对由事件管理 变更发起 更来源”、”变更类型”、”变更是否中断业务”、” 变更是否需要测试”、” 风险等级”、”所属系统类型”、”变更分类”、” 变更状态” 参考并检查、再次确 参考” 常规原则”，所有的变更都应被记录和追踪 流程触发的变更需关联相关的事件单号 (* 参见”流程关联原则”，下同) 问题管理：对由问题触发的变更关联相关的问题单号 配置管理：查询配置管理数据库 参考” 变更分类执行原 检查、测试和计划 定”变更来源”、”变更类型”、”变更是否中断业务”、” 变更是否需要测试”、” 风险等级”、”所属系统类型”、”变更分则”，明确变更分类 参考”所有权原则 ”，变更主管组织人员制定变更计划 参考”紧急变更处理原则 ” 参考” 变更测试原 配置管理：查询配置管理数据库 序号 步骤名称 子流程和流程相关定义 类”、” 变更状态” 执行原则 则”，变更根据需要进行必要的测试 参考” 变更文档控制原则” 参考” 变更分类执行原流程关联 参考” 变更类 评估、审批变更 变更委员会 评估、审批 集团审批 收集审批意见 安排和分派任务 实施变更任务 型”、”变更是否中断业务”、” 变更是否需要测试”、” 风险等级”、”所属系统类型”、”变更分类”、” 变更状态”，确定变更类型和风险等级，评估和审批变更 参考” 变更类型”、”变更是否中断业务”、” 变更是否需要测试”、” 风险等级”、”所属系统类型”、”变更分类”，确定变更类型和风险等级，评估和审批变更 参考” 风险等级”、”所属系统类型”、”变更分类”，审批变更 则” 参考” 所有权原则”，不同风险等级的变更由不同人员审批 参考” 审批上报原则”， 参考”紧急变更处理原则” 配置管理：查询配置管理数据库 参考” 审批上报原则” 参考” 紧急变更处理原 则” 参考” 变更通知原则” 参考” 变更实施记录原 配置管理：更新配置管理 参考” 回顾代码”定则” 义，对失败的变更或风险等级为重大的变更回顾 参考” 常规原则”，回 变更回顾 顾变更的质量 参考”变更状态代 参考” 所有权原则”， 关闭变更 码 ”、” 变更结束代码” 紧急变更由变更经理关闭，其他变更由变更主管关闭 数据库 事件管理：对由事件管理流程触发的变更需通知事件管理流程 问题管理：对由问题管理流程触发的变更需通知事件管理流程 流程实施考虑要素：

“变更委员会评估、审批”的具体实现过程可以根据各省实际情况和需求决定，可以不通过服务管理平台实现，可通过其他方式（如纸质文件或邮件）留下评估审批的记录即可

“安排和分派任务”和“实施变更任务”的具体实现可以根据各省实际情况和需求决定，如采用服务管理平台的工单或其他方式实现

5.7.1 紧急变更子流程

紧急变更管理子流程图：

图19. 紧急变更子流程

紧急变更子流程说明如下：

序号 步骤名称 责任人 说明 变更经理确认是紧急变更，如果不是则返回原流程 变更经理召集紧急变更委员会（EC）成员，注意在特殊环境下会议可 确认紧急变更 变更经理 能并非面对面，而是强调相关重要人员的沟通。可以通过电话方式沟通 将紧急变更的相关信息通告EC成员。或把紧急变更相关资料发送给EC成员 变更委员会-EC成员将检查和审阅需要讨论的紧急变更请求 如果变更委员会-EC发现RFC的信息不足以作出决定，应当立即要求变 快速评估、审批 紧急变更委员会 EC 更请求者提供更多的信息，而变更请求者在紧急变更处理过程中应当随时准备配合 EC成员评估变更，对该变更做出批准或驳回的意见 如不同意该紧急变更，则返回原流程，可取消或按正常流程进行 如批准则指定变更主管 协调资源，制定紧急变更计划，包括实施计划、测试计划、回退计 制定紧急实施计划、测试计划、回退计划，进行必要的测试 变更主管、变更实施人员、变更经理 划、配置项更新计划等（包括实施步骤、实施延续的时间、恢复计划、实施的人员安排、紧急通告等）、进行必要的测试，提交测试报告 对于风险等级为重大的变更，由变更经理按照集团公司要求提交至集团审批 否则进入实施紧急变更任务 集团审阅紧急变更计划，如批准，反馈意见下发给变更经理，由变更 集团审批 集团公司 经理转实施紧急变更任务 否则将驳回意见下发给变更经理，由变更经理转，返回原流程，由变更主管处理 通告相关部门 实施紧急变更任务 变更主管、 变更实施人员 业务恢复后再次通知相关部门 按照计划实施和测试系统，如果变更失败，则转执行回退计划 监测实施效果 变更主管协助变更经理确定参加回顾的人员，并将相关信息发给与会 回顾紧急变更 变更经理、变更主管、紧急变更委员会 变更主管、变更实施人员 人员 变更经理主持回顾会议，回顾该紧急变更的根源，变更的业务或技术目的，给出建议或意见 如果变更实施失败，执行回退计划 如果该变更引起配置项信息的变化，则通知配置管理员及时更新 对于风险等级为重大的变更，提交变更总结报告至集团备案 执行回退计划 关闭变更 变更经理 如果该紧急变更来自于紧急事件处理子流程，则通知紧急事件处理子流程 整理资料，更新变更记录，通知变更请求者，关闭变更 紧急变更子流程为紧急变更提供了快速处理机制，但为了良好的控制，仍应通过服务管理平台完成上述各环节。

5.7.2 变更实施过程

变更实施过程流程图：

图20. 变更实施流程

序号 步骤名称 分派任务 责任人 变更主管 变更主管 变更实施人员 厂家 变更主管 变更实施人员 厂家 变更主管 变更实施人员 厂家 变更主管 说明 变更主管负责协调资源，准备实施前相关工作，组织人员按计划实施变更 变更主管根据变更内容分派实施单到实施人员或者厂家 根据变更计划，在测试环境中进行测试 事前测试 实施变更 根据变更计划，实施变更内容 事后测试 实施监控 根据测试计划，测试变更实施结果 变更主管监控实施过程和结果，并在必要时进行协调或做出决定 5.7.3 日常化需求变更子流程

日常化需求变更的分析、跟踪、实现和上线是业务支撑中心业务应用支持的重要工作之一，固化的变更流程模型如下。

图21. 日常化需求变更管理子流程

序号 步骤名称 登记需求变更 责任人 变更主管 变更主管 变更实施人员 客户 变更主管 变更实施人员 变更主管 变更主管 变更实施人员 变更经理 变更主管 变更实施人员 变更主管 说明 需求变更来源包括集团公司公文、公司内部其他二级部门公文、来函；市场部审批通过的BOSS、经分应用变更需求；其他部门提出、经过OA审批的对业务应用系统的需求变更 讨论细节业务需求，形成面向客户的需求描述 初步确定需求实现的大致日期 形成面向实施人员的规格说明书 通过参数配置即可实现的业务需求，创建和派发实施任务单 需要开发才能实现的业务需求，启动发布管理流程 变更实施人员按照实施计划，在生产环境实施变更 在必要时启动恢复计划 讨论业务需求 确定需求规格 安排和分派任务 实施变更任务 变更回顾 关闭变更 5.8 关键角色、职责定义

变更管理流程建议的角色为：变更请求者、变更主管、变更经理、变更实施人员、变更委员会CAB/紧急变更委员会ECAB、变更管理流程负责人。以下描述每个角色的职责。

5.8.1 变更经理

变更经理全面负责变更管理流程中的所有具体活动执行，保障所有变更依照预定流程顺利执行。通常由具有决策权的人员担任。

帮助变更主管协调必要的变更时间、人员等方面的协调工作

审批变更请求，确保只有授权和必要的变更才被实行，并使该种变更影响最小化 成立变更委员会，并领导和主持变更委员会(变更委员会) 定期召开变更会议，回顾变更

参与流程评估，对流程改进提出意见和建议，与流程负责人共同制定流程改进建议

5.8.2 变更请求者

根据工作的需要，发起变更请求的IT人员，主要负责：

必要时提出变更申请，创建RFC，并提交给相关技术领域的变更主管 在变更处理过程中提供必要的信息

5.8.3 变更主管

变更主管通常由与变更请求内容相关的具体技术领域的负责人担任。可以根据不同的变更种类，分派不同的人员作为变更主管。对于某些重要变更，还可以将变更主管和变更实施人员合并在一起；变更主管主要关注在实施方案、详细实施计划等方面。

检查由变更申请人提交的每一个变更请求RFC，检查变更的正确性和必要性，必要时拒绝无关、无法实施或没有必要的变更请求

确定和检查RFC的分类、变更时间要求、分析风险等

作为具体变更的项目经理，负责领导变更的构建／测试，实施和参与回顾 制定变更实施计划、测试计划、回退计划等 针对具体变更请求，评估并分派相应资源 确保变更在预定的时间，资源和成本内完成

在必要时，确保回退计划（Fallback Plan）得以正确实施

负责收集与该变更有关的部门或小组的意见，综合变更对于应用的影响

5.8.4 变更委员会CAB、紧急变更委员会ECAB

变更委员会( Change Advisory Board ， CAB)是IT组织中对变更进行评估和决策、批准或者拒绝某个变更请求的虚拟组织。

针对具体变更请求，评估潜在影响和风险，并分派相应资源 协助变更经理对变更做出审批、决策 参加变更委员会会议和紧急变更委员会会议

回顾失败或重大的变更，以确保今后不再发生类似情形 回顾已执行的重大变更，确保满足变更的目的 对流程改进提出意见和建议 变更委员会（CAB or /ECAB）的组成人员：

变更委员会是由各省计费业务中心的管理人员组成的虚拟小组。主要由各相关领域的领导、各个IT维护小组的资深人员或者组长组成，有时也会包括发起变更请求的业务部门的代表、第三方厂商集成商等参与。变更委员会应当由该专业有较高技能的人员组成，同时，这些成员对于业务需求、业务逻辑、IT系统技术、应用开发、测试、支持等方面也较为熟悉。

注：紧急变更委员会通常可以属于变更委员会的一个子集，担当紧急变更委员会（ECAB）的职责。

5.8.5 变更实施人员

变更实施人员负责变更在生产环境中的实施，实际情况下现场厂商经常参与变更实施过程，其责任包括：

协助变更主管制定变更实施方案、变更实施计划 记录变更实施相关的信息，确保文档的完整性 负责实施和测试

变更完成后，进行监控，并记录监控结果 与变更主管沟通，通报变更实施的进度和结果

5.9 关键流程衡量指标

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

变更管理流程的主要衡量指标如下：

表17． 变更管理KPI指标

序号 1 衡量指标 新增的每一变更类型的变更数量 新增的每一变更分类的变更数量 新增的每一风险等级的变更数量 变更实施失败的数量 变更实施成功的数量 被取消的变更数量 指标计算 数量：每一变更类型的【登记时间】在统计时间区间内的变更数量 数量：每一变更分类的【登记时间】在统计时间区间内的变更数量 数量：每一风险等级的【登记时间】在统计时间区间内的变更数量 数量：【变更结束代码】=‘失败‘and 【关闭时间】在统计时间区间内的变更数量 数量：【变更结束代码】=‘成功‘and 【关闭时间】在统计时间区间内的变更数量 数量：【变更结束代码】=‘已取消‘and 【关闭时间】在统计时间区间内的变更数量 业务中断时长：【变更状态】=‘已完成‘and 【实际完成时间】在统计时间区间内的【中断时长】分别对应到融合计费、综合帐务、客户服业务系统的子类，进行分类统计 2 3 4 5 6 7 计划内业务中断时长 5.10 集团、省公司两级交互

5.10.1 集团公司审批的交互

所有风险等级为重大的变更，均需上报集团公司审批。省公司必须通过服务管理平台提前3个工作日上报，集团公司通过服务管理平台完成审批，审批意见和结果返回省公司，如果需要完善变更计划则要求省公司修改后重新上报。

交互 方式 触发条件 交互内容 附件内容 提交的文档具体内容说明如下: CAB对风险等级为重大的变更评估审批后，由变更经理整理资料，按照集团要求准备文档后，选择‘是否启动集团审批’为‘是’，上传启动集团审批 变更总体方案（包括变更原因、变更前后系统拓扑、配置或功能对比、变更总体计划、具体方案、进度安排、人员分工、测试标准、风险评估等） 测试报告（提供系统在变更前的测试范围、测试步骤、测试项目、测试情况等） 变更回退/应急方案 服务管理平台 集团经评审后，将审批意见填写在信息项的‘变更审批记录’ 省公司在重大变更实施完成后一周内，变更主管准备好总结报告，当将变更状态改为‘关闭’时上传 如已经过集团审批通过的变更要取消实施，则需在取消前1个工作日通知集团。当变更主管将变更状态改为‘关闭’，结束代码为‘取消’时启动上传 变更信息项（变更审批记录） 变更信息项 变更信息项 变更信息项 变更实施总结报告 变更信息项 取消原因 5.10.2 集团公司备案交互

凡属于风险等级为高的变更，省公司需提前通过服务管理平台上报集团公司备案。 交互 方式 触发条件 交互内容 附件内容 提交的文档具体内容说明如下: CAB对风险等级为高的变更评估审批后，由变更经理整理资料，按照集团要求准备文档后，选择‘是否启动集团审批或上报’定义的‘是’，上传启动集团备案 变更总体方案（包括变更原因、变更前后系统拓扑、配置或功能对比、变更总体计划、具体方案、进度安排、人员分工、测试标准、风险评估等） 测试报告（提供系统在变更前的测试范围、测试步骤、测试项目、测试情况等） 变更回退/应急方案 变更信息项 服务管理平台 变更信息项 5.11 省公司上报报表

参见附件D中变更管理上报报表章节。

5.12 实施指导

5.12.1 流程图、流程角色定义与映射

各省在细化时，可以增加省公司管理层等角色以及相关的流程活动描述 各省在细化时，不能对变更主管和变更经理等角色进行合并或取消 各省在进行流程角色映射时，可以根据实际情况设置多个变更经理

各省在进行流程角色映射时，变更主管可以映射为多个人，通常为各技术领域的负责人，变更实施人员映射为支持人员

各省在细化时，省公司结合自身的组织结构与流程角色相映射，尽量避免一人多角色的现象 各省在细化时，省公司在“流程概要设计”的基础上，可以根据自身的实际工作情况固化、抽取相应的具体变更流程，如口令修改、应用软件升级等

5.12.2 流程衡量指标和报表

各省在细化时，可以扩充流程衡量指标

各省在细化时，可以自定义省内使用的流程报表内容、计算方法和生成频度

5.12.3 变更信息项

变更信息项表内容参见5.6.1。

各省在细化时可以增加新的信息项，但概要设计中已经定义的信息项不能修改和删除，对信息项的描述可以扩充说明，但不能违反现有描述 集团、省公司两级交互时不传递省内新增的变更信息项

5.12.4 变更实施单信息项

变更实施单信息项表内容参见5.6.14。

各省在细化时可以增加新的信息项，但概要设计中已经定义的信息项不能修改，对信息项的描述可以扩充说明，但不能违反现有描述

5.12.5 流程相关定义

定义 变更来源 变更类型 变更是否中断业务 变更是否需要测试 风险等级 章节号 5.6.2 5.6.3 5.6.4 5.6.5 5.6.6 细化原则 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码，不能修改风险等级量化评估表 注：各省在细化设计时不能修改此表中现有定义，第一层业务系统和第二层子类不能修改和扩充(注：第一层为”其它系统”的话，对应的子类可以扩充)，但可以有选择的基于第二层其它说明 各省在细化时，对没有覆盖到的业务系统用”其它系统”表示，子类中没有覆盖到的业务用”其它”表示 所属系统类型 5.6.7 定义 章节号 细化原则 子类定义扩充进行第三层条目的细化。 其它说明 变更分类 是否启动集团审批或备案 变更状态 回顾代码 变更结束代码 5.6.8 5.6.9 5.6.10 5.6.11 5.6.12 分类不能删除，可以进行扩充 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码 5.12.6 变更流程模型

流程针对频发事件或变更提出的概念，是预先建立固化处理过程的模型。例如板卡更换过程、口令复位流程等。流程模型中应包括处理的环节/步骤、每环节的负责人员、表单的预定于字段等。流程模型的不断建立、丰富和修正是流程落实和持续改进的重要内容。

下面以中国移动XX公司固化的“业务系统操作权限变更流程”为例进行解释，建议各省参考逐步创建自己的变更流程模型，结合规范映射角色，补充完善工作步骤，不断固化固化流程和模版。 固化流程和角色

梳理日常实际工作流程，形成工作流程图

结合规范映射角色，补充完善工作步骤，形成固化的业务系统操作权限变更流程

图22. 业务系统操作权限变更流程模型

固化表单模版

根据固化的变更流程，形成专署的业务系统操作权限变更模版

可以固化的信息项由系统自动产生。从而降低重复录入信息，提高可用性 序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 变更ID 登记时间 实际请求人信息 变更标题 变更来源 变更类型 风险等级 变更所属系统类型 变更分类 变更描述 变更是否中断业务 变更是否需要测试 变更状态 变更主管 变更主管接受变更时间 信息项 系统自动产生 系统自动产生 系统自动产生 描述 系统自动产生：“业务系统操作权限变更” 系统自动默认“其他” 系统自动产生：“标准变更” 系统自动产生：“低” 申请人手工填写 系统自动产生：“业务系统操作权限” 申请人手工填写 系统自动产生：“否” 系统自动产生：“否” 根据流程运转，系统自动产生 根据系统管理员审批操作，系统自动产生 根据系统管理员审批操作，系统自动产生 16 17 18 19 20 21 22 23 24 25 26 27 28 29 变更计划 计划开始时间 计划完成时间 变更审批记录 是否启动集团审批或备案 实际开始时间 变更实施记录 变更测试记录 实际完成时间 回顾意见 回顾代码 变更结束代码 关闭人 关闭时间 系统管理员手工填写 系统管理员手工填写 系统管理员手工填写 系统自动产生 系统自动产生：“否” 系统管理员手工填写 系统管理员手工填写 系统管理员手工填写 系统管理员手工填写 系统管理员手工填写 系统管理员手工填写 系统管理员手工填写 系统自动产生 系统自动产生 5.13 本期规范的主要变化

与一期规范定义的变更管理流程相比，本期规范的主要变化包括：

明确把日常化需求变更作为重点之一纳入变更管理流程，并把流程固化为“日常化需求变更流程模型”，参见”5.8.1 日常化需求变更流程模型”

6 发布管理流程概要设计

6.1 流程目的

发布管理流程是将一组通过测试验证后的变更导入实际生产环境的管理控制流程，这些变更涉及到软件版本的变化，发布负责处理相关变更任务在技术与非技术方面所需要考虑的问题。通过发布流程的实施，可以确保对生产环境的变更得到有效控制，对IT服务产生最小影响，客户需求得到最大满足。

发布管理流程通过以下的方式来提高IT系统发布成功率与可用性的运维目标： 计划并监视软件和相关硬件成功的发布

确保正在对其进行改动的硬件和软件是可跟踪的、安全的，而且已安装的版本都是正确的、经过授权和经过测试

通过与“变更管理”达成一致来确定发布的准确内容和计划

利用‘配置管理’和‘变更管理’的控制流程将新的软件发布或硬件有效的添加到生产环境中 确保将所有软件的主副本保存在“最终软件库 (DSL)”中，并确保通过“配置管理”对 “配置管理数据库 (CMDB)” 进行更新

利用“配置管理”的服务确保所有正在对其进行发布的硬件、软件是安全的且是可跟踪的。

6.2 流程主要内容

发布管理流程始于发布的接受，结束于发布的关闭。该流程包含下述主要内容： 接受分派工作单

变更管理流程提出发布申请工作单，发布流程经理对发布请求进行审核，检查文档是否完全（支持文档、运营文档、培训手册、发布手册等），决定是否接受发布申请。对于已接受的发布申请，根据发布请求进行分类，并分派给相应的发布主管，由其进行发布计划的制订工作。

软件的开发与测试

对于需要进行软件开发和测试的发布，发布主管应该根据发布涉及的内容和发布计划的要求，组织相关的软件开发商和系统厂商进行软件开发，并测试其功能。

制定发布计划

发布主管接受发布工作单，制订相应的发布计划，对发布任务进行日程安排，并将一组相关的发布任务安排到相应的发布单元，根据发布周期制定整体发布计划。

对于项目类的发布申请，根据项目上线计划的日程合理安排发布时间。 发布准备

发布实施人根据发布计划进行发布相关的准备工作。包括机房、供电等环境，硬件设备，从最终软件库取得相关软件，相关支持工具的准备等。

发布培训

培训主管根据发布内容制定培训计划，组织相关人员参与发布前的培训工作。以确保相关人员有足够技能来保证系统发布后的有效运行。其中可包括：

1）发布参与人员的技术培训 2）系统维护人员的二线维护培训 3）服务台的人员的一线支持培训 4）系统最终用户的使用培训 系统集成测试

发布主管提出测试申请，发布经理对该申请进行审批。通过审批后，由发布主管组织系统集成测试，测试完毕后相关参与测试专家签署系统测试意见，记录测试文档。如测试未通过，由发布主管与实施人进行原因分析。

1）如果测试失败原因是“测试方法不合理”，由发布主管重新组织系统集成测试； 2）如果测试失败原因是“变更构建或系统冲突造成失败”，由发布主管向发布经理汇报，发布经理将发布请求工作单退回变更流程。 用户测试

发布主管组织相关用户进行用户测试，并在测试完毕后由用户签署用户测试意见，记录用户测试相关文档。如测试未通过，由发布主管与实施人进行原因分析。

1）如测试失败原因是“用户测试不合理”，由发布主管重新组织用户测试工作；

2）如测试失败原因是“变更构建不合理或系统冲突”，由发布主管向发布经理汇报，发布经理将发布请求工作单退回变更流程。 发布沟通

发布主管与系统用户进行沟通，根据业务需求确定发布最佳时间。如发布对业务产生影响，需在实施前通知相应用户，并提供发布期间的临时替代方案建议，以满足发布期间业务需求。

发布批准

各项准备工作完成后，发布主管根据发布周期的安排将投产申请提交发布经理进行审批。发布流程经理检查所有发布的准备工作是否充分，对上线发布进行批准与拒绝。同时批准发布投产后的Release号码，由发布主管组织实施。对于拒绝的上线发布，发布流程经理对说明具体原因：

1）如拒绝原因是“发布准备不充分”，由发布主管进行完善后重新申请；

2）如拒绝原因是“变更流程准备不充分”，发布经理将发布请求工作单退回变更流程。 发布实施

根据发布计划发布实施人负责生产环境的发布工作。发布实施后对结果进行确认，如发布成功则通知发布经理进行确认。如发布失败则实施回退计划。

确认与关闭

发布经理接到发布完成通知，组织相关人员对发布工作进行确认，根据确认结果对发布流程关闭。同时关闭发布申请工作单。

6.3 与其他流程的关系

发布管理流程从变更管理流程接收发布请求工作单。同时变更管理通过实时了解发布工单的状态来监控发布的实施。在发布工作完成后由变更主管协调配置管理流程对与发布相关的配置信息进行及时更新工作。

配置管理

配置管理提供配置项的属性及配置项之间的相互关系、发布所需的配置项与IT服务之间的关系等信息，发布管理判断和估计发布的风险和影响，同时发布管理流程执行完成后通过变更管理流程更新配置项。 变更流程

变更管理通过发布流程实现变更系统在生产环境中的发布，同时发布流程为变更流程提供变更实现的时间表。变更管理流程通过配置管理完成发布所更改配置项在CMDB中的更新工作。发布管理起始点是：变更管理流程中对变更的计划、风险和方案审批通过后。如果需要启动发布来实施这个变更，则向发布管理流程提交发布申请工作单，在发布管理完成整个发布过程后，再回到变更管理流程，继续变更过程的回顾。

6.4 流程范围

发布管理流程的管理范围是：BOSS系统、经营分析系统、容灾系统和BOSS网管系统等IT生产环境的变更所发起的发布请求。

6.5 流程执行原则

6.5.1 流程常规原则

所有涉及生产环境的软件版本的变更都必须严格遵循发布管理流程，安装的版本都是正确的、经过授权和测试

所有发布执行工作都应被记录并可追踪

每月产生发布流程管理报表，对失败的发布进行回顾和检查，以更好地管理发布流程 应半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进发布管理流程。

6.5.2 流程关联原则

和配置管理流程的关联

在制定发布计划时，通过参考配置管理数据库评估可能关联的系统。配置管理流程应当在发布实施完成后1个工作日内对CMDB数据库进行及时更新。 和变更管理流程的关联

涉及发布的变更通过发布流程投产进入生产环境，发布任务完成将结果反馈反馈到变更管理流程。同时变更管理流程需确认与本次发布相关配置项及时得到更新后才能能关闭。

6.5.3 发布通知原则

对现有业务系统产生影响的发布，例如因实施发布而需要停机或者中止业务，均需在发布执行前提前通知有关人员做好业务调整，减少对业务的影响，待发布完成后再次通告。

6.5.4 DSL管理控制原则

DSL（最终软件库）是存储所有软件配置项的最终正式版本的安全的物理存储库。发布管理确保所发布内容在DSL中得到及时更新。

在DSL（最终软件库）中存储了软件配置最新发布版本；实施回退计划的原版本；以及历次发布的所有历史版本。

DSL由软件控制主管进行严格管理，主要内容包括软件出入库、使用申请、更换等，并保证DSL中的软件记录与CMDB信息保持一致。

DSL可以由专业的软件开发配置管理软件来物理实现。

6.5.5 软件版本的策略原则

为了对同一软件的不同版本进行区分，需要对每个发布分派唯一的识别标志。发布识别标识包括相关配置项并包括含有一位或多位的数字版本号。

对于全发布与包发布可以定义为“XX系统V1－日期”;对于Delta发布可以定义为“－日期”例如（ 表示2006年10月10日发布的delta发布版本），具体的定义方式可以参考中国移动相关规定。

6.5.6 发布集成测试与用户测试原则

对于风险为重大或高的发布在引入实际生产环境前必须经过严格的集成测试与用户验收。 通过发布集成测试工作，对发布单元中的一组变更从系统角度进行验证。从而消除相关变更中潜在的系统冲突。

通过用户测试工作，对发布单元中的一组变更从用户功能进行验证。从而消除相关变更中潜在的功能冲突。

对系统进行发布时，需根据发布性质、影响面等情况在发布请求单中选择是否需要在测试环境进行集成测试与用户测试。如果需要，则按照测试计划进行。集成测试及用户测试完成后应由相关测试专家及用户签署确认报告。

测试与验收工作应当由的IT与业务人员来执行

6.5.7 发布拒绝原则

如果一个发布请求被拒绝，应当通过变更管理流程来重新安排。被拒绝的发布请求应当作为失败发布。

6.5.8 发布频率原则

参考变更执行窗口，发布频率为每半个月执行一次（和变更执行窗口一致，可由发布经理调整）。为了保证发布流程中的测试、培训、通知等环节得到有效执行，从而保证发布质量，发布请求至少在期望上线日1个月前提交。

6.6 流程相关定义

6.6.1 发布信息项

发布单必须包含如下发布信息项：

表18． 发布单信息项

序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 发布ID 登记时间 实际请求人信息 发布标题 发布来源 关联的事件单号 关联的问题单号 发布类型 风险等级 发布所属系统类型 发布分类 发布描述 所影响的应用系统、部门 需通知的部门 发布是否中断业务 变更是否需要系统测试 变更是否需要用户测试 发布状态 发布主管 发布主管接受发布时间 发布计划 计划开始时间 计划完成时间 发布审批记录 信息项 描述 为每个发布请求分配一个唯一的序列号（系统自动产生） 发布请求创建的时间（系统自动产生） 记录发布请求人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机（直接继承“变更请求人信息”） 简单描述发布请求（手工填写） 参见“发布来源”定义 直接继承变更信息项的同一字段 直接继承变更信息项的同一字段 参见“发布类型”定义 直接继承变更信息项的同一字段 直接继承变更信息项的“变更所属系统类型”定义 直接继承变更信息项的“变更分类”定义 详细描述发布的内容（手工填写） 实施该发布将对哪些应用、部门产生影响，用于评估发布（直接继承变更信息项的同一字段） 定义需要通知的部门名称（直接继承变更信息项的同一字段） 参见“ 发布是否中断业务“定义 参见“发布是否需要系统测试“定义 参见“发布是否需要用户测试“ 参见“发布状态”定义 发布主管姓名（手工填写） 发布主管接受发布请求的时间（手工填写） 使用附件形式。发布计划通常包括发布的培训计划、测试计划、回退计划、配置项更新计划等（手工填写） 发布计划开始时间 YYYY-MM-DD HH:MM（手工填写） 发布计划完成时间YYYY-MM-DD HH:MM（手工填写） 记录发布审批的历史记录，包括如下信息：审批人姓名、审批结果、原因、时间等（手工填写，包括变更请求审批记录和发布实施审批记录） 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 是否启动集团审批或备案 实际开始时间 发布实施记录 系统测试结果 用户测试结果 实际完成时间 发布观察记录 融合计费业务中断时长 综合帐务业务中断时长 客户服务业务中断时长 发布工作单关闭代码 发布工作单状态 发布结束代码 关闭人 关闭时间 备注 直接继承变更信息项的同一字段 发布实际开始时间YYYY-MM-DD HH:MM（手工填写） 用于描述实施时的现场情况（手工填写） 参见“ 系统测试结果“定义 参见“ 用户测试结果“定义 发布实际完成时间YYYY-MM-DD HH:MM（手工填写） 描述发布结束后，观察期间的情况（手工填写） 描述该发布所中断的关键业务系统1的时长，按分钟计算。（手工填写） 描述该发布所中断的关键业务系统2的时长，按分钟计算。（手工填写） 描述该发布所中断的关键业务系统3的时长，按分钟计算。（手工填写） 参见“发布工作单关闭代码”定义 参见“发布工作单状态”定义 参见“发布结束代码”定义 关闭人的姓名（手工填写） 发布关闭的时间，关闭人手工填写。YYYY-MM-DD HH:MM 留用 6.6.2 发布来源

编号 1 2 代码 正常变更 项目上线 描述 由于正常变更所出发的发布 由于新项目上线引发的变更所触发的发布 6.6.3 发布类型

编号 1 2 3 4 代码 新系统上线 单项升级 包升级 补丁 描述 新系统所有组件及功能的发布方式。 对某系统单项功能进行升级的发布实施方式 对一组相关系统的一组功能进行升级的发布实施方式 对某系统安装相关补丁 6.6.4 发布是否中断业务

编号 1 2 代码 是 否 描述 发布会引起业务中断 发布不会引起业务中断 6.6.5 是否需要系统测试

编号 1 2 代码 需要 不需 描述 需要系统测试 不需要系统测试 6.6.6 是否需要用户测试

编号 1 2 代码 需要 不需 描述 需要用户测试 不需要用户测试 6.6.7 系统测试结果

编号 1 2 代码 通过 未通过 描述 发布系统通过系统测试 发布系统测试失败 6.6.8 用户测试结果

编号 1 2 代码 通过 未通过 描述 用户测试通过 用户测试失败 6.6.9 发布状态

发布从被发布经理接受到最后被关闭，会历经各个阶段。发布处于不同的处理阶段具有不同的状态，需要不同的角色参与。以下是发布请求从接受、计划到结束的整个生命周期中的不同状态：

编号 代码 描述 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 已接受 待准备 已准备 待培训 已培训 待测试审批 测试已审批 待系统测试 系统已测试 待用户测试 用户已测试 待发布审批 发布已审批 已发布 关闭 发布请求已经被发布经理接受 发布主管根据发布周期，将发布请求合理安排到一个发布中 实施人根据发布任务进行相应的硬件与软件的准备工作 等待培训状态 对将发布系统完成服务台培训、维护培训、使用培训等工作 等待发布流程经理审批进入测试环境 发布流程经理已审批按计划发布至测试环境 等待系统测试状态 实施人已完成发布所涉及到多个变更的系统集成测试 等待用户测试状态 用户已完成发布所涉及到多个变更的用户测试 等待发布流程经理审批进入生产环境 发布流程经理已审批按计划发布至生产环境 发布工作完成 发布关闭，关闭发布时需指定关闭代码（成功，失败） 6.6.10 发布结束代码

发布结束代码用来描述其完结时的不同状态。 编号 1 2 代码 成功 失败 发布成功完成 描述 发布不成功，执行了回退计划或被拒绝 6.6.11 发布工作单信息项

表19． 发布工作单信息项

序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 信息项 工作单ID 发布请求单号 标题 实施内容 关联的配置项 记录登记时间 发布工作单状态 实施人员信息 核查人信息 计划开始时间 计划完成时间 实际开始时间 实际完成时间 实施任务记录 核查结论 描述 为每个发布工作单分派一个唯一的序列号（系统自动产生） 该发布工作单所属的发布请求单号，来源于发布信息项（系统自动关联） 简单描述发布请求，来源于发布信息项 描述发布实施的内容（手工填写） 关联的配置项（手工关联） 发布实施单创建的时间（系统自动产生） 参加“发布工作单状态” 姓名、手机、办公电话、邮件地址、联系方式、 地域、机构、部门 （手工填写） 姓名、手机、办公电话、邮件地址、联系方式、 地域、机构、部门（手工填写） 该工作单的计划开始时间（手工填写） 该工作 单的计划完成时间（手工填写） 该工作单的实际开始时间（手工填写） 该工作单的实际完成时间（手工填写） 实施任务的工作日志、系统日志（手工填写） 实施任务的核查结论（手工填写） 6.6.12 发布工作单状态

发布工作单状态向发布流程描述相关发布工作的接受与处理情况。 编号 代码 描述 1 2 3 4 新建 已分派 处理中 关闭 发布工作单在系统中新建 发布工作单已分派至发布主管 发布实施中 工作单完成 6.6.13 发布工作单关闭代码

发布工作单结束代码用来描述发布工作单关闭的不同结果 1 2 成功 失败 发布工作单成功完成 发布工作不成功 6.7 流程概要设计

根据发布来源的不同，我们将发布管理流程分成两种情形：

1、重大发布管理流程：对于来源为“项目上线”的发布，通过重大发布管理流程来执行； 2、日常发布管理流程：对于来源为“正常变更”的发布，通过日常发布流程来运行； 重大发布管理流程概要设计图如下：

图23. 发布管理流程

序号 步骤名称 责任人 说明 变更管理流程提出发布申请工作单 发布经理对发布请求进行审核批准，如拒绝则返回给变更管理流程 根据发布请求分类将工作分派给相应的发布主管 发布主管接受发布工作单 对当前发布计划进行检查，建立相应的发布单元或将该发布合理安接受分派工作单 发布经理 制定发布计划 发布主管 排 至已有发布单元中 对发布任务进行日程安排 对发布任务进行人员安排 制定本发布周期的发布计划包括回退计划 完成与发布相关的配套设施准备工作 发布准备 发布主管 发布实施人 完成与发布相关的硬件设备准备工作 完成与发布相关的软件准备工作 完成与发布相关的支持工具准备工作 根据发布内容制定培训计划 对发布相关的系统维护人员进行培训 发布培训 培训主管 对服务台的人员进行发布系统的培训工作 对系统用户进行发布系统的培训工作 对发布实施参与人进行发布培训工作 对发布所涉及变更进行统一考虑，制定集成测试计划 发布流程经理对测试申请进行审批 发布主管组织进行系统集成测试 系统集成测试 发布主管 发布实施人 通过测试后签署系统集成测试意见 1）如果测试失败原因是“测试方法不合理”，由发布主管重新组织系统集成测试； 2）如果测试失败原因是“变更构建或系统冲突造成失败”，由发布主管向发布经理汇报，发布经理将发布请求工作单退回变更流程。 对发布所涉及变更进行统一考虑，制定用户测试计划 发布主管组织进行用户集成测试 通过测试后签署用户测试意见 用户接受测试 发布主管 1）如果测试失败原因是“用户测试不合理”，由发布主管重新组织用户测试； 2）如果测试失败原因是“变更构建或系统冲突造成失败”，由发布主管向发布经理汇报，发布经理将发布请求工作单退回变更流程。 发布沟通 发布主管 与用户进行沟通 对系统上线时间与系统用户取得一致 在发布执行窗口发布流程经理对发布申请集中审核 对于符合发布要求的进行批准，分派给Release号码，授权发布主管进行投产发布 发布批准 发布经理 如果发布被拒绝，则： 1）如拒绝原因是“发布准备不充分”，由发布主管进行完善后重新申请； 2）如拒绝原因是“变更流程准备不充分”，发布经理将发布请求工作单退回变更流程。 发布实施 发布主管 发布实施人 发布经理 发布主管与发布实施人负责生产环境发布实施工作 发布实施后对结果进行确认，如发布成功则提交发布流程经理进行确认。如发布失败则实施回退计划 发布经理组织对发布工作的确认，关闭发布流程，向变更管理流程 确认与关闭 返回发布申请工作单。 下表以重大发布管理流程概要图中的关键流程活动为主线，与重大发布管理概要设计中的其它重要内容进行了关联，以帮助各省业务支撑维护部门更好地理解重大发布流程设计内容。 序号 步骤名称 子流程和流程相关定义 参考并初步确定”发执行原则 流程关联 事件管理：对由事件管理 接受分派工作单 制定发布计划 发布准备 发布培训 系统集成测试 用户接受测试 发布沟通 发布批准 布来源”、”发布类型”、”发布是否中断业务”、” 发布是否需要系统测试”、“发布所属系统类型”、 ” 发布是否需要用户测试”、” 风险等级”、” 是否启动集团审批或备案”、”发布分类”、” 发布状态” 参考并检查、再次确定”发布来源”、”发布类型”、”发布是否中断业务”、” 发布是否需要系统测试测试”、 ” 发布是否需要系统用户测试”、” 风险等级”、”发布所属系统类型”、”发布分类”、” 发布状态”、“发布计划” 参考” 发布类型”、”发布是否中断业务”、 ” 发布是否需要系统测试测试”、 ” 发布是否需要系统用户测试”、” 风险等级”、”发布所属系统类型”、”发布分类”、” 发布状态” 参考” 发布计划” ” 发布是否需要系统测试测试”、 ” 发布是否需要系统用户测试” ” 发布是否需要系统测试测试”、 ” 发布是否需要系统用户测试” 参考” 发布计划” 参考并检查、再次确定”发布来源”、”发布类型”、”发布是否中断业务”、” 发布是否需要系统测试测试”、 ” 发布是否需要系统用户测试”、” 风险等级”、”发布所属系 参考” 常规原则”，所有的变更都应被记录和追踪，发布是一种特殊的变更 参考” 发布拒绝原则” 流程触发的变更/发布需关联相关的事件单号 (* 参见”流程关联原则”，下同) 问题管理：对由问题触发的变更/发布关联相关的问题单号 配置管理：查询配置管理数据库 参考”原则 ”，发布主管组织人员制定发布计划 参考” 发布集成测试与用户测试原则” 配置管理：查询配置管理数据库 参考”原则 ”，发布主管组织发布实施人员完成发布准备 参考”流程关联原则 ”，从配置管理获取相关信息完成发布准备 配置管理：查询配置管理数据库 参考”原则” 参考” 发布集成测试与 用户测试原则” 参考” 发布集成测试与用户测试原则” 参考” 发布通知原则” 参考”原则” 序号 步骤名称 子流程和流程相关定义 统类型”、”发布分类”、” 发布状态”、“发布计划” 执行原则 流程关联 参考” 发布频率原则” 发布实施 参考” 发布计划” 参考”发布状态代和“软件版本策略原则” 参考”原则”，发布由 配置管理：更新配置管理 确认与关闭 码 ”、” 发布结束代码” 发布经理关闭 数据库 日常发布管理流程概要设计图如下：

图24. 日常发布管理流程

序号 步骤名称 接受发布单 责任人 发布主管 发布主管接受发布请求 根据发布请求确定开发厂商 说明 变更主管提出发布申请工作单 开发与调测 开发厂商 与开发厂商一起确定开发计划 开发厂商实施开发 开发调测 制定用户测试计划对包括客户的培训 发布主管组织用户和厂商进行测试 通过测试后签署用户测试意见，并更新DSL 测试若未通过： 发布主管 用户测试 开发厂商 用户 1）如果测试失败原因是“用户测试不合理”，由发布主管重新组织用户测试； 2）如果测试失败原因是“变更构建或系统冲突造成失败”，由发布主管向发布经理汇报，发布经理将发布请求工作单退回变更流程。 完成与发布相关的配套设施准备工作 完成与发布相关的硬件设备准备工作 发布准备 发布主管 开发厂商 完成与发布相关的软件准备工作 完成与发布相关的支持工具准备工作 对发布相关的人员进行培训 与用户就发布进行沟通 在发布执行窗口发布流程经理对发布申请集中审核 对于符合发布要求的进行批准 授权发布主管进行上线发布 如果发布被拒绝，则： 发布批准 发布经理 1）如拒绝原因是“发布准备不充分”，由发布主管进行完善后重新申请； 2）如拒绝原因是“变更流程准备不充分”，发布经理将发布请求工作单退回变更流程。 发布主管与开发厂商从DSL中提取待发布软件，进行生产环境发布 发布实施 发布主管 开发厂商 实施工作 发布实施后对结果进行确认，如发布成功则提交发布经理进行确认，如发布失败则实施回退计划 确认与关闭 发布监控 发布主管 发布主管 发布经理 发布经理组织对发布工作的确认，关闭发布流程，向变更管理流程返回发布申请工作单。 在开发和测试过程中，发布主管和发布经理监控和检查厂商进度和质量。 6.8 关键角色、职责定义

流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员赋予不同的角色，也可能一个人被赋予多个角色，同时某一角色的人员也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的流程角色在具体的实现中可以有足够的灵活性。

发布管理流程建议的角色为：发布经理、发布主管、发布实施人、培训主管，以下描述每个角色的职责。

6.8.1 发布经理

发布经理全面负责发布管理流程中的所有具体活动执行，保障所有发布依照预定流程顺利执行。通常由具有决策权的人员担任。

审核由变更管理流程提交的发布请求工作单，确认其正确性和必要性，必要时拒绝无关、无法实施或没有必要的发布请求。

审批发布请求，制定发布周期、进行分析风险控制，确保被发布的版本都是正确、且通过有效测试。

确定发布请求分类，指定发布负责人（发布主管），进行发布工作的总体管理与监控。 参与流程评估，对流程改进提出意见和建议，与流程负责人共同制定流程改进。 对发布参与人员工作进行管理与考评。

6.8.2 发布主管

发布主管通常由与发布请求内容相关的具体技术领域的负责人担任。可以根据不同的发布种类，分派不同的人员作为发布主管。发布主管主要关注在制定发布计划、组织发布实施等方面。

作为具体发布工作的负责人，负责领导发布的计划、准备、测试，实施工作 针对具体发布请求，协调相应资源 确保发布在预定的时间，资源内完成

发布成功后通知配置管理流程对配置信息进行及更新 在必要时，确保回退计划（Fallback Plan）得以正确实施

负责收集与该发布有关的部门或小组的意见，综合发布对于应用的影响

6.8.3 发布实施人

发布实施人员负责在生产环境中的发布，其责任包括： 在发布主管领导下实施发布计划 负责与发布相关的软、硬件的准备工作 负责对发布系统的集成测试工作 负责配合用户对发布系统的用户测试工作

保持与发布主管沟通，通报发布实施的进度和结果 必要时负责回退计划的执行

6.8.4 培训主管

培训主管负责发布流程中的培训工作，通过对培训使各类人员掌握相应技能，保证发布系统的有效运营。

确保发布系统的使用与维护人员获取必要知识 提供发布系统的客户使用培训 提供发布系统的维护操作培训 提供发布系统的服务台培训 在培训中收集相关的反馈

需要说明的是：在发布管理中还涉及到除移动业务中心之外的3个角色： 开发厂商：通常是业务支撑系统某个子系统的开发商；

测试专家：通常由的测试厂家或者测试人员参加，他们与开发团队无关； 用户：提交发布请求的人或者部门；

6.9 关键流程衡量指标

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

发布管理流程的主要衡量指标如下： 序号 1 2 3 4 5 衡量指标 各类型的发布数量 各分类的发布数量 各风险等级的发布数量 发布实施成功的数量 发布实施失败的数量 指标计算 数量：每一发布类型的【登记时间】在统计时间区间内的发布数量 数量：每一发布分类的【登记时间】在统计时间区间内的发布数量 数量：每一风险等级的【登记时间】在统计时间区间内的发布数量 统计数量：【发布结束代码】=‘成功‘and 【关闭时间】在统计时间区间内的发布数量 统计数量：【发布结束代码】=‘失败‘and 【关闭时间】在统计时间区间内的发布数量 6.10 集团、省公司两级交互

所有重大版本的发布，均需上报集团公司审批。省公司必须通过服务管理平台提前7个工作日上报，集团公司通过服务管理平台完成审批，审批意见和结果返回省公司，如果需要完善发布计划则要求省公司修改后重新上报。重大发布上报过程包含在变更上报的过程中。

6.11 省公司上报报表

参见附件D中发布管理上报报表章节。

6.12 发布管理流程细化指导

6.12.1 流程图、流程角色定义与映射

各省在细化时，对现有角色和流程活动不可删除和修改 各省在细化时，可以增加流程角色和相关的流程活动描述

各省在进行流程角色映射时，发布管理流程负责人只能设置一个人，发布经理建议也只设置一人；两个角色可以视情况由同一人担任

对发布主管可以按照基础架构分组设置，也可以按照应用系统分组设置，每组可以有一人或多人

6.12.2 流程衡量指标和报表

各省在细化时，可以扩充流程衡量指标

各省在细化时，可以自定义省内使用的流程报表内容、计算方法和生成频度

6.12.3 发布信息项

发布信息项表内容参见6.6.1。

各省在细化时可以增加新的发布信息项，但概要设计中已经定义的信息项不能修改和删除，对信息项的描述可以扩充说明，但不能违反现有描述 集团、省公司两级交互时不传递省内新增的变更信息项

6.12.4 发布工作单信息项

发布工作单信息项表内容参见6.6.13。

各省在细化时可以增加新的工作单信息项，但概要设计中已经定义的信息项不能修改，对信息项的描述可以扩充说明，但不能违反现有描述

6.12.5 流程相关定义

定义 发布来源 变更类型 发布是否中断业务 是否需要系统测试 是否需要用户测试 系统测试结果 用户测试结果 风险等级 发布分类 发布所属系统类型 章节号 6.6.2 6.6.3 6.6.4 6.6.5 6.6.6 6.6.7 6.6.8 6.6.9 6.6.10 6.6.11 细化原则 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码，不能修改风险等级量化评估表 类别不能修改，子类可以扩充，针对子类可以自定义多个条目 不能增加、修改或删除代码 其它说明 例如：对于操作系统子类，条目可以扩展定位为升级、配置修改等 定义 发布状态 发布结束代码 发布工作单状态 发布工作单关闭代码 章节号 6.6.12 6.6.13 6.6.14 6.6.15 细化原则 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码 不能增加、修改或删除代码 其它说明 7 日常运维管理概要设计

7.1 作业计划管理

7.1.1 目的

作业计划管理的主要功能是对IT人员的日常维护作业进行统一的管理，其目的包括： 周期性计划的制定和执行

根据日常维护工作经验，提前制定好周性性的作业计划 作业计划到达执行时间时给相关人员提醒 临时性作业的制定和执行

需要负责人处理时通知相关人员 规范作业计划的执行

制定时需要通过审批 执行完成后需要负责人确认 执行过程的记录

作为历史记录查询的依据

7.1.2 主要内容

作业计划分为周期性的和临时性的两种，包含下述主要内容： 作业计划的制定

作业计划的制定主要以周期性的，可预见的工作为主。制定时必须提供以下要素：

作业计划审批人，负责审批作业计划 作业计划的确认人(或角色) 作业计划的执行人(或角色) 作业计划的执行周期 作业计划的执行内容 作业计划的执行

任务到达时提醒 任务超时时提醒 执行过程的历史数据记录 执行完成后必须通过确认人的确认 执行结果通知定义的相关人员

7.1.3 执行原则

7.1.3.1 通知原则

任务到达时通知执行人 任务超时时通知执行人与创建人 执行完成时通知定义的相关人员 7.1.3.2 历史记录原则

对过程中的每一步记录操作人、操作时间 记录操作过程中的相关数据变更

7.1.4 相关定义

7.1.4.1 作业计划信息项

作业计划必须包含如下信息项，各省可以在此基础上扩充： 序号 1 2 3 4 5 6 7 8 信息项 作业计划ID 创建时间 计划执行时间 计划执行人 执行内容 创建人 审核人 审核时间 系统自动产生 系统自动产生 说明 维护作业的计划执行时间，可以定义为周期性的 计划执行人或角色 作业内容，参见维护作业工单信息项 作业计划的创建人 作业计划的审核人 作业计划的审核时间 7.1.4.2 维护作业单

维护作业单必须包含如下信息项，各省可以在此基础上扩充：

图25. 维护作业单信息项

序号 1 2 3 6 7 8 9 10 11 信息项 作业单ID 登记时间 计划完成时间 标题 描述 执行人 解决方案描述 实际开始时间 实际完成时间 系统自动产生 系统自动产生 维护作业的计划完成时间 维护作业内容简述 维护作业内容详细描述 维护作业的执行人 维护作业的执行结果 说明 维护作业实际开始执行的时间，系统自动填写 维护作业实际完成的时间，系统自动填写 7.1.5 流程设计

7.1.5.1 作业计划制定流程(721)

图26. 作业计划制定流程

作业计划制定流程说明如下： 序号 步骤名称 作业计划制定/修改 审核作业计划 审核通过 说明 系统管理员根据需要制定或修改已有作业计划的配置信息 负责人检查作业计划的配置信息，包括作业内容、计划执行时间、执 作业计划生效 行人等 如果不满足要求，则转进行修改 提交系统进入 在系统中更新相关的作业计划配置信息 7.1.5.2 维护作业流程(720)

图27. 作业计划执行流程

流程说明如下： 序号 步骤名称 根据制定的维护作业计划创建维护作业 创建临时维护作业 执行维护作业 记录执行结果 发现异常吗 说明 系统根据制定的维护作业计划，在到达执行时间后，自动创建维护作业单，并派发给定义好的执行人 用户创建临时维护作业，直接派发给执行人 根据维护作业内容，执行维护作业 在系统中详细记录维护作业的执行结果 如果在执行过程中发现异常，则转创建新事件； 维护作业记录关闭保存 创建新的事件单，进入事件管理流程 创建新事件 7.1.6 关键角色、职责定义

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

作业计划管理主要分为以下几个职责/角色： 7.1.6.1 作业计划制定人

职责:

根据需要在系统中制定新的作业计划 7.1.6.2 处理人

处理人是作业计划的具体实施人员，负责完成制定好的作业计划，并对结果进行详细的记录。 职责:

按时完成定义的作业计划

严格按照流程的控制要求完成作业计划 对处理的过程和结果进行详细的记录

如果处理过程中遇到问题，及时与负责人进行沟通，寻求帮助，从而解决问题

7.2 值班管理

7.2.1 目的

值班管理的主要功能是对IT人员的值班工作进行统一的管理，其目的包括： 统一的值班安排

有效安排每个员工的值班时间 用户在线查询值班表 为值班人员提供提醒功能 值班过程的记录

作为历史记录查询的依据

为下一人提供未解决事件的描述

7.2.2 主要内容

值班计划管理

值班计划定义了值班的时间段(如单班、二班、三班等)、值班的人员、值班主管等信息。每个值班计划可以定义一组通报人员，当与本值班计划相关的值班表安排好后，通过邮件通知相关人员相应值班安排情况。

每个值班计划可以关联一个或多个作业计划，值班人员必须在值班过程中完成相关的作业计划。 排班管理

通过排班管理，可以实现值班表进行自动排班或手动调整。值班主管通过系统安排好值班表并通过审核人员审核通过后，值班表正式生效。

自动排班可以选择按月、按季度、按年度排班，或者通过选择排班起止日期来排班。自动排班规则按各省要求具体定义。

自动排班完成后可以对生成的值班表进行手动调整。 交

交功能是当前值班人与下一值班人的工作交接过程。值班人确认时，必须填写值班过程中的遗留问题以供人继续处理。值班人后，将不能执行除取消外的任何操作。当前值班人后至下一值班人确定前，应该继续负责值班工作。

值班日志

值班日志记录记录了值班人在值班过程中的一切工作内容，包括值班过程中的事件记录以及值班作业计划的执行。

当前值班人可以通过查询历史值班记录了解到过往的值班情况。

7.2.3 执行原则 7.2.3.1 交原则

原定值班作业计划未完成时，不能进行工作

在下一人之前，当前值班人作为责任人，需要继续完成值班工作 时必须提交遗留问题记录 7.2.3.2 排班原则

尽量合理安排每个人员的值班，包括时间段和次数的平均分配 提出值班表的变更时，必须在值班时间到达前一天提出

有多个值班人同时值班时，必需从中指定一个值班负责人，相关的交工作由此负责人完成 7.2.3.3 配置信息管理原则

可以对节假日进行定义，在值班表上应能体现出节假日的标识

7.2.4 相关定义

7.2.4.1 值班记录(排班表)信息项

值班记录在排班操作时产生，值班记录必须包含如下信息项，各省可以在此基础上扩充：

表20． 排班表信息项

序号 1 2 3 4 5 信息项 值班记录ID 值班时间 值班负责人 其他值班人 关联的值班作业 值班记录唯一标识 表示值班的起止时间 值班负责人的相关信息 其他值班人的相关信息 说明 关联的值班作业信息（时系统派发值班作业后自动产生） 7.2.4.2 值班记事信息项

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

表21． 值班记事信息项

序号 1 2 3 信息项 值班记事ID 值班记录ID 发生时间 说明 值班记事流水号（系统自动产生） 定义本值班记事是由哪一个值班记录产生（系统自动产生） 发生时间（手动填写） 序号 4 5 信息项 记录内容 记录人 说明 描述值班记事的详细内容（手动填写） 填写此值班记事的操作人（系统自动产生） 7.2.4.3 交记录

交记录必须包含如下信息项，各省可以在此基础上扩充：

表22． 交记录信息项

序号 1 2 3 4 信息项 值班记录ID 遗留问题 时间 时间 说明 定义本操作关联的值班记录流水号（系统自动产生） 描述时需要下一班需要继续处理的事情（手动填写） 操作的时间（系统自动产生） 操作的时间（系统自动产生） 7.2.5 值班管理概要流程(710)

图28. 值班管理流程

流程说明如下： 序号 步骤名称 值班工作 填写遗留问题，确认 检查遗留问题 确认 更新值班人信息，派发值班作业给值班人 完成值班作业 记录值班记事 说明 有未完工作时详细供述遗留问题，以便一下人继续完成 检查遗留问题，如果发现有疑问，及时与值班人进行沟通 下一值班人变更为当前值班人，重复的工作 7.2.6 关键角色、职责定义

7.2.6.1 值班人员

值班人员负责值班工作，完成定义的值班作业计划并进行记录。 职责:

准时到达值班岗位，接替上一值班人的工作 接受上一值班人的遗留问题并加以解决 按时完成定义的值班作业计划并进行记录 记录值班过程中所遇到的突发事件 7.2.6.2 值班主管

值班主管负责的值班调度工作，是值班的负责人。 职责:

定期安排后续的值班工作

对值班人提出的班次调度进行审核确认

过通值班日志以及值班作业计划记录定期检查值班人员的工作情况 对值班过程中所遇到的问题进行协调

7.3 公告

7.3.1 目的

公告管理目的包括： 信息通知功能

发布信息给所有使用本系统的用户 记录公告的访问日志信息

7.3.2 主要内容

公告管理包含下述主要内容： 信息发布

所有使用者都可以发布信息，发布要素至少包括标题、内容、有效期等。 信息审核

审核人收到使用者的信息，对其发布的内容进行审核，通过后信息正式发布。 日志记录

用户查看公告时记录用户查看的时间、用户名，供统计使用。

7.3.3 执行原则 7.3.3.1 发布原则

所以信息的发布都必须经过审核员审核 公告的有效期一般不超过一个月 对大多数用户有效的信息发可进行发布

7.3.4 相关定义

7.3.4.1 公告信息项

公告必须包含如下信息项，各省可以在此基础上扩充： 序号 1 信息项 公告ID 系统自动产生 说明 序号 2 4 5 6 7 8 9 信息项 创建时间 标题 内容 审核人 审核时间 有效期 创建人 系统自动产生 公告的标题 公告的具体内容 公告的审核人 公告的审核时间 公告有效期 公告的创建人 说明 7.3.5 流程定义

7.3.5.1 信息发布流程(740)

图29. 信息发布流程

信息发布流程说明如下： 序号 步骤名称 提出发布申请 审核 通过吗 说明 发布要素至少包括标题、内容、有效期等 如有需要可以添加附件 根据提交的信息进行审核 正式发布信息，所有使用者可以查看此公告 发布信息 7.3.6 关键角色、职责定义

7.3.6.1 用户

职责:

保证发布的信息对系统中50%以上的用户有效 保证发布信息内容及时、正确 7.3.6.2 审核人

职责:

对不必要的信息进行过滤

检查信息的内容是否填写正确，如生效时间等

7.4 知识库

7.4.1 目的

通过对知识库维护和使用，不仅可以在故障自动处理和人工处理的过程中在知识库中得到相关故障维护的分类和快速定位，找到匹配的处理案例，便于处理人进行借鉴，而且知识库具有的业务帮助功能，使相关人员可以通过关键字查询业务帮助、产品、市场活动、发生过的处理流程、电子文档等。

知识库管理也包括对相关文档（如系统业务需求书、方案建议书、设计文档等）的管理。

7.4.2 主要内容

知识库包含知识管理和文档管理，主要包含下述主要内容： 知识管理

知识的输入：系统提供人工和自动的方式进行知识库的添加，对输入的知识库信息审核（是否是重复的知识库信息等）。

知识的分类：提供目录导航功能，使检索人员可以方便直观的检索信息。目录结构的设计是运维业务管理知识的高度总结。

查询、检索功能：系统提供完善的查询和全文检索功能，例如：知识列表、关键字查询等。提供日常查询界面，供运维人员获取、学习。

知识库接口：为其他功能模块提供主题相关的访问入口以及从其他功能模块创建新知识的入口。 文档管理

管理各种文档，如规章制度、项目设计文档、项目实施文档、培训文档等 文档的历史版本管理 文档的检索功能

7.4.3 执行原则

7.4.3.1 知识创建原则

知识创建后状态为未分类以及待审核

由管理员进行知识的审核和分类后，方可正式发布

创建知识时，首先检索一下系统里有没有相同的知识，避免出现重复的数据 7.4.3.2 知识库维护

知识的扩充应该是一个持续的过程，通过不断总结系统的运维维护过程出现的问题，对知识库进行知识扩充

知识随着时间的推移，有过期的概念，对过期的知识应该从系统的删除，避免对后续的工作产生误导作用

管理员定期收集对已有知识的改进/修正意见，及时更新知识内容

7.4.4 相关定义

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

表23． 知识单信息项

序号 1 2 3 信息项 知识ID 创建时间 分类 系统自动产生 系统自动产生 参见知识分类 说明 序号 4 5 6 7 8 信息项 标题 内容 关键字 有效期 创建人 知识的标题 知识的具体内容 知识的关键字 知识的有有效期 知识的创建人 说明 7.4.5 流程定义

7.4.5.1 知识创建流程(730)

图30. 知识创建流程

知识创建流程说明如下： 序号 步骤名称 创建知识 说明 知识可以从事件管理流程、问题管理流程、其他模块的接口或是通过 知识的审核与分类 重复知识吗 手工录入 知识的内容至少包括有标题、内容、分类、关键字、相关附件等 管理员对提交的知识进行检查，包括，知识的内容是否重复、分类及关键字定义是否正确 必要时对分类、关键字、内容等进行修改调整 知识正式发布 发布知识 7.4.6 关键角色、职责定义

7.4.6.1 用户

职责:

确保录入的信息的正确性 指定录入知识的有效期

发现信息有误时及时向管理员汇报 7.4.6.2 知识库管理员

知识库管理员主要负责知识库信息的维护工作。 职责:

确保进入知识库系统的数据分类正确，关键字定义正确 对过期的知识定期进行删除 对相似的知识定期进行合并整理

7.5 机房出入管理（可选）

7.5.1 目的

机房出入管理的主要功能是对出入机房人员的权限进行控制，并记录一切出入机房的活动。其目的包括：

出入权限管理

有效控制出入的人员 出入日志管理

对出入记录定期进行审阅

7.5.2 主要内容

机房出入管理包含下述主要内容： 出入机房人员授权

机房管理人员每季度应准备机房准入人员名单，由部门负责人对有权限进入机房的人员进行复核，如果发现不恰当用户的存在应及时通知机房管理人员取消相应用户的授权。

出入日志审阅

安全管理员每月应对机房进出记录进行审阅，检查是否有异常进出情况。 临时出入审批

临时出入人员需要进入机房时，访问授权由信息技术部门负责人审批，只有经授权的人员才能进入机房。

7.5.3 执行原则 7.5.3.1 出入原则

在准入人员名单内的方可进入机房

临时出入人员必须在系统中查到已审批通过的出入单，并在有权进入机房的人员陪同下，方可进入机房

所有人员出入机房时必须记录出入时间，出入原因 7.5.3.2 审计原则

出入日志每月检查一次 准入人员名单每季度复核一次

7.5.4 相关定义

7.5.4.1 申请单信息项

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

表24． 机房进出申请单信息项

序号 1 2 4 5 6 7 8 9 信息项 申请单ID 创建时间 机房名称 进入人员 进入人员所属部门 进入原因 进入时间 陪同人员 系统自动产生 系统自动产生 申请进入的机房名称 申请进入的人员姓名 说明 申请进入的人员的所属单位、部门 进入机房的原因 申请进入的时间 陪同临时进入人员进机房的人 7.5.5 流程定义

7.5.5.1 出入机房流程(750)

出入机房流程说明如下： 序号 步骤名称 检查人员是否有权限进入机房 登记进入时间 登记出门时间 说明 检查是否在准入人员名单内 临时人员必须有已审核的申请单，且有准入人员陪同 不满足条件的人员拒绝进入机房 包括有进入时间，人员名单，事由等 7.5.5.2 临时出入审批流程(751)

图31. 临时出入审批流程

临时出入审批流程说明如下： 序号 步骤名称 提出申请 进入审批 同意吗 说明 内容包括机房名称、进入人员、进入人员所属部门、进入原因、进入时间等 检查并确认申请人是否可以进入机房 通知人员包括申请人与申请进入的人员 通知相关人员处理结果 7.5.5.3 准入人员复核流程(752)

图32. 准入人员复核流程

流程说明如下： 序号 步骤名称 说明 每季自动生成核单 提交人员名单 检查人员名单 同意吗 更新准入人名单，通知机房管理员 7.5.6 关键角色、职责定义

7.5.6.1 机房管理员

机房管理员负责本机房的安全工作，并对出入活动进行检查和记录。 职责:

对进入机房的人员进行身份检查 拒绝没有经过授权的进入机房活动 记录人员的出入时间、原因 定期提交准入人员名单给审核人 7.5.6.2 审核人

职责:

定期审核机房出入日志 定期审核准入人员名单

对临时进入机房的人员进行审批 7.5.6.3 准入人员

职责:

配合机房管理员进行身份的确认工作 配合机房管理员进行出入日志的记录 陪同经过审批的临时出入人员进行机房 确保自己及临时出入人员在机房的活动安全

8 附件A: CI属性设计

以下列出CI的详细属性设计，作为各省CI设计的基准，同时作为上报集团的要求，各省可以在此基础上，自行扩充CI的属性。

* 注: 星号标注的为关键CI和关键CI属性。关键CI的关键属性的日常维护和定期审核必须严格按照要求进行，必须保证关键CI的关键属性信息的准确性和时效性。在保证关键CI信息维护准确的前提下鼓励管理和维护非关键CI及非关键CI属性。

8.1 硬件类CI

8.1.1 * 小型机和PC服务器

小型机CI特指硬件，如果该小型机划分为分区，则在逻辑实体-分区服务器CI中记录相应的分区信息；

属性名称 CI的通用属性 资产号 *型号 序列号 *TPCC *CPU描述 *内存大小 *内置硬盘描述 专用设备 光纤通道卡 其他板卡 分区标志 *操作系统 网卡描述 *IP地址 *缺省网关 MAC地址 *系统交换区大小 *文件系统信息 *逻辑卷信息 重启时间 说明 参见”3.6.2 CI的通用属性”中的定义和要求 该CI的资产编号 小型机的型号 小型机的序列号 小型机的TPCC值 小型机的CPU个数、型号和主频描述 小型机内存大小(GB) 小型机的内置硬盘描述，分别描述硬盘的型号和大小 该小型机所使用的专有设备 光纤通道卡的详细描述 其他该CI使用的板卡 如果该主机划分了分区，该项目填“是”，否则填“否”。 操作系统及版本号的描述，如果该CI划分分区，则操作系统在分区服务器中描述 网卡的型号，多个网卡依次描述 多个网卡请依次描述 小型机的缺省网关 多个网卡请依次描述 系统交换区的大小，如果该CI划分分区，则系统交换区大小在分区服务器中描述(GB) 文件系统的名称和空间大小，如果该CI划分分区，则文件系统信息在分区服务器中描述 逻辑卷信息：逻辑名、逻辑卷路径和大小，如果该CI划分分区，则操作系统在分区服务器中描述 小型机最近重新启动的时间 对应KPI-ID CM-00-01-001-04 CM-00-01-001-05 CM-00-01-001-06 CM-00-01-001-07 CM-00-01-001-09 CM-00-01-001-08 CM-00-01-001-11 CM-00-01-001-12 CM-00-01-001-13 CM-00-01-001-16 CM-00-01-001-17 CM-00-01-001-14 CM-00-01-001-15 8.1.2 * 分区服务器

属性名称 CI的通用属性 说明 参见”3.6.2 CI的通用属性”中的定义和要求 *逻辑卷信息 *CPU描述 *内存大小 *内置硬盘描述 *操作系统 网卡描述 *IP地址 *缺省网关 MAC地址 *系统交换区大小 *文件系统名称 文件系统总空间 操作系统序列号 专用设备 分区服务器的逻辑卷信息：逻辑名、逻辑卷路径和大小 分区服务器的CPU个数、型号、主频等详细描述 分区服务器内存大小(GB) 分区服务器的内置硬盘描述，分别描述硬盘的型号和大小 分区服务器的操作系统 网卡的型号，多个网卡依次描 多个网卡请依次描述 小型机的缺省网关 多个网卡请依次描述 系统交换区的大小(GB) 文件系统的名称 文件系统的总空间大小 主机运行操作系统的软件所需的序列号，如windows 的激活序列号。 Unix可能没有该序列号 该分区服务器使用的专用设备 8.1.3 * 路由器和交换机

属性名称 CI的通用属性 资产号 *型号 序列号 说明 参见”3.6.2 CI的通用属性”中的定义和要求 路由器的固定资产号码 路由器的型号 路由器的序列号 对应KPI-ID CM-00-02-001-01 CM-00-02-001-05 CM-00-02-001-03 管理IP地址 管理该路由器的IP地址 *操作系统版本 路由器操作系统的名称和版本 槽位信息 槽位数量以及相应描述，包括：总槽位数和可用槽位数 * 端口信息 各工作端口链路层、网络层信息(IP地址等)，总端口数和可用端口数 CM-00-02-002-01 CM-00-02-002-02 CM-00-02-002-03 CM-00-02-002-04 CM-00-02-002-05 CM-00-02-002-06 8.1.4 * 磁带库

属性名称 CI的通用属性 资产号 *型号 序列号 说明 参见”3.6.2 CI的通用属性”中的定义和要求 磁带库的固定资产编号 磁带库的型号 磁带库的序列号 对应KPI-ID CM-00-06-001-02 CM-00-06-001-05 CM-00-06-001-06 磁带驱动器型号 磁带驱动器的型号 *磁带驱动器数量 磁带驱动器的数量 磁带型号 兼容使用的磁带的型号 *容量 连接方式 可装载磁带数量 磁带库的总容量(GB) 可选项：光纤/SCSI 可装载的磁带数量 CM-00-06-001-07 8.1.5 * 存储光纤交换机

属性名称 CI的通用属性 资产号 *型号 说明 参见”3.6.2 CI的通用属性”中的定义和要求 存储光纤交换机的固定资产编号 存储光纤交换机的型号 序列号 *管理IP地址 Domain-ID *槽位信息 *端口数量 存储光纤交换机的序列号 管理该存储光纤交换机的IP地址 该存储光纤交换机的Domain ID 槽位数量以及相应描述，包括：总槽位数和可用槽位数 端口（1G、2G、其他）信息，总端口数和可用端口数 8.1.6 * 磁盘阵列

属性名称 CI的通用属性 资产号 *型号 序列号 *磁盘描述 微码版本 *磁盘裸容量 *磁盘有效容量 *RAID方式 CACHE容量 磁盘适配器标识 *磁盘适配卡类型 *通道卡类型 通道卡槽位信息 端口数量 说明 参见”3.6.2 CI的通用属性”中的定义和要求 磁盘阵列的固定资产编号 磁盘阵列的型号 磁盘阵列的序列号 磁盘（18GB、36GB、73GB、146GB、其他容量）信息，包括：单盘容量、数量和热备盘数量 磁盘阵列的微码版本 该磁盘阵列的裸容量大小(GB) 该磁盘阵列的有效容量大小(GB) 该磁盘阵列的RAID方式 磁盘阵列的CACHE容量 磁盘阵列的磁盘适配器的标识 可选项：光纤/SCSI/UltralSCSI/SSA等 可选项：光纤/SCSI/UltralSCSI/ESCON等 通道卡槽位数量以及相应描述，总槽位数和可用通道卡槽位数 端口（1G、2G、其他）信息，总端口数和可用端口数 对应KPI-ID CM-00-05-001-03 CM-00-05-002-05 CM-00-05-001-04 CM-00-05-002-02 CM-00-05-002-03 CM-00-05-002-10 CM-00-05-002-07 8.1.7 光盘库

属性名称 CI的通用属性 型号 序列号 磁盘描述 微码版本 磁盘总容量 磁盘可用容量 磁盘适配器标识 磁盘适配卡类型 主机通道卡类型 主机通道卡数目 主机通道卡标识 资产号 说明 参见”3.6.2 CI的通用属性”中的定义和要求 光盘库的型号 光盘库的序列号 光盘库的磁盘情况描述 光盘库的微码版本 光盘库的总容量大小 光盘库的可用容量大小 光盘库的磁盘适配器标识 可选项：光纤/SCSI/UltralSCSI/SSA等 可选项：光纤/SCSI/UltralSCSI/ESCON等 主机通道卡的数量 主机通道卡的标识 光盘库的固定资产编号 8.1.8 链路

属性名称 说明 CI的通用属性 属性 链路类型 带宽 运营商 资费 参见”3.6.2 CI的通用属性”中的定义和要求 可选项：自建/租用 可选想：光纤/DDN/ISDN等 带宽描述 该链路的运营商 该链路的资费情况说明 8.1.9 安全设备

属性名称 CI的通用属性 资产号 序列号 管理IP地址 型号 操作系统 端口数量 槽位信息 详细描述 说明 参见”3.6.2 CI的通用属性”中的定义和要求 防火墙的固定资产号码 防火墙的序列号 管理该防火墙的IP地址 防火墙的型号 防火墙操作系统的名称和版本 端口数量 槽位数量以及相应描述 该设备各种功能属性的说明 8.2 系统软件类CI

8.2.1 操作系统

操作系统CI指每一个被安装的操作系统； 属性名称 说明 CM-00-01-001-08 对应KPI-ID CI的通用属性 参见”3.6.2 CI的通用属性”中的定义和要求 资产号 版本 补丁版本 序列号 License数目 操作系统的固定资产编号 操作系统的版本号 主要补丁版本 操作系统的序列号 操作系统License数量 8.2.2 * 数据库

数据库CI指每一个被安装的数据库实例； 属性名称 CI的通用属性 序列号 资产号 *版本 *补丁版本 *License数目 *实例名 *端口号 数据库位数 *安装路径 说明 参见”3.6.2 CI的通用属性”中的定义和要求 数据库的序列号 数据库的固定资产编号 数据库的版本 数据库的主要补丁版本 数据库的License数量 数据库的实例名称 数据库的监听端口号 数据库的位数 数据库的安装路径 对应KPI-ID CM-00-03-001-02 CM-00-03-001-03 *分配内存大小 分配给数据库的内存大小(MB) 8.2.3 * 中间件

属性名称 CI的通用属性 序列号 资产号 *中间件类别 *版本 *补丁版本 *应用服务器运行模式 License数目 端口号 客户端最大并发连接数 数据库最大并发连接数 *系统日志路径 中间件的用户日志路径 用户日志路径 配置的队列空间大小 配置的队列所在路径 单条队列所允许的消息总个数 单条队列所占字节数 队列模式 允许应用服务器支配的内存堆大小（MB） 配置的总线程数 配置的数据库连接池大小 传输中间件配置的所有队列所占字节数(MB) 传输中间件在队列模式为磁盘队列时有效 传输中间件单条队列所允许的消息总个数 传输中间件单条队列所占字节数(MB) 传输中间件队列属性是内存队列还是磁盘队列 允许应用服务器支配的内存堆大小（MB） 应用服务器配置的总线程数 应用服务器配置的数据库连接池大小 备注 参见”3.6.2 CI的通用属性”中的定义和要求 中间件的序列号 对应KPI-ID 中间件的固定资产编号 选择项：交易中间件/传输中间件/应用服务器 中间件的版本号码 中间件的主要补丁版本 应用服务器群集还是单机 中间件的License数目 中间件监听的端口号 中间件的客户端最大并发连接数 中间件的数据库最大并发连接数 中间件的系统日志路径 CM-00-04-001-02 CM-00-04-001-01 CM-00-04-001-03 CM-00-04-003-05 CM-00-04-001-04 CM-00-04-003-06 CM-00-04-002-01 CM-00-04-002-02 CM-00-04-002-03 CM-00-04-002-04 CM-00-04-002-05 CM-00-04-003-02 CM-00-04-003-03 CM-00-04-003-04 8.2.4 集群

属性名称 CI的通用属性 版本 补丁 成员列表 服务包列表 说明 参见”3.6.2 CI的通用属性”中的定义和要求 集群软件版本 集群软件补丁版本 构成集群的主机列表 群集包含的服务包列表 8.2.5 存储备份软件、系统管理软件和工具软件

属性名称 CI的通用属性 序列号 资产号 版本 补丁版本 License数目 备注 参见”3.6.2 CI的通用属性”中的定义和要求 存储备份软件的序列号 存储备份软件的固定资产编号 存储备份软件的版本号码 存储备份软件的主要补丁版本 存储备份软件的License数目 8.2.6 安全软件

属性名称 CI的通用属性 资产号 序列号 说明 参见”3.6.2 CI的通用属性”中的定义和要求 防火墙的固定资产号码 防火墙的序列号 管理IP地址 型号 操作系统 端口数量 槽位信息 详细描述 管理该防火墙的IP地址 防火墙的型号 防火墙操作系统的名称和版本 端口数量 槽位数量以及相应描述 该设备各种功能属性的说明 8.3 客服设备类CI

8.3.1 排队机

属性名称 CI的通用属性 资产号 序列号 型号 设备版本号 软件说明 中继总数量 中继呼出数量 远端模块说明 备注 说明 参见”3.6.2 CI的通用属性”中的定义和要求 排队机的固定资产编号 排队机的序列号 排队机的型号 排队机的版本号 排队机使用的软件名称及版本号 排队机中继的总数量 排队机中继的呼出数量 排队机的远端模块的说明 8.3.2 CTI

属性名称 CI的通用属性 资产号 序列号 型号 应用软件厂商 应用软件名称 应用软件版本 说明 参见”3.6.2 CI的通用属性”中的定义和要求 排队机的固定资产编号 IVR/CCS的序列号 IVR/CCS的型号 CTI应用的软件厂商 CTI应用软件的名称 CTI应用软件的版本号 8.3.3 IVR和CCS

属性名称 CI的通用属性 资产号 序列号 型号 语音资源数量（E1） 语音资源连接方式 说明 参见”3.6.2 CI的通用属性”中的定义和要求 排队机的固定资产编号 IVR/CCS的序列号 IVR/CCS的型号 IVR/CCS的语音资源数量 IVR/CCS语音资源的连接方式 8.4 配套设施CI

属性名称 CI的通用属性 资产号 管理IP地址 型号 详细描述 说明 参见”3.6.2 CI的通用属性”中的定义和要求 固定资产号码 管理该防火墙的IP地址 防火墙的型号 该设备各种功能属性的说明 8.5 业务应用类CI

8.5.1 BOSS、经营分析、客服应用

属性名称 CI的通用属性 版本 补丁版本 中间件端口号 说明 参见”3.6.2 CI的通用属性”中的定义和要求 应用程序主版本 业务应用程序补丁版本 与应用程序运行相关的中间件监听的端口号 8.5.2 容灾、BOMC、其他应用

属性名称 CI的通用属性 版本 补丁版本 中间件端口号 说明 参见”3.6.2 CI的通用属性”中的定义和要求 应用程序主版本 业务应用程序补丁版本 与应用程序运行相关的中间件监听的端口号 8.6 文档类CI

8.6.1 手册

属性名称 搜索代码 名称 系统名称 模块名称 子模块名称 物理位置 使用部门 创建时间 删除状态 删除时间 审核状态 最近审核时间 CI管理员 最后更新人 最后更新时间 管理员 状态 用途 发布日期 版本信息 更新人 最后更新日期 备注 说明 唯一识别 手册的名称 该CI所属的系统名称 该CI所属系统的模块名称 该CI所属系统的子模块名称 该手册存放的物理位置 该手册的使用部门 手册CI被创建的时间 手册CI是否被删除；正常/已删除 手册CI被删除的时间 手册CI的审核状态；未审核/已审核/不匹配/丢失 最近一次被审核的时间 在服务管理平台中管理该CI的人员 最后更新该CI的人员 该CI最后被更新的时间 手册保管员 手册状态 手册的用途 手册投入使用日期 手册版本信息 手册更新人 手册最后更新日期 8.6.2 合同

属性名称 搜索代码 名称 系统名称 模块名称 子模块名称 唯一识别 合同的名称 该CI所属的系统名称 该CI所属系统的模块名称 该CI所属系统的子模块名称 说明 物理位置 使用部门 创建时间 删除状态 删除时间 审核状态 最近审核时间 CI管理员 最后更新人 最后更新时间 管理员 状态 备注 该合同存放的物理位置 该合同的使用部门 合同CI被创建的时间 合同CI是否被删除；正常/已删除 合同CI被删除的时间 合同CI的审核状态；未审核/已审核/不匹配/丢失 最近一次被审核的时间 在服务管理平台中管理该CI的人员 最后更新该CI的人员 该CI最后被更新的时间 合同保管员 合同状态 8.7 逻辑实体类CI

8.7.1 进程

进程CI主要记录各类应用软件的进程；

属性名称 CI的通用属性 进程描述 执行目录 运行用户 说明 参见”3.6.2 CI的通用属性”中的定义和要求 该进程的详细描述 该进程运行的文件目录 对应的操作系统用户 8.7.2 中间件服务

属性名称 CI的通用属性 中间件服务描述 执行目录 运行用户 说明 参见”3.6.2 CI的通用属性”中的定义和要求 该中间件服务的详细描述 该服务运行的文件目录 对应的操作系统用户 8.7.3 数据库对象

属性名称 CI的通用属性 数据库对象描述 对象属主 说明 参见”3.6.2 CI的通用属性”中的定义和要求 该数据库对象的详细描述 对应的数据库用户 8.8 安全设备类CI

8.8.1 * 防火墙

属性名称 CI的通用属性 资产号 序列号 *管理IP地址 *型号 *操作系统 说明 参见”3.6.2 CI的通用属性”中的定义和要求 防火墙的固定资产号码 防火墙的序列号 管理该防火墙的IP地址 防火墙的型号 防火墙操作系统的名称和版本 *端口数量 槽位信息 详细描述 端口数量 槽位数量以及相应描述 该设备各种功能属性的说明 8.9 其他类CI

8.9.1 IT人员

属性名称 搜索代码 姓名 员工号 职位 部门 Email地址 电话 办公地点 审核状态 最近审核时间 CI管理员 最后更新人 最后更新时间 创建时间 删除状态 删除时间 备注 说明 维护人员的唯一ID 维护人员姓名 维护人员员工号 维护人员职位 维护人员所在部门 维护人员e-mail地址 维护人员电话 维护人员办公地点 该CI的审核状态；未审核/已审核/不匹配/丢失 最近一次被审核的时间 在服务管理平台中管理该CI的人员 最后更新该CI的人员 该CI最后被更新的时间 该CI被创建的时间 该CI是否被删除；正常/已删除 该CI被删除的时间 8.9.2 供应商

属性名称 搜索代码 名称 联系方式 联系人 传真 办公地点 审核状态 最近审核时间 CI管理员 最后更新人 最后更新时间 创建时间 删除状态 删除时间 备注 说明 供应商唯一ID 供应商名称 供应商联系方式 供应商联系人 供应商传真 供应商办公地点 该CI的审核状态；未审核/已审核/不匹配/丢失 最近一次被审核的时间 在服务管理平台中管理该CI的人员 最后更新该CI的人员 该CI最后被更新的时间 该CI被创建的时间 该CI是否被删除；正常/已删除 该CI被删除的时间 8.9.3 机房

属性名称 搜索代码 名称 场所位置 面积 电话 UPS容量 UPS维护管理员 空调容量 机房唯一ID 机房名称 机房场所位置 机房面积 机房值班电话 UPS总功率 UPS维护管理员 机房空调制冷功率 说明 空调管理员 审核状态 最近审核时间 CI管理员 最后更新人 最后更新时间 创建时间 删除状态 删除时间 备注 空调管理员 该CI的审核状态；未审核/已审核/不匹配/丢失 最近一次被审核的时间 在服务管理平台中管理该CI的人员 最后更新该CI的人员 该CI最后被更新的时间 该CI被创建的时间 该CI是否被删除；正常/已删除 该CI被删除的时间 8.9.4 关键地市

属性名称 搜索代码 名称 地址 地市公司负责人 地市公司IT负责人 地市公司IT维护负责人 审核状态 最近审核时间 CI管理员 最后更新人 最后更新时间 创建时间 删除状态 删除时间 备注 说明 地市唯一ID 地市公司名称 公司地址 该地市公司的公司负责人 该地市公司的IT部门负责人 该地市公司的维护负责人 该CI的审核状态；未审核/已审核/不匹配/丢失 最近一次被审核的时间 在服务管理平台中管理该CI的人员 最后更新该CI的人员 该CI最后被更新的时间 该CI被创建的时间 该CI是否被删除；正常/已删除 该CI被删除的时间 9 附录B: CI关系对照表

具体CI之间的关系定义如下表，未列出的CI之间关系可以按照CI关系的定义自行确定。 * 注: 星号标注的为关键关系。关键CI间的关键关系的日常维护和定期审核必须严格按照要求进行，必须保证关键CI的关键关系信息的准确性和时效性。

CI类 *小型机 *小型机 *小型机 *小型机 *小型机 小型机 *小型机 *小型机 *小型机 小型机 小型机 小型机 *小型机 小型机 小型机 小型机 小型机 小型机 小型机 小型机 小型机 小型机 小型机 小型机 小型机 小型机 小型机 CI类 路由器 网络交换机 磁盘阵列 存储光纤交换机 磁带库 光盘库 操作系统 数据库 中间件 存储备份软件 系统管理软件 工具软件 业务应用 防病毒系统 防垃圾邮件 漏洞扫描器 身份认证和帐号管理 防DoS攻击 终端管理软件 安全审计软件 SOC系统 文档 集群 进程 中间件服务 数据库对象 分区服务器 关系代码 连接关系 连接关系 连接关系 连接关系 连接关系 连接关系 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 文档关联 父/子关系 安装在 … 上 安装在 … 上 安装在 … 上 父/子关系 *PC服务器 *PC服务器 *PC服务器 *PC服务器 *PC服务器 PC服务器 PC服务器 *PC服务器 *PC服务器 PC服务器 PC服务器 路由器 网络交换机 磁盘阵列 存储光纤交换机 磁带库 光盘库 操作系统 数据库 中间件 存储备份软件 系统管理软件 连接关系 连接关系 连接关系 连接关系 连接关系 连接关系 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 工具软件 业务应用 防病毒系统 防垃圾邮件 漏洞扫描器 身份认证和帐号管理 防DoS攻击 终端管理软件 安全审计软件 SOC系统 文档 进程 中间件服务 数据库对象 分区服务器 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 文档关联 安装在 … 上 安装在 … 上 安装在 … 上 父/子关系 路由器 路由器 *路由器 路由器 路由器 路由器 路由器 路由器 *路由器 路由器 路由器 小型机 PC服务器 路由器 防火墙 IDS入侵监测系统 IPS入侵防护系统 防毒墙 链路 网络交换机 文档 分区服务器 连接关系 连接关系 连接关系 连接关系 连接关系 连接关系 连接关系 连接关系 连接关系 文档关联 连接关系 网络交换机 网络交换机 网络交换机 网络交换机 网络交换机 网络交换机 网络交换机 网络交换机 网络交换机 网络交换机 小型机 PC服务器 路由器 网络交换机 防火墙 IDS入侵监测系统 IPS入侵防护系统 防毒墙 文档 分区服务器 连接关系 连接关系 连接关系 连接关系 连接关系 连接关系 连接关系 连接关系 文档关联 连接关系 磁盘阵列 磁盘阵列 磁盘阵列 磁盘阵列 *磁盘阵列 小型机 PC服务器 文档 分区服务器 存储光纤交换机 连接关系 连接关系 文档关联 连接关系 连接关系 存储光纤交换机 存储光纤交换机 小型机 PC服务器 连接关系 连接关系 存储光纤交换机 存储光纤交换机 存储光纤交换机 文档 分区服务器 磁盘阵列 文档关联 连接关系 连接关系 磁带库 磁带库 磁带库 磁带库 小型机 PC服务器 文档 分区服务器 连接关系 连接关系 文档关联 连接关系 光盘库 光盘库 光盘库 光盘库 小型机 PC服务器 文档 分区服务器 连接关系 连接关系 文档关联 连接关系 链路 链路 路由器 PC服务器 连接关系 连接关系 排队机 CTI IVR CCS 文档 文档 文档 文档 文档关联 文档关联 文档关联 文档关联 操作系统 操作系统 操作系统 操作系统 操作系统 操作系统 操作系统 小型机 PC服务器 数据库 中间件 业务应用 文档 分区服务器 安装在 … 上 安装在 … 上 依赖关系 依赖关系 依赖关系 文档关联 安装在 … 上 数据库 数据库 数据库 数据库 数据库 数据库 数据库 小型机 PC服务器 操作系统 中间件 业务应用 文档 分区服务器 安装在 … 上 安装在 … 上 依赖关系 依赖关系 依赖关系 文档关联 安装在 … 上 中间件 中间件 中间件 中间件 中间件 中间件 中间件 小型机 PC服务器 操作系统 数据库 业务应用 文档 分区服务器 安装在 … 上 安装在 … 上 依赖关系 依赖关系 依赖关系 文档关联 安装在 … 上 存储备份软件 存储备份软件 小型机 PC服务器 安装在 … 上 安装在 … 上 存储备份软件 存储备份软件 存储备份软件 文档 光盘库 磁带库 文档关联 依赖关系 依赖关系 系统管理软件 系统管理软件 系统管理软件 小型机 PC服务器 文档 安装在 … 上 安装在 … 上 文档关联 工具软件 工具软件 工具软件 小型机 PC服务器 文档 安装在 … 上 安装在 … 上 文档关联 *业务应用 *业务应用 业务应用 *业务应用 *业务应用 *业务应用 业务应用 业务应用 小型机 PC服务器 操作系统 数据库 中间件 业务应用 文档 分区服务器 安装在 … 上 安装在 … 上 依赖关系 依赖关系 依赖关系 父子关系/依赖关系 文档关联 安装在 … 上 文档 文档 文档 文档 文档 文档 文档 文档 文档 文档 文档 文档 文档 文档 文档 文档 文档 文档 文档 文档 文档 小型机 PC服务器 路由器 网络交换机 磁盘阵列 存储光纤交换机 磁带库 光盘库 排队机 CTI IVR CCS 操作系统 数据库 中间件 存储备份软件 系统管理软件 工具软件 业务应用 集群软件 分区服务器 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 文档关联 *集群 集群 *集群 小型机 文档 分区服务器 父/子关系 文档关联 父/子关系 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 小型机 路由器 网络交换机 磁盘阵列 存储光纤交换机 磁带库 光盘库 操作系统 数据库 中间件 存储备份软件 系统管理软件 工具软件 业务应用 防病毒系统 防垃圾邮件 漏洞扫描器 身份认证和帐号管理 防DoS攻击 终端管理软件 安全审计软件 SOC系统 文档 集群 进程 中间件服务 数据库对象 父子关系 连接关系 连接关系 连接关系 连接关系 连接关系 连接关系 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 文档关联 父/子关系 安装在 … 上 安装在 … 上 安装在 … 上 进程 进程 进程 进程 进程 小型机 PC服务器 分区服务器 中间件服务 数据库对象 安装在 … 上 安装在 … 上 安装在 … 上 依赖关系 依赖关系 中间件服务 中间件服务 中间件服务 中间件服务 中间件服务 小型机 PC服务器 分区服务器 进程 数据库对象 安装在 … 上 安装在 … 上 安装在 … 上 依赖关系 依赖关系 数据库对象 数据库对象 数据库对象 数据库对象 数据库对象 小型机 PC服务器 分区服务器 进程 中间件服务 安装在 … 上 安装在 … 上 安装在 … 上 依赖关系 依赖关系 防火墙 路由器 连接关系 IDS入侵监测系统 IPS入侵防护系统 防毒墙 路由器 路由器 路由器 连接关系 连接关系 连接关系 防火墙 IDS入侵监测系统 IPS入侵防护系统 防毒墙 网络交换机 网络交换机 网络交换机 网络交换机 连接关系 连接关系 连接关系 连接关系 防病毒系统 防垃圾邮件 漏洞扫描器 身份认证和帐号管理 防DoS攻击 终端管理软件 安全审计软件 SOC系统 小型机 小型机 小型机 小型机 小型机 小型机 小型机 小型机 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 防病毒系统 防垃圾邮件 漏洞扫描器 身份认证和帐号管理 防DoS攻击 终端管理软件 安全审计软件 SOC系统 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 PC服务器 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 防病毒系统 防垃圾邮件 漏洞扫描器 身份认证和帐号管理 防DoS攻击 终端管理软件 安全审计软件 SOC系统 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 分区服务器 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 安装在 … 上 10 附录C: 厂商和集成商名称标准

本章节厂商和集成商名称标准用来规范配置项属性中”厂商”和”集成商”的信息，同时也用来规范事件管理中”故障厂商”的填写。

10.1 厂商名称标准

编号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 厂商名称 3COM AVAYA BEA BMC Borland CA Cisco DB2 EMC HDS HP IBM Informix McDATA Microsoft NCR NETAPP Oracle Quantum ATL STK SUN Sybase TERADATA 北电 东方通 中兴 华为 SYMANTEC QUEST REDHAT BROCADE 10.2 集成商名称标准

编号 101 102 集成商名称 亚信 联创 103 104 105 106 107 108 109 110 111 神码思特奇 神州数码 华为 新 亿阳 神州泰岳 创我 新宇 从兴 11 附录D: 省公司上报报表

11.1 事件管理上报报表

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

业务系统 BOSS系统 事件性质 故障 申告 告警 故障 总数 优先级 紧急 高 中 低 客服系统 申告 告警 故障 经营分析 申告 告警 故障 告警 故障 告警 故障 告警 容灾系统 BOMC 其它系统 指标计算方法如下： 序号 指标名称 指标计算说明 数量：在事件单中根据以下条件过滤： 1． 【重复事件标记】为空 1 故障总数 2． 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 3． 【事件发生时间】在统计周期内 4． 【事件性质】＝‘故障’ 数量：在事件单中根据以下条件过滤： 1． 【重复事件标记】为空 2 申告总数 2． 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 3． 【事件发生时间】在统计周期内 4． 【事件性质】＝‘申告’ 数量：在事件单中根据以下条件过滤： 1． 【重复事件标记】为空 3 告警总数 2． 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 3． 【事件发生时间】在统计周期内 4． 【事件性质】＝‘告警’ 4 5 紧急、高、中、低 业务系统 在故障、申告、告警中分别过滤【事件优先级】 分别过滤【所属系统类型】的业务系统 11.1.2 按业务系统细分的故障和优先级分类统计报表

业务系统 故障数量 营销管理 渠道管理 客户服务 产品管理 客户管理 订单与服务请求管理 服务开通 资源管理 综合采集 融合计费 综合帐务 综合结算 合作伙伴管理 基础功能 统计报表 一级BOSS 其它 子类 紧急 优先级 高 中 低 BOSS系统 客服系统 经营分析 容灾系统 BOMC 其它系统 指标计算方法如下： 序号 指标名称 指标计算说明 数量：在事件单中根据以下条件过滤： 1． 【重复事件标记】为空 1 故障总数 2． 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 3． 【事件发生时间】在统计周期内 4． 【事件性质】＝‘故障’ 2 3 紧急、高、中、低 业务系统 在故障、申告、告警中分别过滤【事件优先级】 分别过滤【所属系统类型】的子类 11.1.3 按业务系统和影响度分类统计报表

业务系统 BOSS系统 客服系统 经营分析 容灾系统 BOMC 事件性质 故障 申告 故障 申告 故障 申告 故障 故障 总数 影响度 重大 严重 一般 无 其它系统 故障 指标计算方法如下： 序号 指标名称 指标计算说明 数量：在事件单中根据以下条件过滤： 1． 【重复事件标记】为空 1 故障总数 2． 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 3． 【事件发生时间】在统计周期内 4． 【事件性质】＝‘故障’ 数量：在事件单中根据以下条件过滤： 1． 【重复事件标记】为空 2 申告总数 2． 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 3． 【事件发生时间】在统计周期内 4． 【事件性质】＝‘申告’ 3 4 重大、严重、一般、无 业务系统 在故障、申告总数分别过滤【事件影响度】 分别过滤【所属系统类型】的业务系统 11.1.4 按业务系统细分的故障和影响度分类统计报表

业务系统 故障数量 营销管理 渠道管理 客户服务 产品管理 客户管理 订单与服务请求管理 服务开通 资源管理 综合采集 融合计费 综合帐务 综合结算 合作伙伴管理 基础功能 统计报表 一级BOSS 其它 子类 重大 影响度 严重 一般 无 BOSS系统 客服系统 经营分析 容灾系统 BOMC 其它系统 指标计算方法如下： 序号 1 指标名称 故障总数 指标计算说明 数量：在事件单中根据以下条件过滤： 1． 【重复事件标记】为空 序号 指标名称 指标计算说明 2． 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 3． 【事件发生时间】在统计周期内 4． 【事件性质】＝‘故障’ 2 3 重大、严重、一般、无 业务系统 在故障总数分别过滤【事件影响度】 分别过滤【所属系统类型】的子类 11.1.5 按业务系统统计故障和申告处理效率指标报表

平均解决时间 业务系统 BOSS系统 事件性质 故障 申告 咨询 告警 客服系统 故障 申告 咨询 告警 经营分析 故障 申告 咨询 告警 容灾系统 BOMC 故障 告警 故障 告警 其它系统 故障 告警 总数 服务台解决率 一线解决率 二线解决率 三线解决率 及时解决率 一次解决率 超时未解决数 紧急 高 中 低 指标计算方法如下： 序号 指标名称 故障总数 1 申告总数 咨询总数 告警总数 指标计算说明 数量：在事件单中根据以下条件过滤 1． 【重复事件标记】为空 2． 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 3． 【事件发生时间】在统计周期内 4． 分别统计【事件性质】＝‘故障’、‘申告’、‘咨询’、‘告警’ 数量：在（故障、申告、咨询、告警）总数中过滤所有【事件解决人角色】＝‘服务台’ 2 服务台解决率 序号 指标名称 指标计算说明 比率：数量 / 总数 × 100 % 数量：在（故障、申告、咨询、告警）总数中过滤所有【事件解决人角色】＝‘一线’ 比率：数量 / 总数 × 100 % 数量：在（故障、申告、咨询、告警）总数中过滤所有【事件解决人角色】＝‘二线’ 比率：数量 / 总数 × 100 % 数量：在（故障、申告、咨询、告警）总数中过滤所有【事件解决人角色】＝‘三线’ 比率：数量 / 总数 × 100 % 数量1：在（故障、申告、咨询、告警）总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’ 3 一线解决率 4 二线解决率 4 三线解决率 6 一次解决率 数量2：在（故障、申告、咨询、告警）总数中过滤【事件结束代码】＝‘不成功’ 比率：（数量1 － 数量2） / 数量1 × 100 % 数量：在（故障、申告、咨询、告警）总数中过滤【处理已超时】＝‘超时’and 【事件状态】！＝（‘关闭’or ‘已解决’） 完成的事件：在（故障、申告、咨询、告警）总数中过滤所有【事件状态】＝‘已解决’or ‘关闭’的事件 平均解决时间：累加完成事件的（【实际完成时间】－【登记时间】）/ 完成的事件数量 7 超时未解决数 8 平均解决时间 11.1.6 按事件分类的故障和优先级统计报表

类别 子类 小型机 PC服务器 路由器 系统硬件 网络交换机 磁盘阵列 存储光纤交换机 磁带库 安全设备 操作系统 数据库 中间件 系统软件 集群软件 备份软件 系统管理软件 故障 数量 优先级 紧急 高 中 低 安全软件 进程 数据 应用软件 参数 代码 接口 排队机 客服设备 CTI服务器 CCS IVR服务器 类别 子类 UPS 故障 数量 优先级 紧急 高 中 低 配套设施 空调 其它 指标计算方法如下： 序号 指标名称 指标计算说明 数量：在事件单中根据以下条件过滤： 1． 【重复事件标记】为空 1 故障总数 2． 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 3． 【事件发生时间】在统计周期内 4． 【事件性质】＝‘故障’ 2 3 紧急、高、中、低 事件分类 在故障总数分别过滤【事件优先级】 分别过滤【事件分类】的子类 11.1.7 按业务中断时长分类的统计报表

业务系统 子类 营销管理 故障数量 BOSS系统 客服系统 经营分析 容灾系统 BOMC 其它系统 渠道管理 客户服务 产品管理 客户管理 订单与服务请求管理 服务开通 资源管理 综合采集 融合计费 综合帐务 综合结算 合作伙伴管理 基础功能 统计报表 一级BOSS 其它 业务中断时长 注： 业务中断时长＝业务恢复时间－事件发生时间， 单位为分钟 指标计算方法如下： 序号 1 指标名称 故障数量 指标计算说明 数量：在事件单中根据以下条件过滤： 1． 【重复事件标记】为空 序号 指标名称 指标计算说明 2． 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 3． 【事件发生时间】在统计周期内 4． 【事件性质】＝‘故障’ 2 3 业务中断时长 业务系统分类 【业务恢复时间】－【事件发生时间】 分别过滤【所属系统类型】的子类 11.1.8 故障厂商统计

系统分类 厂商名称 HP 小型机 IBM SUN NCR Cisco 路由器 中兴 3COM 华为 Cisco 网络交换机 中兴 3COM 华为 HP EMC IBM 磁盘阵列 NCR HDS NETAPP SUN HP IBM 存储光纤交换机 McDATA BROCADE EMC HP SUN 磁带库 IBM STK Quantum ATL Oracle DB2 数据库 Microsoft TERADATA Informix Sybase 操作系统 HP IBM 故障数量 重大 严重 一般 SUN CA 系统管理软件 HP BMC IBM BEA 中间件 IBM 东方通科技 Borland 华为 客服设备 AVAYA 北电 注：该报表中的厂商按照各省实际情况上报。 指标计算方法如下： 序号 指标名称 指标计算说明 数量：在事件单中根据以下条件过滤： 1． 【重复事件标记】为空 1 故障数量 2． 【事件结束代码】不等于‘消失’or‘误报’or‘可忽略’ 3． 【事件发生时间】在统计周期内 4． 【事件性质】＝‘故障’ 2 3 重大、严重、一般 故障厂商 在故障数量分别过滤【事件影响度】 分别过滤【故障厂商】 11.2 配置管理上报报表

11.2.1 配置项审核及变化状态报表

配置项审核及变化状态报表用于反映配置项各种审核状态以及新增、删除的数量。

已审核 数比量 例 不匹配 数比例 量 丢失 数量 比例 新增 删除 配置项分类 总数 硬件 小型机 分区服务器 PC服务器 路由器 网络交换机 磁盘阵列 存储光纤交换机 磁带库 合计 指标说明： 序号 1 指标名称 总数 【删除状态】=‘正常‘的CI总数 指标计算说明 2 3 4 5 6 已审核数量/比例 不匹配数量/比例 丢失数量/比例 新增 删除 已审核数量：【删除状态】=‘正常‘and【审核状态】=‘已审核‘的CI总数 比例：已审核数量/总数； 不匹配数量：【删除状态】=‘正常‘and【审核状态】=‘不匹配‘的CI总数 比例：不匹配数量/总数 丢失数量：【删除状态】=‘正常‘and【审核状态】=‘丢失‘的CI总数 比例：丢失数量/总数 新增：【删除状态】=‘正常‘and【创建时间】在统计时间区间内的CI总数 删除：【删除状态】=‘已删除‘and【删除时间】在统计时间区间内的CI总数 11.2.2 配置项汇总报表

配置项汇总报表，用于统计每一类配置项各种状态下的数量；

配置项分类 总数 已安装 测试中 使用中 维护中 报废 备用 硬件 小型机 分区服务器 PC服务器 路由器 网络交换机 磁盘阵列 存储光纤交换机 磁带库 合计 指标说明： 序号 1 2 3 4 5 6 7 指标名称 总数 已安装 测试中 使用中 维护中 报废 备用 指标计算说明 总数：【删除状态】=‘正常‘的总数 已安装：CI总数中，【状态】=‘已安装‘的CI数量 测试中：CI总数中，【状态】=‘测试中‘的CI数量 使用中：CI总数中，【状态】=‘使用中‘的CI数量 维护中：CI总数中，【状态】=‘维护中‘的CI数量 报废：CI总数中，【状态】=‘报废‘的CI数量 备用：CI总数中，【状态】=‘备用‘的CI数量 11.2.3 分应用系统小型机/PC服务器统计表

分系统对小型机/PC服务器的数量和TPCC值进行统计 所属系统 BOSS应用 小型机 PC服务器 小计 经营分析系统 小型机 PC服务器 小计 客服系统 小型机 PC服务器 类型 数量 总TPCC值 小计 容灾系统 小型机 PC服务器 小计 BOMC 小型机 PC服务器 小计 合计 指标说明： 序号 1 2 指标名称 数量 总TPCC值 指标计算说明 数量：【删除状态】=‘正常‘的小型机或PC服务器总数 总TPCC值：【删除状态】=‘正常‘的小型机或PC服务器TPCC累计值 11.2.4 分厂商小型机/PC服务器统计表

分厂商对小型机/PC服务器的数量和TPCC值进行统计

厂商 HP 小计 IBM 小计 SUN 小计 NCR 小计 合计 小型机 PC服务器 小型机 PC服务器 小型机 PC服务器 类型 小型机 PC服务器 数量 总TPCC值 指标说明： 序号 1 2 指标名称 数量 总TPCC值 指标计算说明 数量：【删除状态】=‘正常‘的小型机或PC服务器总数 总TPCC值：【删除状态】=‘正常‘的小型机或PC服务器TPCC累计值 11.2.5 分应用系统磁盘阵列统计表

分应用系统对磁盘阵列的数量和容量进行统计。容量单位统一采用GB。 所属系统 BOSS应用 经营分析系统 客服系统 数量 总容量(裸容量) 总容量(有效容量) 容灾系统 BOMC 合计 指标说明： 序号 1 2 3 指标名称 数量 总容量(裸容量) 总容量(有效容量) 指标计算说明 数量：【删除状态】=‘正常‘的磁盘阵列总数 总容量(裸容量)：【删除状态】=‘正常‘的磁盘阵列裸容量的累计值，按照磁盘阵列CI的‘磁盘裸容量‘属性计算 总容量(有效容量)：【删除状态】=‘正常‘的磁盘阵列有效容量的累计值，按照磁盘阵列CI的‘磁盘有效容量‘属性计算 11.2.6 分厂商磁盘阵列统计表

分厂商对磁盘阵列的数量和容量进行统计。容量单位统一采用GB。

厂商 HP EMC IBM NCR HDS NETAPP SUN 合计 数量 总容量(裸容量) 总容量(有效容量) 指标说明： 序号 1 2 3 指标名称 数量 总容量(裸容量) 总容量(有效容量) 指标计算说明 数量：【删除状态】=‘正常‘的磁盘阵列总数 总容量(裸容量)：【删除状态】=‘正常‘的磁盘阵列裸容量的累计值，按照磁盘阵列CI的‘磁盘裸容量‘属性计算 总容量(有效容量)：【删除状态】=‘正常‘的磁盘阵列有效容量的累计值，按照磁盘阵列CI的‘磁盘有效容量‘属性计算 11.3 问题管理上报报表

11.3.1 按照业务系统的新增问题的统计报表

问题来源 已定位原因 问题状态 已有解决方案 已提出变更请求 结束并关闭 优先级 业务系统 问题总数 事件研究 维护提出 趋势分析 已登记 分析中 已回顾 关键 重要 普通 BOSS系统 客服系统 经营分析 问题来源 已定位原因 问题状态 已有解决方案 已提出变更请求 结束并关闭 优先级 业务系统 问题总数 事件研究 维护提出 趋势分析 已登记 分析中 已回顾 关键 重要 普通 容灾系统 BOMC 指标说明： 序号 指标名称 1.【重复问题标记】为空 2.【问题结束代码】不等于‘取消’ 3.【登记时间】在统计周期内 2 3 4 5 6 7 8 9 10 11 12 13 14 事件研究 维护提出 趋势分析 已登记 分析中 已定位原因 已有解决方案 已提出变更请求 已回顾 结束并关闭 关键 重要 普通 数量：在问题总数中，【问题来源】＝‘事件研究‘的问题个数 数量：在问题总数中，【问题来源】＝‘维护提出‘的问题个数 数量：在问题总数中，【问题来源】＝‘趋势分析‘的问题个数 数量：在问题总数中，【问题状态】＝‘已登记‘的问题个数 数量：在问题总数中，【问题状态】＝‘分析中‘的问题个数 数量：在问题总数中，【问题状态】＝‘已定位原因‘的问题个数 数量：在问题总数中，【问题状态】＝‘已有解决方案‘的问题个数 数量：在问题总数中，【问题状态】＝‘已提出变更请求‘的问题个数 数量：在问题总数中，【问题状态】＝‘已回顾‘的问题个数 数量：在问题总数中，【问题状态】＝‘结束并关闭‘问题个数 数量：在问题总数中，【问题优先级】＝‘关键‘的问题个数 数量：在问题总数中，【问题优先级】＝‘重要‘的问题个数 数量：在问题总数中，【问题优先级】＝‘普通‘的问题个数 指标计算说明 数量：在问题单中根据以下条件过滤 1 问题总数 11.3.2 按照分类的新增问题的统计报表

问题来源 问题总数 已定位原因 问题状态 已有解决方案 已提出变更请求 结束并关闭 优先级 类别 子类 事件研究 维护提出 趋 势 分 析 已登记 分析中 已回顾 关键 重要 普通 小型机 PC服务器 路由器 系统硬件 网络交换机 磁盘阵列 存储光纤交换机 磁带库 安全设备 系统操作系统 问题来源 问题总数 已定位原因 问题状态 已有解决方案 已提出变更请求 结束并关闭 优先级 类别 子类 事件研究 维护提出 趋 势 分 析 已登记 分析中 已回顾 关键 重要 普通 软件 数据库 中间件 集群软件 备份软件 系统管理软件 应用软件 客服设备 配套设施 进程 数据 参数 代码 接口 排队机 CTI服务器 CCS IVR服务器 UPS 空调 其它 安全软件 指标说明： 序号 指标名称 1.【重复问题标记】为空 2.【问题结束代码】不等于‘取消’ 3.【登记时间】在统计周期内 2 3 4 5 6 7 8 9 10 11 12 13 14 事件研究 维护提出 趋势分析 已登记 分析中 已定位原因 已有解决方案 已提出变更请求 已回顾 结束并关闭 关键 重要 普通 数量：在问题总数中，【问题来源】＝‘事件研究‘的问题个数 数量：在问题总数中，【问题来源】＝‘维护提出‘的问题个数 数量：在问题总数中，【问题来源】＝‘趋势分析‘的问题个数 数量：在问题总数中，【问题状态】＝‘已登记‘的问题个数 数量：在问题总数中，【问题状态】＝‘分析中‘的问题个数 数量：在问题总数中，【问题状态】＝‘已定位原因‘的问题个数 数量：在问题总数中，【问题状态】＝‘已有解决方案‘的问题个数 数量：在问题总数中，【问题状态】＝‘已提出变更请求‘的问题个数 数量：在问题总数中，【问题状态】＝‘已回顾‘的问题个数 数量：在问题总数中，【问题状态】＝‘结束并关闭‘问题个数 数量：在问题总数中，【问题优先级】＝‘关键‘的问题个数 数量：在问题总数中，【问题优先级】＝‘重要‘的问题个数 数量：在问题总数中，【问题优先级】＝‘普通‘的问题个数 指标计算说明 数量：在问题单中根据以下条件过滤 1 问题总数 11.3.3 按照业务系统的关闭问题的统计报表

业务系统 关闭问结束代码 平均诊断时间 题数量 BOSS系统 客服系统 经营分析 容灾系统 BOMC 根本解决 变通方法 无法解决 取消 关键 重要 普通 指标说明： 序号 1 2 3 4 5 指标名称 关闭问题数量 根本解决 变通方法 无法解决 取消 平均诊断时间（优先级为关键） 指标计算说明 数量：【问题关闭时间】在统计周期内，【问题状态】=‘结束并关闭’的问题个数 数量：在关闭问题数量中，【问题结束代码】＝‘根本解决‘的问题个数 数量：在关闭问题数量中，【问题结束代码】＝‘变通方法‘的问题个数 数量：在关闭问题数量中，【问题结束代码】＝‘无法解决‘的问题个数 数量：在关闭问题数量中，【问题结束代码】＝‘取消‘的问题个数 诊断完成问题数量：【实际诊断结束时间】在统计周期内， 【问题优先级】＝‘关键‘ 的问题个数 平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量 诊断完成问题数量：【实际诊断结束时间】在统计周期内， 【问题优先级】＝‘重要‘ 的问题个数 平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量 诊断完成问题数量：【实际诊断结束时间】在统计周期内， 【问题优先级】＝‘普通‘ 的问题个数 平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量 6 7 平均诊断时间（优先级为重要） 8 平均诊断时间（优先级为普通） 11.3.4 按照分类的已关闭的问题统计报表

类别 子类 小型机 关闭问题数量 结束代码 根本解决 变通方法 无法解决 取消 关键 平均诊断时间 重要 普通 系统硬件 系统软件 应用 PC服务器 路由器 网络交换机 磁盘阵列 存储光纤交换机 磁带库 安全设备 操作系统 数据库 中间件 集群软件 备份软件 系统管理软件 安全软件 进程 类别 软件 子类 数据 参数 代码 接口 排队机 关闭问题数量 结束代码 根本解决 变通方法 无法解决 取消 关键 平均诊断时间 重要 普通 客服设备 CTI服务器 CCS IVR服务器 UPS 空调 其它 配套设施 指标说明： 序号 1 2 3 4 5 指标名称 关闭问题数量 根本解决 变通方法 无法解决 取消 平均诊断时间（优先级为关键） 指标计算说明 数量：【问题关闭时间】在统计周期内，【问题状态】=‘结束并关闭’的问题个数 数量：在关闭问题数量中，【问题结束代码】＝‘根本解决‘的问题个数 数量：在关闭问题数量中，【问题结束代码】＝‘变通方法‘的问题个数 数量：在关闭问题数量中，【问题结束代码】＝‘无法解决‘的问题个数 数量：在关闭问题数量中，【问题结束代码】＝‘取消‘的问题个数 诊断完成问题数量：【实际诊断结束时间】在统计周期内， 【问题优先级】＝‘关键‘ 的问题个数 平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量 诊断完成问题数量：【实际诊断结束时间】在统计周期内， 【问题优先级】＝‘重要‘ 的问题个数 平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量 诊断完成问题数量：【实际诊断结束时间】在统计周期内， 【问题优先级】＝‘普通‘ 的问题个数 平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量 6 7 平均诊断时间（优先级为重要） 8 平均诊断时间（优先级为普通） 11.4 变更管理上报报表

11.4.1 按业务系统类型统计新增变更数量

业务系统 子类 营销管理 渠道管理 客户服务 BOSS系统 产品管理 客户管理 订单与服务请求管理 服务开通 新增 数量 按变更类型统计 简单 标准 紧急 重大 按风险等级统计 高 中 低 业务系统 子类 资源管理 综合采集 融合计费 综合帐务 综合结算 合作伙伴管理 基础功能 统计报表 一级BOSS 其他 新增 数量 按变更类型统计 简单 标准 紧急 重大 按风险等级统计 高 中 低 客服系统 经营分析 容灾系统 BOMC 指标说明： 序号 1 2 3 4 5 6 7 8 指标名称 新增数量 简单 标准 紧急 重大 高 中 低 指标计算说明 新增数量：【登记时间】在统计时间区间内 的变更数量 简单：在新增数量中，【变更类型】=‘简单变更‘的变更数量 标准：在新增数量中，【变更类型】=‘标准变更‘的变更数量 紧急：在新增数量中，【变更类型】=‘紧急变更‘的变更数量 重大：在新增数量中，【风险等级】=‘重大‘的变更数量 高：在新增数量中，【风险等级】=‘高’的变更数量 中：在新增数量中，【风险等级】=‘中’的变更数量 低：在新增数量中，【风险等级】=‘低’的变更数量 11.4.2 按变更分类统计新增变更数量

类别 设备新购 设备入网 设备搬迁 设备部件更换 应用软件版本上线 应用软件配置变更 应用审计调整 应用随机调整 系统例行重启 系统其他重启 配套设施调整 数据迁移 文档变更 新增 数量 按变更类型统计 简单 标准 紧急 重大 按风险等级统计 高 中 低 指标说明： 序号 9 10 11 12 13 14 15 16 指标名称 新增数量 简单 标准 紧急 重大 高 中 低 指标计算说明 新增数量：【登记时间】在统计时间区间内 的变更数量 简单：在新增数量中，【变更类型】=‘简单变更‘的变更数量 标准：在新增数量中，【变更类型】=‘标准变更‘的变更数量 紧急：在新增数量中，【变更类型】=‘紧急变更‘的变更数量 重大：在新增数量中，【风险等级】=‘重大‘的变更数量 高：在新增数量中，【风险等级】=‘高’的变更数量 中：在新增数量中，【风险等级】=‘中’的变更数量 低：在新增数量中，【风险等级】=‘低’的变更数量 11.4.3 按业务系统类型统计关闭变更数量

业务系统 子类 营销管理 渠道管理 客户服务 产品管理 客户管理 订单与服务请求管理 服务开通 资源管理 BOSS系统 综合采集 融合计费 综合帐务 综合结算 合作伙伴管理 基础功能 统计报表 一级BOSS 其他 客服系统 经营分析 容灾系统 BOMC 关闭 数量 按结束代码统计 成功 失败 取消 重大 按风险等级统计 高 中 低 指标说明： 序号 1 2 3 4 5 指标名称 关闭数量 成功 失败 取消 重大 指标计算说明 关闭数量：【关闭时间】在统计时间区间内 的变更数量 成功：在关闭数量中，【变更结束代码】=‘成功‘的变更数量 失败：在关闭数量中，【变更结束代码】=‘失败‘的变更数量 取消：在关闭数量中，【变更结束代码】=‘取消‘的变更数量 重大：在关闭数量中，【风险等级】=‘重大‘的变更数量 6 7 8 高 中 低 高：在关闭数量中，【风险等级】=‘高‘的变更数量 中：在关闭数量中，【风险等级】=‘中‘的变更数量 低：在关闭数量中，【风险等级】=‘低‘的变更数量 11.4.4 按变更分类统计关闭变更数量

类别 设备新购 设备入网 设备搬迁 设备部件更换 应用软件版本上线 应用软件配置变更 应用审计调整 应用随机调整 系统例行重启 系统其他重启 配套设施调整 数据迁移 文档变更 关闭数量 按结束代码统计 成功 失败 取消 重大 按风险等级统计 高 中 低 指标说明： 序号 9 10 11 12 13 14 15 16 指标名称 关闭数量 成功 失败 取消 重大 高 中 低 指标计算说明 关闭数量：【关闭时间】在统计时间区间内 的变更数量 成功：在关闭数量中，【变更结束代码】=‘成功‘的变更数量 失败：在关闭数量中，【变更结束代码】=‘失败‘的变更数量 取消：在关闭数量中，【变更结束代码】=‘取消‘的变更数量 重大：在关闭数量中，【风险等级】=‘重大‘的变更数量 高：在关闭数量中，【风险等级】=‘高‘的变更数量 中：在关闭数量中，【风险等级】=‘中‘的变更数量 低：在关闭数量中，【风险等级】=‘低‘的变更数量 11.4.5 各业务系统业务中断时间统计

业务系统类别 融合计费 综合帐务 客户服务 业务中断总时长（分钟） 指标说明： 序号 1 指标名称 业务中断总时长 指标计算说明 业务中断总时长：【变更状态】=‘已完成‘and{【实际完成时间】在统计时间区间内}，按【融合计费中断时长】、【综合帐务中断时长】、【客户服务中断时长】分别进行类统计，换算为分钟数累计计算 11.5 发布管理上报报表

11.5.1 按发布所属系统类型统计新增发布数量

按发布类型统计 业务系统 子类 新增 数量 新系统上线 单项升级 包升级 补丁 重大 按风险等级统计 高 中 低 营销管理 渠道管理 客户服务 产品管理 客户管理 订单与服务请求管理 服务开通 资源管理 BOSS系统 综合采集 融合计费 综合帐务 综合结算 合作伙伴管理 基础功能 统计报表 一级BOSS 其他 客服系统 经营分析 容灾系统 BOMC 指标说明： 序号 17 18 19 20 21 22 23 24 25 指标名称 新增数量 新系统上线 单项升级 包升级 补丁 重大 高 中 低 指标计算说明 新增数量：【登记时间】在统计时间区间内 的发布数量 新系统上线：在新增数量中，【发布类型】=‘新系统上线‘的发布数量 单项升级：在新增数量中，【发布类型】=‘单项升级‘的发布数量 包升级：在新增数量中，【发布类型】=‘包升级‘的发布数量 补丁：在新增数量中，【发布类型】=‘补丁‘的发布数量 重大：在新增数量中，【风险等级】=‘重大‘的发布数量 高：在新增数量中，【风险等级】=‘高’的发布数量 中：在新增数量中，【风险等级】=‘中’的发布数量 低：在新增数量中，【风险等级】=‘低’的发布数量 11.5.2 按发布分类统计新增发布数量

类别 新增 按发布类型统计 按风险等级统计 数量 新系统上线 单项升级 包升级 补丁 重大 高 中 低 设备新购 设备入网 设备搬迁 设备部件更换 应用软件版本上线 应用软件配置变更 应用审计调整 应用随机调整 系统例行重启 系统其他重启 配套设施调整 数据迁移 文档变更 指标说明： 序号 26 27 28 29 30 31 32 33 34 指标名称 新增数量 新系统上线 单项升级 包升级 补丁 重大 高 中 低 指标计算说明 新增数量：【登记时间】在统计时间区间内 的发布数量 新系统上线：在新增数量中，【发布类型】=‘新系统上线‘的发布数量 单项升级：在新增数量中，【发布类型】=‘单项升级‘的发布数量 包升级：在新增数量中，【发布类型】=‘包升级‘的发布数量 补丁：在新增数量中，【发布类型】=‘补丁‘的发布数量 重大：在新增数量中，【风险等级】=‘重大‘的发布数量 高：在新增数量中，【风险等级】=‘高’的发布数量 中：在新增数量中，【风险等级】=‘中’的发布数量 低：在新增数量中，【风险等级】=‘低’的发布数量 11.5.3 按发布所属系统类型统计关闭发布数量

业务系统 子类 营销管理 渠道管理 客户服务 产品管理 客户管理 BOSS系统 订单与服务请求管理 服务开通 资源管理 综合采集 融合计费 综合帐务 综合结算 关闭 数量 按结束代码统计 成功 失败 重大 按风险等级统计 高 中 低 业务系统 子类 合作伙伴管理 基础功能 统计报表 一级BOSS 其他 关闭 数量 按结束代码统计 成功 失败 重大 按风险等级统计 高 中 低 客服系统 经营分析 容灾系统 BOMC 指标说明： 序号 17 18 19 20 21 22 23 指标名称 关闭数量 成功 失败 重大 高 中 低 指标计算说明 关闭数量：【关闭时间】在统计时间区间内 的发布数量 成功：在关闭数量中，【发布结束代码】=‘成功‘的发布数量 失败：在关闭数量中，【发布结束代码】=‘失败‘的发布数量 重大：在关闭数量中，【风险等级】=‘重大‘的发布数量 高：在关闭数量中，【风险等级】=‘高‘的发布数量 中：在关闭数量中，【风险等级】=‘中‘的发布数量 低：在关闭数量中，【风险等级】=‘低‘的发布数量 11.5.4 按发布分类统计关闭发布数量

类别 设备新购 设备入网 设备搬迁 设备部件更换 应用软件版本上线 应用软件配置变更 应用审计调整 应用随机调整 系统例行重启 系统其他重启 配套设施调整 数据迁移 文档变更 关闭数量 按结束代码统计 成功 失败 重大 按风险等级统计 高 中 低 指标说明： 序号 24 25 指标名称 关闭数量 成功 指标计算说明 关闭数量：【关闭时间】在统计时间区间内 的发布数量 成功：在关闭数量中，【发布结束代码】=‘成功‘的发布数量 26 27 28 29 30 失败 重大 高 中 低 失败：在关闭数量中，【发布结束代码】=‘失败‘的发布数量 重大：在关闭数量中，【风险等级】=‘重大‘的发布数量 高：在关闭数量中，【风险等级】=‘高‘的发布数量 中：在关闭数量中，【风险等级】=‘中‘的发布数量 低：在关闭数量中，【风险等级】=‘低‘的发布数量 11.5.5 各业务系统业务中断时间统计

业务系统类别 融合计费 综合帐务 客户服务 业务中断总时长（分钟） 指标说明： 序号 1 指标名称 业务中断总时长 指标计算说明 业务中断总时长：【发布状态】=‘已完成‘and{【实际完成时间】在统计时间区间内}，按【融合计费中断时长】、【综合帐务中断时长】、【客户服务中断时长】分别进行类统计，换算为分钟数累计计算