中国联通业务支持系统BSS运行维护管理平台业务技术规范

《中国联通业务支持系统BSS运行维护管理平台业务技术规范》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

中国联通业务支持系统BSS运行维护管理平台业务技术规范1042020年5月29日

11042020年5月29日

2文档仅供参考中国联通业务支持系统(BSS)运行维护管理平台业务技术规范(讨论稿)中国联通6月1042020年5月29日

3文档仅供参考目录1.总体概述11.1行业背景11.2系统现状分析11.3编制目的21.4适用范围21.5起草单位21.6解释权21.7参考文献22.建设目标及原则32.1建设目标32.1.1近期目标32.1.2远期目标32.1.3建设规划42.2建设原则53.系统总体结构63.1系统定位以及与现有网管系统之间的关系63.1.1系统定位63.1.2与现有网管系统之间的关系63.2系统组织结构71042020年5月29日

4文档仅供参考3.3系统体系结构83.3.1数据层93.3.1.1监控数据93.3.1.2管理数据103.3.1.3系统数据103.3.1.4文档数据103.3.2功能层103.3.3接入展现层133.4与外部系统之间的关系134.业务功能与流程154.1各模块之间的关系154.2岗位与角色描述154.2.1岗位描述154.2.2角色描述164.3业务功能描述184.3.1服务支持184.3.1.1服务台184.3.1.2事件管理204.3.1.3问题管理244.3.1.4变更管理271042020年5月29日

5文档仅供参考4.3.1.5配置管理304.3.1.6日常运维管理334.3.1.7供应商管理344.3.1.8知识库管理354.3.2系统监控384.3.2.1监控台384.3.2.2性能管理384.3.2.3告警管理404.3.2.4配置处理464.3.3系统管理485.系统技术要求505.1总体技术要求505.1.1应用软件505.1.2数据要求515.1.3性能要求515.1.4开发工具515.2统计报表525.3拓扑展现525.3.1拓扑的生成方式525.3.2技术要求531042020年5月29日

6文档仅供参考5.4工作流535.5安全管理565.5.1对安全管理的统一维护565.5.2运维管理平台的安全性565.6数据采集575.6.1数据源类型575.6.2数据采集要求575.6.3数据预处理586.系统接口596.1接口原则596.2服务支持与系统监控的接口606.2.1接口定义606.2.2接口方式606.2.3接口要求606.2.4接口内容606.3与业务应用系统的接口626.3.1接口定义626.3.2接口方式626.3.3接口策略626.3.4接口要求631042020年5月29日

7文档仅供参考6.3.5接口内容636.4与系统平台的接口636.4.1接口定义636.4.2接口方式636.4.3接口要求646.4.4接口内容646.5两级运维系统间的接口646.5.1接口定义646.5.2两级接口文件命名规则及相关约束656.5.2.1文件命名规则656.5.2.2回执文件格式约定656.5.2.3错误信息说明666.5.3上传关键业务指标686.5.3.1接口定义686.5.3.2接口实现686.5.4工单信息的传递706.5.4.1接口定义706.5.4.2接口实现716.5.5知识库信息传递726.5.5.1接口定义721042020年5月29日

8文档仅供参考6.5.5.2接口实现736.5.6上传统计报表736.5.6.1接口定义736.5.6.2接口实现746.6与其它系统的接口746.6.1接口定义746.6.2接口实现741042020年5月29日

9文档仅供参考1.总体概述1.1行业背景当今通信市场正由传统的以通信网为中心的服务质量的竞争转变成以客户为中心的服务质量的竞争,中国联通为了适应市场竞争的变化,必须建立以客户服务为中心的服务机制。综合电信业务支撑系统在中国联通公司的整体运营中起着至关重要的支撑作用,因此在监控业务支撑系统硬件和系统软件的基础上还应对各业务应用系统进行监控,经过对各业务应用系统的整个处理流程进行监控,掌握各业务系统的运行状况。同时,运维管理应逐步实现从被动服务到主动发现系统中存在的问题,变被动为主动,以流程贯穿整个运维管理过程;减少运维人员的劳动强度,提高效率,切实保障各业务支撑系统可靠、稳定、高效地运行,进一步提高用户的满意度和忠诚度,全面提升中国联通的服务质量。1.2系统现状分析中国联通公司是当前国内电信业务最多的综合性电信业务运营商,经营着GSM、CDMA1042020年5月29日

10文档仅供参考、市话、互联网等业务。在中国联通的统一规划和领导下,建设了各省综合电信业务支撑系统。综合电信业务支撑系统是一个包括众多子系统的复杂系统,需要对各业务子系统的硬件及软件平台进行管理,保障各业务子系统的正常运行。而各业务子系统在建设过程中有的考虑了网管监控有的没有考虑,后来进行了网管与网络安全工程的建设实现对各业务子系统的管理,因此在系统中可能存在多个网管工具,对不同的系统维护需要到不同的管理平台上进行处理,大多数只能对硬件平台(网络、主机等)和系统软件(数据库、中间件等)进行监控,不能对各业务子系统进行监控(或者只能监控到应用系统是否在运行状态下而不能监控其运行效率)。同时各省缺乏对业务子系统处理流程的监控,监控手段和效率较低,因此需要在原有网管系统的基础上进行完善,引进先进的IT管理方法和手段,提高整体运维水平。1.1编制目的中国联通制定本业务支持系统运行维护管理平台(以下简称BSS运维管理平台)业务技术规范,主要用来规范指导中国联通各省分公司运行维护管理平台的建设。1.2适用范围本业务技术规范是中国联通业务支持系统运行维护管理平台规划与建设的基本依据。中国联通各省分公司应依照本业务技术规范,结合本地实际情况进行规划和建设本省BSS运维管理平台。1042020年5月29日

11文档仅供参考1.1起草单位本业务技术规范的起草单位为中国联通有限公司,由中国联通有限公司计费、结算与信息系统部进行管理。1.2解释权本业务技术规范的解释权属于中国联通有限公司计费、结算与信息系统部。1.3参考文献;<中国联通网管及网络安全系统总体方案>;<中国联通企业信息化(UNI-IT)系统运行维护规程>(试行)。1042020年5月29日

12文档仅供参考1.建设目标及原则1.1建设目标BSS运维管理平台应整合当前的系统,逐步实现对”网元级、资源级、应用级”和系统安全等维护管理。同时,结合各省分公司的实际管理情况,由对业务子系统的管理延伸到对人员的管理,逐步实现以流程贯穿整个管理过程,进而实现对业务支持系统”统一管理、集中监控、集中运维”。1.1.1近期目标近期完成BSS运维管理的基本功能,实现对业务子系统(采集、计费、营业、帐务、结算系统等)系统平台和应用软件的运行状况监控以及日常运维管理(如作业计划等),保障业务支撑网的正常运行。n在统一平台上实现对系统运行状态的集中管理(主要包含主机设备、网络设备、存储设备、备份设备、数据库、中间件、应用软件等),保障业务支撑网的正常运行;n实现对业务子系统应用软件关键点的监视和保障,确保系统的运行质量;n经过对业务子系统中各类告警信息的分析,进行故障的快速定位和告警功能;1042020年5月29日

13文档仅供参考n建立日常运维工作流程,实现对日常运维活动的管理,从而实现对维护人员工作的监控和量化;n建立运维管理知识库系统,实现知识交流与共享;n实现供应商的有效管理;n掌握业务子系统的资源配置信息;n实现省公司和总部之间经过运维管理平台上传下达规定的考核指标、运维报表、重大故障/变更等。1.1.1远期目标实现”统一管理、集中监控、集中运维”的现代化运维管理模式,以流程贯穿运维管理过程,建成面向应用、面向市场的BSS运维管理平台;同时经过总部与省两级运维管理平台的协同工作,实现系统的科学管理和规划,从而全面提升中国联通业务支撑网的服务质量。具体包括:n实现事件的集中统一管理;n实现对运维管理中变更过程的有效控制和管理;n实现对运维管理中配置过程的有效控制和管理;n实现问题管理,减少和避免同类事件的再次发生;n经过对应用软件流程的监控,实现对业务运行质量的分析和保障,实现业务运行质量的有机管理;n1042020年5月29日

14文档仅供参考经过对各种运行的状态数据和资源配置数据的分析,为系统安全稳定运行提供合理的优化建议方案;n完善工作流程,提高系统运行维护的质量和维护人员管理的科学化。1.1.1建设规划BSS运维管理平台应分步实施,逐步完善。分步实施如下图所示:图2.1BSS运维管理平台建设规划图1.2建设原则BSS运维管理平台的建设原则包括:n集成性:经过统一的管理平台集成系统平台和应用平台的管理;n先进性:基于先进的IT管理理念和管理流程,采用成熟、先进的管理平台,适应技术的发展方向;n实用性:根据用户需要进行成功的客户化定制,满足实际管理需要,真正解放管理人员的日常维护工作;n规范性:接口的标准化和规范化原则,建立全国统一的KPI,运维管理流程规范化;n开放性:系统应遵循行业的标准或建议,采用标准的、开放性的技术;n1042020年5月29日

15文档仅供参考扩充性:既要充分考虑到未来技术的发展变化又要考虑到将来运维管理的新需求;n安全性:系统本身要提供较高的安全性;n兼容性:能同第三方的管理软件以及原有网管软件集成,充分保护原有投资。1042020年5月29日

16文档仅供参考1.系统总体结构1.1系统定位以及与现有网管系统之间的关系1.1.1系统定位本系统的管理对象是以业务支持系统(BSS)为核心,包括采集、计费、结算、营业、帐务等子系统,实现对业务子系统的统一管理、集中监控和集中运维。1.1.2与现有网管系统之间的关系本系统与已经建设的网管和网络安全系统的关系是互为补充,而不是互为替代。原网管系统在建设过程中所购买的网管软件和在其上实现的系统监控,可与现有各业务系统的分散的应用监控相结合,在充分利用原有投资和资源的基础上,完善功能,综合利用系统平台和应用系统的监控信息,形成运维管理平台的重要组成部分:系统监控部分,以便统一展现支撑平台和业务系统的运行状况,统一监控和维护各种告警、配置、性能数据。同时,为了强化对运行维护人员、流程和信息的管理,避免由于人员的疏忽和信息的混乱所造成的系统运行和服务质量问题,在ITIL1042020年5月29日

17文档仅供参考理论的指导下,结合联通业务支撑系统运行维护管理规程和各省分公司的实际情况,建设该系统的另外一个重要组成部分:以流程管理和资源配置信息管理为核心的服务支持部分,从而进一步梳理、优化运维流程,建立监控手段与运维人员之间的有机联系,初步建立人员绩效考核机制,实现突发事件的快速解决和业务迅速恢复,并尽可能消除或减少突发事件的发生,实现系统的逐步优化,提高现有系统的稳定性。1042020年5月29日

18文档仅供参考图3.1与现有网管系统之间的关系图如图所示,网管与网络安全系统主要包括综合信息传输平台、网管、网络安全三部分内容的建设,同时为实现上述功能需要对信息系统部现有各系统进行优化和改造。一方面,网管与网安系统中的网管功能可纳入运维管理平台中的系统监控部分,另一方面,网管与网安系统的综合传输平台和网安部分可作为运维管理平台中系统监控部分的被监管对象进行管理。另外,系统监控部分和服务支持部分之间可经过自动或人工的方式进行事件和配置信息的交互,从而实现这两部分的功能及信息内容能够在展示层面进行整合,在数据层面进行综合分析,为系统安全稳定运行提供更加合理、高效的管理手段和方案。1.1系统组织结构系统组织结构如下图所示:1042020年5月29日

19文档仅供参考图3.2BSS运维管理平台组织结构图中国联通业务支持系统运维管理平台分为两级结构,第一级为总部运维管理平台;第二级为总部计费、结算中心运维管理平台和各省、自治区、直辖市运维管理平台。第一级总部运维管理平台主要功能为负责对中国联通各省业务支撑系统的运行状况的监督管理;掌握各省的资源配置信息及各资源的性能信息,为系统的升级改造提供依据;对省公司上报的重大故障和总部市场部、客户部等部门的投诉进行管理,并监督和协调省公司的处理;采集各省公司业务系统考核指标,并对省公司进行考核;建立总部与省公司运维管理信息的上传和下达通道,使总部的相关通知信息等能及时下达,省公司上传的重大故障和变更、运维统计报表数据等能及时上传;统计各省分公司的相关运维管理信息,掌握全国业务支撑系统的运行状况。1042020年5月29日

20文档仅供参考第二级省运维管理平台负责对相应省各业务支撑系统具体的管理,包括各业务支撑系统中的应用软件、主机设备、网络设备、存储设备、备份设备、数据库、中间件等,确保各系统稳定可靠地运行,并按总部要求上报相应的数据。1.1系统体系结构BSS运维管理平台体系结构如下图所示:图3.3BSS运维管理平台体系结构图1042020年5月29日

21文档仅供参考运维管理平台体系结构可分为三个层次:数据层、功能层、接入展现层。1.1.1数据层1.1.1.1监控数据监控数据来自系统平台(网络、主机、存储、数据库、中间件等)、应用平台(采集、计费、营业、帐务、结算等)、业务支撑系统安全系统(主机系统安全、网络安全)以及机房环境等。经过各类采集手段或接口实现对监控数据的采集,经过系统监控的各个功能组件实现对监控数据的处理和分析,经过统一的接入展现层实现对监控数据的展现,监控数据从内容角度又能够分为告警数据、性能数据和配置处理数据等,监控数据从时间维度能够分为当前数据和历史数据。1.1.1.2管理数据管理数据主要是为实际管理需要定义或录入的数据,其数据主要经过手工录入获得,内容包括工单、供应商情况,也包括流程配置、告警严重级别、告警过滤规则、相关性模型、告警升级规则、告警传递规则、性能门限配置、配置数据静态信息(设备编号、地理位置等)、值班/排班定义、设备/人员优先级别、服务水平定义、紧急程度定义等,同时管理数据还包括各种与监控数据相关的维度数据,如银行编码与名称对照表、营业厅名称等等。1042020年5月29日

22文档仅供参考管理数据同时包含系统中的各种过程数据,如事件管理和问题管理中从受理到结束的每一步处理过程,变更过程中的变更计划书、变更授权书、变更评估报告、变更实施报告、变更验证报告等也都归类于管理数据。1.1.1.1系统数据系统数据主要是由运维管理平台自身运行所需要或使用的数据构成,主要包括组织机构、人员信息(登录信息、联系方式)、权限状况、角色定义、日志文件、字典表数据和规则数据,包括系统自身运行日志、历史数据保留规则、不同时间粒度报表定时生成规则、设备厂家/型号对照表等、数据采集任务定义等。1.1.1.2文档数据文档数据主要是以附件等形式存放的文件数据,主要包括规章制度、设计文档、培训文档、实施方案等,同时也包括知识库中的知识数据、供应商管理中的合同信息、配置管理中的文件形式的配置数据,在流程管理以附件形式派发的公文信息等。1.1.2功能层运维管理平台的功能层主要由两大部分构成,即系统监控和服务支持。1042020年5月29日

23文档仅供参考（1）.系统监控n系统监控的管理对象是UNI-CRM系统中的所有系统平台设备(网络、主机、数据库、中间件、存储备份设备等)和业务应用系统(主要指采集、计费、营业、帐务、结算等)。n系统监控的监控内容主要是业务支撑系统的平台类和应用类KPI指标(具体指标参见附件),经过接收或采集数据层生成的指标数据(或原始数据),并对这些指标进行统一的存储、处理与分析,将处理结果转发至服务支持部分或直接上传接入展现层。n系统监控的功能组成主要包括四个部分:l监控台:用于统一展现系统平台和业务应用系统的运行状况,统一配置和维护系统监控的各种展现数据和管理规则;l告警管理:用于统一接收、采集系统中发生的各种异常情况,并经过对这些信息统一处理(标准化、压制、合并、过滤、故障源定位等)实现”全面监控、准确告警、及时通知、快速解决”1042020年5月29日

24文档仅供参考的目的,告警管理在保证告警信息准确性的条件下,可经过各种外部接口(邮件、短信、语音)通知指定维护人员,对于较严重的、需要维护人员人工解决的告警信息,应经过服务支持部分自动生成工单,进入闭环处理流程,对于重大告警信息,应经过相应接口及时通报总部,告警管理是系统监控最核心的部分;l性能管理:用于统一存储、处理、分析各类性能指标,实现对性能指标异常变化情况的及时告警、经过对历史性能数据的统计分析为业务系统运行趋势变化分析和系统扩容、优化提供量化依据,性能管理部分是系统监控内容最丰富的部分;l配置处理:用于统一存储、处理、分析各类配置指标,在发生配置数据异常变化时能够生成告警信息,并提供对配置数据的统计、分析和查询,配置处理是系统监控的数据基础。（1）.服务支持n服务支持的使用者主要是信息系统部的各类人员,包括值班人员、维护人员、管理人员等;n服务支持的管理内容主要是依据ITIL理论,根据总部发布的运行维护规程和各省运维组织机构和人员组成情况,结合实际运维状况,梳理、优化运维流程,实现运维工作的流程化、规范化、电子化和自动化,建立监控手段与运维人员之间的有机联系,初步建立人员绩效考核机制;1042020年5月29日

25文档仅供参考n服务支持的功能组成主要包括8个部分l服务台:为流程的起点和终点,是信息系统部为部门内部和其它部门提供的统一服务窗口,统一受理事件、申告、投诉和告警;l事件管理:对于突发事件的流程化处理,事件来源包括系统监控中的告警管理模块以及电话、传真、手工生成等,事件管理的核心是注重突发事件的快速解决和业务迅速恢复;l问题管理:寻求故障根源,解决存在或多发问题的流程,问题管理的核心是注重消除或减少事件的发生,实现系统的逐步优化,提高现有系统的稳定性;l变更管理:对变更请求进行记录、跟踪与管理的流程,消除或减少变更对生产系统的影响和风险,保证变更的顺利完成;l配置管理:管理各配置、资源、资产数据的流程,包括定义和维护配置数据相互间的关联与依赖关系;l日常运维管理:包括机房值班、排班、交接班、作业计划、日志等内容,主要目的是强化日常运维工作的规范性,为各种运维制度提供有效的落实手段;1042020年5月29日

26文档仅供参考l供应商管理:对业务支撑系统集成商、软件供应商的相关资料、与联通签订的服务合同等信息进行管理维护,并对各集成商、软件供应商的产品质量、服务情况进行评分管理,并将评分定期上报总部,使省公司及总部及时、全面地了解供应商的阶段性服务状况;l知识库管理:经过对知识库系统维护和使用,不但能够在故障自动处理和人工处理的过程中在知识库中得到相关故障维护的分类和快速定位,找到匹配的处理案例,便于处理人进行借鉴,而且知识库具有的业务帮助功能,使相关人员能够经过关键字查询业务帮助、产品、市场活动、发生过的处理流程、电子文档等。1.1.1接入展现层接入展现层是运维管理平台提供给值班人员,运维人员和管理人员的统一入口。实现运维管理平台的功能及信息内容在展示层面进行整合,并针对不同角色的使用者提供与角色关联的个性化的展示内容。同时提供对多种设备和接入方式的支持。1.2与外部系统之间的关系运维管理平台与外部系统之间的关系如下图所示:1042020年5月29日

27文档仅供参考图3.4BSS运维管理平台与外部系统关系示意图对于当前建有网管系统的省分公司,现有网管系统将来应融入到运维管理平台中。运维管理平台可从现有网管系统(专业网管或应用网管等)中获得主机、网络、数据库、中间件、业务应用系统等网管信息。运维管理平台从业务应用系统、系统平台、机房环境及安全系统中获得的主要数据内容为:配置数据、性能数据、告警数据等。二级运维管理平台向一级运维管理平台提供的主要数据为:配置数据、重大故障数据、重大变更数据、性能数据和相关的统计报表等。运维管理平台预留有与其它系统的接口,例如MSS能够从运维管理平台中获得运维相关的信息,如运维管理平台的考核结果经过MSS系统进行发布,另外运维管理平台能够接收MSS系统的有关运维管理的通知等。1042020年5月29日

28文档仅供参考运维管理平台的用户包括值班人员、运维人员、管理人员。进一步运维管理平台经过运维人员等受理其它部门如市场部、客服部等对业务支撑系统运行情况的咨询、用户投诉、变更请求等,并反馈处理结果,为其它部门提供服务。1042020年5月29日

29文档仅供参考1.业务功能与流程1.1各模块之间的关系各模块之间的关系如下图所示:图4.1BSS运维管理平台功能模块关系图1.2岗位与角色描述1.2.1岗位描述岗位组织结构如下所示:1042020年5月29日

30文档仅供参考图4.2岗位组织结构图其中运维部门管理负责人、技术业务管理负责人、技术工程师、业务工程师、值班人员的岗位定义、职责详见<中国联通企业信息化(UNI-IT)系统运行维护管理规程>。其中:n上级主管(总部):总部的运维管理负责人,负责批示省分公司运维过程的重大故障、重大变更等问题;n值班经理:协调组织值班人员进行日常运维值班任务,一般由技术工程师或业务工程师担任;n服务供应商:作为中国联通的外协单位,负责协助、完成系统的运行维护,可包括原厂商、集成商、服务商。1.1.1角色描述运维管理平台涉及的角色为:n服务台:是一种管理职能,经过服务台角色在不同流程中的功能体现其职能,同时担任分类、升级、跟踪、协调、一线支持职能,服务台角色由值班人员、值班经理担任;n二线支持:经过服务台初步支持不能解决的事件、问题,由二线支持角色处理,二线支持由技术或业务工程师担任;n1042020年5月29日

31文档仅供参考三线支持:经过二线支持不能解决的事件、问题,由三线支持解决完成,三线支持由联通方的专家和服务供应商的技术专家担任;n管理人员:与运维部门管理负责人完全对应;n问题管理员:在问题管理流程中负责事件的分析、问题的起草、提交审批、问题总结的人员,由业务或技术工程师担任;n问题解决方:负责问题的调查分析、提出问题的解决方案、问题的处理,由技术和业务工程师、服务供应商的相关技术人员担任;n变更管理员:在变更管理流程中负责起草变更请求、分类/分级、编写变更计划,由技术和业务工程师担任;n变更顾问组:负责评估变更请求的必要性以及计划的合理性,由技术业务管理负责人、专家、服务供应商组合担任;n变更实施方:负责变更过程的组织、实施,包括变更的构建、测试、发布、恢复等职能,由技术和业务工程师、服务供应商共同担任;n配置管理员:配置管理中负责配置信息的录入、核实、归档,由技术和业务工程师担任。角色与岗位的关系如表:角色岗位服务台值班人员值班经理二线支持技术业务管理负责人技术工程师业务工程师三线支持联通方的专家1042020年5月29日

32文档仅供参考服务提供商管理人员运维部门管理负责人问题管理员技术业务管理负责人技术工程师业务工程师问题解决方技术业务管理负责人技术工程师业务工程师服务提供商变更管理员技术业务管理负责人技术工程师业务工程师变更顾问组技术业务管理负责人联通方专家服务提供商变更实施方技术工程师业务工程师服务提供商配置管理员技术工程师业务工程师上级主管上级主管1.1业务功能描述1.1.1服务支持1.1.1.1服务台1.1.1.1.1定义服务台是一个综合接口平台,统一接收来自于综合电信业务支撑系统各业务子系统及其它途径的各种服务请求信息(告警、投诉等),提供必要的初始支持,并根据需要启动相应的服务流程、并对服务流程跟踪监督,同时向服务请求方反馈服务结果信息。1042020年5月29日

33文档仅供参考1.1.1.1.1功能管理、协调并尽快解决各类事件,允许各类事件流程能够集成到服务管理基础架构之中。不但能处理故障、投诉和疑问,还可提供与其它过程的接口。(1)接口服务模块n提供统一接收各种事件、故障、投诉等服务请求的信息流逻辑接口;n响应、确认、核实、记录和维护各种服务请求信息;n提供服务支持管理的统一接口;n提供服务处理结果反馈的统一接口。(2)初始服务提供:对于一些能够直接处理而不必启动服务流程的服务请求,由服务台提供必要的初始服务支持。(3)1042020年5月29日

34文档仅供参考服务流程启动:对于经过初始服务支持无法解决的服务请求,服务台记录并判断确定服务类别和级别,并启动相应的服务流程。(1)服务流程监控:跟踪、管理、协调流程处理过程,调整事件优先级,检查流程的处理进度。(2)服务反馈:在服务过程中,保持与服务提出者的联系,及时通知服务进展;在服务结束后,告知提出者处理结果。1.1.1.1.1流程及业务规则服务台负责记录事件相关信息,向用户提供对已知问题的处理方法,报告事件并启动相关服务流程,达到尽可能快速、有效地解决问题的目的。服务台接收的事件信息:n系统获得的故障告警、性能告警、配置告警等告警信息;n从其它系统获得的事件信息,如客服系统的投诉信息等;n人为事件,包括从电话、传真、邮件等途径获得的事件信息,以及其它人工录入事件;n其它事件。如果服务台不能解决这个事件,应当启动维护流程,将事件分配给最合适的服务支持小组/人员来处理,并进行如下工作:n记录相应事件;n判定服务类别;n1042020年5月29日

35文档仅供参考判定事件优先级(各省分公司根据自己的实际情况,制定可操作的、量化的优先级判定的标准);n检查事件记录的处理进度,根据需要调整事件优先级;n保持与事件报告者的联系,及时通知事件处理进展;n最后关闭事件。1.1.1.1.1与其它模块之间的关系n与系统监控功能模块接口:从告警管理接收待处理监控事件信息,返回处理结果。n与事件管理模块接口:记录、发起、并监控服务过程。1.1.1.2事件管理1.1.1.2.1定义事件管理是对监控管理产生的事件以及人工发起的事件处理请求进行管理的功能模块。事件包含告警事件、投诉事件、请求事件。事件能够来源于系统平台、应用平台、机房环境、系统安全等的告警,也可来自外部的投诉、请求等。根据其对服务的影响程度,事件可分为:一般事件和故障事件两大类。1042020年5月29日

36文档仅供参考在上述事件中,凡开通运行的系统、设备和设施,在承担业务期间,造成质量降低至用户无法使用,均定为故障。故障的分级:按影响范围、持续时间和性质严重程度,将故障分为重大故障、严重故障和一般故障。1.1.1.1.1功能n事件记录:从服务台获取事件信息后,记录入系统中;n事件判定:根据事件和故障的现象以及产生原因确定其类别、对业务的影响程度、紧急度和优先级,并指定事件和故障的解决时限;n事件处理:包含对事件的原因和解决方法的分析、故障的解决以及服务(业务)的恢复,同时包括事件处理的流程管理、事件的升级和根据规则向不同级别的上级报告;l分析判断:经过与相关服务、技术支持人员共同研究分析发现事件发生的原因,或查找以前是否发生过同类突发事件,是否有处理方法;1042020年5月29日

37文档仅供参考l上报:发生严重故障和重大故障时,维护部门直接向省分信息系统部和运行监督部报告;对于重大故障,要上报联通总部信息系统部和运行监督部;l解决和业务恢复:利用找到的处理方法解决问题,恢复业务。对于紧急级的事件,在事件管理过程中直接执行紧急变更管理过程,不再向”变更管理”提交工单;l事件、故障升级:对于系统中持续出现以及超过规定处理时间仍未解决的事件和故障,需要升级该事件级别,以保证得到优先、及时的处理。当事件处理超过预期时限,根据预定义的升级条件,将该事件自动/手工升级到更高级别,并通知到指定级别的管理人员。n处理跟踪:跟踪事件和故障处理过程和时限,升级和督促突发事件,随时通知用户处理进展;n事件完结:事件处理完成后,要将结果记录入系统并将处理结果反馈给事件发起方;n统计查询:提供灵活的统计和查询功能,方便对事件的处理状况、处理结果进行查询,并提供统计和汇总报表功能。1.1.1.1.1流程及业务规则事件管理的处理流程如下图所示:1042020年5月29日

38文档仅供参考业务规则:n1042020年5月29日

39文档仅供参考上报总部:对重大故障,分别由省分信息系统部和运行监督部上报至总部信息系统部和运行监督部;n升级规则:对超过处理时限的事件,根据超出的时限,系统自动升级到相应级别,并根据事件级别定义,系统流程自动将消息通知对相应级别的管理人员。1.1.1.1.1与其它模块之间的关系n经过配置管理取得相关资源和配置数据,并将处理过程中对配置的修改提交给配置管理;n根据对事件、故障原因的分析,根据需要产生变更请求并进入变更管理;n将典型的事件处理过程和结果提供给知识库。1.1.1.2问题管理1.1.1.2.1定义问题管理是经过识别问题的真正的潜在原因,控制运维中的故障的过程。问题管理采取积极主动的办法,经过对已发生的问题进行分析,提出解决方案并尽早采取防御措施,防止同类事件或故障的再次发生。问题指已经发生、而且重复多次的事件或重大故障所蕴含的尚未查明的、真正的潜在原因。1042020年5月29日

40文档仅供参考问题来源于事件、故障管理流程中的非突发事件或多次重复发生的事件信息的总结和分析。1.1.1.1.1功能问题管理是问题的提出、分析、解决的管理过程,并提供问题解决方法的记录以及问题的统计分析和查询功能。n问题提交:从对事件的分析中,对于未探明原因的严重事件或对多次重复发生的事件提出问题报告,以待对问题的根源进行分析和解决方法的提出;n问题分析研究:对提交的问题安排相关的技术专家、维护人员和业务管理人员进行研究分析,给出问题的解决方案,并将初步的分析结果和对应的解决方案记录系统;n问题处理:根据对问题的分析得出的解决方案,产生相应的变更工单,交变更管理过程进行处理。n问题完结:对解决方案的处理结果进行记录并进行评估、总结;n1042020年5月29日

41文档仅供参考统计查询:提供对问题的处理过程、处理结果的灵活查询功能以及统计报表功能。1.1.1.1.1流程及业务规则问题管理的业务流程:n问题提出、分类;n问题分析:由相关专家和管理人员经过会议、研究等方式分析问题原因和提出解决方案;n问题解决:根据解决方案产生变更工单,进行变更处理;n处理结果的记录和总结:记录问题的处理过程和最终结果,并对问题的处理结果进行回顾评价,如果未解决问题,再进行相应的分析和处理。1042020年5月29日

42文档仅供参考1.1.1.1.1与其它模块之间的关系n与事件管理/故障管理的关系:对一般事件和故障事件的分析总结是问题管理的数据源。1042020年5月29日

43文档仅供参考n与变更管理的关系:在处理、解决问题的过程中,可能需要对系统配置、软件版本进行修改升级。因此,问题管理能够派生出变更流程。n与知识库管理的关系:问题管理过程积累的问题的典型处理方法为知识库管理提供数据源。1.1.1.1变更管理1.1.1.1.1定义变更是指针对被管理系统中某对象及其配置所进行的修改,大到整个业务支撑系统的升级改造,小到某设备参数的细微调整。为了避免和减少变更所造成新的系统问题和故障隐患,对系统变更过程需要规范化管理,包含提出变更计划及申请、申请评估、审批、授权、实施、验证等流程。变更管理是指对这些流程的规范化管理,以确保使用规范的方法和过程实现快速、有效的变更,保证变更过程的可控性、可管理性和有序性,减少变更带来的突发事件,促进日常工作的正常进行。1.1.1.1.2功能1042020年5月29日

44文档仅供参考变更管理需要包含如下功能和主要环节:n变更请求:由系统或者业务人员填写变更单,提出变更请求。填写内容包括变更提出人姓名、变更原因、变更对象以及变更实施计划、实施时间等具体要求。n变更评估:由变更评估小组对变更申请方案及对系统的影响进行评估。变更评估对于将对系统产生重大影响的变更(如系统升级),是非常必要和重要的;对于影响较小的变更可根据具体情况简化评估流程或直接提交审批。变更评估过程中,评估未经过的申请,会出现两种结果:一种是评估小组并未否定变更请求,而是对变更提出了其它意见,申请人根据意见重新填写申请,再次提交;一种是评估小组否定了变更的请求,变更终止。n变更审批:负责人对经过评估的申请进行审批。如审批经过,则进入变更授权流程,否则,进入变更终止。1042020年5月29日

45文档仅供参考n变更授权:负责人指定相应部门及人员负责变更的实施。n变更实施:能够根据变更对项目的影响程度定义实施流程。对于有重大影响的变更,实施过程将包括变更的准备、变更前试验、变更实施、变更测试、验证等。另外,还需要制定完善的测试恢复计划,以保证在实施过程中,出现意外或实施结果不符合期望时,根据恢复计划进行系统恢复,减少变更对服务质量的影响。变更实施完成后,将通知申请人。n变更终止:变更终止分成两种情况,一种是变更实施成功完成,变更工作结束,对变更进行评价;一种在变更过程中,由于各种情况变更撤销。对于变更撤销,要求记录变更撤销原因。1.1.1.1.1流程及业务规则变更管理的业务流程如下图所示:1042020年5月29日

46文档仅供参考1042020年5月29日

47文档仅供参考业务规则:n任何涉及对主机、网络设备配置、系统软件、应用软件、相关文档的修改都应该经过变更管理规范和记录;n变更流程对配置和设备的修改都应该更新配置记录;n涉及单台设备、非核心系统(非核心网络设备、服务器和应用)的配置修改为简单变更,能够省略审批过程,但必须启动变更流程并更新配置记录;n非紧急变更需要根据具体的业务要求由相关人员(变更经理或变更顾问团)审批。1.1.1.1.1与其它模块之间的关系n与事件及问题管理的关系:在处理、解决系统故障和问题的过程中,经常需要对其配置、版本进行修改。因此,事件管理和问题产生变更请求。n与日常运维管理的关系:在日常运维管理工作过程中也需要修改系统的参数和配置,也需要启动变更流程。n与配置管理的关系:变更的结果导致设备和/或配置的变化,变化的结果需要在配置管理中体现。因此,变更管理导致配置记录项的变更。n与知识库的关系:变更管理积累的经验和对典型变更过程的评价分析,都能够作为知识库的内容供其它相似案例参考。1042020年5月29日

48文档仅供参考1.1.1.1配置管理1.1.1.1.1定义配置管理是指识别和确认IT系统配置项,记录和报告配置项状态和变更历史,检验配置项的正确性和完整性等活动构成的服务管理流程。配置项是指IT系统的组件或IT系统提供服务的相关的配置信息(如主机的设备型号、CPU/内存配置、硬盘配置、网络接口卡配置以及IP地址、端口、性能配置参数等)。配置管理的目的是管理并及时提供准确可靠的IT系统基础架构(硬件、软件资源、机房内资源等)的配置信息。经过对配置信息当前情况的了解,指导系统的升级、改造。系统应提供配置数据的自动和手工输入并进行合法性等检查,对历史数据进行管理。1.1.1.1.2功能配置管理的功能结构如下图所示:1042020年5月29日

49文档仅供参考n配置项设置:是”配置项”定义的工具,经过它实现配置项列表的定义和调整,并定义配置项的层次(颗粒度)和关系以及数据获取方式;n配置项采集:获取资源配置项的完整属性信息,采集方式包含”自动采集”和”手工采集”两种方式,其中”自动采集”部分由系统监控中的”配置处理”来完成,并经过”系统监控”和”服务支持”的接口完成数据的传递;n配置项管理:实现对资源配置项的编辑、修改、调整和变更历史记录;n配置信息查询:提供对配置信息的多途径和目的的查询;n统计分析:实现对配置信息、变更信息按主题和目的进行统计汇总和分析。1.1.1.1.1流程及业务规则配置项采集流程:n自动、手工获取配置信息或配置信息变更;n对比当前配置项信息:l新增项:增加新记录;l变更项:产生变更历史记录;n变更审核,确认配置项变更;1042020年5月29日

50文档仅供参考n信息更新。流程图如下:1.1.1.1.1与其它模块之间的关系n配置管理为各功能模块提供系统的配置信息;n系统监控中的”配置处理”1042020年5月29日

51文档仅供参考自动获取的配置信息和配置变更信息,是配置管理的信息来源。配置处理与配置管理保持配置数据的一致。n事件管理、变更管理产生配置项的变动,变更结果记入配置管理数据库。1.1.1.1日常运维管理1.1.1.1.1定义日常运维管理是对日常运维活动的管理,包括值班与交接班管理、作业计划管理、系统与设备巡检和运维考核管理等日常运维管理活动。1.1.1.1.2功能日常运维管理当前包括值班与交接班管理、作业计划管理、系统和设备巡检等功能。根据运维管理的工作的实际需要,能够根据省分公司工作的需要,增加必要的功能模块。1042020年5月29日

52文档仅供参考(1)值班与交接班管理n值班管理:根据运维规程,值班人员执行系统、设备运行状况巡视,记录和处理系统异常状况和故障。值班管理的功能包括:值班人员排班管理、上岗、离岗的签到、签离,值班日志记录等;n交接班管理:交接班是现值班人员和接班人员的工作交接过程,包含交接班日志填写,接班人员的签收等功能。(2)作业计划管理n维护作业计划包含拟定,审批,执行和检查等四个功能环节;n系统提供不同作业计划的流程配置功能;n提供作业计划的查询、跟踪、统计功能。(3)系统与设备巡检n巡检记录:记录巡检的详细内容;n信息查询:对历史巡检数据进行查询。(4)运维考核管理n考核指标定义:定义运维考核的指标集以及评分标准;n考核评分:定期或现场对考核项进行评分,并记录考核结果;n报表定制:灵活定制、生成考核的报表。1042020年5月29日

53文档仅供参考1.1.1.1.1流程及业务规则各省根据运维规程和实际运维情况制定适合本地的日常运维流程及业务规则。1.1.1.1.2与其它模块之间的关系n与事件管理的关系:值班管理中对系统、设备巡视中发现的异常问题和故障是事件管理的信息源之一。1.1.1.2供应商管理1.1.1.2.1定义对业务支撑系统集成商、软件供应商的相关资料和服务质量服务能力、以及与联通签订的服务合同等信息进行管理维护。对各集成商、软件供应商的产品质量、服务情况进行评分管理,将评分定期上报总部。使省分公司及总部及时、全面地了解供应商的阶段服务状况。1.1.1.2.2功能1042020年5月29日

54文档仅供参考供应商管理的功能结构图如下图所示:n供应商资料管理:对供应商的公司信息,法人信息、联系人、产品等资料进行记录、维护管理,便于进行供应商相关信息查询;n供应商服务合同管理:对供应商的服务合同、服务内容等内容进行归类、维护,并提供例如合同到期、工程验收等提醒、通知功能;n供应商评分管理:供应商管理是对其提供服务的一个综合评价,如供应商提供服务的能力,响应速度等,方便联通对供应商服务质量进行排名;n统计分析汇总:对管理的供应商的信息和服务进行统计、汇总和报表定制功能。同时实现供应商的服务能力、水平的对比分析。1042020年5月29日

55文档仅供参考1.1.1.1.1流程及业务规则供应商评分流程:n设置供应商评分指标;l指标的增减;l指标权重的设定、修改。n采集供应商评分指标数据;n根据指标数据及其权重进行计算,得到评定分数;n对评定分数进行汇总、累加,得到最终评分。1.1.1.1.2与其它模块之间的关系n与总部的接口:向总部提供供应商考核评分数据。1.1.1.2知识库管理1.1.1.2.1定义经过对知识库系统维护和使用,不但能够在故障自动处理和人工处理的过程中在知识库中得到相关故障维护的分类和快速定位,找到匹配的处理案例,便于处理人进行借鉴,而且知识库具有的业务帮助功能,使相关人员能够经过关键字查询业务帮助、产品、市场活动、发生过的处理流程、电子文档等。1042020年5月29日

56文档仅供参考知识库管理系统也包括对相关文档(如系统业务需求书、方案建议书、设计文档等)的管理。知识库管理系统还提供相关业务与管理人员交流的”主题论坛”,交流在相关专业领域的经验教训,推进运维业务的知识管理。1.1.1.1.1功能知识库管理的功能结构图如下图所示:(1)知识库功能n知识的输入:系统提供人工和自动的方式进行知识库的添加,对输入的知识库信息审核(是否是重复的知识库信息等)。n分类目录:提供目录导航功能,使检索人员能够方便直观的检索信息。目录结构的设计是运维业务管理知识的高度总结。n1042020年5月29日

57文档仅供参考查询、检索功能:系统提供完善的查询和全文检索功能,例如:知识列表、关键字查询等。提供日常查询界面,供运维人员获取、学习。n知识库接口:为其它功能模块提供主题相关的访问入口。(1)文档功能在IT系统的运行维护中,产生大量的文档,包括:n规章制度;n项目设计文档;n项目实施文档;n培训文档;n从其它功能中归档的文档;n厂商提供的文档(产品、版本、配置、技术方案等);n其它。文档管理提供对上述文档资料的管理,提供:文档浏览、添加、更新、检索、版本管理等功能。(2)主题讨论”主题讨论”提供按不同主题区进行讨论的论坛功能,比如按主机、数据库、中间件、计费、营帐、结算等进行分类。”主题讨论”的功能包括:n论坛灵活创立;n用户管理;n论坛管理(删除、归类);1042020年5月29日

58文档仅供参考n访问量显示(热点);n评价;n知识库归档;n其它。1.1.1.1.1流程及业务规则n提供支持人员提交经验和知识的输入接口或界面;n具有不同等级用户环境的区别,不同级别的用户完成不同的知识库任务;n提供知识库的分类整理管理,易于扩充、调整;n积累业务支撑系统维护经验,逐步建立、完善对全网存在的共性问题、典型问题的处理手段或优化措施,为维护人员日常工作提供辅助分析手段;n提供各类相关的技术、业务等运维相关文档,方便查找信息;n提供完善、全面的查询功能,例如:知识列表、关键字查询、模糊查询等;n省分公司与总部交互数据,达到知识库的共享。1.1.1.1.2与其它模块之间的关系n与事件管理、问题管理、变更管理的关系:这些模块的典型处理案例能够是知识库的知识素材;1042020年5月29日

59文档仅供参考n知识库提供给各功能模块的知识查询功能。1.1.1系统监控1.1.1.1监控台监控台提供对系统平台和业务应用平台的集中监控,集中展示系统整体状况,是整个运维管理平台接入展现层的重要组成部分。n采用C/S客户端方式或B/S结构,维护人员能够方便的经过监控台实现日常监控管理;n经过监控台应能够统一完成拓扑展示、告警管理、性能管理、配置处理等各项功能和数据的配置、展现、管理和操作;n经过监控台应能完成各种辅助功能,如自动发现、采集调度、对象管理、历史数据维护、系统自管理等;n监控台应具备较好的集成能力,对已有网管和安全产品能够提供事件级、界面级、数据级集成;n系统管理中的用户安全管理应经过监控台进行操作,要求能够根据功能模块、功能点和管理内容进行分权限管理,不同维护人员登录后能够看到不同的内容;n监控台应采用全中文界面;n1042020年5月29日

60文档仅供参考拓扑展现作为监控台的重要内容,其技术要求参见第五章系统技术要求。1.1.1.1性能管理1.1.1.1.1定义性能管理是指对性能指标进行处理、分析和展现的功能模块。性能管理分为实时性能管理和历史性能分析两大部分。1.1.1.1.2功能性能指标反映了系统的运行状况,是判断被管资源运行是否正常的关键信息,性能指标的获取方式应包括主动采集、被动接收和模仿用户行为(响应测试)等多种。性能管理的功能要求如下:n指标管理:指标管理是指对性能指标属性项的管理,包括采集周期、精度、数据类型等属性定义和采集任务的分配与调度等;由于各种性能指标(特别是应用监控指标)的属性不同,要求系统能够灵活调整性能指标模型,具有足够的可扩展性。n1042020年5月29日

61文档仅供参考阀值管理:阀值管理的功能是对阀值进行设定、修改、删除,并能实时生效;阀值能够设定多个级别,阀值能够查询,相同的性能指标针对不同的关键业务监控点能够设定不同的阀值;由于应用监控指标门限设定各不相同,因此要求对阀值的管理具有足够的灵活性。n指标分析:对采集得到的性能指标进行分析,包括历史最高值、最低值、限定时间段的平均值、限定时间段的指标值变化趋势、同一指标不同关键业务点之间的比较等。n告警判断:根据设定的阀值,产生告警信息,对于设定成维护状态的关键业务点不产生告警信息。n告警管理接口:向告警管理提供告警信息。n指标展现:在实时性能管理中能够经过图表或表格的方式展现性能指标的变化情况,同时,经过历史性能数据,生成性能指标的统计报表。1042020年5月29日

62文档仅供参考1.1.1.1.1流程及业务规则1.1.1.1.2与其它模块之间的关系n向告警管理模块提供告警信息;n向统计分析提供性能指标数据源;n经过监控台实现对性能指标和阀值的管理以及实时性能数据的展现。1.1.1.2告警管理1.1.1.2.1定义告警管理模块1042020年5月29日

63文档仅供参考是对系统监控接收到的各类告警数据进行处理、分析和展现的功能模块。告警管理模块是系统监控部分的核心。需要指出的是:在告警模块中事件的概念是Event,而不是服务支持管理中事件(Incident)的概念。告警属性如下表所示:名称说明告警的序列号产生告警消息的序列号KPI标识告警KPI的标识告警标题KPI的解释网元的识别名网元的识别名告警发生时间告警发生时间(对于多次发生的告警,则指第一次告警发生的时间)告警确认时间告警确认时间告警清除时间告警清除时间告警级别告警级别告警最近一次发生时间告警最近一次发生时间(对于多次发生的告警而言)告警发生次数告警发生的次数活动状态告警当前状态告警源告警发生源告警内容告警内容1.1.1.1.1功能(1)事件数据采集与标准化事件数据来源包含系统监控经过主动状态轮询、被动接收SNMPTrap、Syslog1042020年5月29日

64文档仅供参考获得的信息,以及从已有的网管软件或信息安全管理软件中转发过来的事件信息,这些事件信息需要经过标准化处理,形成统一格式的标准化事件,同时,经过性能管理和配置处理模块,告警管理模块能够获得已经是标准事件的性能指标超门限和配置信息变更等事件信息。(1)事件压制与合并在事件生成以后,被处理完之前,有可能生成重复事件,例如当某设备经过状态轮询发现其状态异常后,每次状态轮询将生成一个重复事件,同时同一事件可能由于事件来源不同而生成多个事件/告警,例如,某网络设备接口宕,可能由于经过状态轮询、SNMPTrap和Syslog都能接收到而生成多个事件,事件压制与合并就是对相同的事件或派生型事件进行压制和归并,在告警管理模块中保持告警信息的准确性和精确性。(2)事件过滤针对单位时间内发生大量事件的情况,按维护要求和管理部门的要求及实际管理情况,过滤掉从底层提取的事件信息中监控人员认为不重要的信息,减少轻微告警的干扰,以提高监控与处理的效率。提供灵活的过滤规则:可按事件发生网元、告警级别、事件/告警类别或标题等设置过滤规则;可根据某一具体事件设置过滤规则,也可根据事件信息的内容,屏蔽掉一些次要的字段。对已设定的过滤规则需要提供保存和修改功能,便于维护人员灵活选择。1042020年5月29日

65文档仅供参考(1)事件关联由于在实际环境中,很多事件之间存在关联关系,如父子关系、触发关系、影响关系等,同时由于很多被管对象之间存在父子关系,很多应用处理环节之间有先后次序,因此,能够经过建立合理的事件相关性模型和被管对象的父子关系,以及面向应用过程的分析流图,判断已发生事件间的相关性,实现故障源识别和准确的故障定位。对象之间的关联关系和事件之间的关联关系是相关性分析的基础,准确、完整地描述这些关联关系也是相关性分析实施的前提。应根据实际情况,确定模块内及模块间的关联关系,为相关性处理打好基础。并结合实施情况,根据应用变化和运行效果,不断完善业务与平台关联关系。下图是一个简单的计费关联关系示例:1042020年5月29日

66文档仅供参考(1)告警级别定义根据告警信息的严重程度,将告警级别进行划分,具体分为三级:严重告警、重要告警、一般告警。n严重告警:指告警信息的严重程度高、对系统业务影响范围广、与业务支撑系统考核指标关系紧密。n重要告警:指告警信息的严重程度较高、对系统业务有一定范围的影响、与业务支撑系统相应考核指标有一定关系。n一般告警:指告警信息严重程度低、对系统业务影响范围小、与业务支撑系统考核指标没有紧密联系。除了以上三种告警还存在一种亚健康状态,1042020年5月29日

67文档仅供参考指系统尚未到达告警状态,可是性能下降到达需要管理员密切关注的水平。经过对该状态的监控,系统管理员能够积极主动地对系统进行管理,避免系统故障的出现。显示颜色定义如下:告警级别颜色显示严重告警红色闪烁重要告警红色一般告警桔黄色亚健康状态黄色(1)告警传递在拓扑展现中能够经过颜色改变或闪烁等方法提示维护人员引起注意,应提供告警信息在具有父子关系的被管对象之间,以及被管对象与拓扑图各种逻辑标识之间的传递规则定义,能够根据实际需求定义告警传递规则。(2)告警升级对于系统中持续出现、重复发生以及超过规定处理时间仍未解决的告警,需要升级该告警的告警级别,以保证得到优先及时的处理。(3)告警重定义根据系统平台及应用逻辑在结构、功能等方面发生的变化,重新定义告警数据所属的类别和级别,保证告警系统处理的正确性。告警重定义是标准化功能的一部分。(4)告警通知1042020年5月29日

68文档仅供参考要求提供告警通知功能,将告警信息以各种手段(手机短信、语音、EMAIL等)转至指定的维护人员,要求系统监控能够提供各种通知接口,并维护使用人员各类信息(如手机号码、EMAIL等)。(1)告警清除对于系统中已经处理完毕的告警信息,需要设置相关的标志,标记为清除,退出告警处理流程。告警清除分为手工清除和自动清除两种,其中对于自动清除,要求告警管理模块在进行标准化和相关性分析时能够定义自动清除以及自动关联清除规则;对于手工清除,要求告警管理模块提供单独API或其它可调用方式,以实现服务支持管理中事件管理中关闭工单的同时能够清除相应告警信息。(2)告警数据展现、查询、统计与分析首先要求能够对原始事件、标准事件、告警信息实现分别展现,其次,要求能够实现按照内容的告警信息展示,即不同值班人员和维护人员只能够看到自己职责范围内的告警信息,应能够提供按照各种组合条件的查询手段。要求在拓扑图中能够经过颜色改变帮助维护人员迅速定位发生告警的网元或应用组件,并能够在拓扑图上查看相应的告警明细信息,能够直接进行确认、清除等操作。1042020年5月29日

69文档仅供参考应能够提供关于当前告警和历史告警的查询、统计和分析功能,提供按照日周月等不同时间粒度的告警明细和统计报表。(1)形成工单的原始信息提供与服务支持中事件管理模块的接口,将需要维护人员人工处理的告警信息经过定义合理的规则传递给服务支持的工单处理流程,以实现对这些告警信息的闭环处理。服务支持处理完成后,将通知告警系统,进行告警清除。1042020年5月29日

70文档仅供参考1.1.1.1.1流程1.1.1.1.2与其它模块之间的关系n经过数据采集模块获取各种原始事件信息;n配置处理在发现配置发生变更时,生成变更告警信息,传递给告警管理模块;n告警管理从配置处理获取资源和配置信息;n性能指标超门限生成告警信息;1042020年5月29日

71文档仅供参考n为知识库提供相关知识信息;n在监控台中提供告警信息的查看和处理功能,在拓扑展现中提供告警传递功能和从拓扑中导航到告警信息的功能;n告警信息生成后,将告警递交服务支持的事件管理,生成事件工单中的部分信息。事件管理对告警事件处理完成后,将完成信息反馈告警模块,进行告警清除。1.1.1.1配置处理1.1.1.1.1定义将数据采集层的原始配置数据整合为数据处理层的对象型配置数据(主要以基于网元对象而关联聚合的配置信息集形式存在),以便功能呈现层能够灵活管理和呈现网元对象的配置信息。具体来说,配置数据处理的目标可细分如下三点:n提供完整的原始配置数据;n提供集成化、对象化的配置数据;n配置数据的一致性稽核。1.1.1.1.2功能n配置数据采集:经过各种方式采集原始配置数据;n配置数据采集调度:对于能够自动采集的配置数据,要求能够实现定时的采集调度;1042020年5月29日

72文档仅供参考n配置数据处理和存储:由于各类原始配置信息格式和表现方式不同,要求配置处理对各种资产和设备建立合理的对象模型,定义相关类型和属性,能够对原始配置数据进行统一标准化处理,并根据实际要求和统计分析要求针对不同的配置数据建立不同信息维度,同时对数据的合理性、准确性作判断;对配置数据的保存时长进行统一约束和定义;n配置数据变化告警:要求对不同批次采集到的配置数据系统能够自动判断其是否出现变更,并在发现异常时生成配置变更告警;n配置数据展现:要求维护人员能够经过监控台查看各种平台和应用配置信息,能够在监控台中以合乎使用习惯的方式展现配置信息,提供诸如业务树图、地理树图、厂商树图的表现方式,并提供按照多维度查询和统计分析的功能,同时,为了实现关联分析和业务拓扑,系统应提供建立配置数据间父子关系的功能,并能够从网络或应用拓扑中经过导航的方式查看配置信息;n配置处理与配置管理间接口:系统监控自动发现或手工录入的配置信息能够向服务支持管理模块批量导入,并经过约定资产ID的方式,保持两部分之间的配置数据一致性。另外,要求保证数据传递的及时性;1042020年5月29日

73文档仅供参考n配置数据统计查询(可选):配置数据应能够进行统一的处理、聚合、查询和统计。1.1.1.1.1流程需要说明的是,此图中配置处理的数据为配置管理数据的子集,配置管理的部分数据由配置处理提供。配置处理定期将配置的变化信息写入配置管理数据库。配置处理与配置管理两个部分的关系,参见下一节”配置处理与其它模块之间的关系”部分的详细描述。1042020年5月29日

74文档仅供参考1.1.1.1.1与其它模块之间的关系n告警管理:在发生配置改变时,生成配置变更告警,并发送给告警管理模块;在告警信息中的告警源或告警发生对象信息由配置处理提供;n监控台:配置处理的信息由监控台统一展示,并在拓扑展示模块中提供相应导航功能;n配置管理:配置处理与配置管理的关系在系统建设的前期和后期略有不同。在系统建设前期,如服务支持的配置管理尚未完善,则以系统监控的配置处理为主,允许在配置处理中进行必要的手工录入,且对变更进行手工的确认处理;在服务支持的配置管理完善后,则配置处理采集方式,均为自动采集,不含手工录入方式。需要手工录入的内容全部在配置管理中进行录入,并由配置管理为配置处理提供其所需信息,而配置处理也同样为配置管理提供系统自动采集的配置信息。两者互为补充,且要求保证数据的一致性。配置变更的确认后的回写,也将由事件负责人在事件管理中直接调用配置管理模块,再由配置管理将数据反馈给配置处理,以保持其一致性。1042020年5月29日

75文档仅供参考1.1.1系统管理(1)用户安全管理n权限管理:定义运维管理平台中的被管理对象,基于每个对象建立、读、写、更改、删除、停止、启动等权限,对象应可灵活分类,权限管理主要应包含三方面的内容:l功能模块的权限管理,即能够按照功能模块进行权限控制;l功能点的权限管理,即针对每个功能模块的功能点分别进行权限控制,如值班人员只能查看拓扑图,而不能自己定制拓扑,更不能删除;l按内容的授权管理:即针对配置信息、拓扑视图、告警信息等进行授权和控制,例如,负责营帐的维护人员不能看到采集部分的告警信息;n角色管理:根据对对象权限的划分,定义不同的角色,每种角色由对不同对象(或对象类)的权限组合而成。一个角色可对应有多个/(类)对象多种权限,多个角色可对应同时拥有一个权限。n1042020年5月29日

76文档仅供参考用户管理:用户管理用于认证运维管理平台管理员的身份和控制运维管理平台管理员的管理权限。每个用户有相应的帐号和口令,运维管理平台可经过用户帐号和口令等方式完成对用户的身份认证。每个用户有特定的管理权限,运维管理平台经过用户的管理权限完成对用户管理操作的授权。在角色定义的基础上定义不同用户。(1)日志功能n系统要提供完备的日志功能,记录用户访问及相关的操作日志,并进行分析和跟踪。(2)自身管理n作为一个完备的、稳定的系统,运维管理平台必须提供(在自身主要进程活动的情况下)对自身服务器端关键进程的监控、自维护机制。n运维管理平台应能够定义规则来维护系统中的各种数据的存储周期,如历史性能数据、历史告警信息、配置数据等,并提供对数据的定时备份功能。1042020年5月29日

77文档仅供参考1.系统技术要求1.1总体技术要求1.1.1应用软件应用软件应遵循如下原则:(1)规范性本系统的设计、开发、实施和维护管理必须遵循中国联通的企业标准及规范,保证运维管理平台和各种业务支撑系统能够根据运维需要实现有效的连接。(2)先进性本系统应采用先进的软件技术和业务管理手段,以保障系统具有高效、全面和稳定等良好品质;软件系统应用采用分布式、组件化技术和模块化的构造方式;系统应采用三层体系结构。(3)扩展性本系统的系统容量、处理能力和业务范围应具有良好的扩展能力;应用软件设计应满足今后的业务量和业务需求的增长,保护投资,避免重复建设。(4)安全可靠性本系统应满足电信级的可靠性要求,保证7x241042020年5月29日

78文档仅供参考小时的服务;保证系统在运营过程中管理的各种资料的信息安全;保证业务支撑系统的安全性和本系统的安全性。运维管理平台设计不应影响业务支撑系统的可靠运行,运维管理平台与业务支撑系统之间采取严格的权限控制或设置防火墙等措施,保证业务支撑系统的安全性。(1)易用性本系统应在两个方面容易使用:一方面是方便普通的用户,另一方面是方便系统管理员。由于运维管理平台是为日常运维管理服务的,其特点决定了系统必须具有清晰直观的界面、易于理解的输入和输出内容、易于操作的使用风格。(2)可维护性系统应该具有对自身的集中维护配置功能,包括集中的系统参数设置、集中的系统日志管理,且在需要时要求程序的每一步处理应该是可追踪的。1.1.1数据要求(1)完整性完整性是保证系统数据的全面,对各种操作都需要有详细的记录,对于在线使用的数据应与历史数据清晰的分离,保证在线数据的一致,当需要历史数据时,可方便的导入系统,并保证数据的一致性。1042020年5月29日

79文档仅供参考(1)安全性系统采集到的系统平台和业务应用平台的原始性能数据、配置数据、告警数据等,需要考虑数据的安全,应做定期备份和增量备份。(2)存储要求系统采集到的系统平台和业务应用平台的原始性能数据、配置数据、告警数据应在线保存6个月,脱机保存24个月;系统数据和管理数据长期保存;统计报表在线保存12个月,脱机保存24个月;对文档等数据在线保存24个月,脱机长期保存。1.1.1性能要求n应用系统在并发用户数达到最高峰时,响应时间不超过10秒(除去网络延迟因素);n应用系统在并发用户数达到最高峰时,报表展现从按键到显示不超过20秒;n数据采集接口性能应能保证系统对告警处理的及时性,对系统的运行状况及时反映。1.1.2开发工具1042020年5月29日

80文档仅供参考采用的开发工具及语言应具备开放性、先进性、可移植性、高性能、支持面向对象的开发方式;具有高效率、方便灵活等特点,开发的程序性能高;具有丰富的库函数;具备开放式的接口。1.1统计报表n完整性统计报表系统在设计上,需要统一规划,保证唯一的体系结构,统一数据源,保证数据的一致性。n灵活性对统计报表采用先进技术,支持运维人员的灵活定制,根据需要可方便的组合生成复杂的报表。针对不同的使用对象,可灵活定制不同的功能及显示不同内容。n多样性统计报表应能对各种查询结果进行某一维度的统计分析,并能将统计分析结果以文本列表、图形方式〈直方图、曲线图、饼图等〉或报表方式显示、打印或转存为Excel报表方式输出。n高效性需要考虑数据的多层结构,分散存储,保证最终报表的快速提取,提高工作质量。1.2拓扑展现1042020年5月29日

81文档仅供参考拓扑展现是监控台的重要功能。从拓扑的展示对象来分,拓扑展示对象包括系统平台和业务应用。拓扑展示的主要功能除直观和方便的为维护人员进行系统展示外,还应具备导航功能,便于系统管理员经过拓扑导航到配置处理、性能管理和告警管理等功能模块,以便于维护人员更直接的发现故障并进行维护和管理。另外,拓扑展现应具备自动生成功能,应方便维护人员的使用。1.1.1拓扑的生成方式系统应同时支持自动发现拓扑方式和手工定制两种方式。n自动发现方式:自动生成网络拓扑图,客户端界面实时监视拓扑的生成,生成内容包括对应网元的图标、网元之间的链路、网段的拓扑、总拓扑和OSPF等路由协议的拓扑图等;n手工定制方式:提供手工定制拓扑的手段,从而可手工定制地理拓扑、业务拓扑等。1.1.2技术要求n应支持web发布方式;n对告警的展示应及时、直观;n应能够在拓扑图上自动区别出厂家、型号等信息;n提供分层次的拓扑展示方式,能够设置告警是否往上层传递;n能够改变拓扑图的底色和底图等;1042020年5月29日

82文档仅供参考n经过拓扑节点能够查看该节点相关的配置、性能、告警等信息;n可根据运维人员给定的条件(如按IP、名称、厂家等条件)方便的进行网元的查询和定位;n可设置基于运维人员和拓扑图内容的权限控制;n能够自动排列或手动控制图标的位置;n能够将某些相关网元组合到一个拓扑,便于运维人员对系统的管理;n拓扑图间可互相引用;n可同时安装于分布式的客户端,方便不同运维人员进行同时查看;n能够从拓扑图导航到各个相关的模块,包括配置处理、告警管理和性能管理等。1.1工作流事件管理、问题管理、变更管理、配置管理等模块包含大量工作流程。这些工作流程在符合ITIL的管理思想的基础上,也势必随着管理要求的变化而做出相应的调整。因此,需要一个能够实现工作流建模、执行、监控、分析、度量和优化的基础中间件平台,为事件管理、问题管理、变更管理、配置管理及未来的服务管理等模块服务。1042020年5月29日

83文档仅供参考工作流管理作为事件管理、问题管理、变更管理等重要服务支持模块的工作引擎,必须具备以下技术要求:n符合ITIL管理规范,为未来其它服务模块的建立奠定基础;n可视化的流程设计工具,加速过程建模;用户可根据工作的实际情况建模,以符合实际工作的需要;n支持工作流模板,将已发布的工作流能够定义为模板,以供系统复用;n支持串行、并行、分支、汇合、循环、同步、子流程等流程逻辑结构,满足各类复杂流程建模需要;n图形化的流程监控工具,即时动态监控、跟踪流程执行状态和相关数据;n具备时限定义功能。可灵活定义事件处理的时限,并可定义接近时限或超出时限的处理方式,如催办、超时限的事件升级处理或其它方式等,以保证对故障等紧急事件的及时处理。n具备权限控制机制,防止越权的流程定制。n强大的应用集成服务,完成工作流与”信息孤岛”状的企业已有应用之间的无缝集成与互操作。1042020年5月29日

84文档仅供参考工作流是服务支持模块的核心引擎,工单则是工作流运行的载体。为了更好的说明工作流和工单,下面对工单和工作流进行简要介绍。工单是流程和信息传递的载体,工单在不同部门和人员之间按照规定的业务逻辑流转构成了工作流。通用工单定义如下信息:通用工单信息项说明工单流水号系统自动生成的工单号码申报人信息事件、告警、变更或问题等的申报人信息,包括:¡姓名¡省/分公司¡部门¡电子邮件¡办公电话¡手机申报时间事件或告警的申报时间工单类型以事件的技术架构的类型进行分类,如数据库,服务器等。工单描述对事件、告警、变更或问题的具体描述工单级别工单的优先级,包括紧急、正常初步处理情况及处理建议接受工单人员对事件进行初步处理的情况及处理建议受理部门受理部门协办部门协办部门受理人信息事件、问题或变更的受理人信息受理时间事件、问题或变更的受理时间退回处理原因接受单位提出的退回工单的原因处理结果事件、问题或变更的处理结果处理完成时间事件、问题或变更的处理完成的时间阶段处理结果分阶段处理情况下的阶段总结归档时间处理完成后工单的归档时间工单状态信息工单当前状态,包括开始、已创立、待处理、处理中、已完成工作记录对工作的情况的实时记录资源记录列表事件或问题完成所需要的资源记录附件事件或问题完成过程中生成的相关报告等1042020年5月29日

85文档仅供参考子工单在工作流程中,产生并派发的相应子工单工作流管理(如配置管理流程等)以工单为主线,包括工单定制,工单的派、领、回、退、追等功能及相应状态的变化,如下图:n建申报人创立工单;n派申报人派发工单给受理单位;n领受理人确认受理派来的工单;n退受理人把工单退还给申报人或上一级受理人(处理中能够退);n追申报人或上一级受理人把派出去尚未受理的工单追回(处理中能够追,需要通知负责人);n转受理人把工单转派给其它单位;n办完成负责的处理/协办工作;1042020年5月29日

86文档仅供参考n升工单升级,紧急度增加;n催申报人或上一级受理人催促当前处理人尽快办理;n知当前处理人阶段性知会申报人或上级处理人处理情况;n复处理完毕后,回复给申报人;n释记录注释、说明,供其它人员参考;n评对某级受理人工作的评价,能够输入评价对象、满意程度和说明;n废关闭工单,工单作废;n闭申报人关闭工单,结束处理整个处理。1.1安全管理在运维管理平台中,信息安全的管理是重要内容之一。在系统的建设中,主要从两个方面考虑系统的安全管理:首先,安全管理作为运营维护的管理对象的一个主要部分,也应纳入系统运维的统一管理框架;其次,运维管理平台要保证其正常运行,必须要保证其自身的安全性。1.1.1对安全管理的统一维护1042020年5月29日

87文档仅供参考将现有信息安全系统纳入运维支持体系中,将现有的安全漏洞扫描、入侵检测和病毒防护系统生成的事件经过各种接口方式与系统监控的告警管理模块集成,实现统一的告警管理,严重的安全事件进入服务支持的事件处理流程中,对于重大安全事件提供主动上报总部的功能。1.1.1运维管理平台的安全性n对运维管理平台进行安全评估,明确系统安全建设的目标和任务;n经过针对关键服务器和网络设备(如交换机、路由器、防火墙等)进行安全加固和策略调整,加强运维管理平台的健壮性;n建立健全信息安全制度,加强运维管理人员的安全生产意识、明确岗位职责、建立机房安全、设备安全、软件安全、数据安全和人员安全管理规范,并经过服务支持系统实现对信息安全制度的电子化和规范化管理;n加强对运维人员使用的桌面PC机的管理,包括:l控制桌面PC访问Internet的权限,实现分人员、分时段、授权的Internet访问控制,尽量减少恶意代码和病毒的危害;l控制一般用户(非技术人员)对PC配置的修改(包含安装/卸载软件、改变IP地址、修改注册表等);l在条件许可的情况下,实现对桌面PC1042020年5月29日

88文档仅供参考的统一补丁版本和安装管理。1.1数据采集1.1.1数据源类型二级运维管理平台采集的数据源类型如下:采集数据源类型包括信息平台类数据源主机、网络、存储、数据库、中间件应用类数据源采集、计费、营帐、结算其它数据源机房环境、安全数据、文档数据采集的数据包括如下信息:性能数据、告警数据、配置数据。1.1.2数据采集要求n接口支持多协议标准;n采用双向的数据传输,主动获取和被动接收;n支持多种数据格式,单条数据、批量数据;n支持定时、实时、准实时采集方式;l性能数据应可经过定时方式、周期方式等进行采集;l告警数据的实时性要求较高,应由支撑系统主动上报,系统实时接受,保证告警数据及时获得;l配置数据相对稳定,建议在系统比较闲时进行采集。n1042020年5月29日

89文档仅供参考采集程序必要时应能进行补采或重采,以保证数据采集的完整性。1.1.1数据预处理数据采集需要进行预处理,保证数据的正确性和标准化。n正确性审核,对不符合要求的数据及其记录,进行标记,并提示出错信息,并进行重采;n标准化处理,把采集的数据转变成统一的标准格式,向后台提供数据源。1042020年5月29日

90文档仅供参考1.系统接口1.1接口原则本处定义的接口为运维管理平台与其它相关的系统,以及运维管理平台内部之间进行数据交换的逻辑层面。编制本接口规范的目标是保证运维管理平台与相关系统以及内部之间的数据接口的标准化,同时保证相关系统的数据安全。运维管理平台与其它相关系统及内部接口应达到如下目标:n接口简单明了,便于形成、操作和传输,并能满足现在和将来的需求;n接口能灵活地支撑运维管理平台和其它相关系统的业务需求;n运维管理平台与其它系统的接口应充分考虑安全性,适用性,不影响运维管理平台和其它系统的安全性能和业务性能。为了保证运维管理平台与其它相关系统及运维管理平台内部模块间方便、可靠地接口,接口规范应满足如下原则:n屏蔽运维管理平台与其它相关系统接口的细节,使得所编制的接口具有普遍的适应性;n1042020年5月29日

91文档仅供参考使用简单、快捷的方式实现运维管理平台与其它相关系统的接口;n接口规范应充分考虑运维管理平台与其它相关系统的应用扩展情况;n保证接口数据在运维管理平台与其它相关系统的一致性;n接口数据能够方便的形成,并能在被接口方顺利地导入;n在接口数据交互过程中,应具有数据传送和接收传送后的确认过程;n在满足要求的前提下,使接口数据量最少;n接口数据传输控制策略可靠且完善;n具有可靠的接口数据出错处理机制。1.1服务支持与系统监控的接口1.1.1接口定义n服务支持从系统监控获得告警事件;n服务支持的处理结果返回给系统监控接口,由系统监控做相关的后续处理;n服务支持和系统监控保持配置信息同步。1042020年5月29日

92文档仅供参考1.1.1接口方式n数据库方式;n专用API方式;n消息方式;nCORBA;n其它接口方式,如邮件、短信、电话通知等方式。1.1.2接口要求服务支持与系统监控的交互接口是整个运维系统是否实时高效运行的关键,其接口要求能够及时、准确的传达相关信息,需要采用实时、准实时的同步策略。1.1.3接口内容(1)系统监控提供给服务支持的告警事件内容序号数据内容数据类型说明1告警的序列号字符串产生告警消息的序列号2KPI标识字符串告警KPI的标识3告警标题字符串KPI的解释4网元的识别名字符串发生告警的网元的识别名,即配置的ID5告警发生时间时间告警发生时间(对于多次发生的告警,则指第一次告警发生的时间)6告警级别整数告警级别7告警最近一次发生时间时间告警最近一次发生时间(对于多次发生的告警而言)1042020年5月29日

93文档仅供参考8告警发生次数整数标记同一告警在关闭前发生的次数9活动状态整数告警当前状态,新建、已解决10告警内容字符串告警内容(1)服务支持处理后返回给系统监控的告警事件数据内容(可选):序号数据内容数据类型说明1告警的序列号字符串产生告警消息的序列号2活动状态字符串服务支持系统对告警的处理后的结果状态:1、清除(当前规范只有这种状态);2、服务支持系统要求监控系统做相应的控制动作(为以后的扩展,当前不做要求);(2)系统监控与服务支持交互的配置数据内容序号数据内容数据类型说明举例1配置项名称字符串设备名称计费1号机2配置的唯一标识(ID)字符串配置的唯一标识码JNK0013配置类别字符串配置的关键性级别平台类4配置的属性标识字符串配置的属性标识CpuNum5配置的属性值字符串配置的属性值86操作时间时间被发现、变更等操作的时间-6-91.1与业务应用系统的接口1.1.1接口定义从现有业务支撑系统获得实时运行信息、各种性能、配置指标数据及告警信息。1042020年5月29日

94文档仅供参考1.1.1接口方式接口子系统要求支持以下一种或多种接口方式:n文件方式接口;n数据库接口(在安全、性能允许的情况下,能够采用简便、可靠的数据库接口方式);nCORBA接口;nSOCKET接口:完成与业务应用系统实时通讯功能;nSOAP接口;nHTTP接口;nMQ接口;n其它方式接口,如利用第三方网管产品作为业务应用系统监控的数据源,经过采集第三方网管数据达到采集业务应用系统指标的目的。1.1.2接口策略运维管理平台和业务应用系统的接口按照以下方式能够分为。n按照时间:l实时;l准实时;1042020年5月29日

95文档仅供参考l定时。n按照获取方式:l主动获取;l被动接收。1.1.1接口要求为适用不同业务应用系统的多样性和不同厂商业务处理的不同性,对接口的格式采用灵活处理的方式,运维管理平台提供多种接口处理的方式适用业务系统的不同对外接口。n运维管理平台和业务应用系统的交互以不影响业务系统正常运行为前提;n要求业务应用系统提供相关KPI指标或运行信息原始数据;n运维管理平台采集代理采用多种数据传输的方式和不同业务系统通信完成数据采集的功能;n接口采用的传输方式、采集策略、采集代理的部署方式能够灵活配置,以适合业务的灵活变化;n接口必须提供错误处理机制,能够进行补采、重采等错误的补救措施。1042020年5月29日

96文档仅供参考1.1.1接口内容参见<中国联通BSS运维管理平台KPI指标>附件。1.2与系统平台的接口1.2.1接口定义运维管理平台与被管设备、系统软件之间的接口,用于提取平台级KPI指标。1.2.2接口方式接口协议支持以下一种或几种方式:nSNMP;nCORBA;nSOAP;nSocket;n其它方式,如利用成熟的第三方网管平台作为系统平台监控的数据源,经过采集第三方网管数据达到采集系统平台指标的目的。1.2.3接口要求n运维管理平台和系统平台的接口由运维管理平台数据采集功能实现;1042020年5月29日

97文档仅供参考n运维管理平台采集代理和系统平台交互获得运维相关数据信息,运维管理平台和系统平台的交互以不影响业务系统正常运行为前提,同时要求系统平台必须提供相关KPI指标和实时运行信息的数据。运维管理平台采集代理采用多种数据传输的方式和不同业务系统通信完成数据采集的功能。1.1.1接口内容参见<中国联通BSS运维管理平台KPI指标>附件。1.2两级运维系统间的接口1.2.1接口定义省级运维管理平台与总部运维管理平台之间的数据传递接口。n省运维管理平台需要经过接口向总部系统上报的关键业务指标(性能、告警、配置信息);n上传工单信息:分公司发生的重大事件、故障、问题、变更等工单信息;n下发工单信息:总部的审批、指示、内部文件等相关的信息;n知识库信息:向总部系统上传,同时也需要从总部系统下载知识库信息;n统计报表。1042020年5月29日

98文档仅供参考1.1.1两级接口文件命名规则及相关约束1.1.1.1文件命名规则文件命名规则:【TYPE】【YYMMDD】【NNN】.【SSS】共计16位文件名称,文件名称长度为16位。规则代码代码说明备注TYPE两级运维传输信息文件的分类:1.MDI:关键业务指标日报,对应的回执文件为:MDO;2.MMI:关键业务指标月报,对应的回执文件为:MMO;3.MSI:关键业务指标季报,对应的回执文件为:MSO;4.MEI:上传工单信息文件,对应的回执文件为:MEO;5.MAI:下发工单信息文件,对应的回执文件为:MAO;6.MKI:上传知识库信息文件,对应的回执文件为:MKO;7.MFI:下发知识库信息文件,对应的回执文件为:MFO;8.MRI:上传报表信息文件,对应的回执文件为:MRO;3位YYMMDD日期信息,(含有月份信息)表示上报内容的日期6位NNN1.本日(月/季)文件的实际传送次数,按类型分别计算。第一次为001。如果文件内容不变,重传仍为001;若第一次有错误记录,下一次把错误记录修改后重新传送,文件序号为002。且文件名中的序号与首记录中文件序列号相同。2.日报文件、月报文件、季报文件分别按指定的时间进行上传。要求在每日10:00前上报前一天的日报文件;每月5日10:00之前上报上月的月报文件;每季度开始月的5日10:00之前上报上季度的季报文件。3位SSS代表发送或接收文件的分公司代码(省分公司代码)。3位1.1.1.2回执文件格式约定(1)文件格式nXML格式;n文本格式;1042020年5月29日

99文档仅供参考下发回执文件每条记录以”

100”分隔。(1)文件内容文件头:序号名称字节数备注1省分公司代码3bytes2文件标志3bytes参见文件命名规则中的TYPE定义3文件名称12bytes回执对应的上传文件名,不含扩展名4文件产生日期8bytesYYYYMMDD5文件错误代码3bytes缺省为空格,否则为文件错误代码6总记录数8bytes不含首记录。右对齐,左补0。7正确记录数8bytes右对齐,左补0。8错误记录数8bytes右对齐,左补0。9校验码32bytes同数据文件文件体:序号名称字节数备注1指标记录71bytes出错的记录2分隔符2bytes两个冒号”::”3错误代码3bytes见错误代码定义1.1.1.1错误信息说明(1)错误信息种类1)错误类型错误种类分为以下二类:n文件错误(F)。当出现文件错误时,回执文件只包含文件头。n记录错误(R)。对于两种类型的错误,分公司都需要重新上传出错的文件。2)错误代码范围划分1042020年5月29日

101文档仅供参考以下是错误代码分类及相应的错误代码范围。n文件级错误:错误代码范围为001～099;n格式错误:数据类型错误(如:数值域中出现字母字符),这类错误的错误码范围为100～199;n无效的字段值:字段中的值不符合值域的定义范围,此类错误的代码范围为:200～299;n指标缺少错误:上传文件中缺少必须上报的指标,这类错误的代码范围为:300～399;n同一指标的采样记录缺少:上传文件中缺少指标的所有采样记录,这类错误的代码范围为:400～499;n其它错误:不属于以上几类的错误为其它错误,错误代码的范围为:500～999。(1)文件错误字段名错误代码代码错误描述N/A001文件格式错误N/A002文件名错误N/A003文件名中分公司代码错误N/A004文件序列号错误(2)记录错误下表中的错误代码的第一位根据错误代码分类确定。如KPI的格式错误时,错误代码为130;内容无效时,错误代码为230;缺少指定KPI时,错误代码为330;缺少指定KPI的采样记录时,错误代码为430。1042020年5月29日

102文档仅供参考字段名错误代码错误描述省分公司代码X00与文件名中的分公司代码不同文件标志X01错误的文件标志文件序列号X02与文件名中的序列号不同文件产生日期X03不符合年/月/日的规定总记录数X04总记录数与详细记录数不符校验码X05计算出的检验码与文件中不符KPIX30KBPX31采样时间X32值X331.1.1上传关键业务指标1.1.1.1接口定义将省公司需要上报的关键业务指标数据经过文件传输传送到指定的位置。(1)接口协议可采用POP3、SMTP、SOAP、TCP/IP等。(2)接口方式n邮件方式;nMQ;nFTP。(3)接口策略n人工方式;信息的上传过程由手工完成;1042020年5月29日

103文档仅供参考n全自动方式:信息的形成、打包、传送、接收、解析等过程完全采用系统自动完成。(1)接口内容参见<中国联通省级运维管理平台上报总部KPI指标>附件。(2)接口要求数据传输应高效和安全可靠、断点续传、数据压缩传输、在数据传输中发生的错误由数据传输发起方负责控制并重新传输。1.1.1.1接口实现(1)上传文件格式nXML格式;n文本格式。上传文件每条记录以”

104”分隔。(2)上传文件内容文件头:序号名称字节数备注1省分公司代码3bytes2文件标志3bytes参见文件命名规则中的TYPE注释3文件序列号3bytes注14文件产生日期8bytesYYYYMMDD5总记录数8bytes不含首记录。右对齐,左补0。6校验码32bytes注27扩展用32bytes空格1042020年5月29日

105文档仅供参考文件体:序号名称字节数缺省值备注1KPI14bytes见KPI编码规则2KBP11bytes见KBP编码规则3采样时间14bytesYYYYMMDDHHMISS4指标值32bytes”##”注3。左对齐,右补空格(1)注释I.分公司上传文件每日从001开始排序。且文件序列号与文件名中序号一致。例如:7月3日北京分公司第一次上报的日报文件名MDI04070.011,首记录文件序列号001,第二次上报的指标文件名MDI04070.011,首记录文件序列号为002。第一次上报的月报文件名MMI06001.011,首记录文件序列号001,第二次上报的指标文件名MMI06002.011,首记录文件序列号为002。第一次上报的季报文件名MSI06001.011,首记录文件序列号001,第二次上报的指标文件名MSI06002.011,首记录文件序列号为002。II.校验码采用MD5算法,生成唯一的32位校验串。生成校验码的内容域包括除校验码域之外的所有域。III.由于各种原因造成分公司无法生成某采样时间点的指定对象指标值时,需以缺省值(”##”)传送该数据记录。1042020年5月29日

106文档仅供参考1.1.1工单信息的传递1.1.1.1接口定义(1)接口内容n省级运维管理平台将系统中出现的重大事件/故障工单、典型问题工单、重大变更工单上传;n总部运维管理平台将审批工单、其它指示工单信息下发。(2)接口协议可采用POP3、SMTP、SOAP、TCP/IP等。(3)接口方式n邮件方式;nMQ;nFTP。(4)接口策略n人工方式:工单申请人在将工单派发出去和关闭工单的时候选择是否上报总部;n全自动方式:工单的形成、打包、传送、接收、解析等过程完全采用系统自动完成。(5)工单类型1042020年5月29日

107文档仅供参考n分公司重大事件/故障工单;n分公司典型问题工单;n分公司重大变更工单数据;n总部审批工单,分公司的报批工单的回复意见信息;n总部指示信息工单,如问题工单、业务需求工单、宣传指示工单,其它与运维有关的工单。(1)接口要求数据传输应高效和安全可靠、断点续传、数据压缩传输、在数据传输中发生的错误由数据传输发起方负责控制并重新传输。1.1.1.1接口实现(1)上传工单1)文件格式nXML格式;n文本格式。2)接口内容:n1042020年5月29日

108文档仅供参考上传工单至少应该包含如下信息:工单流水号、申报人信息、申报时间、工单类型、工单描述、工单级别、初步处理情况及处理建议、受理部门、协办部门、受理人信息、受理时间、退回处理原因、处理结果、处理完成时间、阶段处理结果、归档时间、退回处理意见、工单状态信息、工作记录、资源记录列表、附件、子工单。(1)下发工单1)文件格式nXML格式;n文本格式。2)接口内容:n下发审批工单至少包含的信息:工单流水号、申报人信息、申报时间、工单类型、工单描述、工单级别、初步处理情况及处理建议、受理部门、协办部门、受理人信息、受理时间、退回处理原因、处理结果、处理完成时间、阶段处理结果、归档时间、退回处理意见、工单状态信息、工作记录、附件、子工单。n下发指示工单至少包含的信息:工单流水号、申报人信息、申报时间、工单类型、工单描述、工单级别、受理部门、协办部门、受理人信息、受理时间、处理完成时间、阶段处理结果、归档时间、工单状态信息、工作记录、附件、子工单。1042020年5月29日

109文档仅供参考1.1.1知识库信息传递1.1.1.1接口定义省运维管理平台将系统知识库中比较有价值的知识条目上报总部,同时系统管理员浏览总部知识库系统,将比较有价值的知识条目下载到本省知识库中。(1)接口协议可采用POP3、SMTP、SOAP、TCP/IP等。(2)接口方式n邮件方式;nMQ;nFTP。(3)接口策略n人工方式:上传时,由省管理员选中本地知识库中可上传的知识条目,点击上传后自动打包成文件发送总部,或由省管理员登陆到总部运维管理平台中直接录入;下载时,省管理员登陆总部系统,选中要下载的知识条目,点击下载后自动打包成文件发往省公司,由省级系统自动解析后添加到本地知识库中;n1042020年5月29日

110文档仅供参考全自动方式:知识库条目的形成、打包、传输、接收、解析完全由系统完成。(1)接口内容n省级运维管理平台活动中形成的可用于共享的知识条目;n总部系统在自身运维活动中形成或接收的省级上报的知识条目。(2)接口要求数据传输应实时、高效和安全可靠、断点续传、数据压缩传输、在数据传输中发生的错误由数据传输程序负责控制并重新传输。1.1.1.1接口实现(1)上传知识文件1)文件格式文件采用XML格式。2)接口内容内容包含:知识标题,知识分类,知识线索,知识详细内容,最新更新时间。(2)下传知识文件1)文件格式文件采用XML格式。1042020年5月29日

111文档仅供参考1)接口内容内容包含:知识标题、知识分类、知识线索、知识详细内容、最新更新时间。1.1.1上传统计报表1.1.1.1接口定义省级运维管理平台将总部运维管理平台关心的一些系统重要报表上传总部系统。(1)接口协议可采用POP3、SMTP、SOAP、TCP/IP等。(2)接口方式n邮件方式;nMQ;nFTP。(3)接口策略n手工方式,由系统管理员选择需要上传的报表文件;n全自动方式:报表的生成,打包、传输、接收、解析完全由系统自动完成。(4)接口要求1042020年5月29日

112文档仅供参考数据传输应实时、高效和安全可靠、断点续传、数据压缩传输、在数据传输中发生的错误由数据传输程序负责控制并重新传输。1.1.1.1接口实现(1)系统自动生成报表,报表文件格式采用:nEXCEL;nXML。(2)接口内容参见总部规定的上报报表附件(待定);1.2与其它系统的接口1.2.1接口定义与其它系统的接口包括与MSS、客服系统等,实现方便地从其它系统导入数据和将本系统数据传送给其它系统。1.2.2接口实现对于OA等其它已建系统,原则是适应其已有的接口规范。在系统的初期可采用E_Mail等方式在本系统与其它系统间传输数据,随着各系统的逐步完善采用相应的接口方式实现数据的共享。1042020年5月29日

113文档仅供参考1042020年5月29日

114文档仅供参考附件1:中国联通BSS运维管理平台KPI指标。附件2:中国联通省级运维管理平台上报总部KPI指标。1042020年5月29日