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

《中国移动业务管理及网络管理知识规范》由会员分享，可在线阅读，更多相关《中国移动业务管理及网络管理知识规范（86页珍藏版）》请在装配图网上搜索。

1、中国移动通信企业标准业务支撑网网管规范目录前言说明该标准制定的目的、标准的附件及提示性information附件。本标准由中国移动通信集团公司业务计费中心提出并归口。业务相关标准由业务部门提出并归口、计费相关标准由计费业务中心提出并归口、网管相关标准由网络部提出并归口，其它标准由技术部提出并归口。本标准由标准提出并归口部门负责解释。本标准起草单位：本标准主要起草人：本标准解释单位：同提出单位1 概述为了提高中国移动的服务水平、管理水平和经营决策水平，为客户提供及时、准确和高质量的服务，使中国移动向世界一流通信运营企业迈进，建立高效科学的中国移动业务支撑网网管系统，特制定本规范。本规范包含对中国

2、移动业务支撑网网管系统的服务管理平台和监控管理平台的功能和技术基本要求。按照两级网管系统的原则，对中国移动业务支撑网网管系统进行了统一的规划，从而构建一个信息资源充分共享的一体化业务支撑体系，为中国移动业务组织、管理及市场经营、客户服务工作提供有力的技术支撑。本技术规范包括三个附件，分别为：附件一、附件二、附件三、本规范是中国移动业务支撑网网管系统规划和建设的基本技术依据。全国中心、各省、自治区、直辖市公司在满足本规范的基础上，进行业务支撑网网管系统的建设。1.1 范围本标准 对标准的主要内容作提要式的说明本标准适用于 说明标准的适用领域本规范适用于中国移动集团业务支撑网网管系统及各省（直辖市

3、、自治区）业务支撑网网管系统。1.2 引用标准中国移动BOSS业务规范中国移动BOSS技术规范中国移动业务运营支撑系统维护规程IT Infrastructure Library1.3 术语和定义名词解释服务台也称为帮助台，IT服务管理与用户的接口，受理并处理用户的服务请求。事件管理和帮助台一起组成事件处理流程，有效解决各类IT突发事件，尽快恢复IT服务。问题管理寻求IT故障的根源，解决存在问题的流程，能消除或减少IT事件的发生。配置管理管理各IT资产系统(配置元素，CI)的流程，包括相互间的关联与依赖关系。变更管理对变更请求进行记录、跟踪与管理的流程，消除或减少IT变更对生产环境和系统的影响和

4、风险，保证变更的平稳运行。监控管理完成对平台部件、应用的统一监控、统一维护，包括集中监测和故障定位与管理。运维管理包括帮助台/事件管理，配置管理，问题管理和变更管理等流程，作为业务支撑网网管分阶段实施所建议的第一阶段。服务管理业务支撑网网管分阶段实施所建议的第二阶段，在企业的IT环境中了解业务的IT服务级别需求，以此定义双方同意的服务级别，并通过标准的流程进行服务级别的监视，汇报和改进，最终实现量化管理， 实现连续的质量改进循环，把IT部门建设成为真正的服务中心。监控管理平台服务管理平台业务应用软件系统平台1.4 符号和缩略语符号和缩略语说明：缩写英文描述中文描述BOSSBusiness Op

5、eration Support System中国移动定义和建设的业务运营支撑系统KPIKey Performance Indicator关键性能指标CMConfiguration ManagementTMN中定义的配置管理FMFault ManagementTMN中定义的故障管理PMPerformance ManagementTMN中定义的性能管理SNMPSimple Network Management Protocol简单网络管理协议CORBASMTPSimple Mail Transfer Protocol简单邮件传送协议SMPPCMPPMQMessage Queue消息队列ITILIT

6、 Infrastructure LibraryIT基础设施库，是英国国家电脑局开发的IT管理国际规范RFCRequest for Change变更请求CMDBConfiguration Management DatabaseITIL中定义的配置管理数据库SLAService Level Agreement服务级别协议2 总体说明2.1 建设原则业务支撑网网管系统的建设应遵循以下五条原则： 先进性参考全球IT管理业界公认的指导性框架ITIL（Information Technical Infrastructure Library）服务管理体系，规范业务支撑网运行管理和操作，指导各省采用先进的规范

7、化IT管理模式，建设一流的服务管理流程。 实用性在不对生产系统带来过重的负荷下，在不影响正常生产的情况下，针对业务支撑系统，特别是目前已基本建设完成的BOSS系统，实现监控与运维管理，并结合各省公司的实际管理情况，逐步实现以运维流程管理贯穿整个运维管理过程，最终实现所有业务支撑系统的统一监控、统一管理、统一维护，为实现服务管理奠定基础。根据业务支撑网网管系统采集的数据，进行趋势分析，预测将出现的问题，并在出现问题之前解决问题，从而避免故障的发生。 高效性值班人员操作简捷，运维人员处理快捷，管理人员管理直接。当系统出现故障时，可能会有几十个乃至上百个告警信息，众多的告警让值班人员无从顾及。因此，

8、在发出告警信息前需要对告警信息进行合并、过滤、定制，并提供初步的故障分析手段。提供简单快捷的操作方式，以及以简单、有效的方式通知运维人员或管理人员。运维人员借助于业务支撑网网管系统，能进行快速故障定位，快速寻求帮助，从而达到快速解决故障的目的，最大限度地减少业务支撑系统的损失。管理人员可随时了解业务支撑系统的运行状况，对工单进行跟踪，促进运维人员高效工作，对流程进行优化调整，提高管理水平。 扩展性目前建设的业务支撑网网管系统主要是针对BOSS系统进行监控与运维管理。随着业务、管理的发展，业务支撑网网管系统能以快速灵活的配置方式，将其管理范围扩充到整个业务支撑网上，逐步发展成为业务支撑网服务管理

9、系统。 规范性各省建设省级业务支撑网网管系统，全国中心建设一套集团公司级业务支撑网网管系统。关键KPI全国统一，但各地根据实际情况，可扩充KPI，并细化相应的运维管理流程，促进运维管理流程化、规范化。2.2 建设目标业务支撑网网管系统的建设不是一个一蹴而就的过程，而是一个逐步建设、逐步完善的过程，其建设的阶段性决定了系统在不同阶段具有不同的建设目标。在工程项目的本期建设中，业务支撑网网管系统的管理对象定位以BOSS系统为核心，提供如下管理功能：1、监控管理功能完成对平台部件、应用部件的集中监控、集中维护与集中管理，包括两大功能： 集中监测实现对BOSS平台部件与应用部件的告警数据、性能数据和配

10、置数据进行采集、处理和呈现。 故障定位与管理及时采集各类告警数据和性能数据，进行数据分析和整合，并以适当的形式进行呈现，支持维护人员进行简单的故障定位，同时为运维管理提供基本信息。2、运维管理依靠流程实现由被动式支持向主动式服务演进，本期工程建设包括四大运维管理功能，即事件管理、问题管理、变更管理和配置管理，其分别对应四大运维管理流程，即事件管理流程、问题管理流程、变更管理流程和配置管理流程。 事件管理流程事件管理流程受事件驱动，所关心的是响应速度和尽快恢复业务运作，其目的是尽可能快地把服务恢复正常，使对业务的影响最小化。 问题管理流程问题管理流程的根本目的是消除或减少事件的发生，将BOSS架

11、构内部缺陷导致的业务事件或问题的负面影响降到最低限度。 变更管理流程变更管理流程是通过一个单一的职能流程来控制和管理整个BOSS运行环境中的一切变更。 配置管理流程配置管理流程是一个描述、跟踪和汇报BOSS基础架构中的每一个设备或系统的配置过程。运维管理流程的建设是非常关键的一个环节。流程的合理定义是对业务支撑系统进行成功有效管理的关键。管理对象、管理环境和管理要求的不断改变，使得管理流程也会随之变化，所以我们在制定本期目标时不能盲目追求大而全，以降低业务支撑网网管系统的项目实施风险。本期目标应立足于监测业务，搜集、完善相关信息，制定管理流程，为下一步的工作打下基础。从项目的长期建设看，业务支

12、撑网网管系统的管理对象不限于BOSS系统，而是将逐步扩展到其它生产型业务支撑系统，如经营分析系统、OA系统、MIS系统等。考虑到各个专业的应用系统通常都有自己的监控系统，所以业务支撑网网管系统的管理对象扩展到其它应用系统时，不是替代其原有监控系统，而是整合其监控系统，整个业务支撑网网管的核心仍立足在对BOSS系统的管理上。按管理对象范围划分，业务支撑网网管系统建设的本期目标和远期目标如表2-1所示，表中BOSS系统的内涵包括省级BOSS、一级BOSS以及客服系统。对象 目标本期远期BOSS系统经营分析系统MIS系统其它应用表2-1网管系统本期和远期管理范围按照所实现的管理功能划分，业务支撑网网

13、管系统的本期目标和远期目标如表2-2所示。功能 目标本期远期监控管理集中监测故障定位与管理运维管理事件管理问题管理变更管理配置管理服务管理服务级别管理可用性管理安全管理发布管理容量管理服务连续性管理表2-2网管系统本期和远期实现的功能实现运维管理是向服务管理演进的基础，运维管理所包含的内容在实现服务管理时还需要进行深化。2.3 业务支撑网网管系统的体系结构参照中国移动业务支撑系统建设的体系结构，中国移动业务支撑网网管系统的体系结构分为两级，如图2-3所示，即集团公司业务支撑网网管系统和省公司业务支撑网网管系统。图2-3 中国移动业务支撑网网管体系结构中国移动业务支撑系统遍布全国，规模较大，为了

14、集团公司更加有效地全面监控和管理，在集团公司一级业务支撑系统和各省公司业务支撑系统建设的基础上，设置两级业务支撑网网管系统，采用两级管理模式进行管理，即：第一级：集团公司业务支撑网网管系统，负责全面监控和管理北京清算中心、深圳清算中心，并且通过省级网管系统管理各省市自治区的业务支撑系统。第二级：省公司业务支撑网网管系统，负责统一全面监控和管理本省、市、自治区的业务支撑系统运行状况。集团公司业务支撑网网管系统与省公司业务支撑网系统通过广域网或专门的传输线路相联，以实现业务管理数据的交换。2.4 业务支撑网网管系统框架图2-4 省级业务支撑网网管系统框架如图2-4所示，省级业务支撑网网管系统主要由

15、监控管理平台、服务管理平台、安全管理和接口四部分组成。其主要功能描述如下：1、监控管理平台 监控管理平台实现对业务支撑系统的运行状态的统一监控。 业务支撑系统的被监控对象包括平台部件类的主机、网络、数据库、中间件、存储、备份等设备和应用部件类的各系统的应用软件。 监控管理平台结构划分为三层，分别是数据采集层、数据处理层、应用展现层，被监控对象的网管数据(性能数据、告警数据、部分配置数据)通过三个层面的处理，统一展现给监控和维护人员。 数据采集层通过与被管系统的接口采集网管数据，送到数据处理层进行数据处理。 数据处理层一方面对数据进行判断产生告警信息送到应用展现层，另一方面录入监控数据库。 应用

16、展现层不仅展现告警信息，而且展现各种监控视图。 通过与服务管理平台的接口，监控管理平台有选择性地将告警信息送到服务管理平台，形成事件提交运维管理人员处理。 通过与服务管理平台的接口，监控数据库中的配置数据可与服务管理平台的CMDB中的相应配置数据进行同步。2、服务管理平台 服务管理平台用于业务支撑网网管系统的统一维护管理工作，它主要提供的四大管理流程分别是：事件管理流程、问题管理流程、变更管理流程和配置管理流程。 事件管理模块中的帮助台作为IT事件来源的中心接口，接受和记录各种信息，并形成事件，进而通过事件管理流程进一步处理。 问题管理流程对已发生的事件或紧急重大事件进行根本原因的分析，从而解

17、决根本问题，防止事件的发生或重复发生。 变更管理流程通过提出变更请求实施问题/事件的解决方案，并通过分析和控制变更的风险和影响来确保变更的平稳实施。 配置管理给事件管理和问题管理提供配置信息，进行原因分析和确定解决方案，而变更管理通过了解配置元素信息和相互关系，确定变更的潜在影响和风险，并通过通知配置管理更新配置信息，保证配置元素的正确性，以确保事件管理和问题管理能得到所需要的最新的配置信息。 通过以上四个流程的建立，可以使日常的运维工作流程化，职责角色清晰化， 从而使解决问题的速度和质量得到有效提高。 四大流程的实现需要流程支撑层和服务管理数据库的支撑。 通过与集团业务支撑网网管接口，将关键

18、配置数据、紧急事件、紧急问题、重大变更及审批申请等信息送到集团公司。3、安全管理安全管理包括用户、角色及权限的管理，以及网管系统自身的安全管理和日志要求。4、监控管理平台和服务管理平台既相对独立，又存在一定的依赖关系。两个平台的结合，能够全面、正确、及时地反映被管系统的运行状态，提高维护质量和效率，使IT部门内支持服务的信息更为畅通、透明、完整和有效；同时，通过知识积累和知识管理，进而设定优化指标，进行量化管理，实现持续的服务改进；最终，能够为业务部门和用户提供更高质量的服务并提高他们的满意度，把IT部门建设成为规范的IT运维中心。3 功能要求3.1 系统功能概述如图3-1所示，业务支撑网网管

19、系统分为四大功能模块，即：监控管理平台、服务管理平台、安全管理、接口。图3-1 业务支撑网网管总体功能监控管理平台，完成对被管平台部件、应用部件的集中监控、集中维护和集中管理；服务管理平台侧重于通过流程的管理完成对系统服务状况的统一管理。监控管理平台主要完成对网管数据的采集、处理、和呈现。通过网管数据的采集和处理，实现对系统的统一监控，形成告警数据、性能数据和配置数据。监控管理平台着重于及时发现各类告警和性能异常，进行数据分析和整合，同时以适当的形式进行呈现；另一方面，维护人员借助监控管理平台应能进行相关操作，及时完成维护职能。被管对象分为两类：一类为平台部件，包括主机、数据库、网络、存储、中

20、间件等；另一类为应用部件，主要针对业务支撑系统的各类应用。服务管理平台与监控管理平台的事件接口为事件管理的帮助台。通过帮助台，服务管理平台接收各类事件，并按照预先定义的事件管理流程完成事件的处理；同时，通过问题管理、变更管理、配置管理流程的有效执行，将运维模式由被动的支持转为主动式服务。服务管理平台着重于依靠流程实现人员与工具的有机结合。服务管理平台与监控管理平台有相应的配置管理数据，由两个平台的数据接口来保障配置管理数据的一致。省级业务支撑网网管系统本身作为一个完整的管理系统，对各省业务支撑网提供平台、业务方面的监测及管理，涉及到与各个业务系统以及集团公司网管系统的接口，应提供完善的安全管理

21、机制，保证业务支撑系统以及网管系统本身的安全。3.2 服务管理平台功能描述3.2.1 总体设计原则服务管理平台的建设应充分考虑并遵循安全、高效、合理、先进、可扩展性的原则。 高可靠性：网管系统应具备冗余机制，避免由于意外down机而造成的损失。 安全性：应具备防范黑客、病毒攻击的措施，避免泄漏机密的信息。 高效性：应保障高效的运转，避免由于并发访问而造成的性能瓶颈。 合理性：通过合理的分配利用资源，避免资源的浪费。 先进性：系统采用先进的、成熟的设备和技术。 开放性：开放与各种网络、主机、应用管理系统的接口，开放数据存储的结构。 可扩展性：系统应考虑到将来的发展，为将来的发展预留足够的空间。3

22、.2.2 功能综述 参照ITIL 基本框架引入服务管理平台不仅是满足当前中国移动的本期需求，更重要的是为未来实施其它服务管理流程打好基础。借鉴先进的管理思想，要求服务管理平台的帮助台、事件管理、问题管理、变更管理、配置管理以及远期的可用性管理、版本发布管理、服务等级管理等各方面参照ITIL标准，与ITIL的结构、功能、词汇等各方面要求一致。 流程的定制中国移动业务支撑系统的环境在发展、业务在发展、组织结构在发展、需求在发展，直接导致业务逻辑流程的不断变化，需要服务管理平台能够快速适应变化，管理流程的定制应该尽可能的方便、快速，尽可能对现有的运行环境不产生负面影响。 体系结构系统设计为三层体系结

23、构：由数据库服务器，应用服务器和展现界面组成。三层结构可以集中在一台机器上也可以分布在不同的设备中。要求数据集中存储，建立统一的服务管理数据库，便于分析和管理。服务管理平台应具有可配置性和可监控性。服务管理平台应具有流程的完整性，提供机制保障流程的闭环。服务管理平台应具有可管理性，可以跟踪和监视工单。服务管理平台应具有可扩展性，有较好的集成性。 安全策略系统具有用户的权限管理，按照角色定义用户人员的权限等相关的安全属性，定义用户可以查看、修改、新增、删除的操作范围，对每个信息字段的读写权限。这些权限和状态可以灵活定义。服务管理平台应能够按照维护小组划分，为每个小组分配适当的权限。安全策略在整个

24、环境中保持一致，在一个地方通过管理员的设定后，在任意客户端都可以实现安全的控制。 查询与统计服务管理平台应提供查询功能，可以针对任意关键字段进行查询。服务管理平台应该提供报表统计功能，可以针对任意字段进行查询、过滤、排序等操作，生成各种统计报表和图表。另外服务管理平台的数据要基于开放的关系数据库，数据结构有详细的描述以及开放接口，能够采用第三方的专用报表产品做报表的详尽统计分析功能。 附件添加服务管理平台应支持添加附件文件的功能。设备的文档、手册、故障发生时的拷屏图等是运行维护中的重要信息。附件的存储与处理方式，不能对服务管理平台的正常运行产生不良的影响。 通告机制事件的通告、变更的授权等都要

25、保持服务管理平台与使用者之间的有效联络，应能使用短信、邮件、声光等灵活的方式提供通告机制。 触发机制为了配合集团公司的管理要求，将紧急事件、紧急问题、重大变更及时上报给集团公司，服务管理平台的事件管理模块、问题管理模块、变更管理模块应有触发机制，在每个变化点触发上报的功能，将事件/问题/变更请求的当前状态上传给集团公司。对于统计报表，服务管理平台应提供选择报表、上传集团公司的功能。 日志在服务管理平台中，人员的操作过程在数据库中应有日志记录，并可被浏览和审核。包括：事件、问题、变更、配置等模块信息的变化，都应生成日志。 知识库服务管理平台应建立知识库。作为知识库的管理通常包含两个方面：知识的积

26、累和知识的使用。知识库初始化的信息来自于IT运维人员过去的管理经验，加以提炼作为解决方案加入到知识库中，包含着问题根源的分析、解决方法的建议、如何有效地避免问题的发生等丰富的管理知识。另外，在长期的运维过程中还可不断地积累知识。知识库应具有如下功能：1. 提供支持人员提交经验和知识的输入接口或界面。2. 提供知识库内容的审查功能。3. 提供完善的查询功能，例如：查询关键字、知识列表等。4. 具有不同等级用户环境的区别，不同等级的用户管理不同的知识库内容。5. 提供知识库的分类整理，易于扩展、调整。6. 知识库应支持Word/Excel/TXT等格式文档作为附件的输入。3.2.3 事件管理功能3

27、.2.3.1 事件接收和记录 支持人工发起故障处理请求，以及监控管理平台自动产生事件请求。 根据提交方式的不同，支持WEB、Email、电话和其它管理软件自动发送等方式：提交方式描述WEB方式经过授权的最终用户可以登录web界面输入事件信息，并且能够查看知识库，判断是否可以自助解决问题。最终用户按要求填写故障处理请求内容，不能漏掉必需的关键字段，否则无法生成事件。若注册成功需自动将故障处理请求的ID号送回请求者，以便随时查看自己提交的请求状态。E-Mail方式用户按照不同的服务类型，选择相应的E-mail地址，填写并发送请求。流程管理平台收到E-Mail后，自动产生相应的故障处理请求，若注册成

28、功需自动将故障处理请求的ID号送回请求者，若不成功必须以邮件等方式返回相应的出错信息。人工方式用户打电话向服务台接线员报告问题，接线员根据记录的内容，注册故障处理请求。系统应当提供每个故障处理请求的检查列表（预先定义的一些常规问题，以标准化的方式收集信息），受理员可以通过检查列表的帮助，询问必要的信息，然后系统自动将问题结果填入故障处理请求中，实现信息采集的标准化。其它系统 其它监控系统（如：客服系统）将监控到的事件自动发送到流程管理平台，并能够把事件相关的属性（故障描述、时间、配置元素搜索代码等）传送到流程管理平台。事件可经过其它监控系统的预先处理，以预定格式进入流程管理平台。在这一阶段支持

29、：1. 事件信息应尽量由系统自动生成，具体内容参见附件一。2. 事件管理模块还应当支持重复事件记录的关联。3.2.3.2 分类和优先级设定 事件的分类按照事件的级别层次和内容由管理员预先定义，可以灵活调整。 只需要从已定义级别中做出选择，不需要手工输入信息。 监控管理平台上传的告警信息，应包含该告警相关联的配置元素的搜索代码，帮助台人员以此确定配置元素及其关键级别。 在掌握事件中足够的信息后，就可以根据上述条件自动计算出该事件的解决方案的最终期限，并在需要的情况下可以适当地做人为调整。3.2.3.3 调查和诊断 事件管理模块可与服务管理平台中的其它模块进行关联，如：事件管理模块可与问题管理、变

30、更管理、配置管理等紧密集成，并提供查找相关信息的功能。 服务管理平台应支持知识库功能，可以查询知识库中是否有此种事件处理的标准步骤，如果有则直接按照标准步骤进行操作。从而使得这类已经清楚掌握的事件能够以标准规范的方法处理。 可以和配置元素（如主机等）关联，自动获取该对象的信息。 可以分别根据事件的属性、事件申请人、配置元素、事件所影响到的业务、申请人所属部门等查看正在进行和已处理完毕的事件。 服务管理平台可以集成必要的管理工具，帮助维护人员借助此类工具进行初步的调查与诊断。3.2.3.4 事件处理 系统可以实现人工指派和自动指派方式，并且可以重新指派，如：故障处理请求是某台设备出现故障，则自动

31、将故障处理请求派发给管理该设备的部门和人员。 可以向受理人员发出提示信息，如手机短信、电子邮件等，提示工单的生成。 在受理工单人员登录进入系统后，能够根据自己的权限看到自己应处理的故障单，并且根据角色的不同所看到的表现形式也是不同的。 受理部门生成事件工单后可以有以下几种处理动作：动作描述事件处理请求批准系统定义一个事件处理请求的批准流程，只有按照步骤由有权限的经理批准后，才可以进行下一步的操作。确认事件工单服务管理平台应支持以下分派方式：分派到工作组分配到个人退回事件工单受理人如认为工单分派错误，可填写理由，退回上一级人员修改，工单进入退回状态。转发事件工单服务管理平台应支持事件工单的同级别

32、转发、以及转发到其它部门的管理平台。通知支持通知功能，受理人如有阶段性处理成果，可填写阶段处理结果通知相关人员（可进行多次阶段通知）。处理过程的监控系统可根据事件优先级、最终期限、转派次数进行监控，在预定义条件，自动向相关的负责人发送通知或转派。可以通过事件日志来监控事件处理。 事件处理请求查询支持多角度的查询功能，可以根据事件处理请求中的任意字段查询事件工单的信息。3.2.3.5 事件升级 可以方便定义自动升级处理的阀值。 可基于时间信息升级处理。当事件处理超过预期时限，根据预定义的升级条件，服务管理平台将该事件自动/手工升级到指定的人员。3.2.3.6 结束事件 支持提供可客户化的事件工单

33、结束代码 对于监控系统自动产生的事件工单，可以在服务管理平台自动关闭（可选）3.2.4 问题管理功能问题管理模块可以支持以下几种创建问题的方式： 通过事件管理模块创建一个问题事件管理模块与问题管理模块具有关联，可以对系统中记录的历史事件进行统计分析，从中分析出潜在的问题，自动创建一个问题记录，该问题记录与相关事件信息进行关联。 直接录入在问题管理模块界面中创建问题记录，直接录入问题的信息。3.2.4.1 分类和优先级设定 按照优先级对问题的级别进行划分，划分的层次、内容预先由管理员定义，用户只需要从中做出选择，不需要手工输入信息。 问题的分类由管理员预先定义，可以灵活调整。 在掌握了问题中足够

34、的信息后，就可以根据上述条件自动计算出该问题的解决方案的最终期限，并在需要的情况下可以适当地做人为调整。3.2.4.2 问题处理 根据问题内容，将问题记录分派给适当的技术小组负责处理。 问题管理模块应当支持通知功能，使不同组别或部门间保持沟通。 支持对问题解决历史过程的记录功能。 问题管理模块应当记录问题的解决方案、变通方法、预防性措施。 支持问题的状态代码的设定，如：已知错误等。 支持与变更管理功能模块的关联，可直接转入变更管理模块发起一个变更请求（RFC）。3.2.4.3 关闭 一旦找出问题根本原因，实施了解决方案，并确认已解决了问题，问题记录可以关闭。 问题管理模块应提供问题关闭功能，并

35、标识问题结束代码。3.2.4.4 事后回顾 问题管理模块可记录回顾活动的内容。3.2.5 变更管理功能3.2.5.1 建立变更 变更管理模块应提供建立变更请求（RFC）的功能。变更请求有以下来源：1. 直接录入（用户直接产生一个变更请求）2. 事件管理模块产生一个变更请求3. 问题管理模块产生一个变更请求 变更管理模块可提供预定义变更模板的功能。变更模板功能可以支持结构化的变更方法，模板可用于保证使用标准的操作步骤，可以创建每个变更都应包含的任务单。 变更请求可与事件、问题记录关联，可以给出有关变更的信息。3.2.5.2 变更授权 变更的通知和沟通变更管理模块应当支持通知功能，使不同组别或部门

36、间保持沟通。 变更请求的分类变更管理模块应提供变更请求分类、优先级设定的功能。 变更请求的分派变更管理模块应能将变更请求分派到相应的人员，进行评估和授权等，未经授权的变更请求不能得到实施。 变更评估的记录变更请求在评估过程中，变更管理模块应能为每个评估人员提供记录评估结果的入口，并记录评估结果。 变更请求的拒绝变更请求未得到批准时，变更管理模块应能将变更请求返回给请求者，并注明原因。3.2.5.3 处理变更 规划RFCRFC一旦获得批准，它必须根据资源和其它情况进行规划，确定实施日期，分配相应资源，并通知请求人。变更管理模块能记录和管理RFC的实施计划等内容。 协调变更实施变更功能模块应提供沟

37、通、监视功能，监视实施过程，并在必要时进行协调。 项目计划功能变更管理应在规划、构建、测试和实施过程中与企业计划或项目的管理工作相结合。可以使用项目计划功能来计划变更涉及的所有工作，协调多个变更之间的关系。 更新变更状态变更功能模块应提供变更状态的更新功能。 回顾和关闭能够设置变更结束代码；当变更完成后，问题、事件和配置元素应当自动或手动随之更新。3.2.6 配置管理功能3.2.6.1 配置管理数据库 配置管理数据库（CMDB）：是一个数据集合，存储所有配置管理的数据和信息。配置管理数据库是配置管理流程的核心，也为事件管理、问题管理、变更管理提供了查询、诊断、记录的基础。 配置元素（CI）：生

38、产环境中需要被管理的软件、硬件、文档、人员等。 配置管理数据库：包含了配置元素的信息以及各元素之间的关系。 服务管理平台应能建立、维护配置管理数据库。3.2.6.2 识别配置元素 设定配置元素的唯一识别号（搜索代码） 支持配置元素的层次化结构配置元素结构的细分程度取决于组织中配置元素的使用情况。例如：将服务器整体看作一个配置元素，则可将CPU看作服务器的一个配置属性；进一步细分，可将CPU看作是一个配置元素。 配置元素属性配置元素属性表示配置元素CI的一项信息，如序列号、版本等。 支持附件功能为了使CI的信息更加全面，可以采用附件的方式记录CI的相关额外信息：手册、维护合同、配置文件、拷屏图等

39、。 不同配置元素之间的字段是不尽相同的，所以流程管理实现工具需要能够灵活地增加新的字段，以满足对各种配置元素信息的记录。 配置元素状态代码配置元素状态代码反映了配置元素在其生命周期中的不同状态。 配置元素关系配置管理模块能够提供反映配置元素之间关系的功能，可用图表方式展现。 配置信息的收集支持以下两种信息收集方式：1、从其它管理平台中获得，把配置元素及其细节信息记录进流程管理平台中。2、使用模板来手工创建配置元素，创建一个或多个配置元素。3.2.6.3 配置控制 能够在CI的整个生命周期内跟踪CI的状态，确保只有被认可的和被标识的配置元素及其配置信息才能输入CMDB或更新CMDB。 CI记录中

40、特定字段的变化，应被记录在CI的历史记录中，对一个CI中一系列的配置变化过程在数据库中应有日志记录，并可被浏览和审核。3.2.6.4 汇报和状态汇总 根据需要，定期产生配置管理报表，并能使相关人员进行选择、抓取、分类和返回所查询的CMDB数据。定期产生配置元素的状态报告，并能反映配置元素的版本和变动历史。 提供与服务管理平台其它管理模块的信息关联，如：某个CI所发生的历史事件记录。3.2.6.5 审计和确认 应提供审计功能，能够自动或者手工审核全部或部分CMDB数据，确认和实际环境的一致性，从而确保配置信息的完整性。该工作可定期和不定期进行。1、不定期(可每周或根据需要当发现信息更新时)从监控

41、平台传送配置数据到服务管理平台的进行比对。2、定期(月、季度、年)对全部或部分配置元素进行审计。 如发现物理信息和逻辑信息的不一致性，能够提交变更请求RFC，通过变更管理流程进行调整。3.3 监控管理平台功能描述3.3.1 数据采集层数据采集包括平台数据采集和应用数据采集，各自分为性能数据采集、故障数据采集和配置数据采集。3.3.1.1 采集方式业务支撑网网管系统的采集方式通常有以下几种： 通过定时轮循机制来获取被管资源对象的数据； 通过监听Agent的TRAP消息实时获取数据； 通过设备厂家提供的监听工具（如Netflow和Cflowd）获取数据。 通过读取SYSLOG获取数据。 通过专用监

42、视设备获取数据。 通过手工录入或批文件导入基础数据。 无法直接采集的数据，通过测试手段获取。根据实际情况，可采取其它方式采集数据，如：可通过原厂商网管平台采集数据。3.3.1.2 采集要求 性能数据应可通过定时方式、周期方式等进行采集。 故障数据的实时性要求较高，应根据具体的接口方式采用不同采集机制，保证故障数据及时获得。 配置数据相对稳定，建议在系统比较闲时进行采集。 采集程序必要时应能进行补采或重采，以保证数据采集的完整性。3.3.1.3 平台系统的可管理性要求平台系统的可管理性要求包括主机设备、网络设备、数据库、中间件、存储与备份设备等的可管理性要求。 主机设备主机设备应支持SNMP等协

43、议。日常运行时，SNMP的Agent作为一个后台进程，保持正常运行。 网络设备网络设备应支持SNMP等协议。相应的端口/协议等安全设置要求完成，SNMP的Agent保证正常运行。 数据库数据库支持SNMP等协议，不支持SNMP的应提供日志功能和相应的工具/接口。 中间件中间件支持SNMP等协议，不支持SNMP的应提供日志功能和相应的管理工具/接口。存储存储设备支持SNMP等协议，不支持SNMP的应提供日志功能和相应的管理工具/接口。 备份设备备份设备支持SNMP等协议。不支持SNMP的应提供日志功能和相应的管理工具/接口。3.3.1.4 应用系统可管理性要求应用系统应支持下列常见管理接口： 数

44、据库接口 文件接口（日志文件等） SNMP 其它API接口在设计过程中应考虑系统的可管理性，提供给网管系统尽可能多的数据，才能使网管系统有的放矢。如：进程状态信息、数据一致性信息，运行配置信息，输入、输出信息，安全、操作信息等。3.3.2 数据处理层3.3.2.1 告警数据处理告警数据处理针对来自平台部件类和应用部件类的告警事件，进行故障定位、告警过滤、告警升级、告警级别重定义、告警前转、告警清除等操作。3.3.2.1.1 处理原则 实时性：保证关键告警信息及时得到处理。 准确性：保证告警信息根据所属级别得到准确处理。 参数化管理：提供灵活的参数化配置，保证告警处理具有很强的适应性。3.3.2

45、.1.2 告警数据分类按照告警信息所属资源的类别，将告警信息划分为如下类别：告警类别告警子类系统平台告警主机告警网络告警存储告警备份告警终端告警数据库告警中间件告警其它告警应用系统告警计费告警结算告警营业告警帐务处理告警帐务管理告警客服告警采集告警拨测告警一级BOSS告警安全系统告警防火墙告警主机防护告警入侵监测告警另外，针对每种类别的告警，根据告警信息的严重程度、影响范围以及与企业相应考核指标的关系确定告警级别，具体分为三级：严重告警(Critical)、重要告警(Major)、一般告警(Minor)。 严重告警(Critical)：指告警信息的严重程度高、对系统业务影响范围广、与业务支撑系

46、统相应考核指标的关系紧密。 重要告警(Major)：指告警信息的严重程度较高、对系统业务有一定范围的影响、与业务支撑系统相应考核指标有一定关系。 一般告警(Minor)：指告警信息的严重程度低、对系统业务影响范围小、与业务支撑系统相应考核指标没有紧密的联系。建议告警级别与颜色的对应关系见下表：告警级别颜色严重告警(Critical)红色重要告警(Major)黄色一般告警(Minor)蓝色3.3.2.1.3 告警数据内容中文名称说明告警的序列号产生告警消息的序列号告警KPI标识告警KPI的标识网元的识别名网元的识别名告警发生时间告警发生时间告警确认时间告警确认时间告警清除时间告警清除时间告警类型

47、告警类型告警级别告警级别告警原始类型原始告警数据中的告警类型告警原始级别原始告警数据中的告警级别活动状态告警当前状态告警源告警发生源确认操作员确认操作员用户名清除操作员清除操作员用户名告警标题告警标题告警内容告警内容3.3.2.1.4 告警数据的处理 告警故障定位告警故障定位应与配置数据和应用逻辑相结合，根据设备厂商或应用软件开发商提供的最小粒度定位，如CPU、路由模块、网络接口卡、关键业务点等。告警故障定位至少要做到被管资源级或关键业务点。 告警过滤针对单位时间内发生大量告警的情况，按维护要求和管理部门的要求及实际管理情况，过滤从底层提取的告警信息中不重要的信息，减少轻微告警的干扰，以提高监

48、控与处理的效率。同时可以根据业务与平台的关联关系，对业务与平台两层面的告警数据进行关联分析，定位主要告警、过滤掉关联告警，提高告警的处理效率。告警过滤需要提供灵活的过滤规则，可按告警网元、告警级别、告警类别或告警标题等设置过滤规则。可根据告警信息的内容，屏蔽掉一些次要的字段。对已设定的过滤规则需要提供保存和修改功能，便于维护人员灵活选择。告警过滤应实现对以下告警的过滤： u 频繁发送的同一告警u 由主要告警引起的相关大量的关联告警u 已进入服务管理流程进行处理，重复发送的告警u 特殊情况下，只需要记录不需要展现的特殊资源的相关告警 告警升级对于系统中持续出现以及超过规定处理时间仍未解决的告警，

49、需要升级该告警的告警级别，以保证得到优先及时的处理。 告警重定义根据系统平台及应用逻辑在结构、功能等方面发生的变化，重新定义告警数据所属的类别和级别，保证告警系统处理的正确性。 告警前转系统提供告警前转功能，将告警信息以各种手段（手机短信、EMAIL等）转至指定的维护人员。1、告警前转方式自动前转：根据事先的设定，将告警信息自动前转其它网管系统或相关人员。手工前转：由监控人员把告警手工前转其它系统或相关人员。2、告警前转条件告警前转的设置条件：告警级别、告警类型、被管资源类型、告警设备所在地区、需要通知的相关系统和人员、告警的处理时间等。管理员可以存储设定的告警前转条件，并可对告警前转条件列表

50、进行增、删、改、查等操作。 告警清除对于系统中已经处理完毕的告警信息，需要设置相关的标志，标记为清除，退出告警处理流程。3.3.2.2 配置数据处理3.3.2.2.1 配置数据处理的目标配置数据处理的基本目标，即将数据采集层的原始配置数据整合为数据处理层的对象型配置数据（主要以基于网元对象而关联聚合的配置信息集形式存在），以便功能呈现层能够灵活管理和呈现网元对象的配置信息。具体来说，配置数据处理的目标可细分如下三点： 提供完整的原始配置数据网元对象的配置信息既包括网元对象自身的配置信息，也包括网元对象关联的业务描述信息和其它辅助信息，如作为一个网元对象的应用进程有自身的配置信息，同时也有该应用

51、进程为哪个业务模块服务的描述信息。配置数据处理应支持以动态采集、手工录入等多种方式和多种渠道获取网元对象的原始配置数据，保证网元对象的原始配置数据的完整性。 提供集成化、对象化的配置数据网元对象的原始配置信息经过配置数据处理后，经过关联、聚合后整合为集成化、对象化的配置数据，以便功能呈现层能够灵活管理和展现。 保证配置数据的一致性配置数据处理应提供一定的手段，保证业务支撑网网管系统中监控管理平台保存的配置数据和网元对象的实际配置信息的一致性。3.3.2.2.2 配置数据处理原则 配置数据处理的灵活性配置数据处理应能够提供多样化的处理手段，完成对原始配置数据的处理，如动态采集、手工录入、批量文件

52、导入等。 配置数据处理的可扩展性配置数据处理相关的网元对象种类是多样化的，各种不同的网元对象配置数据的内容与形式以及处理方法，处理逻辑都可能不同或者发生变更，配置数据处理应提供相应的可扩展性支持。3.3.2.2.3 配置数据处理的对象 平台类对象1、主机设备配置系统中运行的主机设备的相关配置信息。2、网络设备配置系统中运行的网络设备的相关配置信息，网络设备具体包括：核心路由器、核心交换机。3、存储设备配置系统中运行的存储设备的相关配置信息。4、备份设备配置系统中运行的备份系统中的备份软件、备份介质库（如：磁带库、光盘库等）的相关配置信息。5、数据库配置系统中运行的数据库的相关配置信息。6、中间

53、件配置系统中使用的中间件软件产品的相关配置信息。7、其它设备配置系统中运行的其它设备的相关配置信息。 应用类对象1、应用进程配置应用类对象的配置信息主要为业务支撑系统中各个业务环节相关应用进程的配置信息。2、业务模块配置业务模块指业务支撑系统中的各个逻辑业务模块。各省可以根据自己的实际情况进一步定义业务模块的种类和个数。业务模块的配置信息主要指各个业务模块的静态配置信息，如每个业务模块的功能描述信息，相关的网元对象概要信息等。3、业务点配置关键业务点指业务支撑系统中各个逻辑业务模块下的管理节点。业务点的配置信息主要指各个业务点的静态配置信息，如每个业务点所属业务模块、该业务点的功能描述信息、相

54、关的网元对象概要信息等。 机房环境类对象(可选)3.3.2.2.4 配置数据处理的功能 配置数据审核1、配置数据的合法性审核配置数据合法性审核是依据网元对象配置信息的数据合法性约束规则，对配置数据本身的合法性进行审核。配置信息的数据合法性约束规则是根据具体需要来定制的，可有多种形式，如某个配置项非空、某个配置项只能在特定值域内取值、某个配置项值有唯一性限制等。在网管人员以手工方式或批量文件方式输入网元对象的配置信息时，系统应进行配置数据合法性审核。在网管人员手工录入网元对象配置信息时，网管系统实施配置数据合法性审核，自动检查配置数据信息的合法性（如同类网元的中文名称相同），可提示网管人员修改或

55、者重新填写。2、配置数据的一致性审核网管系统应审核网管系统中网元对象的当前配置信息与网元对象当前的实际配置信息的一致性。如不一致，网管系统应提供配置数据的及时更新功能。配置数据与网元对象实际配置的一致性审核工作应可以定期执行，也可以随机执行。 配置数据整合配置数据整合是基于网元对象将数据采集层的原始配置数据进行关联，聚合处理并保存处理结果的过程。经过整合后，配置数据以基于网元对象关联聚合的配置信息集形式存在，为功能呈现层模块灵活方便的管理和呈现网元对象的配置信息提供了数据基础。 配置数据更新配置数据更新包括配置数据的自动更新和手动更新。1、配置数据的自动更新网管系统应提供配置数据的自动更新功能

56、。在配置数据动态采集方式下，当配置处理模块接收到最新的配置信息，系统应检测最新采集到的配置信息与网管系统中当前保存的配置信息是否一致，如不一致，系统能够根据最新配置信息更新网管系统中当前保存的配置信息。2、配置数据的手动更新网管系统应提供方便灵活的界面，供网管人员以手动方式更改网元对象的配置信息。 配置历史数据管理网元对象的配置数据随网元对象的实际配置情况动态变更，网管系统不仅应保存网元对象的当前配置数据，同时也应该保存一定时限内网元对象的历史配置数据，并提供对历史配置数据的查询、统计、分析、归档、备份等功能。网管系统应可定制历史数据的处理规则，如配置历史数据在系统中保存期限等。配置数据处理的

57、数据流图示例：3.3.2.3 性能数据处理3.3.2.3.1 性能数据的处理目标通过性能数据的处理与分析，及时发现关键点的异常情况，保障系统正常运行，并为分析优化工作提供必要的依据。3.3.2.3.2 性能数据的处理原则性能数据处理应遵循以下原则： 完整性：必须保证性能数据处理的完整性。 连续性：对于增量类型的性能数据必须保证连续性。如对于异常话单数量，由于网络故障造成该性能数据处理中断，当网络恢复的时候，需要恢复处理这段时间内的性能数据。下图为性能数据的处理流程。3.3.2.3.3 性能数据的预处理预处理是对采集来的原始数据进行格式转换、检错纠错，形成内部标准记录，支持比较灵活的格式转换配置

58、和检错纠错配置。3.3.2.3.4 性能数据计算与汇总对预处理后的数据进行必要的计算、汇总形成所需的性能指标。处理后的性能数据保存到数据库中，供分析和呈现使用，性能数据的保留时间可配置，须符合本规范的有关规定。3.3.2.3.5 性能数据阀值分析性能数据反映了系统的运行状况，是判别被管资源运行是否正常的关键数据。性能数据一旦超出预先设定的阀值时，系统将触发一个告警，该告警称为性能告警。系统应能提供设定/查询/修改/删除性能阀值的工具，可设多个阀值进行分级告警。系统也应能设置性能数据的取样时间间隔。性能阀值告警的内容应能比较全面地描述该性能数据超出阀值的情况，方便分析、排除故障。性能指标及相关性

59、能阀值告警见附件：接口数据分册。3.3.2.3.6 性能数据汇总统计为了性能数据分析和呈现，以及故障的分析，系统应能定期生成统计数据。通过分析历史指标的情况，预测未来的发展，提升管理层次，达到面向服务品质的管理。系统应支持多种分类统计方式，如时间、应用种类等。3.3.2.4 业务与平台关联性处理业务指BOSS规范中明确规定的业务模块及其中包含的子业务。BOSS系统中的业务运行状态是否正常取决于实现业务的应用进程（软件）状态和承载这些应用进程的平台类资源的运行状态。业务关联性包括业务与平台关联性以及业务与应用软件的关联性。业务与平台的关联性和业务与应用进程的关联性分开处理。由于业务的核心直接由应

60、用软件实现，并且有明确的直接相关性（准确、完整、及时），因此本章不再赘述业务与应用软件关联性处理。3.3.2.4.1 业务与平台关联性处理原则业务与平台关联的处理是指通过基于规则进行判断，对业务与平台两层面的告警数据和性能数据进行关联分析，实现主要告警的定位、关联告警的屏蔽以及性能瓶颈的跟踪，从而提高告警的处理效率和系统的性能指标。业务与平台关联性处理主要是对告警数据和性能数据的处理。告警数据包括故障告警以及性能告警，而性能数据包括平台和应用的各项性能数据。业务与平台关联性处理应遵循以下原则： 数据的实时性在相关性处理的两种数据中，告警数据是实时性要求较高的数据，告警数据的延时不仅会使网管系统降低应用价值，而且告警的相关性分析也失去价值。因此在关联性处理时，应做到告警数据的实时上报，对于无法实时上报的数据，应在尽可能短的时间内上报。 数据的完整性在相关性处理的过程中，对于部分告警数据，如在规定窗口长度内告警发生频度没有超过门限值，可予以过滤。在事件相关性处理中，应充分考虑告警数据的类型和特点，合理设置关联窗口长度和门限值，防止发生告警数据的丢失。 处理的及时性相关性处理虽然可以提高告警的处理效率，但必然带来一定的延时。延时主要