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

1、中国联通业务支持系统BSS运行维护治理平台业务技术标准讨论稿中国联通2004年6月1 .总体概述1.1 行业背景 1.2 系统现状分析 1.3 编制目的 1.4 适用范围 1.5 起草单位 1.6 解释权 1.7 参考文献 2 .建设目标及原那么 2.1 建设目标 2.1.1 近期目标 错误！未定义书签.2.1.2 远期目标2.1.3 建设规划2.2 建设原那么 3 .系统总体结构 3.1 系统定位以及与现有网管系统之间的关系 3.1.1 系统定位 13.1.2 与现有网管系统之间的关系 3.2 系统组织结构 3.3 系统体系结构 3.3.1 数据层监控数据 治理数据 系统数据 文档数据 3.

2、3.2 功能层3.3.3 接入展现层3.4 与外部系统之间的关系 4 .业务功能与流程 4.1 各模块之间的关系 4.2 岗位与角色描述 4.2.1 岗位描述4.2.2 角色描述4.3 业务功能描述 4.3.1 效劳支持效劳台 事件治理 问题治理 变更治理 配置治理 27日常运维治理 供给商治理 知识库治理 4.3.2 系统监控监控台 性能治理 告警治理 配置处理 4.3.3 系统治理5 .系统技术要求 5.1 总体技术要求 5.1.1 应用软件5.1.2 数据要求5.1.3 性能要求5.1.4 开发工具5.2 统计才艮表 5.3 拓扑展现 5.3.1 拓扑的生成方式 5.3.2 技术要求5.

3、4 工作流 5.5 平安治理 5.5.1 对平安治理的统一维护 5.5.2 运维治理平台的平安性 5.6 数据采集 5.6.1 数据源类型5.6.2 数据采集要求5.6.3 数据预处理6 .系统接口 6.1 接口原那么 6.2 效劳支持与系统监控的接口 6.2.1 接口定义6.2.2 接口方式6.2.3 接口要求6.2.4 接口内容6.3 与业务应用系统的接口 576.3.1 接口定义6.3.2 接口方式6.3.3 接口策略6.3.4 接口要求6.3.5 接口内容6.4 与系统平台的接口 错误！未定义书签.6.4.1 接口定义6.4.2 接口方式6.4.3 接口要求6.4.4 接口内容6.5

4、两级运维系统间的接口 6.5.1 接口定义 646.5.2 两级接口文件命名规那么及相关约束 文件命名规那么 回执文件格式约定 错误信息说明 6.5.3 上传关键业务指标 63接口定义 接口实现 6.5.4 工单信息的传递接口定义 接口实现 6.5.5 知识库信息传递 72接口定义 接口实现 6.5.6 上传统计报表接口定义 接口实现 6.6 与其他系统的接口 6.6.1 接口定义6.6.2 接口实现1 .总体概述1.1 行业背景当今通信市场正由传统的以通信网为中央的效劳质量的竞争转变成以客户为中央的效劳 质量的竞争,中国联通为了适应市场竞争的变化,必须建立以客户效劳为中央的效劳机制.综 合电

5、信业务支撑系统在中国联通公司的整体运营中起着至关重要的支撑作用,因此在监控业务 支撑系统硬件和系统软件的根底上还应对各业务应用系统进行监控,通过对各业务应用系统的 整个处理流程进行监控,掌握各业务系统的运行状况.同时,运维治理应逐步实现从被动效劳到主动发现系统中存在的问题,变被动为主动,以 流程贯穿整个运维治理过程；减少运维人员的劳动强度,提升效率,切实保证各业务支撑系统 可靠、稳定、高效地运行,进一步提升用户的满意度和忠诚度,全面提升中国联通的效劳质量.1.2 系统现状分析中国联通公司是目前国内电信业务最多的综合性电信业务运营商,经营着GSM、CDMA、市话、互联网等业务.在中国联通的统一规

6、划和领导下,建设了各省综合电信业务支撑系统. 综合电信业务支撑系统是一个包括众多子系统的复杂系统,需要对各业务子系统的硬件及软件 平台进行治理,保证各业务子系统的正常运行.而各业务子系统在建设过程中有的考虑了网管 监控有的没有考虑,后来进行了网管与网络平安工程的建设实现对各业务子系统的治理,因此 在系统中可能存在多个网管工具,对不同的系统维护需要到不同的治理平台上进行处理,大多 数只能对硬件平台网络、主机等和系统软件数据库、中间件等进行监控,不能对各业 务子系统进行监控或者只能监控到应用系统是否在运行状态下而不能监控其运行效率.同 时各省缺乏对业务子系统处理流程的监控,监控手段和效率较低,因此

7、需要在原有网管系统的 根底上进行完善,引进先进的IT治理方法和手段,提升整体运维水平.BSS运维治理平台业务技1.3 编制目的中国联通制定本业务支持系统运行维护治理平台以下简称术标准,主要用来标准指导中国联通各省分公司运行维护治理平台的建设O1.4 适用范围本业务技术标准是中国联通业务支持系统运行维护治理平台规划与建设的基 本依据.中国联通各省分公司应依照本业务技术标准,结合本地实际情况进行规划 和建设本省BSS运维治理平台.1.5 起草单位本业务技术标准的起草单位为中国联通,由中国联通计费、 结算与信息系统部进行治理.1.6 解释权本业务技术标准的解释权属于中国联通计费、结算与信息系统部.1

8、.7 参考文献?UNI-IT体系架构指南?；?中国联通网管及网络平安系统总体方案?；?中国联通企业信息化UNI-IT 系统运行维护规程?试行.2 .建设目标及原那么2.1 建设目标BSS运维治理平台应整合目前的系统,逐步实现对“网元级、资源级、应用级和系统平安 等维护治理.同时,结合各省分公司的实际治理情况,由对业务子系统的治理延伸到对人员的治理,逐步实现以流程贯穿整个治理过程,进而实现对业务支持系统“统一治理、集中监控、集中运维.2.1.1 近期目标近期完成BSS运维治理的根本功能,实现对业务子系统采集、计费、营业、帐务、结算系统 等系统平台和应用软件的运行状况监控以及日常运维治理如作业方案

9、等,保证业务支撑网的 正常运行.在统一平台上实现对系统运行状态的集中治理主要包含主机设备、网络设备、存储设备、备份设备、数据库、中间件、应用软件等,保证业务支撑网的正常运行；实现对业务子系统应用软件关键点的监视和保证,保证系统的运行质量； 通过对业务子系统中各类告警信息的分析,进行故障的快速定位和告警功能； 建立日常运维工作流程,实现对日常运维活动的治理,从而实现对维护人员工作的监控 和量化；建立运维治理知识库系统,实现知识交流与共享；实现供给商的有效治理；掌握业务子系统的资源配置信息；实现省公司和总部之间通过运维治理平台上传下达规定的考核指标、运维报表、重大故 障/变更等.2.1.2 远期目

10、标实现“统一治理、集中监控、集中运维的现代化运维治理模式,以流程贯穿运维治理过程,建成面向应用、面向市场的 BSS运维治理平台；同时通过总部与省两级运维治理平台的协同工作,实现系统的科学治理和规划,从而全面提升中国联通业务支撑网的效劳质量.具体包括：实现事件的集中统一治理；实现对运维治理中变更过程的有效限制和治理；实现对运维治理中配置过程的有效限制和治理；实现问题治理,减少和预防同类事件的再次发生；通过对应用软件流程的监控,实现对业务运行质量的分析和保证,实现业务运行质量的有机治理；通过对各种运行的状态数据和资源配置数据的分析,为系统平安稳定运行提供合理的优 化建议方案；完善工作流程,提升系统

11、运行维护的质量和维护人员治理的科学化.2.1.3 建设规划BSS运维治理平台应分步实施,逐步完善.分步实施如下列图所示：图2.1 BSS运维治理平台建设规划图2.2 建设原那么BSS运维治理平台的建设原那么包括：集成性：通过统一的治理平台集成系统平台和应用平台的治理；先进性：基于先进的IT治理理念和治理流程,采用成熟、先进的治理平台,适应技术的开展方向；实用性：根据用户需要进行成功的客户化定制,满足实际治理需要,真正解放治理人员的日常维护工作；标准性：接口的标准化和标准化原那么,建立全国统一的KPI ,运维治理流程标准化;开放性：系统应遵循行业的标准或建议,采用标准的、开放性的技术；扩充性：既

12、要充分考虑到未来技术的开展变化又要考虑到将来运维治理的新需求;平安性：系统本身要提供较高的平安性；兼容性：能同第三方的治理软件以及原有网管软件集成,充分保护原有投资.3 .系统总体结构3.1 系统定位以及与现有网管系统之间的关系3.1.1 系统定位本系统的治理对象是以业务支持系统BSS为核心,包括采集、计费、结算、营业、帐务等子系统,实现对业务子系统的统一治理、集中监控和集中运维.3.1.2 与现有网管系统之间的关系本系统与已经建设的网管和网络平安系统的关系是互为补充,而不是互为替代.原网管系统在建设过程中所购置的网管软件和在其上实现的系统监控,可与现有各业务系统的分散的应 用监控相结合,在充

13、分利用原有投资和资源的根底上,完善功能,综合利用系统平台和应用系 统的监控信息,形成运维治理平台的重要组成局部：系统监控局部,以便统一展现支撑平台和业务系统的运行状况,统一监控和维护各种告警、配置、性能数据.同时,为了强化对运行维护人员、流程和信息的治理,预防由于人员的疏忽和信息的混乱所造成的系统运行和效劳质量问题,在ITIL理论的指导下,结合联通业务支撑系统运行维护管理规程和各省分公司的实际情况,建设该系统的另外一个重要组成局部：以流程治理和资源配置信息治理为核心的 效劳支持局部,从而进一步梳理、优化运维流程,建立监控手段与运维人员 之间的有机联系,初步建立人员绩效考核机制,实现突发事件的快

14、速解决和业务迅速恢复,并尽可 能消除或减少突发事件的发生,实现系统的逐步优化,提升现有系统的稳定性.图3.1与现有网管系统之间的关系图如下图,网管与网络平安系统主要包括综合信息传输平台、网管、网络平安三局部内容的建设,同时为实现上述功能需要对信息系统部现有各系统进行优化和改造.一方面,网管与网安系统中的网管功能可纳入运维治理平台中的系统监控局部,另一方面,网管与网安系统的综合传输平 台和网安局部可作为运维治理平台中系统监控局部的被监管对象进行治理.此外,系统监控局部和效劳支持局部之间可通过自动或人工的方式进行事件和配置信息的交互,从而实现这两局部的功能及信息内容可以在展示层面进行整合,在数据层

15、面进行综合分析,为系统平安稳定运行提供更 加合理、高效的治理手段和方案.3.2 系统组织结构系统组织结构如下列图所示:图3.2 BSS运维治理平台组织结构图中国联通业务支持系统运维治理平台分为两级结构,第一级为总部运维治理平台；第二级为 总部计费、结算中央运维治理平台和各省、自治区、直辖市运维治理平台.第一级总部运维治理平台主要功能为负责对中国联通各省业务支撑系统的运行状况的监督管 理；掌握各省的资源配置信息及各资源的性能信息,为系统的升级改造提供依据；对省公司上报的 重大故障和总部市场部、客户部等部门的投诉进行治理,并监督和协调省公司的处理；采集各省公 司业务系统考核指标,并对省公司进行考核

16、；建立总部与省公司运维治理信息的上传和下达通道, 使总部的相关通知信息等能及时下达,省公司上传的重大故障和变更、运维统计报表数据等能及时 上传；统计各省分公司的相关运维治理信息,掌握全国业务支撑系统的运行状况.第二级省运维治理平台负责对相应省各业务支撑系统具体的治理,包括各业务支撑系统中的 应用软件、主机设备、网络设备、存储设备、备份设备、数据库、中间件等,保证各系统稳定可靠 地运行,并按总部要求上报相应的数据.3.3 系统体系结构BSS运维治理平台体系结构如下列图所示:值班人员运维人员治理人员A 一 级运行维护治理平台系统管理统一接入和展现监控.数据.治理 数据 -系统 数据一文档 数据|-

17、>数据采集自动/人工接入展现层功能层数据层其他系统平台类数据源应用类数据源其他数据源主机网络存储中间件数据库UNI-CRM ERP MSS平安机房环境工档等数据源二级运行维护治理平台图3.3 BSS运维治理平台体系结构图运维治理平台体系结构可分为三个层次：数据层、功能层、接入展现层.3.3.1数据层3.3.1.1监控数据监控数据来自系统平网络、主机、存储、数据库、中间件等、应用平台采集、计费、 营业、帐务、结算等、业务支撑系统平安系统主机系统平安、网络平安以及机房环境等.通 过各类采集手段或接口实现对监控数据的采集,通过系统监控的各个功能组件实现对监控数据的处 理和分析,通过统一的接入展

18、现层实现对监控数据的展现,监控数据从内容角度又可以分为告警数 据、性能数据和配置处理数据等,监控数据从时间维度可以分为当前数据和历史数据.3.3.1.2 治理数据治理数据主要是为实际治理需要定义或录入的数据,其数据主要通过手工录入获得,内容包 括工单、供给商情况,也包括流程配置、告警严重级别、告警过滤规那么、相关性模型、告警升级规 那么、告警传递规那么、性能门限配置、配置数据静态信息设备编号、地理位置等、值班/排班定义、设备/人员优先级别、效劳水平定义、紧急程度定义等,同时治理数据还包括各种与监控数据相关的 维度数据,如银行编码与名称对照表、营业厅名称等等.治理数据同时包含系统中的各种过程数据

19、,如事件治理和问题治理中从受理到结束的每一步 处理过程,变更过程中的变更方案书、变更授权书、变更评估报告、变更实施报告、变更验证报 告等也都归类于治理数据.3.3.1.3 系统数据系统数据主要是由运维治理平台自身运行所需要或使用的数据构成,主要包括组织机构、人 员信息登录信息、联系方式、权限状况、角色定义、日志文件、字典表数据和规那么数据,包括 系统自身运行日志、历史数据保存规那么、不同时间粒度报表定时生成规那么、设备厂家/型号对照表等、数据采集任务定义等.3.3.1.4 文档数据文档数据主要是以附件等形式存放的文件数据,主要包括规章制度、设计文档、培训文档、 实施方案等,同时也包括知识库中的

20、知识数据、供给商治理中的合同信息、配置治理中的文件形式 的配置数据,在流程治理以附件形式派发的公文信息等.3.3.2功能层运维治理平台的功能层主要由两大局部构成,即系统监控和效劳支持.（1） .系统监控系统监控的治理对象是 UNI-CRM 系统中的所有系统平台设备网络、主机、数据库、中间件、存储藏份设备等和业务应用系统主要指采集、计费、营业、帐务、结算等.系统监控的监控内容主要是业务支撑系统的平台类和应用类KPI指标具体指标参见附件,通过接收或采集数据层生成的指标数据或原始数据,并对这些指标进行统一的存储、处理与分析,将处理结果转发至效劳支持局部或直接上传接入展现层.系统监控的功能组成主要包括

21、四个局部：监控台：用于统一展现系统平台和业务应用系统的运行状况,统一配置和维护系统监控的各种展现数据和治理规那么；告警治理：用于统一接收、采集系统中发生的各种异常情况,并通过对这些信息统一处理标准化、压制、合并、过滤、故障源定位等实现“全面监控、准确告警、及时通知、快速解决的目的,告警治理在保证告警信息准确性的条件下,可通过各种外部接口邮件、短信、语音通知指定维护人员,对于较严重的、需要维护人员人工解决的告警信息,应通过效劳支持局部自动生成工单,进入闭环处理流程,对于重大告警信息,应通过相应接口及时通报 总部,告警治理是系统监控最核心的局部；性能治理：用于统一存储、处理、分析各类性能指标,实现

22、对性能指标异常变化情况的及时告警、通过对历史性能数据的统计分析为业务系统运行趋势变化分析和系统扩容、优化提供量化依据,性能治理局部是系统监控内容最丰富的局部；配置处理：用于统一存储、处理、分析各类配置指标,在发生配置 数据异常变化时能够生成告警信息,并提供对配置数据的统计、分 析和查询,配置处理是系统监控的数据根底.（2） .效劳支持效劳支持的使用者主要是信息系统部的各类人员,包括值班人员、维护人员、治理人员等；效劳支持的治理内容主要是依据ITIL理论,根据总部发布的运行维护规程和各省运维组织机构和人员组成情况,结合实际运维状况,梳理、优化运维流程,实现运维工作的流程化、标准化、电子化和自动化

23、,建立监控手段与运维人员之间的有机联系,初步建立人员绩效考核机制；效劳支持的功能组成主要包括8个局部效劳台：为流程的起点和终点,是信息系统部为部门内部和其它部 门提供的统一效劳窗口,统一受理事件、中告、投诉和告警；事件治理：对于突发事件的流程化处理,事件来源包括系统监控中 的告警治理模块以及 、 、手工生成等,事件治理的核心是 注重突发事件的快速解决和业务迅速恢复；问题治理：寻求故障根源,解决存在或多发问题的流程, 问题治理 的核心是注重消除或减少事件的发生, 实现系统的逐步优化,提升 现有系统的稳定性； 变更治理：对变更请求进行记录、跟踪与治理的流程, 消除或减少变更对生产系统的影响和风险,

24、保证变更的顺利完成；配置治理：治理各配置、资源、资产数据的流程,包括定义和维护 配置数据相互间的关联与依赖关系；日常运维治理：包括机房值班、排班、交接班、作业方案、日志等 内容,主要目的是强化日常运维工作的标准性, 为各种运维制度提 供有效的落实手段；供给商治理：对业务支撑系统集成商、软件供给商的相关资料、与 联通签订的效劳合同等信息进行治理维护,并对各集成商、软件供 应商的产品质量、效劳情况进行评分治理,并将评分定期上报总部, 使省公司及总部及时、全面地了解供给商的阶段性效劳状况；知识库治理：通过对知识库系统维护和使用,不仅可以在故障自动 处理和人工处理的过程中在知识库中得到相关故障维护的分

25、类和快速定位,找到匹配的处理案例, 便于处理人进行借鉴,而且知识 库具有的业务帮助功能,使相关人员可以通过关键字查询业务帮 助、产品、市场活动、发生过的处理流程、电子文档等.3.3.3接入展现层接入展现层是运维治理平台提供给值班人员,运维人员和治理人员的统一入口.实现运维管理平台的功能及信息内容在展示层面进行整合,并针对不同角色的使用者提供与角色关联的个性化的展示内容.同时提供对多种设备和接入方式的支持.3.4与外部系统之间的关系运维治理平台与外部系统之间的关系如下列图所示：一级运维治理平台值班人员运维人员治理人员通 知 业务信息 考核结果配 置重大故障 重大变更其他系统图3.4 BSS运维治

26、理平台与外部系统关系示意图对于目前建有网管系统的省分公司,现有网管系统将来应融入到运维治理平台中.运维治理 平台可从现有网管系统专业网管或应用网管等中获得主机、网络、数据库、中间件、业务应用 系统等网管信息.运维治理平台从业务应用系统、系统平台、机房环境及平安系统中获得的主要数据内容为： 配置数据、性能数据、告警数据等.二级运维治理平台向一级运维治理平台提供的主要数据为：配置数据、重大故障数据、重 大变更数据、性能数据和相关的统计报表等.运维治理平台预留有与其他系统的接口,例如MSS可以从运维治理平台中获得运维相关的信息,如运维治理平台的考核结果通过MSS系统进行发布,另外运维治理平台可以接收

27、MSS系统的有关运维治理的通知等.运维治理平台的用户包括值班人员、运维人员、治理人员.进一步运维治理平台通过运维人 员等受理其他部门如市场部、客服部等对业务支撑系统运行情况的咨询、用户投诉、变更请求等, 并反应处理结果,为其他部门提供效劳.4.业务功能与流程4.1 各模块之间的关系各模块之间的关系如下列图所示:图4.1 BSS运维治理平台功能模块关系图4.2 岗位与角色描述4.2.1 岗位描述岗位组织结构如下所示:图4.2岗位组织结构图其中运维部门治理负责人、技术业务治理负责人、技术工程师、业务工程师、值班人员的岗 位定义、责任详见?中国联通企业信息化 UNI-IT 系统运行维护治理规程?.其

28、中：上级主管总部：总部的运维治理负责人,负责批示省分公司运维过程的重大故障、重大变更等问题；值班经理：协调组织值班人员进行日常运维值班任务,通常由技术工程师或业务工程师担任；效劳供给商：作为中国联通的外协单位,负责协助、完成系统的运行维护,可包括原厂商、集成商、效劳商.4.2.2 角色描述运维治理平台涉及的角色为：效劳台：是一种治理职能,通过效劳台角色在不同流程中的功能表达其职能,同时 担任分类、升级、跟踪、协调、一线支持职能,效劳台角色由值班人员、值班经理 担任；二线支持：经过效劳台初步支持不能解决的事件、问题,由二线支持角色处理,二线支持由技术或业务工程师担任；三线支持：经过二线支持不能解

29、决的事件、问题,由三线支持解决完成,三线支持由联通方的专家和效劳供给商的技术专家担任；治理人员：与运维部门治理负责人完全对应；问题治理员：在问题治理流程中负责事件的分析、问题的起草、提交审批、问题总结的人员,由业务或技术工程师担任；问题解决方：负责问题的调查分析、提出问题的解决方案、问题的处理,由技术和业务工程师、效劳供给商的相关技术人员担任；变更治理员：在变更治理流程中负责起草变更请求、分类/分级、编写变更方案,由技术和业务工程师担任；变更参谋组：负责评估变更请求的必要性以及方案的合理性,由技术业务治理负责人、专家、效劳供给商组合担任；变更实施方：负责变更过程的组织、实施,包括变更的构建、测

30、试、发布、恢复等职能,由技术和业务工程师、效劳供给商共同担任;配置治理员：配置治理中负责配置信息的录入、核实、归档,由技术和业务工程师担任.角色与岗位的关系如表：角色岗位效劳台值班人员值班经理二线支持技术业务治理负责人技术工程师业务工程师三线支持联通方的专家效劳提供商治理人员运维部门治理负责人问题治理员技术业务治理负责人技术工程师业务工程师问题解决方技术业务治理负责人技术工程师业务工程师效劳提供商变更治理员技术业务治理负责人技术工程师业务工程师变更参谋组技术业务治理负责人联通方专家效劳提供商变更实施方技术工程师业务工程师效劳提供商配置治理员技术工程师业务工程师上级主管上级主管4.3 业务功能描

31、述4.3.1 效劳支持4.3.1.1 效劳台4.3.1.1.1 定义效劳台是一个综合接口平台,统一接收来自于综合电信业务支撑系统各业务子系统及其他途 径的各种效劳请求信息(告警、投诉等),提供必要的初始支持,并根据需要启动相应的效劳流程、 并对效劳流程跟踪监督,同时向效劳请求方反应效劳结果信息.4.3.1.1.2 功能治理、协调并尽快解决各类事件,允许各类事件流程能够集成到效劳治理根底架构之中.不 仅能处理故障、投诉和疑问,还可提供与其他过程的接口.效劳台接口效劳初始效劳提供效劳流程启动效劳流程监控效劳结果反应接口效劳模块提供统一接收各种事件、故障、投诉等效劳请求的信息流逻辑接口;响应、确认、

32、核实、记录和维护各种效劳请求信息；提供效劳支持治理的统一接口；提供效劳处理结果反应的统一接口.(2) 初始效劳提供：对于一些能够直接处理而不必启动效劳流程的效劳请求,由效劳台提供必要的初始效劳支持.(3) 效劳流程启动：对于通过初始效劳支持无法解决的效劳请求,效劳台记录并判断确定服务类别和级别,并启动相应的效劳流程.(4) 效劳流程监控：跟踪、治理、协调流程处理过程,调整事件优先级,检查流程的处理进度.(5) 效劳反应：在效劳过程中,保持与效劳提出者的联系,及时通知效劳进展；在效劳结束后,告知提出者处理结果.4.3.1.1 .琬程及业务规那么效劳台负责记录事件相关信息,向用户提供对问题的处理方

33、法,报告事件并启动相关服务流程,到达尽可能快速、有效地解决问题的目的.效劳台接收的事件信息：系统获得的故障告警、性能告警、配置告警等告警信息；从其它系统获得的事件信息,如客服系统的投诉信息等；人为事件,包括从 、 、邮件等途径获得的事件信息,以及其他人工录入事件；其他事件.如果效劳台不能解决这个事件,应当启动维护流程,将事件分配给最适宜的效劳支持小组/人员来处理,并进行如下工作：记录相应事件；判定效劳类别；判定事件优先级(各省分公司根据自己的实际情况,制定可操作的、量化的优先级判定的标准)；检查事件记录的处理进度,根据需要调整事件优先级；保持与事件报告者的联系,及时通知事件处理进展； 最后关闭

34、事件4.3.1.1.4f其他模块之间的关系与系统监控功能模块接口 ：从告警治理接收待处理监控事件信息,返回处理结果.与事件治理模块接口：记录、发起、并监控效劳过程.4.3.1.2 事件治理4.3.1.2.1 定义事件治理是对监控治理产生的事件以及人工发起的事件处理请求进行治理的功能模块.事件包含告警事件、投诉事件、请求事件.事件可以来源于系统平台、应用平台、机房环境、系统平安等的告警,也可来自外部的投诉、请求等.根据其对效劳的影响程度,事件可分为：一般事件和故障事件两大类.在上述事件中,凡开通运行的系统、设备和设施,在承当业务期间,造成质量降低至用户无法使用,均定为故障.故障的分级：按影响范围

35、、持续时间和性质严重程度,将故障分为重大故障、严重故障和一般故障.4.3.1.2.2 功能事件记录：从效劳台获取事件信息后,记录入系统中；事件判定：根据事件和故障的现象以及产生原因确定其类别、对业务的影响程度、紧急度和优先级,并指定事件和故障的解决时限；事件处理：包含对事件的原因和解决方法的分析、故障的解决以及效劳业务的恢复,同时包括事件处理的流程治理、事件的升级和根据规那么向不同级别的上级报告；分析判断：通过与相关效劳、技术支持人员共同研究分析发现事件发生的原因,或查找以前是否发生过同类突发事件, 是否有处理方法；上报：发生严重故障和重大故障时,维护部门直接向省分信息系统部和运行监督部报告；

36、对于重大故障,要上报联通总部信息系统部和运行监督部；解决和业务恢复：利用找到的处理方法解决问题,恢复业务.对于紧急级的事件,在事件治理过程中直接执行紧急变更治理过程,不再向“变更治理提交工单；事件、故障升级：对于系统中持续出现以及超过规定处理时间仍未解决的事件和故障,需要升级该事件级别,以保证得到优先、及时的处理.当事件处理超过预期时限,根据预定义的升级条件,将该事件自动/手工升级到更高级别,并通知到指定级别的治理人员.处理跟踪：跟踪事件和故障处理过程和时限,升级和催促突发事件,随时通知用户处理进展；事件完结：事件处理完成后,要将结果记录入系统并将处理结果反应给事件发起方；统计查询：提供灵活的

37、统计和查询功能,方便对事件的处理状况、处理结果进行查询,并提供统计和汇总报表功能.4.3.1.2.琬程及业务规那么事件治理的处理流程如下列图所示:业务规那么：上报总部：对重大故障,分别由省分信息系统部和运行监督部上报至总部信息系统部和运行监督部；升级规那么：对超过处理时限的事件,根据超出的时限,系统自动升级到相应级别,并根据事件级别定义,系统流程自动将消息通知对相应级别的治理人员4.3.1.2.4f其他模块之间的关系通过配置治理取得相关资源和配置数据,并将处理过程中对配置的修改提交给配置 治理；根据对事件、故障原因的分析,根据需要产生变更请求并进入变更治理；将典型的事件处理过程和结果提供给知识

38、库.4.3.1.3问题治理4.3.1.3.1 定义问题治理是通过识别问题的真正的潜在原因,限制运维中的故障的过程.问题治理采取积极主动的方法,通过对已发生的问题进行分析,提出解决方案并尽早采取防御举措,预防同类事件或故障的再次发生.问题指已经发生、并且重复屡次的事件或重大故障所蕴含的尚未查明的、真正的潜在原因.问题来源于事件、故障治理流程中的非突发事件或屡次重复发生的事件信息的总结和分析.4.3.1.3.2 功能问题治理是问题的提出、分析、解决的治理过程,并提供问题解决方法的记录以及问题的统 计分析和查询功能.问题提交：从对事件的分析中,对于未探明原因的严重事件或对屡次重复发生的事件提出问题报

39、告,以待对问题的根源进行分析和解决方法的提出；问题分析研究：对提交的问题安排相关的技术专家、维护人员和业务治理人员进行研究分析,给出问题的解决方案,并将初步的分析结果和对应的解决方案记录系统;问题处理：根据对问题的分析得出的解决方案,产生相应的变更工单,交变更治理过程进行处理.问题完结：对解决方案的处理结果进行记录并进行评估、总结；统计查询：提供对问题的处理过程、处理结果的灵活查询功能以及统计报表功能.4.3.1.3 .琬程及业务规那么问题治理的业务流程：问题提出、分类；问题分析：由相关专家和治理人员通过会议、研究等方式分析问题原因和提出解决方案；问题解决：根据解决方案产生变更工单,进行变更处

40、理；处理结果的记录和总结：记录问题的处理过程和最终结果,并对问题的处理结果进 行回忆评价,如果未解决问题,再进行相应的分析和处理.4.3.1.4 .4f其他模块之间的关系与事件治理/故障治理的关系：对一般事件和故障事件的分析总结是问题治理的数据源.与变更治理的关系：在处理、解决问题的过程中,可能需要对系统配置、软件版本进行修改升级.因此,问题治理可以派生出变更流程.与知识库治理的关系：问题治理过程积累的问题的典型处理方法为知识库治理提供数据源.4.3.1.4变更治理4.3.1.4.1 定义变更是指针对被治理系统中某对象及其配置所进行的修改,大到整个业务支撑系统的升级改造,小到某设备参数的细微调

41、整.为了预防和减少变更所造成新的系统问题和故障隐患,对系统变更过程需要标准化治理,包含提出变更方案及申请、申请评估、审批、授权、实施、验证等流程.变更治理是指对这些流程的标准化治理,以保证使用标准的方法和过程实现快速、有效的变更,保证变更过程的可控性、可治理性和有序性,减少变更带来的突发事件,促进日常工作的正常进行.4.3.1.4.2 功能变更治理需要包含如下功能和主要环节：变更治理变更终止变更实施变更评估变更请求变更请求：由系统或者业务人员填写变更单,提出变更请求.填写内容包括变更 提出人姓名、变更原因、变更对象以及变更实施方案、实施时间等具体要求.变更评估：由变更评估小组对变更申请方案及对

42、系统的影响进行评估.变更评估 对于将对系统产生重大影响的变更如系统升级,是非常必要和重要的；对于 影响较小的变更可根据具体情况简化评估流程或直接提交审批.变更评估过程 中,评估未通过的申请,会出现两种结果：一种是评估小组并未否认变更请求, 而是对变更提出了其他意见,申请人根据意见重新填写申请,再次提交；一种是 评估小组否认了变更的请求,变更终止.变更审批：负责人对通过评估的申请进行审批.如审批通过,那么进入变更授权流 程,否那么,进入变更终止.变更授权：负责人指定相应部门及人员负责变更的实施.变更实施：可以根据变更对工程的影响程度定义实施流程.对于有重大影响的变 更,实施过程将包括变更的准备、

43、变更前试验、变更实施、变更测试、验证等. 此外,还需要制定完善的测试恢复方案,以保证在实施过程中,出现意外或实施 结果不符合期望时,根据恢复方案进行系统恢复,减少变更对效劳质量的影响. 变更实施完成后,将通知申请人.变更终止：变更终止分成两种情况,一种是变更实施成功完成,变更工作结束, 对变更进行评价；一种在变更过程中,由于各种情况变更撤销.对于变更撤销,要求记录变更撤销原因4.3.1.4.琬程及业务规那么变更治理的业务流程如下列图所示：变更治理流程运维人员变更治理员业务负责人/技术负责人变更参谋组运维人员/效劳提供商变更实施方治理人员上级主管总部开始1变更请求,分类/分级1变更方案评估过程变

44、更评估必要性问题治理 子流程配置治理子流程是实施过程系统恢复上报接口 子系统业务规那么:任何涉及对主机、网络设备配置、系统软件、应用软件、相关文档的修改都应该通 过变更治理标准和记录；变更流程对配置和设备的修改都应该更新配置记录；涉及单台设备、非核心系统非核心网络设备、效劳器和应用的配置修改为简单变更,可以省略审批过程,但必须启动变更流程并更新配置记录；非紧急变更需要根据具体的业务要求由相关人员变更经理或变更参谋团审批.4.3.1.4.4f其他模块之间的关系与事件及问题治理的关系：在处理、解决系统故障和问题的过程中,经常需要对其 配置、版本进行修改.因此,事件治理和问题产生变更请求.与日常运维

45、治理的关系：在日常运维治理工作过程中也需要修改系统的参数和配置,也需要启动变更流程.与配置治理的关系：变更的结果导致设备和/或配置的变化,变化的结果需要在配置治理中表达.因此,变更治理导致配置记录项的变更.与知识库的关系：变更治理积累的经验和对典型变更过程的评价分析,都可以作为 知识库的内容供其他相似案例参考.4.3.1.5配置治理4.3.1.5.1 定义配置治理是指识别和确认IT系统配置项,记录和报告配置项状态和变更历史,检验配置项的正确性和完整性等活动构成的效劳治理流程.配置项是指IT系统的组件或IT系统提供效劳的相关的配置信息如主机的设备型号、CPU/内存配置、硬盘配置、网络接口卡配置以

46、及IP地址、端口、性能配置参数等.配置治理的目的是治理并及时提供准确可靠的IT系统根底架构硬件、软件资源、机房内资源等的配置信息.通过对配置信息当前情况的了解,指导系统的升级、改造.系统应提供配置数据的自动和手工输入并进行合法性等检查,对历史数据进行治理.4.3.1.5.2 功能配置治理的功能结构如下列图所示:配置治理配置项设置：是“配置项定义的工具,通过它实现配置项列表的定义和调整,并 定义配置项的层次颗粒度和关系以及数据获取方式；配置项采集：获取资源配置项的完整属性信息,采集方式包含“自动采集和“手 工采集两种方式,其中“自动采集局部由系统监控中的“配置处理来完成, 并通过“系统监控和“效

47、劳支持的接口完成数据的传递；配置项治理：实现对资源配置项的编辑、修改、调整和变更历史记录；配置信息查询：提供对配置信息的多途径和目的的查询；统计分析：实现对配置信息、变更信息按主题和目的进行统计汇总和分析.4.3.1.5.琬程及业务规那么配置项采集流程：自动、手工获取配置信息或配置信息变更；比照当前配置项信息：新增项：增加新记录；变更项：产生变更历史记录；变更审核,确认配置项变更；信息更新.流程图如下：4.3.1.5.4f其他模块之间的关系配置治理为各功能模块提供系统的配置信息；系统监控中的“配置处理自动获取的配置信息和配置变更信息,是配置治理的信 息来源.配置处理与配置治理保持配置数据的一致

48、.事件治理、变更治理产生配置项的变动,变更结果记入配置治理数据库.4.3.1.6日常运维治理4.3.1.6.1 定义日常运维治理是对日常运维活动的治理,包括值班与交接班治理、作业方案治理、系统与设 备巡检和运维考核治理等日常运维治理活动.4.3.1.6.2 功能日常运维治理目前包括值班与交接班治理、作业方案治理、系统和设备巡检等功能.根据运 维治理的工作的实际需要,可以根据省分公司工作的需要,增加必要的功能模块.日常运维治理值班与交接班治理运维考核治理(1)值班与交接班治理值班治理：根据运维规程,值班人员执行系统、设备运行状况巡视,记录和处理系统异常状况和故障.值班治理的功能包括：值班人员排班

49、治理、上岗、离岗的签到、签离,值班日志记录等； 交接班治理：交接班是现值班人员和接班人员的工作交接过程,包含交接班日志填 写,接班人员的签收等功能.(2)作业方案治理维护作业方案包含拟定,审批,执行和检查等四个功能环节；系统提供不同作业方案的流程配置功能；提供作业方案的查询、跟踪、统计功能.(3)系统与设备巡检巡检记录：记录巡检的详细内容；信息查询：对历史巡检数据进行查询.(4)运维考核治理考核指标定义：定义运维考核的指标集以及评分标准；考核评分：定期或现场对考核项进行评分,并记录考核结果；报表定制：灵活定制、生成考核的报表.4.3.1.6. 琬程及业务规那么各省根据运维规程和实际运维情况制定

50、适合本地的日常运维流程及业务规那么.4.3.1.7. *其他模块之间的关系与事件治理的关系：值班治理中对系统、设备巡视中发现的异常问题和故障是事件治理 的信息源之一.4.3.1.8. 应商治理4.3.1.8.1 定义对业务支撑系统集成商、软件供给商的相关资料和效劳质量效劳水平、以及与联通签订的服务合同等信息进行治理维护.对各集成商、软件供给商的产品质量、效劳情况进行评分治理,将评分定期上报总部.使省分公司及总部及时、全面地了解供给商的阶段效劳状况.4.3.1.8.2 功能供给商治理的功能结构图如下列图所示：供给商治理供给商资料治理效劳合同治理供给商考评统计分析汇总供给商资料治理：对供给商的公司

51、信息,法人信息、联系人、产品等资料进行记录、 维护治理,便于进行供给商相关信息查询；供给商效劳合同治理：对供给商的效劳合同、效劳内容等内容进行归类、维护,并提供例如合同到期、工程验收等提醒、通知功能；供给商评分治理：供给商治理是对其提供效劳的一个综合评价,如供给商提供效劳 的水平,响应速度等,方便联通对供给商效劳质量进行排名；统计分析汇总：对治理的供给商的信息和效劳进行统计、汇总和报表定制功能.同 时实现供给商的效劳水平、水平的比照分析.4.3.1.7 .琬程及业务规那么供给商评分流程：设置供给商评分指标；指标的增减；指标权重的设定、修改.采集供给商评分指标数据；根据指标数据及其权重进行计算,

52、得到评定分数； 对评定分数进行汇总、累加,得到最终评分.4.3.1.8 .4f其它模块之间的关系与总部的接口：向总部提供供给商考核评分数据.4.3.1.8知识库治理4.3.1.8.1 定义通过对知识库系统维护和使用,不仅可以在故障自动处理和人工处理的过程中在知识库中得 到相关故障维护的分类和快速定位,找到匹配的处理案例,便于处理人进行借鉴,而且知识库具有 的业务帮助功能,使相关人员可以通过关键字查询业务帮助、产品、市场活动、 发生过的处理流程、电子文档等.知识库治理系统也包括对相关文档(如系统业务需求书、方案建议书、设计文档等)的治理.知识库治理系统还提供相关业务与治理人员交流的“主题论坛,交

53、流在相关专业领域的经 验教训,推进运维业务的知识治理.4.3.1.8.2 功能知识库治理的功能结构图如下列图所示：(1)知识库功能知识的输入：系统提供人工和自动的方式进行知识库的添加,对输入的知识库信息 审核(是否是重复的知识库信息等).分类目录：提供目录导航功能,使检索人员可以方便直观的检索信息.目录结构的设计是运维业务治理知识的高度总结.查询、检索功能：系统提供完善的查询和全文检索功能,例如：知识列表、关键字查询等.提供日常查询界面,供运维人员获取、学习.知识库接口：为其他功能模块提供主题相关的访问入口.(2)文档功能在IT系统的运行维护中,产生大量的文档,包括：规章制度；工程设计文档；工程实施文档；培训文档；从其他功能中归档的文档；厂商提供的文档产品、版本、配置、技术方案等；其他.文档治理提供对上述文档资料的治理,提供：文档浏览、添加、更新、检索、版本治理等功 能.3 主题讨论“主题讨论提供按不同主题区进行讨论的论坛功能,比方按主机、数据库、中间件、计费、 营帐、结算等进行分类.“主题讨论的功能包括：论坛灵活创立；用户治理；论坛治理删除、归类；访问量显示热点；评价；知识库归档；其他.4.3.1.8.琬程及业务规那么提供支持人员提交经验和知识的输入接口或界面；具有不