ITIL服务管理流程手册

中国移动业务支撑网网管系统规范

服务管理流程分册

中国移动通信集团公司

2004年4月

精选

目

1 2

录

综述 ....................................................................................................................................................... 3 运维管理流程详述 ............................................................................................................................... 4

2.1 事件管理 ....................................................................................................................................................4

2.1.1 事件管理描述 ............................................................................................................................................4 2.1.2 事件管理目的 ............................................................................................................................................4 2.1.3 事件管理范围 ............................................................................................................................................5 2.1.4 相关定义 ....................................................................................................................................................6 2.1.5 流程职责/角色 ......................................................................................................................................... 11 2.1.6 主要内容 ..................................................................................................................................................12 2.1.7 流程衡量标准 ..........................................................................................................................................13 2.1.8 流程图举例 ..............................................................................................................................................16 2.1.9 事件信息项 ..............................................................................................................................................18 2.2

问题管理 ..................................................................................................................................................19

2.2.1 问题管理描述 ..........................................................................................................................................19 2.2.2 问题管理目的 ..........................................................................................................................................21 2.2.3 问题管理范围 ..........................................................................................................................................21 2.2.4 相关定义 ..................................................................................................................................................21 2.2.5 职责/角色 .................................................................................................................................................25 2.2.6 主要内容 ..................................................................................................................................................25 2.2.7 流程衡量标准 ..........................................................................................................................................26 2.2.8 流程图举例 ..............................................................................................................................................28 2.2.9 问题信息项 ..............................................................................................................................................31 2.3

变更管理 ..................................................................................................................................................32

2.3.1 描述 ..........................................................................................................................................................32 2.3.2 目的 ..........................................................................................................................................................33 2.3.3 范围 ..........................................................................................................................................................33 2.3.4 相关定义 ..................................................................................................................................................33 2.3.5 职责/角色 .................................................................................................................................................38 2.3.6 主要内容 ..................................................................................................................................................39 2.3.7 流程衡量标准 ..........................................................................................................................................41 2.3.8 流程图举例 ..............................................................................................................................................44 2.3.9 变更请求信息项 ......................................................................................................................................46

精选

2.4 配置管理 ..................................................................................................................................................47

2.4.1 描述 ..........................................................................................................................................................47 2.4.2 目的 ..........................................................................................................................................................48 2.4.3 范围 ..........................................................................................................................................................48 2.4.4 相关定义 ..................................................................................................................................................48 2.4.5 职责/角色 .................................................................................................................................................52 2.4.6 主要内容 ..................................................................................................................................................53 2.4.7 流程衡量标准 ..........................................................................................................................................54 2.4.8 流程图举例 ..............................................................................................................................................55 2.4.9 常见配置元素属性表 ..............................................................................................................................57

3

运维管理流程关系和运维支持体系 ................................................................................................. 67

3.1 3.2

4

运维流程相互关系 ..................................................................................................................................67 整体运维支持体系 ..................................................................................................................................69

附录 ..................................................................................................................................................... 71

4.1 ITIL国际规范简介 ...................................................................................................................................71

4.1.1 ITIL国际规范简介 ...................................................................................................................................71 4.1.2 分阶段实施方法 ......................................................................................................................................73 4.2

名词解释 ..................................................................................................................................................76

1 综述

本文作为《中国移动业务支撑网网管规范》附件之一，将详细描述本期中国移动业务支撑网网管的四大管理功能，及四大管理功能之关的关系，并借助于流程图的实例进行详细说明。

运维管理流程包括：事件管理、问题管理、变更管理、配置管理，本附件将分别对其进行定义和描述，包括：管理目的、管理范围、主要内容、职责/角色规划、流程示例等。

在本附件最后，还简单介绍ITIL的相关内容和实施方法。

精选

2 运维管理流程详述

根据本期业务支撑网网管系统建设目标，本期运维管理主要实现事件管理、问题管理、变更管理和配置管理，而管理流程是运维管理的主线，它将整个运维管理工作有机地联接起来，下面将对每个流程的内容及其实际应用做一个详细介绍。

2.1 事件管理

2.1.1 事件管理描述

事件管理流程是为IT用户尽快回到正常工作状态而设计，其关心的重点是快速响应、快速恢复，使故障对业务的影响最小化。

事件管理流程受事件触发和驱动，所谓事件，是指发生了非常规的运作情况，包括系统崩溃、软件故障、任何影响用户业务操作和系统正常运作的事情、以及影响业务流程或违背服务水平协议的情况。事件也包括一个用户的请求，如，重设用户密码。不是所有的事件都由用户产生，监控管理平台产生的告警也可引发事件。

通常由帮助台负责记录事件相关信息，向用户提供对已知问题的处理方法，报告事件和尽快恢复服务，目的是在事件管理阶段获得尽可能高的事件解决率。

所有的事件应该基于相关配置元素的关键等级和影响度进行优先级分类。 事件管理的责任是记录、分类、调查/诊断、解决已知问题、监控跟踪事件、与用户和问题管理流程交流、最终解决事件。

2.1.2 事件管理目的

事件管理流程的主要功能是尽快解决环境中出现的事件，保持IT环境的稳定性，其目的包括：

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

❖ 快速响应系统监控产生的故障或用户的电话请求

精选

❖ 在线获得帮助 ❖ 沟通问题解决的状态 • 进行事件控制 ❖ 记录事件

❖ 就事件的优先级、紧急性和严重性进行分类 ❖ 分析、诊断，必要时进行升级 ❖ 监视，并结束事件 • 支持业务运行

❖ 对业务应用提供二级支持 ❖ 解答有关如何使用的问题 ❖ 记录关于新服务的需求 ❖ 记录关于改变的请求 • 提供一个与业务部门的日常接口 ❖ 提供关于服务状态的信息更新 ❖ 新服务的报告

❖ 关于即将到来的新服务或事件的通知 ❖ 进行事后回顾 • 提供IT管理信息 ❖ 人力利用情况 ❖ 服务可用性 ❖ 产品质量 ❖ 支持效率 ❖ 供应商服务情况

2.1.3 事件管理范围

在BOSS系统运维范围内所指的事件，包括所有与IT基础架构和业务相关的如下事件： ❖ 申告 ❖ 故障

精选

❖ 咨询 ❖ 业务处理 ❖ 维护作业工科 事件的产生有两类：

❖ 由监控管理平台自动发现并产生的告警事件 ❖ 由用户/IT维护人员报告的事件 但不包括：

❖ 外部用户汇报的事件

❖ 在开发和测试环境中的设备或系统产生的事件

“事件管理”流程不一定必须找到问题发生的根本原因，其重点在于如何在尽量短的时间内，恢复已经中断的IT服务，提高服务的可用性。

2.1.4 相关定义

• 重分配规则

事件的及时、正确分配和接手处理是确保事件在解决时限内解决的关键因素。 一线和二线技术人员可以拒绝并根据重分配原则重新分配不属于自己运维范围的事件。 • 事件性质

根据移动的业务要求和管理要求，按照事件性质定义如下六类事件： 性质 申告 故障 咨询 业务处理 维护作业 其他

描述 针对BOSS系统的IT用户投诉 指因BOSS系统错误或非正常因素由监控管理平台发现的告警事件 指对系统操作、业务流程等方面的求助和询问 指需要运维人员进行后台数据处理的要求 指运维人员的日常维护作业或临时进行的维护作业 其他性质的事件。 • 事件来源

当接到一个问题时，帮助台人员需要记录事件来源的类型。帮助台的事件来源可

精选

以包括以下：

来源 用户 描述 来自IT用户的事件可以有以下几种记录方式：  电话/邮件/传真---来自用户/IT维护人员报告的事件  自助开单---用户/支持人员发现问题，直接在服务台系统客户端开单  客服平台---来自客服平台的事件  其他---其他方式进入帮助台的事件 监控管理平台 监控管理平台发现的告警事件，通过与服务管理平台接口发送告警信息到服务管理系统中 • 事件优先级

优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级，如下表所示：

编号 1 2 3 4 优先级 紧急 高 中 低 事件的优先级分两个层面来定义和确认：  帮助台

帮助台在接到来自监控管理平台的告警事件或IT用户报告的事件时，迅速根据事件相关的业务/子业务或IT系统/设备的关键级别及事件的性质，定义该事件的优先级别。如果为紧急事件，立即升级到一线。

对于监控管理平台上传的报警事件，应包含该事件相关联的配置元素的搜索代码，帮助台人员据此确定配置元素及其关键级别。

帮助台人员可参考下表确定事件优先级：

精选

事件优先级 1 2 3 申告 咨询/业务处理/维护作业 本次事件所对应CI的关键级别 1 2 高 中 低 中 低 3 中 低 低 低 低 事件性质 故障 紧急 紧急 高 高 中  一线

一线人员在接受到帮助台升级上来的事件后，根据该事件相关的业务或IT系统/设备的实际故障情况，并结合其他相关因素，再次确定事件优先级，如确实为紧急事件，则启动升级机制。

确定事件优先级后，即可以确定事件的处理时限，优先级对应的事件解决时限参考下表：

优先级 解决时限 (小时)

紧急 4 高 8 中 24 低 48 • 事件的升级

事件升级的目的是确保基于事件的优先级等级及时通知有关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。

可根据所要求的处理时间定义事件优先级升级规则，包括不同等级的事件在不同的时间被升级到不同级别的人员：

时间 优先级 紧急 高 中 低

即时响应 +15分钟 处理时限30% 处理时限40% 处理时限 A A A A B B B B D E F C C C -- D -- -- -- E D -- 升级组群： A B

帮助台 一线支持人员

精选

C D E

二线支持人员 事件经理 管理层

F 集团公司

各省可以根据业务的实际情况调整升级标准。

• 事件分类

根据移动目前的事件种类，事件的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为”子类”，第三级分类，称之为”条目”。本规范给出第一级、第二级分类。各省市根据自己的情况决定是否要定义到第三层。

下表为事件分类表举例：

类别 子类 网络通讯系统 条目 基础架构 服务器 存储系统 操作系统 数据库 系统软件 中间件 双机热备软件 系统监控软件 采集 计费 业务 结算 客服 业务管理 精选

账务管理 账务处理 一级BOSS 拨测 其他 配套设施 空调 UPS 机柜 照明 温湿度传感器 外设 其他

• 事件状态代码

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

事件状态代码 新建 分配 一线处理 二线处理 供应商处理 已解决 关闭

描述 新开事件记录 事件在帮助台 一线支持人员已接手处理事件 二线支持人员已接手处理事件 由供应商处理 事件已找到解决方案 确认解决方案，事件得以关闭 • 事件结束代码

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

事件结束代码 暂时解决 已解决 帮助台 一线解决 二线解决 描述 用变通办法暂时解决 由帮助台人员成功解决 由一线人员成功解决 由二线人员成功解决 精选

第三方解决 其他 由第三方成功解决 包括消失,误操作,可忽略等

• 处理是否超时

事件超时代码 未超时 超时 描述 事件最后时限范围内结束 事件未能在最后时限范围内结束 2.1.5 流程职责/角色

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

• 作为事件流程的负责人，负责制定流程的规则、策略、步骤 • 调度资源，协调解决跨小组、部门的事件

• 指导日常操作，确保流程的执行符合预定的要求和规则 • 建立流程的衡量指标和报表

• 与用户、服务商和管理层交流流程的使用情况 • 确认和实施对流程的变更/改进计划 ➢ 帮助台人员

• 在指定的响应时间内响应所有帮助台热线电话、邮件、传真等事件报告 • 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等

• 为事件进行适当的分类、为事件分配优先级等属性 • 尝试使用工具、初步诊断、分析相关信息等方式解决问题

• 如果帮助台不能解决这个事件，应当将事件分配给最合适的一线支持小组/人员来处理

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

➢ 一线支持人员

一线支持人员负责提供对帮助台无法解决的事件进行快速有效的分析并提出解决方案以

精选

尽快恢复服务，并在必要时提供现场支持。 • 验证事件的描述和信息，进一步收集相关信息 • 决定需要采取何种措施恢复服务并实施有效的行动 • 必要时提供现场支持

• 根据优先级提供有效的解决方案

• 已解决的事件转回帮助台，由帮助台关闭事件 • 实施事件解决方案

• 更新事件解决信息，已解决的事件转回帮助台，由帮助台关闭事件

• 如果一线不能解决这个事件，应当决定选择最合适的二线支持小组/人员来处理 ➢ 二线支持人员

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

• 根据经验和专业技能，决定需要采取何种措施恢复服务并实施有效的行动 • 必要时引入供应商的支持

• 在系统中更新事件根源和最终解决方案

• 更新事件记录，确保事件状态代码真实反映事件状态。 • 及时提供有效解决方案 • 与其他小组合作，确定解决方案

• 已解决的事件转回帮助台，由帮助台关闭事件

• 如果二线不能在解决时限内解决这个事件，应当将事件进行升级

2.1.6 主要内容

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

这个环节是事件管理流程的起点。所有用户或系统报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相

精选

关人员。在此步骤中将会收集创建事件记录所需的信息。 该环节的关键是信息的准确性和完整性。 ➢ 分类和在线支持

事件可以是一个服务请求、信息请求或服务故障，对于每个事件，需要确立优先级、影响度、和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。

该环节的关键是需要知识库支持和正确的事件分派。 ➢ 调查和诊断

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

技术人员实施事件的解决方案，并将解决完毕的事件转回帮助台，由帮助台通知用户解决的结果，并得到用户的确认。 ➢ 紧急事件和事件升级

对于紧急事件，帮助台应立即提交给一线人员，由一线人员判断，上报给事件经理，并同时上报给集团公司，由事件经理决定紧急处理的方式，确保其得到最快速的解决。 当事件处理超过预期时限，将自动升级或由运维人员升级，以引起相关人员和管理人员的重视和参与。 ➢ 结束事件

当用户确认事件解决后，此时可结束该事件，并在必要时更新知识库。若用户对此解决方案不满意，则对该事件继续进行处理，不能关闭。

2.1.7 流程衡量标准

事件管理流程的主要衡量指标如下：

• 事件记录数量，可按照部门、事件分类等分别统计

• 事件关闭的数量，可以按照优先级，或者按照分类分别统计 • 事件成功关闭的数量

• 规定时间内解决的事件数量/百分比 • 帮助台解决率

精选

• 事件解决的平均时间，可以按照事件分类统计 • 超时的事件数量，可以按人员、组别统计 统计报表

• 事件记录的数量，可按照事件分类、事件性质、事件优先级等分别按月、周、日汇总统计该时间段内创建的事件记录数量

紧急 网络设备 服务器 存储系统 … 计费 结算 … 客服 故障 申告 咨询 中 低 业务处理 中 低 维护作业 中 低 紧急 其他 高 中 低 高 中 高 中 低 • 处于各状态的事件数量，可按事件来源、事件分类、事件状态实时汇总事件记录数量

网络设备 服务器 存储系统 … 计费 结算 新建 分配 一线处理 二线处理 供应商处理 已解决 关闭 精选

… 客服 • 事件关闭的数量，可按事件来源、事件分类、事件结束代码等分别按月、周、日汇总统计该时间段内创建的事件记录的关闭数量

部门1 … 监控系统1 … 成功解决 可忽略事件 后续操作解决 部分解决 网络设备 服务器 存储系统 … 成功解决 可忽略事件 后续操作解决 部分解决 • 按时、超时解决的事件数量/百分比，可按事件来源、事件分类、处理角色等分别按月、周、日汇总统计该时间段内创建的事件记录的解决数量

帮助台 按时 数百超时 数量 百分比 按时 数量 百分比 一线 超时 数百按时 数量 百分比 二线 超时 数量 百分比 第三方 按时 数百超时 数量 百分比 量 分比 部门1 … 监控系统1 … 量 分比 量 分比 帮助台 按时 超时 一线 按时 超时 二线 按时 超时 第三方 按时 超时 精选

数百数百数量 百分比 数百数百数百数百数百量 分比 网络设备 服务器 存储系统 … 量 分比 量 分比 量 分比 量 分比 量 分比 量 分比 • 各角色事件解决率，可按事件来源、事件分类、处理角色等分别按月、周、日汇总统计该时间段内创建的事件记录的解决率

部门1 … 监控系统1 … 帮助台 一线 二线 第三方 网络设备 服务器 存储系统 … 帮助台 一线 二线 第三方 2.1.8 流程图举例

如下是事件管理的逻辑示意图：

精选

事件管理逻辑流程集团公司上报集团用户报告事件系统产生事件省公司IT用户100.1创建事件记录并分类帮助台100.2优先级最高 YN100.5尝试解决100.6解决了吗 N100.7事件转发至一线Y100.16确认并关闭事件Yes100.3确认优先级100.4优先级最高 NYY100.8.检查事件信息并解决100.9解决了吗 N100.10事件转发至二线YN一线支持Y100.11调查诊断并解决事件通知事件经理事件经理100.13需要第三方支持 二线支持100.12解决了吗 NN100.14超出时限 YY通知事件经理第三方100.15.技术支持

流程说明

序号 100.1 步骤名称 创建事件记录并分类 责任人 帮助台 输入 说明 事件特接受从IT用户或监控管理平台报告的事件，在帮征描述 助台系统中产生新服务记录，填入相关信息。 并对事件进行分类，根据设定标准进行分类和分优先级，设置相关属性。 事件记根据事件相关的配置元素CI的关键级别。 录 确定事件的优先级是否最高，如是立即升级到一线支持人员，否则尝试解决。 事件记录 一线支持人员根据事件相关配置元素和其他相关信 息确定该事件是否确属优先级最高 已确定优先级的事件记录 事件记录 如果优先级确实最高，则立即升级到事件经理，并通报集团公司，并立即开始处理，如不是，则返回帮助台 最高优先级事件必须立即通知事件经理，由事件经理决定是否由原处理人按照原流程执行，还是需要采取必要手段干预（例如：启动危机处理流程、会输出 事件记录 100.2 优先级最高？ 帮助台 100.3 确认优先级别 一线 优先级确定结果 已确定优先级的事件记录 N/A 100.4 优先级最高？ 一线 通知事件经理 事件经理 紧急解决方案 精选

100.5 100.6 100.7 100.8 上报集团 尝试解决 解决了吗？ 事件转发至一线 检查事件并解决 解决了吗？ 集团 帮助台 帮助台 帮助台 一线 事件记录 事件记录 N/A 事件记录 事件记录 N/A 议等）。 紧急事件必须上报集团公司(并在事件处理过程中的每个状态变化点将最新事件记录上传到集团公司) 通过查询知识库，尝试电话支持 如果解决了，则进入100.16，确认并关闭事件； 如果不能解决，进入100.7，转发至一线。 选择适当的一线人员，将事件转发 检查事件信息，寻求解决方案 如果解决，则将解决方案记入事件记录，并发还帮助台，进入100.16； 如果不能解决，则需在事件记录中说明原因，转发二线 选择适当的二线人员，将事件转发 进行进一步调查分析，找出解决方案 紧急事件 解决方案 N/A 转发的事件 解决方案 N/A 100.9 一线 事件记录 事件记录 N/A 事件转发至二线 调查诊断并解100.11 决 100.10 100.12 解决了吗？ 一线 二线 二线 100.13 需要第三方支持？ 二线 二线 事件经理 供应商 100.14 超出时限？ 通知事件经理 100.15 技术支持 确认并关闭事100.16 件 帮助台 如果”是”，则将解决方案记入事件记录，发还帮助台，进入100.16； 如果”否”，则转入100.13。需要供应商支持？ N/A 判断是否需要引入第三方(第三方包括厂商和其他部门的支持人员)： “是”，转入100.15； “否”，转入100.14 N/A 如果超出处理时限，必须及时通知事件经理 N/A 事件经理应当特别关注超时的事件，并帮助协调资源，监督事件尽快解决 支持请供应商得到通知后，应参与事件的解决，并提出解求 决方案，由二线人员监控供应商的响应速度和处理速度。 已解决帮助台应与用户确认是否接受解决方案，如果用户的事件 认可，则可关闭事件，如果用户不能接受，则发还处理人员，继续处理。 转发的事件 解决方案 N/A N/A N/A N/A 解决方案 关闭的事件记录 2.1.9 事件信息项

本规范规定事件管理流程必须包含如下事件信息项: 信息项 事件流水号 报告人信息 说明 工单号码 本次事件报告人的联络信息，包括：  姓名  省/分公司  部门 填写方式 系统生成 根据报告人的搜索代码，自动获取CMDB中报告人信息 精选

 电子邮件  办公电话  手机/BP 生成时间 地点 发生时间 事件性质 事件来源 在帮助台生成事件记录的时间 事件发生的地点 系统生成 - 事件优先级 事件分类 事件标题 事件描述 事件解决确认人 事件状态 分配对象 事件日志 是否超时 解决时间 解决方案描述 事件结束代码 事件发生的实际时间 - 从事件所属性质的角度来确定其处理流程，如申告、故- 障、求助、业务处理、维护作业等。 指事件工单产生的途径，有人工产生、系统自动产生两由监控管理平台自类。 动产生的，可自动填写 事件优先级决定了事件的解决时限和处理次序，通过综合- 衡量配置元素的关键级别和其他相关信息得出。 从事件从属的系统或技术架构的类型来进行分类，如数据- 库，服务器等。 事件的标题 由监控管理平台自动产生的，可自动填写 对于整个事件内容的详细描述 由监控管理平台自动产生的，可自动填写 在帮助台得到用户确认的有关人员 - 在事件整个生命周期中的不同状态 系统生成 被分配的技术支持组和人员 - 反映事件处理过程中的事件处理信息，包括人员，时间等- 信息 事件处理时间是否超出解决时限 系统生成 事件得到解决的时间 - 事件解决方案的描述 - 根据事件结束的不同方式赋予不同的结束代码 -

2.2 问题管理

2.2.1 问题管理描述

问题是一个或几个已暂时处理但根本原因尚不明确的事件， 许多事件往往是由同一个问题引起的。问题的来源主要有以下几种：

 已经关闭的事件，经过回顾分析后，可能形成一个问题；

 重大事件，虽然经过紧急处理恢复服务，但未找到根本原因，也形成一个问题；

精选

 对于趋势性事件的分析，形成问题。

问题管理流程的根本目的是消除或减少事件的发生， 将BOSS系统内部缺陷导致的业务事件或问题的负面影响降到最低限度，此流程分析发生在生产环境的事件(常常是已关闭的事件记录)，确定最常发生或具有最大影响的事件，找出根本原因，然后生成变更请求(RFC)、变通方法或建议的预防性措施来防止事件的再次发生。所以问题管理流程需要和变更管理流程一起来实施找出的解决方案以从根本上解决问题。 问题通常具有以下特征中的一个或全部： ➢ 一组具有一定关系的已结束的事件

➢ 一个重大或紧急事件(事件处理结束后定义为问题，由问题管理找出根本解决方案)

问题管理与事件管理之间的差异

问题管理与事件管理并不相同，它的主要目的是查明事件的潜在原因，并制定随后的解决方案和预防方法。在大多情况下，此目的与事件管理目的之间有一定冲突，因为事件管理的目的是尽快地恢复客户服务，通常是通过实施替代方案，而非确定一个永久性的解决方案（例如为了尽可能地预防未来可能出现的事件，寻求改善信息技术基础架构的结构）。就问题管理而言，对潜在原因的调查可能需要一定的时间，找到解决方案的速度是次要的考虑因素，但是预防了问题的再次发生。

问题管理流程可以按照不同领域的问题（如网络问题，或应用问题等）由相关组的技术支持专家来执行，原则上这些专家可以是事件管理的二线支持专家，他们在负责接受来自一线支持人员（帮助台员工）的支持请求的同时，也负责对以往事件进行分析，找出事件产生的根本原因，从而确定解决方案，消除这些根本原因，最终使此类事件不再发生；同时，也要从发生的事件中找出事件的发展趋势或潜在可能发生的问题，从而预先采取措施，保证IT服务的正常化。

问题的根本原因找出后即成为已知错误， 对已知错误实施解决方案， 从而解决问题。所以问题管理流程的输出有： ➢ 变更请求 ➢ 变通方法 ➢ 根本解决方案 ➢ 预防性措施 ➢ 已知错误

精选

2.2.2 问题管理目的

问题管理流程在 IT部门设立的主要目的是分析已被列为问题的事件（一组或一个）的根本原因，然后找出解决方案。包括： ➢ 分析并确定事件的根本原因，以防止再次发生 ➢ 主动提供预防性措施 ➢ 提高IT服务的可靠性 ➢ 降低IT支持成本

➢ 提高IT部门的整体形象和名誉

2.2.3 问题管理范围

问题管理范围是对所有IT生产环境中未根本解决的问题和已知错误进行管理，并采取主动性预防措施来降低事件数量，重大或紧急事件在处理完后也被定义为问题以分析其产生的根本原因。一般对IT服务影响最大或最占用支持人员资源的事件优先进行分析。

问题管理范围不包括处于开发或测试环境的系统和应用。

2.2.4 相关定义



优先级

需要确定解决方案的紧急程度，本规范定义如下问题优先级：

编号 1 2 3 4

优先级代码 紧急 高 中 低 解释 关键级别为1的业务中断或将中断,影响一个以上关键地区或半数以上地区 关键级别为1的业务中断或将中断,影响一个以上地区但未达到紧急标准 关键级别为1的子业务或半数以上子业务中断或将中断 未达到以上标准 精选



问题状态代码

问题在整个生命周期中的不同状态。本规范定义如下问题状态：

编号 1 2 3 4 5 6 7 8

代码 已登记 处理中 拒绝 已知错误 已有解决方案 RFC 结束 回顾 描述 问题登录到系统中 问题正在处理过程中 问题分派被拒绝 问题根本原因已找出 解决方案已找到 已提交RFC 问题已结束 问题已做回顾



问题分类 (classification)

从问题从属的系统或技术架构的类型来进行分类。本规范定义如下问题分类：

类别 子类 网络通讯系统 条目 服务器 基础架构 存储系统 操作系统 系统软件 数据库 中间件 精选

双机热备软件 系统监控软件 采集 计费 结算 业务 客服 业务管理 账务管理 账务处理 一级BOSS 精选

拨测 其他 配套设施 空调 UPS 机柜 照明 温湿度传感器 外设 其他 

问题性质

根据问题的不同来源进行分类。本规范定义如下问题性质： 编号 1 2 3 代码 升级事件 系统构架问题 主动防范性 备注 从事件管理中升级的事件 技术专家提出的问题 分析事件记录找出的问题 

问题结束代码

问题结束代码： 根据事件结束的不同方式赋予不同的结束代码。本规范定义如下问题结束代码： 编号 1 2 3 4 代码 根本解决 变通方法 没有解决 消失 说明 找出问题的根本原因，并得到解决方案，成功解决 未找出根本原因，但有临时解决方案作为变通方法 问题无法解决 问题无法再现 精选

2.2.5 职责/角色

问题管理流程主要分为如下几个职责角色，分别简述如下： 问题经理

• 整体上对流程负责，确保流程的有效执行 • 定期评估流程，制定流程改进计划 • 确定或定义问题，并确保有效协调资源 • 监视问题的诊断，分析和处理过程 • 提出实施解决方案的变更请求

• 定期制定IT问题报表，提供正确决策信息

问题分析专家

• 接受问题经理分派过来的问题 • 分析和诊断问题，确定根本原因 • 确定和测试解决方案

• 协助事件支持人员进行重大或紧急事件的处理

2.2.6 主要内容

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

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

• 在系统中生成问题记录并把所有相关事件与此记录关联起来 • 重大或紧急事件处理完后定义为问题 • 技术支持专家在日常运维中发现的问题

精选

• 主动性防范

3. 分派 根据问题内容将问题记录分派给适当的技术小组。

4. 根本原因分析 被分派的小组人员将调查问题以期找出其原因，制定解决方案、变通方法或提出预防性措施，以消除产生原因，或在重发时使其影响力最小化。 5. 更新已知错误 问题记录必须被更新以反映它是已知错误状态，并且把任何变通方法、避免或最小化负面影响的动作行为也记录下来（如果需要添加到知识库中）。 6. 提出变更请求 对问题的解决方案进行评估，通过提出变更请求（RFC）以对该方案进行测试和实施。如果RFC没有被批准，问题记录保持为已知错误，它们可以被事件支持人员在事件再次发生时参考借鉴。

7. 关闭 一旦找出问题根本原因，并实施了解决方案，确认已解决了问题，问题记录可以关闭。

8. 事后回顾 问题必须进行回顾以找出改进机会或总结预防性措施。包括改进事件监测、找出技能差距和文档资料改进等。

2.2.7 流程衡量标准

问题管理流程的主要衡量指标如下： • 每一阶段内的已知错误数量 • 在每一阶段内未结的问题记录

• 每一阶段内未了结的由问题引发的RFC数量 • 在IT环境中存在的临时性变通办法数量 统计报表

问题的数量，可按问题分类、问题性质、优先级、影响度等分别按月、周、日汇总统计该时间段内创建的问题记录数量

紧急 网络设备 服务器 优先级 高 中 低 高 影响程度 中 低 无 精选

存储系统 … 优先级 紧急 高 中 低 高 影响程度 中 低 无 升级事件 系统构架问题 主动防范性 处于各状态的问题数量，可按问题分类、问题性质、问题状态分类实时汇总

已登记 处理中 拒绝 已知错误 网络设备 服务器 已有解决方案 RFC 结束 回顾 存储系统 … 已登记 处理中 拒绝 已知错误 已有解决方案 RFC 结束 回顾 升级事件 系统构架问题 主动防范性 • 问题关闭的数量，可按问题分类、问题事件、问题结束代码等分别按月、周、日汇总统计该时间段内创建的问题记录的关闭数量 网络设备 服务器 根本解决 变通方法 没有解决 消失 存储系统 … 精选

升级事件 系统构架问题 主动防范性 根本解决 变通方法 没有解决 消失 2.2.8 流程图举例

如下是问题管理的逻辑示意图举例：

精选

问题管理逻辑流程事件管理变更管理省公司管集团公司人员人员理层上报集团公司升级到管理层在必要时升级到管理层评估/实施变更Y事件记录300.1分析事件问题经理300.2创建问题记录300.3问题优先级和分类N优先级最高吗?300.4分派给工作组/监视300.9提交变更请求/监视变更实施Y300.10关闭问题记录300.11回顾300.8安排实施解决方案N需要变更吗?问题分析专家300.5拒绝问题N接受吗?Y300.6分析根本原因300.7推荐解决方案/变通方法

关于该逻辑流程的简单描述如下：

序号 步骤名称 300.1 分析事件 责任人 问题经理 事件记录 定期分析回顾事件，主动发现潜在问题。分析事件的频度和严重度，和其他的相关因素进行关联，如CI位置、宕机时间、特定用户、硬件平台、软件版本和一天中发生的时间等。 具体的做法可以是一周开一次由主要事件支持人员参加的例会，讨论上周发生的IT事件。 300.2 创建问问题分析结把找出的问题记录到系统中去，并进行详细说明 问题记分析结果 输入 说明 输出 精选

题记录 300.3 问题优先级及分类 经理 问题经理 果 问题记录 根据问题的实际情况，给其分派一个优先级代码和录 已分类影响度代码(必要时进行升级，如优先级最高时)，并问题 根据拟定的分类原则给问题赋予适当的类别代码并根据问题具体情况设定一个解决时限。 优先级问题已分类问题 问题记录 如果问题优先级为最高，由问题经理立即把该问题上报到集团公司，并把该问题升级到管理层 初步判断问题的可能原因，把问题分派给相应工作组或个人，并监视问题的解决过程，如有必要(如超过解决时限)启动升级流程 N/A 最高吗? 经理 300.4 分派给工作组/监视 在必要时升级 判断是问题经理 问题问题经理 已分派问题 N/A 问题经理在监视问题解决的过程中，根据具体情况可把该问题升级到管理层，如问题超出解决时限时 N/A N/A 问题分析专家对问题进行初步分析，以决定接受与否。如拒绝转向300。6继续，如接受转向300。7继续。 N/A 否接受? 分析专家 300.5 拒绝问问题题 300.6 分析根本原因 分析专家 问题分析专家 已接受问题 已分派问题 问题分析专家根据判断发现问题应该由其他组分析解决，就把问题发回问题经理，注明拒绝理由并推荐组名。转向300。4继续。 如果问题确应由本人或本小组解决，接受分派的问题，然后调查诊断问题，如有必要成立问题分析小组，举行问题根本原因分析研讨会议并确定问题的潜在原因。必要时更新问题状态。 已拒绝问题 问题根本原因 300.7 推荐解决方案/变通方法 问题分析专家 问题记录、 问题根本原因 找出问题的根本原因后，根据实际情况制定变通方法或根本性解决方案，并确保这些方法或方案将降低或消除事件的发生率或影响度，更新问题记录。 问题解决方案 问题变通方法 300.8 安排实施解决方案 问题经理 问题解决方案 问题变通方法 根据问题专家提供的解决方案或变通方法， 计划并实施解决方案以解决问题 解决方案实施计划 判断是否需要问题经理 N/A 判断实施上述解决方案是否需要进行变更，如不需要变更转向300。10继续，如需要变更转向300。9N/A 精选

变更? 300.9 提交变更请求 问题经理 解决方案实施计划 300.10 关闭问 题记录 问题经理 问题经理 已解决的问题 已关闭的问题 以提出变更请求。 根据问题分析专家制定的解决方案或变通办法，提出变更请求，填写变更请求单，递交到变更管理流程，并监视变更的实施过程，和变更管理保持沟通。 变更结束后，确认问题已经解决，选择相应的结束代码，更新问题状态，关闭问题记录。 对所有已关闭问题都进行回顾，找出可能改进的机会，包括问题的解决方案和管理流程方面，如改进升级规则、改进事件监测、找出技能差距和文档资料改进等；回顾之后更新问题状态。 已关闭的问题 已回顾的问题 变更请求RFC 300.11 回顾 2.2.9 问题信息项

本规范规定问题管理流程必须包含如下问题信息项：

信息项 问题流水号 生成时间 地点 问题性质 问题优先级 影响程度 问题分类 系统自动生成的工单号码 生成问题记录的时间 问题发生的地点 指问题的来源 问题优先级决定找到解决方案的紧急程度 问题对IT环境的影响程度 从问题从属的系统或技术架构的类型来进行分类，如数据库，服务器等。 问题标题 问题描述 问题状态 问题日志 解决时间 解决方案描述 问题结束代码 问题的标题 对于整个问题内容的详细描述 在问题整个生命周期中的不同状态 反映问题处理过程中的问题处理信息，包括人员，时间等信息 问题得到解决的时间 问题解决方案的描述 根据问题结束的不同方式赋予不同的结束代码 说明 精选

2.3 变更管理

2.3.1 描述

变更管理通过一个单一的职能流程来控制和管理整个IT运行环境中的一切变更，并和配置管理建立接口。变更管理应该由管理工具来支持，管理的范围可包括软件，硬件，网络设备和文档等的变更。

变更请求通常由于问题的解决方案中需要对生产环境进行某些改变而产生。

需成立一个变更顾问委员会(Change Advisory Board，以下简称CAB)来帮助和支持变更经理，根据变更内容来决定CAB的成员，可以包括客户代表、运维支持人员、应用开发和供应商等跟变更有关的人员。

CAB通过开会讨论等手段来评估变更请求(RFC)的：

   

潜在风险和影响 实施变更需要的资源 是否批准变更

如果批准，什么时间实施

CAB也负责变更实施后的回顾以考察：

 

变更是否成功?是否产生其他副作用? 实际所用的资源和预期的是否一致?

批准后，变更将进入计划，测试/构建和实施阶段。计划/构建阶段也包括开发一个回退计划(Fallback Plan)，用以在实施阶段出现问题或紧急状况时需要把变更回退回去。变更管理流程也负责紧急变更，在此种情况下，变更的评估、计划、测试和实施阶段都将快速进行。

精选

2.3.2 目的

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

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

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

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

2.3.3 范围

变更管理流程涵盖生产环境的所有变更。一般不包括： • 尚处于开发和测试阶段的系统和应用的变更 • 不需要IT部门介入的、由用户控制的行为动作

2.3.4 相关定义



优先级

优先级用来说明变更需要得到实施的紧急程度：

序号 1 2 优先级 紧急 正常 常规 说明 要求变更在提出申请后二天内完成 除了常规和紧急之外的变更 预先定义的日常类变更 3 

风险等级

除了常规变更，还需通过下表所列的衡量因素来评估实施变更可能带来的风险。

衡量因素 条件 得分 精选

衡量因素 条件 地市/区域IT用户数量（受到影响一个以上关键地区或半数实施或取消的影响） 以上地区 影响一个以上地区但未达到半数,并没有关键地区受影响 影响一个地区的全部用户 影响一个地区的部分用户 准备/实施必需的资源 3个或更多支持小组 2个支持小组 超过1人，相同的支持小组 1人 变更成功的可能性 无法测试，变更失败可能性很高 能实现部分测试，变更失败可能性较高 有成熟的变更方案，变更失败可能低 无需测试，变更失败可能性没有 变更规划时间 6天或更长 2-6 天 1-2天 小于1天 变更实施时间 超过2小时或在线/服务断供期 1-2小时 不到1小时 不到30分钟 回退时间 回退时间超过2小时 回退难度中等以上（1-2小时） 回退难度适中（1小时或更短） 易于回退（30分钟或更短）

得分 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

注：紧急变更的实际规划时间很短，但评估时应按照该变更正常处理情况下所需的规划时间来评估。

根据上表，对每个变更进行评估，最终得分为各分项得分的总和，再根据总分确定对应的风险等级和实施完成后的观察期：

总得分 6 – 9 风险等级 重大 实施完后的观察周期 6-7天 精选

10 – 13 14 – 17 18 +

较大 中等 较小 4-5天 2-3天 小于等于1天 以上风险等级由变更主管进行初步评定，再由CAB进行最终确定。



状态

变更请求从提出、实施到结束的整个生命周期中的不同状态： 序号 1 2 3 4 5 6 7 7 8 

状态 已登记 已评估 已授权 已计划 进行中 已结束 观察中 已回顾 关闭 说明 变更请求已登入系统 变更请求已得到CAB评估 变更请求已得到CAB授权 变更实施计划已由变更经理收集并确定可执行 变更实施过程中 变更已结束 变更实施结束后处于观察状态 变更已得到回顾 变更请求已关闭

结束代码

根据结束变更的不同方式赋予不同代码：

序号 1 2 3 4 

代码 完全成功 部分成功 取消 拒绝 说明 完全达到变更目的 部分达到变更目的 变更实施过程中被取消 变更请求被CAB拒绝 类别（Category）

根据中国移动目前的变更种类，变更的分类层次设计不超过三层。第一级分类，称之为”类别”，第二级分类，称之为”子类”，第三级分类，称之为”条目”。本规范给出第一级、第二级分类，各省市根据自己的情况决定是否要定义到第三层。 下表为变更分类表举例：

类别 子类 网络通讯系统 基础架构 服务器 条目 精选

存储系统 操作系统 数据库 系统软件 中间件 双机热备软件 系统监控软件 采集 业务 计费 结算 精选

客服 业务管理 账务管理 账务处理 一级BOSS 拨测 其他 配套设施 空调 UPS 机柜 照明 温湿度传感器 外设 其他

精选

2.3.5 职责/角色

变更管理流程主要分为如下几个职责角色，分别简述如下： 变更请求者

• 发现或获取变更需求 • 确定并分析变更需求和内容

• 填写变更请求单并提交给相关相应变更主管 变更经理

• 整体上对流程负责，确保流程的有效执行 • 确保变更请求得到有效评估，授权和实施

确保只有授权和必要的变更才被实行，并使该种变更影响最小化 • 定期召开变更会议，回顾/制定下阶段变更规划 • 定期评估流程，制定流程改进计划

• 定期制定变更管理报表，提供正确决策信息

变更顾问委员会CAB

• 针对具体变更请求，评估并分派相应资源

• 回顾所有提交的RFC，并确保它们的潜在影响和风险得到评估 • 回顾所有已执行的变更，确保满足变更目的 • 参加CAB会议和紧急CAB会议

• 协助变更经理确定变更优先级及变更规划 • 一般根据不同变更内容有不同人员组成 变更主管

• 由与变更请求内容相关的具体技术领域的负责人(如组长)担任

• 检查由变更申请人提交的变更请求RFC，并完善或调整RFC信息，必要时拒绝无关或无法实施或没有必要的变更请求

• 作为具体变更的项目经理，负责领导变更的构建／测试，实施和参与回顾

精选

• 制定变更项目计划和时间规划等

• 确保变更在预定的时间，资源和成本内完成

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

变更实施人员

• 根据变更主管制定的变更实施计划 • 执行分派的任务以推进变更项目 • 向变更主管汇报工作进程 • 现场负责变更实施

2.3.6 主要内容

变更管理流程通常将包括如下内容：



提出RFC

变更申请人提出RFC，由变更主管负责检查和完善其内容，并进行风险等级、优先级的初步评估。



接受RFC

变更经理接受RFC。

变更请求分类和升级



通过分类，确定是否为重大变更、紧急变更，如果是常规变更请求，则由相应变更主管安排实施；如果风险等级为”重大”的变更请求，应上报省公司管理层和集团公司；紧急变更适用同一流程但将得到快速批准和实施。



变更顾问委员会（ＣＡＢ）评估

变更经理将根据特定的变更请求成立特定的CAB，成员包括对该变更的评估和批准提供应有附加价值的技术人员和管理人员．评估工作包括技术可行性，对容量的影响，对现有服务的影响，资源需求等．

批准 RFC



变更经理确定对该RFC有批准权的人员参加CAB，必要时参与评估．评估后CAB根

精选

据判断决定是否批准RFC。



建立变更实施计划／测试结果，并批准实施

变更请求得到评估和批准后，变更主管安排相应资源进行变更的构建/开发、测试，并制定实施计划。随后提交计划和测试结果给变更经理以获得批准。

规划RFC



实施计划一旦获得批准，变更主管必须根据资源和其他情况进行规划，确定实施时间表，分配相应资源，并通知请求人。

协调变更实施



一切就绪后，可以实施变更．相应小组实施变更，变更主管监视实施过程，并在必要时进行协调．



更新变更状态

在整个变更过程中，变更的状态从登记，评估，回顾到最后关闭是不同的．变更经理负责更新预先定义好的变更状态．

回顾和关闭



实施变更后，CAB负责从技术和流程角度去回顾变更，确保RFC得到了预期效果，并寻找流程的改进机会。随后，变更经理负责关闭RFC。

总结汇报



向管理层提供流程报表，提供变更的用价值的信息，定期向相关小组／部门根据流程衡量标准汇报。



变更会议

变更经理负责定期或不定期召开变更会议，与IT内部成员和用户沟通，传递将要实施的变更等信息，以及对变更流程的反馈和建议等。

变更流程回顾



建议定期回顾变更管理流程以提高效率和效能，在实施变更流程不久之后，可以进

精选

行第一次回顾，以确保流程得到正确实施并起到预期目的。对发现的问题必须追根溯源并尽快解决．之后，可以定期举行正式的回顾，如每六个月回顾一次。

2.3.7 流程衡量标准

变更管理流程的主要衡量指标如下： • 每一类型的变更数量

• 执行回退计划(Fallback plan)的变更数量 • 变更实施的成功率 • 紧急变更所占的比率 • 被拒绝的RFC的数量或比例 • 每一类优先级的变更数量 统计报表

RFC数量，按优先级、风险等级、变更类别、申请人部门/归属小组等分别按月、周、日汇总统计该时间段内创建的RFC数量

紧急 正常 常规 紧急 网络设备 服务器 存储系统 … 紧急 优先级 正常 常规 重大 风险等级 高 中 低 优先级 正常 常规 重大 风险等级 高 中 低 风险等级重大 风险等级高 风险等级中 风险等级低 精选

部门1 … 小组1 … 处于各状态的RFC数量，可按优先级、风险等级、变更类别、申请人部门/归属小组、状态实时汇总 紧急 已登记 已评估 已授权 已计划 进行中 已结束 观察中 已回顾 关闭

已登记 网络设备 服务器 已评估 已授权 已计划 进行中 已结束 观察中 已回顾 关闭 优先级 正常 常规 重大 风险等级 高 中 低 存储系统 …

已登记 部门1 … 已评估 已授权 已计划 进行中 已结束 观察中 已回顾 关闭 精选

小组1 …

RFC关闭的数量，可按优先级、风险等级、变更类别、关闭代码等分别按月、周、日汇总统计该时间段内创建的RFC的关闭数量 紧急 完全成功 部分成功 取消 拒绝

网络设备 服务器 完全成功 部分成功 取消 拒绝 优先级 正常 常规 重大 风险等级 高 中 低 存储系统 …

部门1 … 小组1 …

完全成功 部分成功 取消 拒绝 精选

2.3.8 流程图举例

如下是变更管理的逻辑示意图举例：

变更管理逻辑流程集团公司上报集团公司批准吗集团公司审批省公司管理层升级到管理层Y变更请求者400.1提交变更请求400.3接受变更请求常规类变更吗Y拒绝变更申请NN变更经理重大变更吗?Y/N紧急变更吗?Y紧急流程N批准吗?YY400.7总体变更计划 需要集团公司审批吗?400.11结束N变更顾问委员会 (CAB)400.5评估风险/影响YN授权?N400.10回顾400.2检查/完善变更请求变更主管400.4协调CAB相关活动400.6制定测试/实施计划400.8制定具体计划& 协调沟通变更实施人员Y400.9 实施 关于该逻辑流程的简单描述如下：

步骤名称 提交变更请求 检查/完善变更请求 接受变更请求 责任人 变更请求者 变更主管 输入 变更需求及相关信息 初始RFC 说明 请求者发现或接到变更请求，跟相关部门或用户确认，然后填写变更请求并提交给相关变更主管 相关变更主管负责对变更请求者提交的RFC进行检查，确定变更优先级和风险等级，如有必要则对RFC相关信息完善或更正，以保证RFC的正确性和完整性 接受变更请求，检查变更请求的完整性和正确性，确定相关变更顾问委员会CAB成员 输出 初始RFC 序号 400。1 400。2 400。3 变更经理 经过完善的RFC 经过完善的RFC，包含所有必需的正确信息 RFC登录进变更管理系精选

常规变更? 重大变更？ 紧急变更? 协调CAB相关活动 评估风险/影响 变更经理 变更经理 变更经理 变更主管 变更顾问委员会CAB 变更顾问委员会CAB 变更主管 变更经理 400。4 400。5 确定的CAB名单 待评估的RFC 授权吗? 统 判断所提交的变更是否为常规变更， 如果 是，直接由变更主管负责该变更的计划和执行;如不是常规类变更，则继续 风险等级为”重大”的变更请求，变更经理 应立即上报至集团和省公司管理层 判断是否为紧急变更，如是，则转向紧急变 更流程，否则继续 相关变更主管与已确定的CAB成员进行沟CAB成员都通，确保RFC具体内容得到共识，并准备已明确RFCCAB会议 内容 召开会议或指定人员对变更请求进行评估并RFC得到评得出结论 估，包括变更风险，优先级，影响度等 决定是否对该变更请求授权，如果授权，则 继续，否则拒绝变更请求并由变更经理与变更请求者进行沟通 变更主管负责测试和制定实施计划，并把测试结果和实施计划递交给变更经理以批准实施 决定是否批准实施变更，必要时召集变更顾问委员会，如批准，则继续，否则把测试结果和实施计划 退还给变更主管并要求重新提交 综合其他RFC，来制定或修改总体变更计划 变更的测试计划和实施计划 400。6 制定测试/实施计划 批准吗? 得到授权的RFC 400。7 总体变更计划 需要集团公司审批吗? 变更经理 400。8 制定具体计划和协调沟通 400。9 实施 变更的测试计划和实施计划 变更经N/A 对于重大变更，还需判断是否属于需要集团理 公司审批的变更，如是，则上报集团公司，等待批准，如批准，则转400。8，制定具体计划，如不批准，则转400。6，重新制定测试和实施计划；如不需要集团公司审批的变更，则直接转400。8进行制定具体计划 变更主• 变更综合总体变更计划、变更测试和实施计划，管 测试确定一个最合适的实施时间，根据需要与相计划关部门进行充分沟通 和实施计划 • 总体变更计划 变更实具体实施根据具体实施计划执行变更实施，在必要时施人员 计划 启动回退计划(Fallback Plan);并在实施完成后得到配置经理授权更新相关配置信息 总体变更计划 N/A 具体实施计划 • 已实施的变更 • 已更新的配置信息 精选

400。10 回顾 400。11 结束 变更顾问委员会CAB 变更经理 已实施的变更 变更经理召开CAB会议对实施的变更进行回顾以确定变更目的是否已达到 已回顾的变更 已回顾的变更 更新相关信息，关闭变更记录 变更请求关闭 2.3.9 变更请求信息项

本规范定义如下变更请求信息项：

信息项 变更请求序列号 记录创建时间 说明 为每个变更请求分配一个唯一的序列号 变更请求创建的时间 记录变更请求者的基本信息，包括：  姓名  省/分公司 发起人信息  部门  电子邮件  办公电话  手机/BP 优先级 风险等级 所影响的应用系统 变更类别 变更描述 变更详细内容 变更完成时限 变更状态 变更主管 变更主管提交时间 □紧急 □正常 □常规 □重大 □高 □中 □低 实施该变更将对哪些应用产生影响 变更的分类 简单描述变更请求 详细描述变更的内容 变更要求完成的时限 RFC所处的状态 填入变更主管姓名，变更请求应当先由变更主管检查 变更主管提交变更请求的时间 精选

记录变更审批的历史记录，包括：  审批人姓名 变更审批记录  审批结果  原因  时间 变更计划 变更日程安排 变更实施情况 变更测试情况 变更观察情况 变更关闭状态 关闭时间 关闭人 包括变更的实施计划、测试计划、回退计划等，以及变更任务分配给哪些实施者 变更实施的时间安排 由变更实施人填写，用于描述实施时的现场情况 描述测试的情况、测试结果 描述变更结束后，观察期间的情况 □完全成功 □部分成功 □取消 □拒绝 变更关闭的时间 关闭人的姓名 2.4 配置管理

2.4.1 描述

配置管理是一个描述、跟踪和汇报所有IT基础架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置元素(CI) 。每一个CI必须被有效管理、跟踪和控制以支持IT服务和基础设施成功运行。配置管理流程所管理的配置元素包括硬件、软件和网络设备、文档等IT基础架构中所有必须控制的组成部份。所有的数据存在配置管理数据库(CMDB) 中。

在说明一个配置元素(CI) 时，CI被赋予一个名字和描述，同时诸如责任人、状态、配置等相关属性也被详细记录。CI之间的关系也可找出并记录到CMDB中。CI改变时，CMDB中的相关信息被更新，对CMDB也进行定期审核以确认和维护数据的完整性和一致性。

精选

配置管理是IT基础架构组成部份的文档化描述(如状态，关系等) ，并包括配置元素(CI) 相关的文档资料。它制定、跟踪和汇报相关信息，以增强其他流程的更有效运行，特别是变更管理、事件管理和问题管理等流程。

配置管理是IT服务管理的一个核心流程，能确保IT环境中所有IT设备/系统及其配置信息得到有效完整的记录和维护，包括各IT设备/系统之间的物理和逻辑关系，从而为实现有效IT服务管理奠定基础。例如： 通过了解系统当前的配置信息，与其他配置元素的关系和历史状况等，帮助台员工可迅速正确判断故障，找出有效解决方案，从而确保系统的可用性。

2.4.2 目的

配置管理流程的总体目标是提供一个统一的一致的流程来管理IT生产环境中的所有组成部份，以确保：

• 所有配置元素(CI) 被识别和记录下来 • 配置元素当前和历史状态得到汇报 • 配置元素记录的完整性得到维护和确认 • BOSS系统生产环境的稳定性

2.4.3 范围

配置管理的范围是IT生产环境的所有配置元素(CI) ，包括生产环境的硬件、软件、网络设备、文档等，具体内容包括识别、控制、汇报和审核等行为。 不包括：

• 处于开发或测试环境的设备或系统

2.4.4 相关定义

精选



配置元素关键级别

为了区别事件相关联的配置元素对移动业务的影响，对于BOSS系统主要配置元素（CI）进行关键等级定义：

等级 1 2 3

所有配置元素的关键级别由其相关联的业务或子业务的关键级别决定，业务和子业

描述 高 中 低 说明 务作为配置元素在配置管理数据库中管理。

本规范规定业务/子业务关键级别定义如下： 业务 采集 业务关键级子业务 别 1 采集源 采集点 数据传输 计费 1 服务使用记录接受点 预处理点 高额处理 分拣 批价 入库 输出点 结算 1 漫游结算数据上传 漫游结算数据接收 漫游结算数据处理 漫游结算稽核 漫游结算单生成 子业务关键级别 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 精选

网间结算关口局数据收3 集 网间结算数据处理 网间结算稽核 网间结算单生成 帐务处理 1 帐务数据采集 出帐预处理 加载外部数据 出帐计算 出帐核查 出帐调整 出帐确认 定期出帐 实时出帐 定额出帐 帐务管理 1 销帐 反销帐 欠费催缴 欠费服务 无主帐单检查 帐务对帐 帐务调帐 帐务减免 呆坏帐处理 挂帐处理 营业 1 业务受理开户 预约服务 业务受理预销户 业务受理销户 更改用户资料 服务变更 3 3 3 1 1 1 1 1 1 1 1 1 3 1 1 1 1 2 3 2 2 2 3 1 3 3 2 3 1 精选

付费计划变更 套餐计划变更 营业缴费 托收 缴费卡缴费 银行划帐 冲正 客户服务查询 帐务情况查询 详单查询 停/复机管理 银行接口管理 SMP接口管理 拨测 3 计费准确性 拨测系统运行状况 业务受理销户 客服 1 性能统计 信令相关的性能统计 电路群性能统计 语音服务 CTI服务器 IVR 自动台话务 人工台话务 话务员信息 客户查询 业务受理 客户投诉与建议 预约服务 信息发布 一级BOSS 1 异地客户资料查询 2 2 1 2 1 1 1 2 2 2 1 1 2 3 3 3 3 1 1 1 1 1 2 1 3 1 1 1 3 3 1 精选

异地停/复机 异地换卡/补卡 异地缴费 交费冲正 17201业务鉴权 WLAN业务鉴权 1 1 1 1 2 2  主机、存储、数据库、中间件的关键级别按其所承载的业务的最高关键级别确定  网络、备份等设备原则上不作为高关键级别的资源，其关键级别由各省自定



配置元素状态

配置元素在整个生命周期中的不同状态，本规范规定如下配置元素状态代码： 代码 1 2 3 4 5 6 7 8 9 10 11 状态 已订购 已开发 已入库 已安装 测试中 生产中 维护中 已报废 已丢失 已退役 非管辖

2.4.5 职责/角色

配置管理流程主要分为如下几个职责角色，分别简述如下： 配置经理

• 整体上对流程负责，确保流程的有效执行 • 定期评估流程，制定流程改进计划 • 制定配置管理

• 定期制定配置管理报表，提供正确决策信息

精选

配置管理员

• 记录和维护CMDB中的所有CI及相关信息 • 根据配置经理要求产生相关报表 • 保证对所负责的CI的数据正确性 • 对所负责的CI进行添加，修改等

2.4.6 主要内容

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

1. 识别和维护CIs

确定需要进行配置管理的IT元素， 及所有必需的配置属性，并指明与IT环境中其他配置元素之间的关系。

对配置管理数据库提供日常维护。

2. 配置控制

加强对CI变更的相应授权，在CI的整个生命周期内跟踪CI的状态(如以前、当前、计划状态等) ， 确保只有被认可的和被标识的配置项及其配置信息才能输入CMDB或更新CMDB。

3. 汇报和状态汇总

根据需要，定期产生配置管理报表，并能使相关人员进行选择、抓取、分类和返回所查询的CMBD数据。

定期产生配置项的状态报告，并能反映配置项的版本和变动历史。

4. 审计和确认

定期审核全部或部分CMDB数据，确认和物理环境的一致性，从而确保配置信

精选

息的完整性。该工作可定期和不定期进行：

• 不定期(可每周或根据需要)从监控平台传送配置数据到服务管理平台的进

行比对

• 定期(如每季度)对全部或部分配置元素进行审计

如发现物理信息和逻辑信息的不一致性，需提交变更请求RFC，通过变更管理流程进行调整。

5. 流程管理

配置流程管理主要包括计划、回顾和改进等。

配置经理定期制定计划(如半年)，以明确下阶段配置管理工作。

配置经理定期回顾流程和审核结果，找出改进机会，包括针对流程和CMDB的改进

2.4.7 流程衡量标准

配置管理流程的主要衡量指标如下： • 所审计的CI符合CMDB版本/信息的比例 • 由CMDB控制的CI的比例

• 检测到未被批准/授权的IT元素正在使用中 统计报表

由CMDB控制的CI的数量，可按CI的状态、类别汇总统计

主机 网络 链路 中间件 已订购 数据库 存储设备 业务 合同 人员 介质/文档 已开发 已入库 已安装 测试中 生产中 维护中 精选

已报废 已丢失 已退役 非管辖 所审计的CI不符CMDB信息的数量，可按CI的类别汇总统计

主机 网络 链路 中间件 审计不 符数量 占该类 总数百分比 数据库 存储设备 业务 合同 人员 介质/文档 监控平台检测到的不符CMDB信息的CI数量，可按CI的类别按月、周、日分别汇总统计该时间段内所监测到的信息不符的CI数量

主机 网络 链路 中间件 审计不 符数量 占该类 总数百分比 数据库 存储设备 业务 合同 人员 介质/文档 2.4.8 流程图举例

如下是配置管理的逻辑示意图举例：

精选

配置管理逻辑流程配置管理员配置经理200.5流程计划制定200.6流程计划实施200.7流程回顾和改进建议200.1维护/识别/定义200.2更新CMDB200.3报表/状态汇总200.4审计/确认

关于该逻辑流程的简单描述如下： 序号 步骤名称 200。1 识别，定义 责任人 配置管理员 待入库的IT元素 对所要管理的IT环境的所有组成元素进行命名和说明，包括对CI之间关系的描述；在添加一个新的授权记录时，确保所有需要的信息度符合配置管理的要求和标准 200。2 更CMDB 新配置管理员 200。3 报表和状态汇总 200。4 审计/确认 配置管理员 配置管理员 审计需求 通过审核确认CMDB中CI信息和其物理信息的一致性，并通过变更管理流程消除不一致信息 ，具体可通过对所管理的配置元素的定期审计和随机抽查。 200。5 流程计划制定 配置经理 • 计划周期开始 定期制定配置管理活动计划，包括人员，技术已制定或改和流程等方面的内容。可以每半年进行一次 进的流程计划 配置信息的增删请求 报表或信息需求 根据需要定期产生报表和状态汇总报告，向其配置信息报他流程和相关人员提供配置信息 表或状态报告 审计结果 变更请求 根据需要更新配置管理数据库，如增加或删除配置信息 已更新的CMDB 确定所有必要信息的配置元素 输入 说明 输出 精选

• 流程改进建议 • 审计结果 200。6 200。7 流程计划实施 流程回顾/改进建议 配置已制定的实施流程计划 审计确认结束或回顾后发现流程效率不高，其他流程或组织需要新的方法等情况时，都需要对当前流程进行改进或制定新的流程。 已实施流程计划 • 已回顾流程 • 改进建议 经理 流程计划 配置回顾周期经理 开始 2.4.9 常见配置元素属性表

以下对BOSS网管中需要维护的CI，以及CI的常见属性进行汇总罗列：



主机

主机基本属性

属性 说明 主机的标示 主机的关键级别 主机的IP地址(服务IP) 主机的厂商 主机的型号 主机序列号 主机的逻辑名 主机的唯一ID 各逻辑卷的路径名 各逻辑卷的大小（MB） 主机的状态 主机的用途 主机名 关键级别 主机地址 主机厂商 主机型号 序列号 逻辑名 搜索代码 逻辑卷路径 逻辑卷大小 状态 用途 精选

CPU个数 CPU型号 CPU主频 内存大小 内置硬盘大小 操作系统版本 资产号 系统网络接口数 主机的CPU数目 主机CPU的属性 主机CPU的主频率 主机的内存大小 主机内置 主机操作的版本 主机的资产号 系统中网络接口的数量 系统网络接口IP地址 系统各网络接口的IP地址 系统网络接口物理地系统各网络接口的物理地址 址 总的SWAP区大小（MB） 系统交换区大小 文件系统的标示 文件系统名称 主机文件系统总的可用量 文件系统的总空间 主机的TPCC值 TPCC 备注

主机相关配置元素 相关联配置元素 业务 数据库 中间件 存储设备 网络设备 管理员 维护合同 购置合同



说明 主机上承载的业务或子业务 主机上安装的数据库 主机上安装的中间件 与主机相连的存储设备 与主机相连的网络设备 主机的管理员 主机的维护合同 主机的购置合同 网络

精选

网络基本属性

属性 设备名称 关键级别 设备型号 搜索代码 状态 管理人员 序列号 网元类型 网元厂商 设备软件版本 网元名 网元IP地址 端口标识 端口类型 端口设置速率 端口物理地址 端口IP地址 端口数量 资产号 用途 备注 网络相关配置元素 相关联配置元素 网络设备 主机 服务合同 相关联的网络设备 相关联的主机 网络设备的维护合同 说明 网络设备的标示 网络设备的关键级别 网络设备的型号 网络设备的唯一ID 网络设备的状态 网络设备的管理员 网络设备的序列号 网络设备的类型 网络设备供应商 网元设备当前安装的软件版本号 网元配置名称，或由名字解析、DNS服务解释的名称 网元管理端口IP地址 网元设备的每个端口的唯一标识名或ID号 网络设备配置的端口模块类型 网络设备各端口的最大速率（kbps） 网络设备端口固化的物理地址 网络设备端口配置的IP地址以及其掩码 网络设备配置各种类型端口的数目 网络设备的资产号 网络设备的用途 说明 精选

购置合同 管理员 

网络设备的购置合同 网络设备的管理员 链路(广域网)

链路基本属性

属性 链路名称 搜索代码 关键级别 状态 类型 带宽 运营商 资费 序列号 用途 备注 链路相关配置元素 相关联配置元素 管理员 网络设备 服务合同 购置合同



说明 链路的标识 链路的唯一代码 链路的关键级别 链路的状态 链路的类型 链路的带宽 链路所属的运营商 链路的资费 链路的序列号 链路的用途 说明 链路的管理员 相关联的网络设备 链路的维护合同 链路的购置合同 中间件

中间件基本属性

属性 说明 中间件软件名称 软件名称 精选

版本 关键级别 序列号 搜索代码 厂商 用途 状态 中间件产品版本 中间件的关键级别 产品序列号 中间件的唯一ID 中间件产品的厂商 中间件的用途 中间件的状态  交易中间件 中间件类别  传输中间件  应用服务器 中间件端口号 最大并发连接数 中间件的端口号 与数据库连接数 最大并发网络客户端与客户端连接数 数量 系统日志路径 用户日志路径 中间件的系统日志路径 中间件的用户日志路径 配置的队列空间大小 传输中间件使用，中间件配置的所有队列所占字节数 配置的队列所在路径 传输中间件使用，在队列模式为磁盘队列时有效 单条队列所允许的消传输中间件使用，单条队列所允许的消息总个数 息总个数 单条队列所占字节数 传输中间件使用，单条队列所占字节数 队列模式 传输中间件使用，指队列属性是内存队列还是磁盘队列 应用服务器运行模式 应用服务器群集还是单机 允许应用服务器支配的内存堆大小（MB） 配置的总线程数 配置的数据库连接池大小 应用服务器使用，允许应用服务器支配的内存堆大小（MB） 应用服务器使用，配置的总线程数 应用服务器使用，配置的数据库连接池大小 精选

中间件相关配置元素

相关联配置元素 主机 业务 数据库 管理员 服务合同 购置合同



说明 运行中间件的主机 中间件关联的业务或子业务 与中间件相关联的数据库 中间件的管理员 中间件的维护合同 中间件的购置合同 存储设备

存储设备基本属性

属性 说明 存储设备名称 设备规格型号 存储设备的关键级别 存储设备的唯一ID 产品序列号 存储设备厂商 配置项状态 存储设备的用途 安放地点 各种类型的存储阵列的数目 每个存储阵列设定的唯一标识名 存储阵列的类型，包括是生产厂家、所属系列以及设备名 设备型号 关键级别 搜索代码 序列号 厂商 状态 用途 位置 存储阵列数目 存储阵列标识 存储阵列类型 存储微码版本 存储配置容量 存储采用RAID方式 规格等 存储阵列当前安装的微码版本号 存储阵列当前配置的磁盘总容量 存储阵列各逻辑卷采用哪种RAID数据保护方式 精选

存储CACHE容量 磁盘标识 磁盘的规格 主机通道卡标识 主机通道卡类型 主机通道卡数目 磁盘适配卡标识 磁盘适配卡类型 LUN标识 热备盘配置数 存储设备相关配置元素

相关联配置元素 主机 管理员 服务合同 购置合同



存储阵列内配置的CACHE内存容量 每个磁盘在存储中的标识名 存储阵列配置的磁盘规格，包括：单盘容量及转速 主机通道卡在存储中的标识名 存储配置主机通道卡的类型，例如：光纤、SCSI、UltralSCSI、ESCON等类型的通道卡 存储配置的各种通道卡数目 磁盘适配卡在存储中的标识名 存储配置的磁盘适配卡的类型，例如：光纤、SCSI、UltralSCSI、SSA等类型的适配卡 存储中划分的每个逻辑卷的标识 存储阵列当前配置的热备盘数目 说明 与该存储设备相关的主机 存储设备的管理员 存储设备的维护合同 存储设备的购置合同 数据库

数据库基本属性

属性 软件名称 版本 关键级别 序列号 搜索代码 厂商 数据库软件名称 数据库版本信息 数据库的关键级别 产品序列号 数据库的唯一ID 数据库厂商 说明 精选

用途 状态 数据库名 数据库端口号 数据库的位数 安装的选项 归档方式 归档日志目录 本数据库用于哪些应用 数据库状态(即配置元素状态) 数据库实例名 数据库的端口号 32/位 指数据库已经安装的选项，如分区、并行等 日志归档方式信息 如果采用归档方式，则列出归档日志目录 共享内存的大小 共享内存的设定大小（MB） 数据设备名

数据库相关配置元素 相关联配置元素 主机 管理员 服务合同 购置合同



数据库内数据文件或数据设备名 说明 与该数据库相关的主机 数据库的管理员 数据库的维护合同 数据库的购置合同 业务（业务和子业务均属于业务类CI进行配置管理） 业务基本属性

属性 业务名称 版本 关键级别 搜索代码 数据库实例名 中间件端口号 用途 状态 业务的名称 版本信息 业务的关键级别 业务的唯一ID 与业务关联的数据库实例 与业务关联的中间件端口 业务用途 业务的状态 说明 精选

厂商

业务相关配置元素

相关联配置元素 应用软件厂商 说明 如果是子业务，填入上级业务搜索代码； 父业务 主机 数据库 中间件 管理员 服务合同 购置合同



否则，填为”无”； 与该业务相关的主机 与该业务相关的数据库 与该业务相关的中间件 业务的管理员 业务的维护合同搜索代码 业务的购置合同搜索代码 PC

属性 设备名 搜索代码 型号 序列号 状态 用途 CPU 内存 硬盘 操作系统 业务 IP 位置 管理员 PC的设备名称 PC的唯一ID PC的型号 PC的序列号 PC的状态 PC的用途 CPU主频 内容容量 硬盘容量 操作系统名称和版本 PC所承载的业务 IP地址 PC的安装位置 PC的管理员 说明 精选

服务合同 购置合同



PC的服务合同 PC的购置合同 配套设施

属性 设备名 搜索代码 型号 产品序列号 状态 位置 用途 管理员 服务合同 购置合同 说明 机房配套设施的设备名称 配套设施的唯一ID 配套设施的型号 配套设施的产品序列号 配套设施的状态 配套设施所处的位置 配套设施的用途 配套设施的管理员 配套设施的服务合同 配套设施的购置合同



合同

属性 合同名 对象 编号 搜索代码 位置 管理员 签约厂商 合同名称 合同主体对象 合同编号 合同的唯一ID 合同存放位置 合同管理人员 合同签约厂商 说明



人员

属性 说明 精选

姓名 搜索代码 办公电话 手机号码 邮件地址 地点 组织 职务 IT组别



维护人员姓名 维护人员的唯一ID 维护人员办公室电话 维护人员手机号码 维护人员邮件地址 维护人员工作地点 维护人员所属的部门 人员职务 维护人员所属的维护组 介质/文档

属性 文档名称 搜索代码 用途 状态 位置 管理员 文档名称 文档的唯一ID 文档用途 文档状态 文档存放位置 文档管理员 说明

3 运维管理流程关系和运维支持体系

3.1 运维流程相互关系

上一章是第一阶段各运维流程的详细描述和实际应用流程举例。但是，由于IT环境从总体上来说是一个不可分割的有机体，所以上述各流程是不可能运行的，为了提高IT运维管理的整体性，各流程之间必须设计接口。如下是上述四个流程之间的接口关系图：

精选

业务部门或IT用户监控工具问题,咨询等沟通,更新,变通方法等帮助台事件变更或发布请求事件管理问题管理服务报告事件统计审计报告问题统计趋势分析问题报告问题回顾已知错误审计报告变更管理管配置理变更(发布)计划CAB会议纪要变更统计变更回顾审计报告CMDB报告CMDB统计/标准审计报告事件 问题/已知错误 变更 Cis/关系CMDB 如下为各接口的几个关键要点：

1. 业务部门或IT用户与IT的接口主要表现在：

• 用户提交事件或咨询请求给帮助台，帮助台在整个事件处理过程中保持与IT用户的沟通，直至解决方案的确认和事件请求的关闭

• 如果在管理流程中允许变更请求可以由用户提交，则IT用户可以把RFC提交给变更管理人员

2. 事件管理流程的接口：

• 监控系统发现的故障或报警输入到事件管理流程 • IT用户的事件或服务请求输入到事件管理流程 • 问题管理流程分析事件记录，确定问题

• 提出变更请求RFC到变更管理流程实施事件解决方案，解决事件 • 事件管理流程查询CI配置信息，进行事件的分析，诊断和解决

精选

3. 问题管理流程的接口：

• 事件记录输入到问题管理流程进行问题分析

• 提出变更请求RFC到变更管理流程实施问题解决方案，解决问题 • 问题管理流程查询CI配置信息，进行问题的分析，诊断和解决

4. 变更管理流程的接口：

• 事件管理和问题管理提出变更请求RFC到变更管理流程实施解决方案，解决

事件或问题

• 变更管理流程查询CI配置信息，如相互关系等，进行变更的风险，影响分析

等

• 变更请求处理完毕后，与配置管理协调以更新相关CI信息

5. 配置管理流程的接口：

• 给事件管理，问题管理和变更管理等运维流程提供CI信息

以上各流程还需和报表系统建立接口，以根据各自管理需求产生相关报表。

3.2 整体运维支持体系

通过在IT部门建立以上各符合ITIL指导框架的流程规范和设计各流程的相互关系及流程接口，可以在IT部门建立如下的三级支持体系：

精选

IT用户 监控系统 帮助台 一线

帮助台 一线支持/配置管理员 二线支持/问题分析专家 … 数据库支持 网络支持 主机支持 第三方 事件经理 问题经理 配置经理 变更经理

二线

结合移动公司BOSS运维的具体情况，本规范有如下建议: • 帮助台人员必须7*24接受事件和分派事件

• 一线人员一般是对系统和业务提供初始支持的维护人员，配置管理员也可由

一线人员承担，负责配置管理数据库的维护工作

• 二线人员一般是对系统和业务提供专业支持的维护人员，常按系统和业务分

成不同小组，分别解决相应的事件;二线人员在问题管理流程中也作为相应领域的问题分析专家，负责对该类问题的调查和诊断

• 所有流程的责任人(包括事件经理，问题经理，配置经理和变更经理)负责该

流程的整体管理和资源协调，常由较资深的维护主管承担 • 流程中的几个角色可以由同一个人承担

上图从三层支持的流程角度描述了运维支持体系，这里的重点是不同层面人员需要不同的技能和管理的侧重点，通过该支持体系，可以保证IT部门在处理IT事件和变更等日常工作中，具体岗位和人员的角色职责的明确定义，具体的运维流程与ITIL规范相一致，从而保证整个IT管理系统的高效、平稳地运作，同时能和外部的厂商或合作伙伴实现有机结合。

精选

4 附录

4.1 ITIL国际规范简介

为加强对BOSS系统的管理和维护，规范IT运行管理和操作，实现信息系统的自动化运行管理，提高系统可靠性、可用性，保障业务的稳定，特制定本规范，指导各省采用规范化的IT管理模式，建设集中式服务管理平台和管理流程。

本规范中流程管理的理论依据参照ITIL（Information Technical Infrastructure Library）服务管理体系，这是在全球IT管理业界公认的指导性框架。

4.1.1 ITIL国际规范简介

ITIL由CCTA（英国国家电脑局）颁布，这是一套IT部门用来计划、研发、实施、运维高质量服务的标准管理库。它把各个业界在IT管理方面最好的方法归纳起来，变成规范，旨在为企业的IT部门提供一套标准的IT管理方法， 使这些企业的IT部门可以站在”巨人”的肩膀上， 直接按照国际先进的IT管理思想和方法来管理和运行IT，协助IT部门建立以服务为导向的IT运作。它一经推出，立即被广泛采用，目前在全球已被多于100，000家在各行业处于领先地位的企业所采用。

ITIL包含了一系列IT部门进行IT服务支持和实施的规范性流程，以及关于IT服务管理的最佳经验，包括帮助台、突发事件管理、变更管理等运维管理流程和服务级别管理、可用性管理等规划管理流程，通过这些流程规范的实施，可以将IT部门的管理工作从被动式服务转向主动式服务，并通过相应管理工具的集成， 为IT工作人员和IT管理人员提供一个灵活量化的服务管理平台，从而使已往繁杂的IT管理变得有序而轻松。

ITIL标准库里的流程，可以分为两大组：

 服务运行管理流程，包括帮助台/突发事件管理，问题管理，变更管理和配置管理和

发布管理等

精选

 服务规划管理流程，包括服务级别管理，IT财务管理，容量管理，IT连续性管理和

可用性管理等，最近把安全管理也纳入了进来。

。两者的主要区别在于，服务运行管理流程是日常性的，目标是处理日常的维护性管理工作、包括处理事件、控制变更等，以保证IT系统的稳定性，可靠性和用户的满意度；而服务规划性流程是通过服务目标的规划、确定、监控和改进，来确保日常的IT服务水平达到所需要的目标，并实现IT服务的持续性改进， 通过两者的结合，可以帮助IT部门提供面向业务和用户的IT服务，通过流程化、规范化的IT服务管理模式，帮助IT部门真正实现IT服务的业务价值。 如下为各流程的简要介绍：

服务台（Service Desk、HelpDesk），也称为帮助台，IT服务管理与用户的单一接口，受理并处理用户的服务请求。

➢ 事件管理（Incident Management），它和帮助台一起组成事件处理流程，有

效解决各类IT突发事件，尽快恢复IT服务。

➢ 问题管理（Problem Management）， 寻求IT故障的根源，解决存在的问题，

从而消除或减少IT事件的发生。

➢ 配置管理（Configuration Management），管理各IT资产系统(配置元素，

CI)，包括相互间的关联与依赖关系。

➢ 变更管理（Change Management）， 对变更请求进行记录、跟踪与管理，消

除或减少IT变更对生产环境和系统的影响和风险，保证变更的平稳运行。 ➢ 发布管理（Release Management），确保IT系统和软件的有效实施和版本管

理。

➢ 服务级别管理（Service Level Management），保证整个业务系统的服务等级

或水平，实现量化管理。

➢ 可用性管理（Availability Management），监控所有重要IT资源，保证整个业

务系统的可用性。

➢ 容量管理（Capacity Management），监控和提高系统性能，进行性能规划。 ➢ IT连续性管理（Service Continuity），建立业务持续计划，保证系统的高可用

性，以实现业务的持续运行。

IT财务管理( Finacial Management)， 包括IT预算管理，成本管理和收费管理。 安全管理（Security Management），对应用系统，网络及所有服务器提供可靠的安全保

精选

护。

ITIL服务框架帮助IT部门将目光转向了基于流程、关注服务品质、满足服务等级要求、面向用户的一系列服务管理范畴，它帮助IT管理人员回答了”IT部门能提供什么服务”的问题，也回答了”如何实施高质量IT服务”，更回答了“以什么可衡量的方式和标准”提供满足用户和业务需求的服务的问题。

参考ITIL管理体系来建立运行管理平台、管理制度和流程，设计相应人员职责角色，优化管理组织结构，选择和配置各类管理工具，通过人员(People)、技术/工具(Technology)和流程(Process)的有机结合，有效实现上述项管理，并集成为一个整体的IT运行管理系统，是实现IT运维管理标准化，规范化的重要步骤。

4.1.2 分阶段实施方法

ITIL是综合性的IT服务管理体系，包含了全部IT管理流程规范，但IT管理流程的构建或规范化是一个长期的过程，没有任何一家企业可以让自己的IT部门在一夜之间把所有的ITIL规范流程建立起来，一步使自己的IT管理变得成熟起来。因此，有计划、分步骤地将ITIL中所描述的各流程应用在日常的系统运行维护和管理中去是现阶段最切实可行的方法。

精选

利润中心 IT价值

人员 – 流程 – 技术 • 容量管理 • IT财务管理

服务管理 • 服务级别管理 • 可用性管理 • 安全管理 •

运维管理 • 配置管理

• 突发事件管理 • 问题管理 • 变更管理

时间

根据ITIL的建议和实践经验，以上是比较常见和可行的分阶段实施方案，其中的第一阶段包括帮助台/突发事件管理、配置管理、问题管理和变更管理， 所有这些流程组合成ITIL的运维管理流程规范，属于上述的服务运行管理流程。

在第一阶段实行运维管理规范流程的目的，是通过采用ITIL国际标准和全新的IT管理结构，综合企业信息系统的各种资源，包括人员，流程和技术，形成全面、统一、集中的管理构架及服务管理流程，确保信息系统能为企业发展提供可靠、高效、安全的IT服务。

上述的运维管理流程和日常性运维工作是不同的，日常性运维工作是针对不同的系统平台和应用进行的例行工作，如数据库管理、数据备份等等， 而运维管理流程是通过规范的流程来处理来自日常性运维工作中出现的突发事件，提出的变更请求等，包括所有在IT运行环境中必要的管理活动和衡量方法以推动和维护IT服务和生产环境能满足服务级别协议和业务目标， 通过与日常性运维工作的结合，将管理着眼于”监视和控制”以确保IT基础设施的稳定性， 实现规范性的流程管理， 确保IT服务及IT的相关运作环境达到所业务所需要的服务级别。

日常性运维工作在大多数IT部门里被认为是后端支持，所以动作和角色价值经常被低估。然而，高效的运维人员、相关工作流程和运维工具对于高质量的IT服务是很关键的。没有这些基础性工作，运维管理流程要成为7*24的连续性流程是不可能的，日

精选

常性运维工作通常包括：

➢ 系统资源状态/警告管理 ➢ 输出和打印队列管理 ➢ 备份管理

➢ 客户端，服务器和网络管理 ➢ 用户管理 ➢ IP地址管理 ➢ 数据库管理 ➢ 语音设施管理 ➢ 安全管理 ➢ 协调预防性维护 ➢ ……

下图为第一阶段四个运维流程之间的总体关系图：

由此可见，帮助台作为IT事件来源的中心接口，接受和登记事件并通过事件管理流程进行统一处理解决，问题管理流程对已发生的事件或紧急重大事件进行根本原因的分

精选

析，从而解决根本问题，防止事件的发生或重复发生；而变更管理流程通过提出变更请求实施问题/事件的解决方案，并通过分析和控制变更的风险和影响来确保变更的平稳实施；同时，配置管理给事件管理和问题管理提供配置信息，进行原因分析和确定解决方案，而变更管理通过了解配置元素信息和相互关系，确定变更的潜在影响和风险，并通过通知配置管理更新配置信息，保证配置元素的正确性，以确保事件管理和问题管理能得到所需要的最新的配置信息。

通过以上四个流程的建立，可以使日常的运维工作流程化，职责角色更清晰化， 从而使解决问题的速度和质量得到有效提高，使IT部门内的相关支持信息更为畅通和透明，使支持服务的信息更为完整和有效，实现知识积累和知识管理，并可以帮助IT部门更好地进行量化管理和设定优化指标，进行持续地服务改进， 最终能够为业务部门和用户提供更高质量的服务并提高他们的满意度，把IT部门建设成为规范的IT运维中心。

第二阶段的流程管理目的是实现服务管理， 重点在于在企业的IT环境中了解业务的IT服务级别需求，以此定义双方同意的服务级别，如可用性需求，并通过标准的流程进行服务级别的监视，汇报和改进，最终实现量化管理，通过分析实际服务水平和预定的服务目标之间的差距制定质量改进计划， 实现连续的质量改进循环，把IT部门建设成为真正的服务中心。

第三阶段是实现业务和IT的战略整合， 通过标准流程评估IT服务的在企业中的市场， 基于业务需要定义IT如何对企业价值链做贡献， 使IT部门最终能够成为用户的业务合作伙伴，最终把IT部门建设成为利润中心。

4.2 名词解释

ITIL国际规范 CCTA（英国国家电脑局）开发的ITIL，这是一套IT部门用来计划，研发，实施，运维高质量服务的标准管理库。它把各个业界在IT管理方面最好的方法归纳起来，变成规范，旨在为企业的IT部门提供一套标准的IT管理方法 帮助台 事件管理 IT服务管理与用户的单一接口，受理并处理用户的服务请求 和帮助台一起组成事件处理流程，有效解决各类IT突发事件；尽快精选

恢复IT服务 问题管理 寻求IT故障的根源，解决存在的问题；从而消除或减少IT事件的发生。 配置管理 变更管理 管理各IT资产系统(配置元素，CI)，包括相互间的关联与依赖关系。 对变更请求进行记录、跟踪与管理，消除或减少IT变更对生产环境和系统的影响和风险，保证变更的平稳运行。 发布管理 服务级别管理 可用性管理 容量管理 IT连续性管理 IT财务管理 安全管理 事件 确保IT系统和软件的有效实施和版本管理 保证整个业务系统的服务等级或水平，实现量化管理 监控所有重要IT资源，保证整个业务系统的可用性 监控和提高系统性能，进行性能规划 建立业务持续计划，保证系统的高可用性，以实现业务的持续运行 包括IT预算管理，成本管理和收费管理 对应用系统，网络及所有服务器提供可靠的安全保护 指发生了非常规的运作情况，包括系统崩溃、软件故障、任何影响用户业务操作和系统正常运作的事情、以及影响业务流程或违背服务水平协议的情况，事件也包括一个用户的请求 重分配规则 申告 故障 事件的及时、正确分配和接手处理是确保事件在目标服务时间内解决的关键因素。 指因IT系统或应用原因引起的用户投诉或数据差错。 指系统或应用中存在的错误或非正常因素，导致部分或全部业务不可用或者服务不正常。 咨询 业务处理 维护作业 事件来源 指对系统操作、业务流程等方面的求助和询问 指需要技术人员进行后台数据处理的要求 支持人员的日常维护作业或临时进行的维护作业 当接到一个问题时，帮助台人员需要记录事件来源的类型： 用户， 系统管理工具 事件优先级 优先级是事件管理流程的一个关键要素。优先级决定处理事件的顺序及所需的努力。事件的优先级通过综合衡量事件的影响度和紧急度得出 影响度 影响度用于衡量事件的业务严重程度，通常等于事件对服务水平的影响程度。影响度通常通过问题所影响的人数、关键系统数以及服务故障所造成的损失。 紧急度 紧急度表明解决问题所需的速度。具有高影响度的问题默认并不一定精选

需要立即解决。 事件升级 事件升级的目的是确保基于事件的优先级等级及时通知有关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。 事件分类 根据移动目前的事件种类，事件的分类层次设计不超过三层，第一级分类，称之为”类别”，第二级分类，称之为”子类”，第三级分类，称之为”条目”。 事件状态 事件状态表明事件所处在整个生命周期中的不同状态，如新开事件，一线处理中，已关闭等。 事件结束代码 事件经理 一线支持人员 事件结束代码说明了事件是在何种情况下关闭的 作为事件流程的负责人 负责提供对帮助台无法解决的事件进行快速有效的分析并提出解决方案以尽快恢复服务，并在必要时提供现场支持 二线支持人员 是相关问题领域的专家。他负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案尽快恢复服务 三线支持人员 事件流水号 事件持续时间 配置元素CI 配置管理数据库CMDB 配置元素属性 配置元素状态 配置元素关系 搜索代码 表示配置元素CI的一项信息，如序列号，版本等 配置元素在整个生命周期中的不同状态，如已登记，维修中等 不同配置元素之间的相互关系，如联结，父子等 在配置管理数据库(CMDB)唯一能识别配置元素的代码，并以此进行配置元素的搜索等 问题优先级别 问题影响程度 问题状态 问题分类 问题需要找到解决方案的紧急程度 问题对IT环境的影响程度，包括对其他IT系统，对相关IT人员等 问题在整个生命周期中的不同状态，如已登记，处理中等 从问题从属的系统或技术架构的类型来进行分类，如数据库，服务器等 问题性质 问题结束代码 根据问题的不同来源进行分类，如事件记录主动性分析等 根据事件结束的不同方式赋予不同的变同方法，没解决等 一般由第三方厂商承担 系统自动生成的工单号码 事件从发生到解决的时间 需要被管理的每一个IT系统或设备 是一个数据集合，存储所有配置管理的数据和信息 精选

流程角色 在问题管理流程中的的不同角色，具体包括问题经理， 问题分析专家等 变更优先级别 变更风险 变更状态 结束代码 变更类别 变更类型 流程角色 变更需要得到实施的紧急程度 实施变更可能带来的风险 变更请求从提出到实施到结束的整个生命周期中的不同状态 根据结束变更的不同方式赋予不同代码 变更的不同来源进行类别划分 从变更从属的系统或技术架构的类型来进行分类 在变更管理流程中的的不同角色， 具体包括变更请求者， 变更经理， 变更顾问委员会CAB等， 变更主管等 RFC 对问题的解决方案进行评估，通过变更请求（RFC）进行测试和实施。根据RFC对业务的影响和成本进行评估并决定继续进行与否。 CAB (Change 来帮助和支持变更经理，CAB的成员根据变更的实质可以包括客户代表，运维支持，应用开发和供应商等跟变更有关的人员 用以在实施阶段出现问题或紧急状况时需要把变更回退回去 Advisory Board） 回退计划

精选