中国移动业务管理及网络管理知识规范

更新时间:2023-04-29 17:17:01 阅读量: 实用文档 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

中国移动通信企业标准业务支撑网网管规范

1

目录

2

前言

说明该标准制定的目的、标准的附件及提示性{information}附件。

本标准由中国移动通信集团公司业务计费中心提出并归口。{业务相关标准由业务部门提出并归口、计费相关标准由计费业务中心提出并归口、网管相关标准由网络部提出并归口,其它标准由技术部提出并归口。}

本标准由标准提出并归口部门负责解释。

本标准起草单位:

本标准主要起草人:

本标准解释单位:同提出单位

3

1概述

为了提高中国移动的服务水平、管理水平和经营决策水平,为客户提供及时、准确和高质量的服务,使中国移动向世界一流通信运营企业迈进,建立高效科学的中国移动业务支撑网网管系统,特制定本规范。

本规范包含对中国移动业务支撑网网管系统的服务管理平台和监控管理平台的功能和技术基本要求。按照两级网管系统的原则,对中国移动业务支撑网网管系统进行了统一的规划,从而构建一个信息资源充分共享的一体化业务支撑体系,为中国移动业务组织、管理及市场经营、客户服务工作提供有力的技术支撑。

本技术规范包括三个附件,分别为:

附件一、

附件二、

附件三、

本规范是中国移动业务支撑网网管系统规划和建设的基本技术依据。全国中心、各省、自治区、直辖市公司在满足本规范的基础上,进行业务支撑网网管系统的建设。

1.1 范围

本标准{对标准的主要内容作提要式的说明}

本标准适用于{说明标准的适用领域}

本规范适用于中国移动集团业务支撑网网管系统及各省(直辖市、自治区)业务支撑网网管系统。

1.2 引用标准

《中国移动BOSS业务规范V1.0》

《中国移动BOSS技术规范V1.0》

4

《中国移动业务运营支撑系统维护规程》《IT Infrastructure Library V2.0》

1.3 术语和定义

1.4 符号和缩略语

符号和缩略语说明:

5

2总体说明

2.1 建设原则

业务支撑网网管系统的建设应遵循以下五条原则:

?先进性

参考全球IT管理业界公认的指导性框架ITIL(Information Technical Infrastructure Library)服务管理体系,规范业务支撑网运行管理和操作,指导各省采用先进的规范化IT管理模式,建设一流的服务管理流程。

?实用性

在不对生产系统带来过重的负荷下,在不影响正常生产的情况下,针对业务支撑系统,特别是目前已基本建设完成的BOSS系统,实现监控与运维管理,并结合各省公司的实际管理情况,逐步实现以运维流程管理贯穿整个运维管理过程,最终实现所有业务支撑系统的统一监控、统一管理、统一维护,为实现服务管理奠定基础。

6

根据业务支撑网网管系统采集的数据,进行趋势分析,预测将出现的问题,并在出现问题之前解决问题,从而避免故障的发生。

?高效性

值班人员操作简捷,运维人员处理快捷,管理人员管理直接。

当系统出现故障时,可能会有几十个乃至上百个告警信息,众多的告警让值班人员无从顾及。因此,在发出告警信息前需要对告警信息进行合并、过滤、定制,并提供初步的故障分析手段。提供简单快捷的操作方式,以及以简单、有效的方式通知运维人员或管理人员。

运维人员借助于业务支撑网网管系统,能进行快速故障定位,快速寻求帮助,从而达到快速解决故障的目的,最大限度地减少业务支撑系统的损失。

管理人员可随时了解业务支撑系统的运行状况,对工单进行跟踪,促进运维人员高效工作,对流程进行优化调整,提高管理水平。

?扩展性

目前建设的业务支撑网网管系统主要是针对BOSS系统进行监控与运维管理。随着业务、管理的发展,业务支撑网网管系统能以快速灵活的配置方式,将其管理范围扩充到整个业务支撑网上,逐步发展成为业务支撑网服务管理系统。

?规范性

各省建设省级业务支撑网网管系统,全国中心建设一套集团公司级业务支撑网网管系统。关键KPI全国统一,但各地根据实际情况,可扩充KPI,并细化相应的运维管理流程,促进运维管理流程化、规范化。

2.2 建设目标

业务支撑网网管系统的建设不是一个一蹴而就的过程,而是一个逐步建设、逐步完善的过程,其建设的阶段性决定了系统在不同阶段具有不同的建设目标。

在工程项目的本期建设中,业务支撑网网管系统的管理对象定位以BOSS系统为核心,提供如下管理功能:

1、监控管理功能

完成对平台部件、应用部件的集中监控、集中维护与集中管理,包括两大功能:

7

?集中监测

实现对BOSS平台部件与应用部件的告警数据、性能数据和配置数据进行采集、处理和呈现。

?故障定位与管理

及时采集各类告警数据和性能数据,进行数据分析和整合,并以适当的形式进行呈现,支持维护人员进行简单的故障定位,同时为运维管理提供基本信息。

2、运维管理

依靠流程实现由被动式支持向主动式服务演进,本期工程建设包括四大运维管理功能,即事件管理、问题管理、变更管理和配置管理,其分别对应四大运维管理流程,即事件管理流程、问题管理流程、变更管理流程和配置管理流程。

?事件管理流程

事件管理流程受事件驱动,所关心的是响应速度和尽快恢复业务运作,其目的是尽可能快地把服务恢复正常,使对业务的影响最小化。

?问题管理流程

问题管理流程的根本目的是消除或减少事件的发生,将BOSS架构内部缺陷导致的业务事件或问题的负面影响降到最低限度。

?变更管理流程

变更管理流程是通过一个单一的职能流程来控制和管理整个BOSS运行环境中的一切变更。

?配置管理流程

配置管理流程是一个描述、跟踪和汇报BOSS基础架构中的每一个设备或系统的配置过程。

运维管理流程的建设是非常关键的一个环节。流程的合理定义是对业务支撑系统进行成功有效管理的关键。管理对象、管理环境和管理要求的不断改变,使得管理流程也会随之变化,所以我们在制定本期目标时不能盲目追求大而全,以降低业务支撑网网管系统的项目实施风险。

本期目标应立足于监测业务,搜集、完善相关信息,制定管理流程,为下一步的工作打下基础。

从项目的长期建设看,业务支撑网网管系统的管理对象不限于BOSS系统,

8

而是将逐步扩展到其它生产型业务支撑系统,如经营分析系统、OA系统、MIS 系统等。考虑到各个专业的应用系统通常都有自己的监控系统,所以业务支撑网网管系统的管理对象扩展到其它应用系统时,不是替代其原有监控系统,而是整合其监控系统,整个业务支撑网网管的核心仍立足在对BOSS系统的管理上。

按管理对象范围划分,业务支撑网网管系统建设的本期目标和远期目标如表2-1所示,表中BOSS系统的内涵包括省级BOSS、一级BOSS以及客服系统。

表2-1网管系统本期和远期管理范围

按照所实现的管理功能划分,业务支撑网网管系统的本期目标和远期目标如表2-2所示。

表2-2网管系统本期和远期实现的功能

9

实现运维管理是向服务管理演进的基础,运维管理所包含的内容在实现服务管理时还需要进行深化。

2.3 业务支撑网网管系统的体系结构

参照中国移动业务支撑系统建设的体系结构,中国移动业务支撑网网管系统的体系结构分为两级,如图2-3所示,即集团公司业务支撑网网管系统和省公司业务支撑网网管系统。

图2-3 中国移动业务支撑网网管体系结构

中国移动业务支撑系统遍布全国,规模较大,为了集团公司更加有效地全面监控和管理,在集团公司一级业务支撑系统和各省公司业务支撑系统建设的基础上,设置两级业务支撑网网管系统,采用两级管理模式进行管理,即:第一级:集团公司业务支撑网网管系统,负责全面监控和管理北京清算中心、深圳清算中心,并且通过省级网管系统管理各省市自治区的业务支撑系统。

第二级:省公司业务支撑网网管系统,负责统一全面监控和管理本省、市、自治区的业务支撑系统运行状况。

集团公司业务支撑网网管系统与省公司业务支撑网系统通过广域网或专门的传输线路相联,以实现业务管理数据的交换。

10

2.4 业务支撑网网管系统框架

图2-4 省级业务支撑网网管系统框架

如图2-4所示,省级业务支撑网网管系统主要由监控管理平台、服务管理平台、安全管理和接口四部分组成。其主要功能描述如下:

1、监控管理平台

?监控管理平台实现对业务支撑系统的运行状态的统一监控。

?业务支撑系统的被监控对象包括平台部件类的主机、网络、数据库、中间件、存储、备份等设备和应用部件类的各系统的应用软件。

?监控管理平台结构划分为三层,分别是数据采集层、数据处理层、应用展现层,被监控对象的网管数据(性能数据、告警数据、部分配置数据)

通过三个层面的处理,统一展现给监控和维护人员。

?数据采集层通过与被管系统的接口采集网管数据,送到数据处理层进行数据处理。

?数据处理层一方面对数据进行判断产生告警信息送到应用展现层,另一方面录入监控数据库。

?应用展现层不仅展现告警信息,而且展现各种监控视图。

?通过与服务管理平台的接口,监控管理平台有选择性地将告警信息送到

11

服务管理平台,形成事件提交运维管理人员处理。

?通过与服务管理平台的接口,监控数据库中的配置数据可与服务管理平台的CMDB中的相应配置数据进行同步。

2、服务管理平台

?服务管理平台用于业务支撑网网管系统的统一维护管理工作,它主要提供的四大管理流程分别是:事件管理流程、问题管理流程、变更管理流

程和配置管理流程。

?事件管理模块中的帮助台作为IT事件来源的中心接口,接受和记录各种信息,并形成事件,进而通过事件管理流程进一步处理。

?问题管理流程对已发生的事件或紧急重大事件进行根本原因的分析,从而解决根本问题,防止事件的发生或重复发生。

?变更管理流程通过提出变更请求实施问题/事件的解决方案,并通过分析和控制变更的风险和影响来确保变更的平稳实施。

?配置管理给事件管理和问题管理提供配置信息,进行原因分析和确定解决方案,而变更管理通过了解配置元素信息和相互关系,确定变更的潜

在影响和风险,并通过通知配置管理更新配置信息,保证配置元素的正

确性,以确保事件管理和问题管理能得到所需要的最新的配置信息。

?通过以上四个流程的建立,可以使日常的运维工作流程化,职责角色清晰化,从而使解决问题的速度和质量得到有效提高。

?四大流程的实现需要流程支撑层和服务管理数据库的支撑。

?通过与集团业务支撑网网管接口,将关键配置数据、紧急事件、紧急问题、重大变更及审批申请等信息送到集团公司。

3、安全管理

安全管理包括用户、角色及权限的管理,以及网管系统自身的安全管理和日志要求。

4、监控管理平台和服务管理平台既相对独立,又存在一定的依赖关系。

两个平台的结合,能够全面、正确、及时地反映被管系统的运行状态,提高维护质量和效率,使IT部门内支持服务的信息更为畅通、透明、完整和有效;同时,通过知识积累和知识管理,进而设定优化指标,进行量化管理,实现持续

12

的服务改进;最终,能够为业务部门和用户提供更高质量的服务并提高他们的满意度,把IT部门建设成为规范的IT运维中心。

3功能要求

3.1 系统功能概述

如图3-1所示,业务支撑网网管系统分为四大功能模块,即:监控管理平台、服务管理平台、安全管理、接口。

图3-1 业务支撑网网管总体功能

监控管理平台,完成对被管平台部件、应用部件的集中监控、集中维护和集中管理;服务管理平台侧重于通过流程的管理完成对系统服务状况的统一管理。

监控管理平台主要完成对网管数据的采集、处理、和呈现。通过网管数据的采集和处理,实现对系统的统一监控,形成告警数据、性能数据和配置数据。监控管理平台着重于及时发现各类告警和性能异常,进行数据分析和整合,同时以适当的形式进行呈现;另一方面,维护人员借助监控管理平台应能进行相关操作,及时完成维护职能。

被管对象分为两类:一类为平台部件,包括主机、数据库、网络、存储、中间件等;另一类为应用部件,主要针对业务支撑系统的各类应用。

服务管理平台与监控管理平台的事件接口为事件管理的帮助台。通过帮助台,服务管理平台接收各类事件,并按照预先定义的事件管理流程完成事件的处理;同时,通过问题管理、变更管理、配置管理流程的有效执行,将运维模式由

13

被动的支持转为主动式服务。服务管理平台着重于依靠流程实现人员与工具的有机结合。

服务管理平台与监控管理平台有相应的配置管理数据,由两个平台的数据接口来保障配置管理数据的一致。

省级业务支撑网网管系统本身作为一个完整的管理系统,对各省业务支撑网提供平台、业务方面的监测及管理,涉及到与各个业务系统以及集团公司网管系统的接口,应提供完善的安全管理机制,保证业务支撑系统以及网管系统本身的安全。

3.2 服务管理平台功能描述

3.2.1总体设计原则

服务管理平台的建设应充分考虑并遵循安全、高效、合理、先进、可扩展性的原则。

?高可靠性:网管系统应具备冗余机制,避免由于意外down机而造成的损失。

?安全性:应具备防范黑客、病毒攻击的措施,避免泄漏机密的信息。

?高效性:应保障高效的运转,避免由于并发访问而造成的性能瓶颈。

?合理性:通过合理的分配利用资源,避免资源的浪费。

?先进性:系统采用先进的、成熟的设备和技术。

?开放性:开放与各种网络、主机、应用管理系统的接口,开放数据存储的结构。

?可扩展性:系统应考虑到将来的发展,为将来的发展预留足够的空间。

3.2.2功能综述

?参照ITIL 基本框架

引入服务管理平台不仅是满足当前中国移动的本期需求,更重要的是为未来实施其它服务管理流程打好基础。借鉴先进的管理思想,要求服务管理平台的帮助台、事件管理、问题管理、变更管理、配置管理以及远期的可用性管理、版本

14

发布管理、服务等级管理等各方面参照ITIL标准,与ITIL的结构、功能、词汇等各方面要求一致。

?流程的定制

中国移动业务支撑系统的环境在发展、业务在发展、组织结构在发展、需求在发展,直接导致业务逻辑流程的不断变化,需要服务管理平台能够快速适应变化,管理流程的定制应该尽可能的方便、快速,尽可能对现有的运行环境不产生负面影响。

?体系结构

系统设计为三层体系结构:由数据库服务器,应用服务器和展现界面组成。三层结构可以集中在一台机器上也可以分布在不同的设备中。

要求数据集中存储,建立统一的服务管理数据库,便于分析和管理。

服务管理平台应具有可配置性和可监控性。

服务管理平台应具有流程的完整性,提供机制保障流程的闭环。

服务管理平台应具有可管理性,可以跟踪和监视工单。

服务管理平台应具有可扩展性,有较好的集成性。

?安全策略

系统具有用户的权限管理,按照角色定义用户人员的权限等相关的安全属性,定义用户可以查看、修改、新增、删除的操作范围,对每个信息字段的读写权限。这些权限和状态可以灵活定义。

服务管理平台应能够按照维护小组划分,为每个小组分配适当的权限。

安全策略在整个环境中保持一致,在一个地方通过管理员的设定后,在任意客户端都可以实现安全的控制。

?查询与统计

服务管理平台应提供查询功能,可以针对任意关键字段进行查询。

服务管理平台应该提供报表统计功能,可以针对任意字段进行查询、过滤、排序等操作,生成各种统计报表和图表。

另外服务管理平台的数据要基于开放的关系数据库,数据结构有详细的描述以及开放接口,能够采用第三方的专用报表产品做报表的详尽统计分析功能。

?附件添加

15

服务管理平台应支持添加附件文件的功能。设备的文档、手册、故障发生时的拷屏图等是运行维护中的重要信息。附件的存储与处理方式,不能对服务管理平台的正常运行产生不良的影响。

?通告机制

事件的通告、变更的授权等都要保持服务管理平台与使用者之间的有效联络,应能使用短信、邮件、声光等灵活的方式提供通告机制。

?触发机制

为了配合集团公司的管理要求,将紧急事件、紧急问题、重大变更及时上报给集团公司,服务管理平台的事件管理模块、问题管理模块、变更管理模块应有触发机制,在每个变化点触发上报的功能,将事件/问题/变更请求的当前状态上传给集团公司。

对于统计报表,服务管理平台应提供选择报表、上传集团公司的功能。

?日志

在服务管理平台中,人员的操作过程在数据库中应有日志记录,并可被浏览和审核。包括:事件、问题、变更、配置等模块信息的变化,都应生成日志。

?知识库

服务管理平台应建立知识库。作为知识库的管理通常包含两个方面:知识的积累和知识的使用。

知识库初始化的信息来自于IT运维人员过去的管理经验,加以提炼作为解决方案加入到知识库中,包含着问题根源的分析、解决方法的建议、如何有效地避免问题的发生等丰富的管理知识。

另外,在长期的运维过程中还可不断地积累知识。

知识库应具有如下功能:

1.提供支持人员提交经验和知识的输入接口或界面。

2.提供知识库内容的审查功能。

3.提供完善的查询功能,例如:查询关键字、知识列表等。

4.具有不同等级用户环境的区别,不同等级的用户管理不同的知识库内

容。

5.提供知识库的分类整理,易于扩展、调整。

16

6.知识库应支持Word/Excel/TXT等格式文档作为附件的输入。

3.2.3事件管理功能

3.2.3.1 事件接收和记录

?支持人工发起故障处理请求,以及监控管理平台自动产生事件请求。

?根据提交方式的不同,支持WEB、Email、电话和其它管理软件自动发送等方式:

17

在这一阶段支持:

1.事件信息应尽量由系统自动生成,具体内容参见附件一。

2.事件管理模块还应当支持重复事件记录的关联。

3.2.3.2 分类和优先级设定

?事件的分类按照事件的级别层次和内容由管理员预先定义,可以灵活调整。

?只需要从已定义级别中做出选择,不需要手工输入信息。

?监控管理平台上传的告警信息,应包含该告警相关联的配置元素的搜索代码,帮助台人员以此确定配置元素及其关键级别。

?在掌握事件中足够的信息后,就可以根据上述条件自动计算出该事件的解决方案的最终期限,并在需要的情况下可以适当地做人为调整。

3.2.3.3 调查和诊断

?事件管理模块可与服务管理平台中的其它模块进行关联,如:事件管理模块可与问题管理、变更管理、配置管理等紧密集成,并提供查找相关

信息的功能。

?服务管理平台应支持知识库功能,可以查询知识库中是否有此种事件处理的标准步骤,如果有则直接按照标准步骤进行操作。从而使得这类已

经清楚掌握的事件能够以标准规范的方法处理。

?可以和配置元素(如主机等)关联,自动获取该对象的信息。

?可以分别根据事件的属性、事件申请人、配置元素、事件所影响到的业务、申请人所属部门等查看正在进行和已处理完毕的事件。

?服务管理平台可以集成必要的管理工具,帮助维护人员借助此类工具进行初步的调查与诊断。

3.2.3.4 事件处理

?系统可以实现人工指派和自动指派方式,并且可以重新指派,如:故障

18

处理请求是某台设备出现故障,则自动将故障处理请求派发给管理该设

备的部门和人员。

?可以向受理人员发出提示信息,如手机短信、电子邮件等,提示工单的生成。

?在受理工单人员登录进入系统后,能够根据自己的权限看到自己应处理的故障单,并且根据角色的不同所看到的表现形式也是不同的。

?受理部门生成事件工单后可以有以下几种处理动作:

3.2.3.5 事件升级

?可以方便定义自动升级处理的阀值。

?可基于时间信息升级处理。当事件处理超过预期时限,根据预定义的升

19

级条件,服务管理平台将该事件自动/手工升级到指定的人员。

3.2.3.6 结束事件

?支持提供可客户化的事件工单结束代码

?对于监控系统自动产生的事件工单,可以在服务管理平台自动关闭(可选)

3.2.4问题管理功能

问题管理模块可以支持以下几种创建问题的方式:

?通过事件管理模块创建一个问题

事件管理模块与问题管理模块具有关联,可以对系统中记录的历史事件进行统计分析,从中分析出潜在的问题,自动创建一个问题记录,该问题记录与相关事件信息进行关联。

?直接录入

在问题管理模块界面中创建问题记录,直接录入问题的信息。

3.2.

4.1 分类和优先级设定

?按照优先级对问题的级别进行划分,划分的层次、内容预先由管理员定义,用户只需要从中做出选择,不需要手工输入信息。

?问题的分类由管理员预先定义,可以灵活调整。

?在掌握了问题中足够的信息后,就可以根据上述条件自动计算出该问题的解决方案的最终期限,并在需要的情况下可以适当地做人为调整。

3.2.

4.2 问题处理

?根据问题内容,将问题记录分派给适当的技术小组负责处理。

?问题管理模块应当支持通知功能,使不同组别或部门间保持沟通。

20

?支持对问题解决历史过程的记录功能。

?问题管理模块应当记录问题的解决方案、变通方法、预防性措施。

?支持问题的状态代码的设定,如:已知错误等。

?支持与变更管理功能模块的关联,可直接转入变更管理模块发起一个变更请求(RFC)。

3.2.

4.3 关闭

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

?问题管理模块应提供问题关闭功能,并标识问题结束代码。

3.2.

4.4 事后回顾

问题管理模块可记录回顾活动的内容。

3.2.5变更管理功能

3.2.5.1 建立变更

?变更管理模块应提供建立变更请求(RFC)的功能。变更请求有以下来源:

1. 直接录入(用户直接产生一个变更请求)

2. 事件管理模块产生一个变更请求

3. 问题管理模块产生一个变更请求

?变更管理模块可提供预定义变更模板的功能。变更模板功能可以支持结构化的变更方法,模板可用于保证使用标准的操作步骤,可以创建每个

变更都应包含的任务单。

?变更请求可与事件、问题记录关联,可以给出有关变更的信息。

21

本文来源:https://www.bwwdw.com/article/y1uq.html

Top