2022年中国联通BSS运行维护管理平台业务技术规范讨论稿.doc

中国联通业务支持系统（BSS）运转维护治理平台业务技术标准（讨论稿）中国联通2004年6月目 录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 系统组织构造73.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 变更治理274.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 技术要求535.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 接口要求636.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 接口定义726.5.5.2 接口实现736.5.6 上传统计报表736.5.6.1 接口定义736.5.6.2 接口实现746.6 与其他系统的接口746.6.1 接口定义746.6.2 接口实现741. 总体概述1.1 行业背景当今通讯市场正由传统的以通讯网为中心的效劳质量的竞争转变成以客户为中心的效劳质量的竞争，中国联通为了习惯市场竞争的变化，必须建立以客户效劳为中心的效劳机制。综合电信业务支撑系统在中国联通公司的整体运营中起着至关重要的支撑作用，因而在监控业务支撑系统硬件和系统软件的根底上还应对各业务应用系统进展监控，通过对各业务应用系统的整个处理流程进展监控，掌握各业务系统的运转情况。同时，运维治理应逐步实现从被动效劳到主动发觉系统中存在的征询题，变被动为主动，以流程贯穿整个运维治理过程；减少运维人员的劳动强度，提高效率，实在保障各业务支撑系统可靠、稳定、高效地运转，进一步提高用户的满意度和忠诚度，全面提升中国联通的效劳质量。1.2 系统现状分析中国联通公司是目前国内电信业务最多的综合性电信业务运营商，运营着GSM、CDMA、市话、互联网等业务。在中国联通的统一规划和领导下，建立了各省综合电信业务支撑系统。综合电信业务支撑系统是一个包括众多子系统的复杂系统，需要对各业务子系统的硬件及软件平台进展治理，保障各业务子系统的正常运转。而各业务子系统在建立过程中有的考虑了网管监控有的没有考虑，后来进展了网管与网络平安工程的建立实现对各业务子系统的治理，因而在系统中可能存在多个网管工具，对不同的系统维护需要到不同的治理平台上进展处理，大多数只能对硬件平台（网络、主机等）和系统软件（数据库、中间件等）进展监控，不能对各业务子系统进展监控（或者只能监控到应用系统是否在运转状态下而不能监控其运转效率）。同时各省缺乏对业务子系统处理流程的监控，监控手段和效率较低，因而需要在原有网管系统的根底上进展完善，引进先进的IT治理方法和手段，提高整体运维水平。1.3 编制目的中国联通制定本业务支持系统运转维护治理平台（以下简称BSS运维治理平台）业务技术标准，主要用来标准指导中国联通各省分公司运转维护治理平台的建立。1.4 适用范围本业务技术标准是中国联通业务支持系统运转维护治理平台规划与建立的根本依照。中国联通各省分公司应按照本业务技术标准，结合本地实际情况进展规划和建立本省BSS运维治理平台。1.5 起草单位本业务技术标准的起草单位为中国联通，由中国联通计费、结算与信息系统部进展治理。1.6 解释权本业务技术标准的解释权属于中国联通计费、结算与信息系统部。1.7 参考文献UNI-IT体系架构指南；中国联通网管及网络平安系统总体方案；中国联通企业信息化（UNI-IT）系统运转维护规程（试行）。2. 建立目的及原则2.1 建立目的BSS运维治理平台应整合目前的系统，逐步实现对“网元级、资源级、应用级”和系统平安等维护治理。同时，结合各省分公司的实际治理情况，由对业务子系统的治理延伸到对人员的治理，逐步实现以流程贯穿整个治理过程，进而实现对业务支持系统“统一治理、集中监控、集中运维”。2.1.1 近期目的近期完成BSS运维治理的根本功能，实现对业务子系统（采集、计费、营业、帐务、结算系统等）系统平台和应用软件的运转情况监控以及日常运维治理（如作业计划等），保障业务支撑网的正常运转。n 在统一平台上实现对系统运转状态的集中治理（主要包含主机设备、网络设备、存储设备、备份设备、数据库、中间件、应用软件等），保障业务支撑网的正常运转；n 实现对业务子系统应用软件关键点的监视和保障，确保系统的运转质量；n 通过对业务子系统中各类告警信息的分析，进展毛病的快速定位和告警功能；n 建立日常运维工作流程，实现对日常运维活动的治理，从而实现对维护人员工作的监控和量化；n 建立运维治理知识库系统，实现知识交流与共享；n 实现供给商的有效治理；n 掌握业务子系统的资源配置信息；n 实现省公司和总部之间通过运维治理平台上传下达规定的考核指标、运维报表、严重毛病/变更等。2.1.2 远期目的实现“统一治理、集中监控、集中运维”的现代化运维治理方式，以流程贯穿运维治理过程，建成面向应用、面向市场的BSS运维治理平台；同时通过总部与省两级运维治理平台的协同工作，实现系统的科学治理和规划，从而全面提升中国联通业务支撑网的效劳质量。详细包括：n 实现事件的集中统一治理；n 实现对运维治理中变更过程的有效操纵和治理；n 实现对运维治理中配置过程的有效操纵和治理；n 实现征询题治理，减少和防止同类事件的再次发生；n 通过对应用软件流程的监控，实现对业务运转质量的分析和保障，实现业务运转质量的有机治理；n 通过对各种运转的状态数据和资源配置数据的分析，为系统平安稳定运转提供合理的优化建议方案；n 完善工作流程，提高系统运转维护的质量和维护人员治理的科学化。2.1.3 建立规划BSS运维治理平台应分步施行，逐步完善。分步施行如下列图所示：图2.1 BSS运维治理平台建立规划图2.2 建立原则BSS运维治理平台的建立原则包括：n 集成性：通过统一的治理平台集成系统平台和应用平台的治理；n 先进性：基于先进的IT治理理念和治理流程，采纳成熟、先进的治理平台，习惯技术的开展方向；n 有用性：依照用户需要进展成功的客户化定制，满足实际治理需要，真正解放治理人员的日常维护工作；n 标准性：接口的标准化和标准化原则，建立全国统一的KPI，运维治理流程标准化；n 开放性：系统应遵照行业的标准或建议，采纳标准的、开放性的技术；n 扩大性：既要充分考虑到今后技术的开展变化又要考虑到今后运维治理的新需求；n 平安性：系统本身要提供较高的平安性；n 兼容性：能同第三方的治理软件以及原有网管软件集成，充分保护原有投资。3. 系统总体构造3.1 系统定位以及与现有网管系统之间的关系3.1.1 系统定位本系统的治理对象是以业务支持系统（BSS）为核心，包括采集、计费、结算、营业、帐务等子系统，实现对业务子系统的统一治理、集中监控和集中运维。3.1.2 与现有网管系统之间的关系本系统与已经建立的网管和网络平安系统的关系是互为补充，而不是互为替代。原网管系统在建立过程中所购置的网管软件和在其上实现的系统监控，可与现有各业务系统的分散的应用监控相结合，在充分利用原有投资和资源的根底上，完善功能，综合利用系统平台和应用系统的监控信息，构成运维治理平台的重要组成部分：系统监控部分，以便统一展现支撑平台和业务系统的运转情况，统一监控和维护各种告警、配置、功能数据。同时，为了强化对运转维护人员、流程和信息的治理，防止由于人员的忽略和信息的混乱所造成的系统运转和效劳质量征询题，在ITIL理论的指导下，结合联通业务支撑系统运转维护治理规程和各省分公司的实际情况，建立该系统的另外一个重要组成部分：以流程治理和资源配置信息治理为核心的效劳支持部分，从而进一步梳理、优化运维流程，建立监控手段与运维人员之间的有机联络，初步建立人员绩效考核机制，实现突发事件的快速处理和业务迅速恢复，并尽可能消除或减少突发事件的发生，实现系统的逐步优化，提高现有系统的稳定性。图3.1 与现有网管系统之间的关系图如下图，网管与网络平安系统主要包括综合信息传输平台、网管、网络平安三部分内容的建立，同时为实现上述功能需要对信息系统部现有各系统进展优化和改造。一方面，网管与网安系统中的网管功能可纳入运维治理平台中的系统监控部分，另一方面，网管与网安系统的综合传输平台和网安部分可作为运维治理平台中系统监控部分的被监管对象进展治理。此外，系统监控部分和效劳支持部分之间可通过自动或人工的方式进展事件和配置信息的交互，从而实现这两部分的功能及信息内容能够在展示层面进展整合，在数据层面进展综合分析，为系统平安稳定运转提供更加合理、高效的治理手段和方案。3.2 系统组织构造系统组织构造如下列图所示：图3.2 BSS运维治理平台组织构造图中国联通业务支持系统运维治理平台分为两级构造，第一级为总部运维治理平台；第二级为总部计费、结算中心运维治理平台和各省、自治区、直辖市运维治理平台。第一级总部运维治理平台主要功能为负责对中国联通各省业务支撑系统的运转情况的监视治理；掌握各省的资源配置信息及各资源的功能信息，为系统的晋级改造提供依照；对省公司上报的严重毛病和总部市场部、客户部等部门的投诉进展治理，并监视和协调省公司的处理；采集各省公司业务系统考核指标，并对省公司进展考核；建立总部与省公司运维治理信息的上传和下达通道，使总部的相关通知信息等能及时下达，省公司上传的严重毛病和变更、运维统计报表数据等能及时上传；统计各省分公司的相关运维治理信息，掌握全国业务支撑系统的运转情况。第二级省运维治理平台负责对相应省各业务支撑系统详细的治理，包括各业务支撑系统中的应用软件、主机设备、网络设备、存储设备、备份设备、数据库、中间件等，确保各系统稳定可靠地运转，并按总部要求上报相应的数据。3.3 系统体系构造BSS运维治理平台体系构造如下列图所示：图3.3 BSS运维治理平台体系构造图运维治理平台体系构造可分为三个层次：数据层、功能层、接入展现层。3.3.1 数据层3.3.1.1 监控数据监控数据来自系统平台（网络、主机、存储、数据库、中间件等）、应用平台（采集、计费、营业、帐务、结算等）、业务支撑系统平安系统（主机系统平安、网络平安）以及机房环境等。通过各类采集手段或接口实现对监控数据的采集，通过系统监控的各个功能组件实现对监控数据的处理和分析，通过统一的接入展现层实现对监控数据的展现，监控数据从内容角度又能够分为告警数据、功能数据和配置处理数据等，监控数据从时间维度能够分为当前数据和历史数据。3.3.1.2 治理数据治理数据主要是为实际治理需要定义或录入的数据，其数据主要通过手工录入获得，内容包括工单、供给商情况，也包括流程配置、告警严峻级别、告警过滤规则、相关性模型、告警晋级规则、告警传递规则、功能门限配置、配置数据静态信息（设备编号、地理位置等）、值班/排班定义、设备/人员优先级别、效劳水平定义、紧急程度定义等，同时治理数据还包括各种与监控数据相关的维度数据，如银行编码与名称对照表、营业厅名称等等。治理数据同时包含系统中的各种过程数据，如事件治理和征询题治理中从受理到完毕的每一步处理过程，变更过程中的变更计划书、变更受权书、变更评估报告、变更施行报告、变更验证报告等也都归类于治理数据。3.3.1.3 系统数据系统数据主要是由运维治理平台本身运转所需要或使用的数据构成，主要包括组织机构、人员信息（登录信息、联络方式）、权限情况、角色定义、日志文件、字典表数据和规则数据，包括系统本身运转日志、历史数据保存规则、不同时间粒度报表定时生成规则、设备厂家/型号对照表等、数据采集任务定义等。3.3.1.4 文档数据文档数据主要是以附件等方式存放的文件数据，主要包括规章制度、设计文档、培训文档、施行方案等，同时也包括知识库中的知识数据、供给商治理中的合同信息、配置治理中的文件方式的配置数据，在流程治理以附件方式派发的公文信息等。3.3.2 功能层运维治理平台的功能层主要由两大部分构成，即系统监控和效劳支持。（1）. 系统监控n 系统监控的治理对象是UNI-CRM系统中的所有系统平台设备（网络、主机、数据库、中间件、存储藏份设备等）和业务应用系统（主要指采集、计费、营业、帐务、结算等）。n 系统监控的监控内容主要是业务支撑系统的平台类和应用类KPI指标（详细指标参见附件），通过接收或采集数据层生成的指标数据（或原始数据），并对这些指标进展统一的存储、处理与分析，将处理结果转发至效劳支持部分或直截了当上传接入展现层。n 系统监控的功能组成主要包括四个部分：l 监控台：用于统一展现系统平台和业务应用系统的运转情况，统一配置和维护系统监控的各种展现数据和治理规则；l 告警治理：用于统一接收、采集系统中发生的各种异常情况，并通过对这些信息统一处理（标准化、压制、合并、过滤、毛病源定位等）实现“全面监控、精确告警、及时通知、快速处理”的目的，告警治理在保证告警信息精确性的条件下，可通过各种外部接口（邮件、短信、语音）通知指定维护人员，关于较严峻的、需要维护人员人工处理的告警信息，应通过效劳支持部分自动生成工单，进入闭环处理流程，关于严重告警信息，应通过相应接口及时通报总部，告警治理是系统监控最核心的部分；l 功能治理：用于统一存储、处理、分析各类功能指标，实现对功能指标异常变化情况的及时告警、通过对历史功能数据的统计分析为业务系统运转趋势变化分析和系统扩容、优化提供量化依照，功能治理部分是系统监控内容最丰富的部分；l 配置处理：用于统一存储、处理、分析各类配置指标，在发生配置数据异常变化时能够生成告警信息，并提供对配置数据的统计、分析和查询，配置处理是系统监控的数据根底。（2）. 效劳支持n 效劳支持的使用者主要是信息系统部的各类人员，包括值班人员、维护人员、治理人员等；n 效劳支持的治理内容主要是依照ITIL理论，依照总部发布的运转维护规程和各省运维组织机构和人员组成情况，结合实际运维情况，梳理、优化运维流程，实现运维工作的流程化、标准化、电子化和自动化，建立监控手段与运维人员之间的有机联络，初步建立人员绩效考核机制；n 效劳支持的功能组成主要包括8个部分l 效劳台：为流程的起点和终点，是信息系统部为部门内部和其它部门提供的统一效劳窗口，统一受理事件、申告、投诉和告警；l 事件治理：关于突发事件的流程化处理，事件来源包括系统监控中的告警治理模块以及、手工生成等，事件治理的核心是注重突发事件的快速处理和业务迅速恢复；l 征询题治理：寻求毛病根源，处理存在或多发征询题的流程，征询题治理的核心是注重消除或减少事件的发生，实现系统的逐步优化，提高现有系统的稳定性；l 变更治理：对变更恳求进展记录、跟踪与治理的流程，消除或减少变更对消费系统的妨碍和风险，保证变更的顺利完成；l 配置治理：治理各配置、资源、资产数据的流程，包括定义和维护配置数据互相间的关联与依赖关系；l 日常运维治理：包括机房值班、排班、交接班、作业计划、日志等内容，主要目的是强化日常运维工作的标准性，为各种运维制度提供有效的落实手段；l 供给商治理：对业务支撑系统集成商、软件供给商的相关材料、与联通签订的效劳合同等信息进展治理维护，并对各集成商、软件供给商的产质量量、效劳情况进展评分治理，并将评分定期上报总部，使省公司及总部及时、全面地理解供给商的阶段性效劳情况；l 知识库治理：通过对知识库系统维护和使用，不仅能够在毛病自动处理和人工处理的过程中在知识库中得到相关毛病维护的分类和快速定位，找到匹配的处理案例，便于处理人进展借鉴，而且知识库具有的业务协助功能，使相关人员能够通过关键字查询业务协助、产品、市场活动、发生过的处理流程、电子文档等。3.3.3 接入展现层接入展现层是运维治理平台提供给值班人员，运维人员和治理人员的统一入口。实现运维治理平台的功能及信息内容在展示层面进展整合，并针对不同角色的使用者提供与角色关联的个性化的展示内容。同时提供对多种设备和接入方式的支持。3.4 与外部系统之间的关系运维治理平台与外部系统之间的关系如下列图所示：图3.4 BSS运维治理平台与外部系统关系示意图关于目前建有网管系统的省分公司，现有网管系统今后应融入到运维治理平台中。运维治理平台可从现有网管系统（专业网管或应用网管等）中获得主机、网络、数据库、中间件、业务应用系统等网管信息。运维治理平台从业务应用系统、系统平台、机房环境及平安系统中获得的主要数据内容为：配置数据、功能数据、告警数据等。二级运维治理平台向一级运维治理平台提供的主要数据为：配置数据、严重毛病数据、严重变更数据、功能数据和相关的统计报表等。运维治理平台预留有与其他系统的接口，例如MSS能够从运维治理平台中获得运维相关的信息，如运维治理平台的考核结果通过MSS系统进展发布，另外运维治理平台能够接收MSS系统的有关运维治理的通知等。运维治理平台的用户包括值班人员、运维人员、治理人员。进一步运维治理平台通过运维人员等受理其他部门如市场部、客服部等对业务支撑系统运转情况的征询、用户投诉、变更恳求等，并反应处理结果，为其他部门提供效劳。4. 业务功能与流程4.1 各模块之间的关系各模块之间的关系如下列图所示：图4.1 BSS运维治理平台功能模块关系图4.2 岗位与角色描绘4.2.1 岗位描绘岗位组织构造如下所示：图4.2 岗位组织构造图其中运维部门治理负责人、技术业务治理负责人、技术工程师、业务工程师、值班人员的岗位定义、职责详见中国联通企业信息化（UNI-IT）系统运转维护治理规程。其中：n 上级主管（总部）：总部的运维治理负责人，负责批示省分公司运维过程的严重毛病、严重变更等征询题；n 值班经理：协调组织值班人员进展日常运维值班任务，通常由技术工程师或业务工程师担任；n 效劳供给商：作为中国联通的外协单位，负责协助、完成系统的运转维护，可包括原厂商、集成商、效劳商。4.2.2 角色描绘运维治理平台涉及的角色为：n 效劳台：是一种治理职能，通过效劳台角色在不同流程中的功能表达其职能，同时担任分类、晋级、跟踪、协调、一线支持职能，效劳台角色由值班人员、值班经理担任；n 二线支持：通过效劳台初步支持不能处理的事件、征询题，由二线支持角色处理，二线支持由技术或业务工程师担任；n 三线支持：通过二线支持不能处理的事件、征询题，由三线支持处理完成，三线支持由联通方的专家和效劳供给商的技术专家担任；n 治理人员：与运维部门治理负责人完全对应；n 征询题治理员：在征询题治理流程中负责事件的分析、征询题的起草、提交审批、征询题总结的人员，由业务或技术工程师担任；n 征询题处理方：负责征询题的调查分析、提出征询题的处理方案、征询题的处理，由技术和业务工程师、效劳供给商的相关技术人员担任；n 变更治理员：在变更治理流程中负责起草变更恳求、分类/分级、编写变更计划，由技术和业务工程师担任；n 变更参谋组：负责评估变更恳求的必要性以及计划的合理性，由技术业务治理负责人、专家、效劳供给商组合担任；n 变更施行方：负责变更过程的组织、施行，包括变更的构建、测试、发布、恢复等职能，由技术和业务工程师、效劳供给商共同担任；n 配置治理员：配置治理中负责配置信息的录入、核实、归档，由技术和业务工程师担任。角色与岗位的关系如表：角色岗位效劳台值班人员值班经理二线支持技术业务治理负责人技术工程师业务工程师三线支持联通方的专家效劳提供商治理人员运维部门治理负责人征询题治理员技术业务治理负责人技术工程师业务工程师征询题处理方技术业务治理负责人技术工程师业务工程师效劳提供商变更治理员技术业务治理负责人技术工程师业务工程师变更参谋组技术业务治理负责人联通方专家效劳提供商变更施行方技术工程师业务工程师效劳提供商配置治理员技术工程师业务工程师上级主管上级主管4.3 业务功能描绘4.3.1 效劳支持4.3.1.1 效劳台4.3.1.1.1 定义效劳台是一个综合接口平台，统一接收来自于综合电信业务支撑系统各业务子系统及其他途径的各种效劳恳求信息（告警、投诉等），提供必要的初始支持，并依照需要启动相应的效劳流程、并对效劳流程跟踪监视，同时向效劳恳求方反应效劳结果信息。4.3.1.1.2 功能治理、协调并尽快处理各类事件，同意各类事件流程能够集成到效劳治理根底架构之中。不仅能处理毛病、投诉和疑征询，还可提供与其他过程的接口。(1) 接口效劳模块n 提供统一接收各种事件、毛病、投诉等效劳恳求的信息流逻辑接口；n 响应、确认、核实、记录和维护各种效劳恳求信息；n 提供效劳支持治理的统一接口；n 提供效劳处理结果反应的统一接口。(2) 初始效劳提供：关于一些能够直截了当处理而不必启动效劳流程的效劳恳求，由效劳台提供必要的初始效劳支持。(3) 效劳流程启动：关于通过初始效劳支持无法处理的效劳恳求，效劳台记录并推断确定效劳类别和级别，并启动相应的效劳流程。(4) 效劳流程监控：跟踪、治理、协调流程处理过程，调整事件优先级，检查流程的处理进度。(5) 效劳反应：在效劳过程中，保持与效劳提出者的联络，及时通知效劳进展；在效劳完毕后，告知提出者处理结果。4.3.1.1.3 流程及业务规则效劳台负责记录事件相关信息，向用户提供对已经知道征询题的处理方法，报告事件并启动相关效劳流程，到达尽可能快速、有效地处理征询题的目的。效劳台接收的事件信息：n 系统获得的毛病告警、功能告警、配置告警等告警信息；n 从其它系统获得的事件信息，如客服系统的投诉信息等；n 人为事件，包括从、邮件等途径获得的事件信息，以及其别人工录入事件；n 其他事件。假如效劳台不能处理这个事件，应当启动维护流程，将事件分配给最适宜的效劳支持小组/人员来处理，并进展如下工作：n 记录相应事件；n 断定效劳类别；n 断定事件优先级（各省分公司依照本人的实际情况，制定可操作的、量化的优先级断定的标准）；n 检查事件记录的处理进度，依照需要调整事件优先级；n 保持与事件报告者的联络，及时通知事件处理进展；n 最后关闭事件。4.3.1.1.4 与其他模块之间的关系n 与系统监控功能模块接口：从告警治理接收待处理监控事件信息，返回处理结果。n 与事件治理模块接口：记录、发起、并监控效劳过程。4.3.1.2 事件治理4.3.1.2.1 定义事件治理是对监控治理产生的事件以及人工发起的事件处理恳求进展治理的功能模块。事件包含告警事件、投诉事件、恳求事件。事件能够来源于系统平台、应用平台、机房环境、系统平安等的告警，也可来自外部的投诉、恳求等。依照其对效劳的妨碍程度，事件可分为：一般事件和毛病事件两大类。在上述事件中，凡开通运转的系统、设备和设备，在承担业务期间，造成质量降低至用户无法使用，均定为毛病。毛病的分级：按妨碍范围、持续时间和性质严峻程度，将毛病分为严重毛病、严峻毛病和一般毛病。4.3.1.2.2 功能n 事件记录：从效劳台获取事件信息后，记录入系统中；n 事件断定：依照事件和毛病的现象以及产生缘故确定其类别、对业务的妨碍程度、紧急度和优先级，并指定事件和毛病的处理时限；n 事件处理：包含对事件的缘故和处理方法的分析、毛病的处理以及效劳（业务）的恢复，同时包括事件处理的流程治理、事件的晋级和依照规则向不同级别的上级报告；l 分析推断：通过与相关效劳、技术支持人员共同研究分析发觉事件发生的缘故，或查找往常是否发生过同类突发事件，是否有处理方法；l 上报：发生严峻毛病和严重毛病时，维护部门直截了当向省分信息系统部和运转监视部报告；关于严重毛病，要上报联通总部信息系统部和运转监视部；l 处理和业务恢复：利用找到的处理方法处理征询题，恢复业务。关于紧急级的事件，在事件治理过程中直截了当执行紧急变更治理过程，不再向“变更治理”提交工单；l 事件、毛病晋级：关于系统中持续出现以及超过规定处理时间仍未处理的事件和毛病，需要晋级该事件级别，以保证得到优先、及时的处理。当事件处理超过预期时限，依照预定义的晋级条件，将该事件自动/手工晋级到更高级别，并通知到指定级别的治理人员。n 处理跟踪：跟踪事件和毛病处理过程和时限，晋级和催促突发事件，随时通知用户处理进展；n 事件结束：事件处理完成后，要将结果记录入系统并将处理结果反应给事件发起方；n 统计查询：提供灵敏的统计和查询功能，方便对事件的处理情况、处理结果进展查询，并提供统计和汇总报表功能。4.3.1.2.3 流程及业务规则事件治理的处理流程如下列图所示：业务规则：n 上报总部：对严重毛病，分别由省分信息系统部和运转监视部上报至总部信息系统部和运转监视部；n 晋级规则：对超过处理时限的事件，依照超出的时限，系统自动晋级到相应级别，并依照事件级别定义，系统流程自动将音讯通知对相应级别的治理人员。4.3.1.2.4 与其他模块之间的关系n 通过配置治理获得相关资源和配置数据，并将处理过程中对配置的修正提交给配置治理；n 依照对事件、毛病缘故的分析，依照需要产生变更恳求并进入变更治理；n 将典型的事件处理过程和结果提供给知识库。4.3.1.3 征询题治理4.3.1.3.1 定义征询题治理是通过识别征询题的真正的潜在缘故，操纵运维中的毛病的过程。征询题治理采取积极主动的方法，通过对已发生的征询题进展分析，提出处理方案并尽早采取防备措施，防止同类事件或毛病的再次发生。征询题指已经发生、同时重复屡次的事件或严重毛病所包含的尚未查明的、真正的潜在缘故。征询题来源于事件、毛病治理流程中的非突发事件或屡次重复发生的事件信息的总结和分析。4.3.1.3.2 功能征询题治理是征询题的提出、分析、处理的治理过程，并提供征询题处理方法的记录以及征询题的统计分析和查询功能。n 征询题提交：从对事件的分析中，关于未探明缘故的严峻事件或对屡次重复发生的事件提出征询题报告，以待对征询题的根源进展分析和处理方法的提出；n 征询题分析研究：对提交的征询题安排相关的技术专家、维护人员和业务治理人员进展研究分析，给出征询题的处理方案，并将初步的分析结果和对应的处理方案记录系统；n 征询题处理：依照对征询题的分析得出的处理方案，产生相应的变更工单，交变更治理过程进展处理。n 征询题结束：对处理方案的处理结果进展记录并进展评估、总结；n 统计查询：提供对征询题的处理过程、处理结果的灵敏查询功能以及统计报表功能。4.3.1.3.3 流程及业务规则征询题治理的业务流程：n 征询题提出、分类；n 征询题分析：由相关专家和治理人员通过会议、研究等方式分析征询题缘故和提出处理方案；n 征询题处理：依照处理方案产生变更工单，进展变更处理；n 处理结果的记录和总结：记录征询题的处理过程和最终结果，并对征询题的处理结果进展回忆评价，假如未处理征询题，再进展相应的分析和处理。4.3.1.3.4 与其他模块之间的关系n 与事件治理/毛病治理的关系：对一般事件和毛病事件的分析总结是征询题治理的数据源。n 与变更治理的关系：在处理、处理征询题的过程中，可能需要对系统配置、软件版本进展修正晋级。因而，征询题治理能够派生出变更流程。n 与知识库治理的关系：征询题治理过程积累的征询题的典型处理方法为知识库治理提供数据源。4.3.1.4 变更治理4.3.1.4.1 定义变更是指针对被治理系统中某对象及其配置所进展的修正，大到整个业务支撑系统的晋级改造，小到某设备参数的细微调整。为了防止和减少变更所造成新的系统征询题和毛病隐患，对系统变更过程需要标准化治理，包含提出变更计划及申请、申请评估、审批、受权、施行、验证等流程。变更治理是指对这些流程的标准化治理，以确保使用标准的方法和过程实现快速、有效的变更，保证变更过程的可控性、可治理性和有序性，减少变更带来的突发事件，促进日常工作的正常进展。4.3.1.4.2 功能变更治理需要包含如下功能和主要环节：n 变更恳求：由系统或者业务人员填写变更单，提出变更恳求。填写内容包括变更提出人姓名、变更缘故、变更对象以及变更施行计划、施行时间等详细要求。n 变更评估：由变更评估小组对变更申请方案及对系统的妨碍进展评估。变更评估关于将对系统产生严重妨碍的变更（如系统晋级），是特别必要和重要的；关于妨碍较小的变更可依照详细情况简化评估流程或直截了当提交审批。变更评估过程中，评估未通过的申请，会出现两种结果：一种是评估小组并未否认变更恳求，而是对变更提出了其他意见，申请人依照意见重新填写申请，再次提交；一种是评估小组否认了变更的恳求，变更终止。n 变更审批：负责人对通过评估的申请进展审批。如审批通过，则进入变更受权流程，否则，进入变更终止。n 变更受权：负责人指定相应部门及人员负责变更的施行。n 变更施行：能够依照变更对工程的妨碍程度定义施行流程。关于有严重妨碍的变更，施行过程将包括变更的预备、变更前试验、变更施行、变更测试、验证等。此外，还需要制定完善的测试恢复计划，以保证在施行过程中，出现意外或施行结果不符合期望时，依照恢复计划进展系统恢复，减少变更对效劳质量的妨碍。变更施行完成后，将通知申请人。n 变更终止：变更终止分成两种情况，一种是变更施行成功完成，变更工作完毕，对变更进展评价；一种在变更过程中，由于各种情况变更撤销。关于变更撤销，要求记录变更撤销缘故。4.3.1.4.3 流程及业务规则变更治理的业务流程如下列图所示：业务规则：n 任何涉及对主机、网络设备配置、系统软件、应用软件、相关文档的修正都应该通过变更治理标准和记录；n 变更流程对配置和设备的修正都应该更新配置记录；n 涉及单台设备、非核心系统（非核心网络设备、效劳器和应用）的配置修正为简单变更，能够省略审批过程，但必须启动变更流程并更新配置记录；n 非紧急变更需要依照详细的业务要求由相关人员(变更经理或变更参谋团)审批。4.3.1.4.4 与其他模块之间的关系n 与事件及征询题治理的关系：在处理、处理系统毛病和征询题的过程中，经常需要对其配置、版本进展修正。因而，事件治理和征询题产生变更恳求。n 与日常运维治理的关系：在日常运维治理工作过程中也需要修正系统的参数和配置，也需要启动变更流程。n 与配置治理的关系：变更的结果导致设备和/或配置的变化，变化的结果需要在配置治理中表达。因而，变更治理导致配置记录项的变更。n 与知识库的关系：变更治理积累的经历和对典型变更过程的评价分析，都能够作为知识库的内容供其他类似案例参考。4.3.1.5 配置治理4.3.1.5.1 定义配置治理是指识别和确认IT系统配置项，记录和报告配置项状态和变更历史，检验配置项的正确性和完好性等活动构成的效劳治理流程。配置项是指IT系统的组件或IT系统提供效劳的相关的配置信息（如主机的设备型号、CPU/内存配置、硬盘配置、网络接口卡配置以及IP地址、端口、功能配置参数等）。配置治理的目的是治理并及时提供精确可靠的IT系统根底架构（硬件、软件资源、机房内资源等）的配置信息。通过对配置信息当前情况的理解，指导系统的晋级、改造。系统应提供配置数据的自动和手工输入并进展合法性等检查，对历史数据进展治理。4.3.1.5.2 功能配置治理的功能构造如下列图所示：n 配置项设置：是“配置项”定义的工具，通过它实现配置项列表的定义和调整，并定义配置项的层次（颗粒度）和关系以及数据获取方式；n 配置项采集：获取资源配置项的完好属性信息，采集方式包含“自动采集”和“手工采集”两种方式，其中“自动采集”部分由系统监控中的“配置处理”来完成，并通过“系统监控”和“效劳支持”的接口完成数据的传递；n 配置项治理：实现对资