【摘要】本文结合作者实际运维经验及最新监测技术、运维管理理念，详细介绍了中央人民广播电台（以下简称“中央电台”）制播系统集中监测平台设计思路，并以在设计中遇到的问题实例加以说明。
【关键词】 集中监测 系统事件关联故障快速定位 业务建模
1引言
中央电台制播系统由多业务系统组成，各业务系统即独立又有联系，目前各业务系统均由自己的监测软件对系统运行状态进行监测，这些监测系统为日常的业务运行工作提供了有效的技术检测数据，但是随着制播信息系统改造，流程化制播运用，各系统之间联系程度越来越紧密，这种分立式单独监测方式，无法将系统事件进行关联，无法快速定位故障点，导致维护人员精力分散处理事故慢，不能满足目前运维需求，需建立集中监测平台改变运维模式，提高业务系统运维关联性，满足运维管理需求。
2设计目标
本设计最终目标是通过制定统一的安全策略，采用合适的安全技术措施和进行制度化的运维管理，建立一体化的集中监测平台，最终实现基础网络、业务流程状态、终端设备状态的集中监测及运行维护的流程化管理，加强系统故障与性能、服务与流程的管理融合，实现网络管理、运维管理和服务管理一体化。
3系统架构设计和功能设计
3.1部署设计
集中监测平台部署设计充分考虑到制播网络安全等级保护的要求，利用防火墙及网络策略隔离出安全区域“安全运维管理区”，所有与制播系统业务无关的功能系统均放置在此区域，包括：集中监测、运维管理、安全管理等。
图1集中监测平台部署架构图
3.2逻辑架构设计
设计基于信息系统标准规范，建立与第三方标准接口，整合基础设备管理，应用管理，端到端应用流分析，业务服务管理，业务流程管理等，消除信息系统运维断点，使各模块之间信息互通，以业务的视角实现整体信息系统运维管理，最终帮助信息中心建立完备的信息系统运维系统，实现流程化、自动化和规范化管理。
图2制播系统集中监测平台逻辑架构图
集中监测平台采用分层、模块化设计，每一层次的模块设计分开，且模块之间的松耦合。层与层之间的沟通是通过API接口。
集中监测平台为能达到高性能、低成本，则采用B/S架构。同时提供与第三方接口（包括安全管理中心、云计算、虚拟化等），与第三方集成可以在以下三方面实现：
数据：直接利用其它系统的接口，采集性能监控数据，采集后进行数据的分析及汇总，统一产生告警事件并生成历史数据报表。
事件：接收或者读取第三方系统产生的故障告警事件，进行统一的故障事件展现和处理（报警发送等）。
界面：实现管理员的单点登录
3.3技术架构设计
集中监测平台采用分步式布置，整个技术架构分为四层：第一层：被采集层，主要由被监控设备及应用系统组成；第二层：采集层，主要通过采集器对被采集层设备信息进行采集。采集方式采用标准协议，采集数据进行压缩、加密，保证传输安全性；第三层：汇聚处理层，负责下发监测策略，并汇总和筛选从采集层采集的监测数据信息，写进数据库，以便于展现层从数据库选择调用；第四层：展现层，将需要展示的信息通过图形化的方式实时统一展示，同时可以融合其它监测产品，并统一登录。
通过以上部署方式即可实现对制播网信息系统资源的统一监测及运维服务。各系统管理员可以根据实际情况利用权限设定管理信息系统资源和运维工作范畴。
图3制播系统集中监测平台技术架构图
监测方式可以选择代理和无代理方式，这两种方式可以根据系统运行情况进行选择。
防火墙策略根据实际情况及安全等保规定，进行策略设计。
3.4安全设计
本项目集中监测平台部属在经过安全等级保护等级的制播网内，因此需要遵守相关安全规定，包括原国家广播电影电视总局《总局广播电视安全播出管理规定-总局令62号》、原国家广播电影电视总局《广播电台数字化网络化建设白皮书（2007）》原国家广播电影电视总局《广播电视相关信息系统安全等级保护基本要求》进行安全设计。
例如：在制播网内，利用防火墙划分出安全区域“安全运维管理区”，一切和制播系统业务无关的系统均部属在此区域，集中监测平台部属在此区域；采集信息传输方式采用点对点，传输协议采用标准协议，传输数据加密；网络层面采用划分单独vlan并在防火墙设置访问策略；用户层面采用登录限制，包括登录时间限制、登录次数限制，并记录所有管理人员的认证和操作日志等。
3.5功能设计实现原理
图4制播系统集中监测平台功能图
5.4.1统一事件告警设计
设计支持多种事件收集方式，包括代理和无代理方式的事件收集机制，对系统收集到的各类系统事件和应用事件进行压缩、关联、过滤等分析处理，并可统一进行展现，及时帮助系统管理员能够准确确定故障位置，快速处理问题。在统一事件告警设计中考虑到监测的种类包含基础架构、服务器、应用、业务、脚本等多种内容，各自监测后产生的报警信息则需要一个统一的实时告警平台可以直观的将所有监测内容的告警信息囊括进来。
5.4.2统一策略管理设计
策略管理设计中，可以给设备、基础应用等每个资源设置独立策略，也可以对相同资源进行统一策略设置，这些策略的设置阈值和事件报警相统一，节省了管理维护成本
5.4.3运维流程管理设计
设计结合信息系统ITIL体系框架，建立以CMDB为中心的运维流程管理，主要实现以下目标：
1.强化主动监测
充分利用监测系统监测大数据的分析能力，主动及时的发现问题，并主动将监测信息推送给运维人员，使维护人员从“救火员”转变为“消防员”，解决被动服务的局面。
2.帮助定位故障
故障定位是这次设计中的关键一点，快速的定位故障点，不但减轻维护人员工作量，还减少了恢复系统使用时间，提高维护效率。
3.规范运维管理
参照信息系统ITIL规范和相关信息系统标准，结合中央台的实际运维经验，规范运维管理。运维管理要流程化，规范化，更要电子化，给运维人员制定合理的运维制度提高工作效率。
4.共享运维经验
维护人员的运维经验是很宝贵的，合理的把运维人员的好的工作经验进行总结和归纳，并以知识库的方式共享给各系统维护人员，实现维护经验的共享和交流。
5.提供统计分析
通过各种报表可以从各方面详细的反映系统一段时间运行状态，性能使用情况及维护人员工作情况等。
6.全面直观展现
通过统一展示模块,使运维人员能快速了解到系统资源的运行状态、性能使用情况、服务工单情况等。
5.4.4统一运行展现设计
设计本系统与其他第三方管理系统实现统一认证统一登录机制，并对整合后的内容进行统一展现，打造个人工作平台。
图5制播系统集中监测平台统一运行展现设计图
5.4.5运维统计分析设计
在运维过程中，每天处理多少故障，处理结果怎样，每月维护人员处理故障多少、系统运行状态趋势如何，怎么去避免不必要的问题处理等，都需要大数据分析，运维统计分析模块即可统一展现出信息系统资源性能报告、趋势报告、故障报告，运维团队工作报告，并可自动进行实时分析、历史分析，例如总体运行状态一览表、设备运行故障报表、性能报表、关键链路流量报表等。同时为便于管理员掌握各业务系统和基础网络的运行情况，可以提供监测目标的存活率数据，并通过图表及表格的方式以日期分类统计。
5.4.6业务流程管理设计
制播系统流程化，故障出现时多种多样，但表现会出现在每个流程节点，因此我设计将复杂异构的信息系统资源通过业务建模的过程形成层次化管理视图，同时完善监控采集规则，把信息管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系关联起来，业务建模强调以整体的方式来理解、设计和构架业务服务系统。通过业务关联管理，系统管理员可以轻松的建立各业务系统综合信息模型，随时了解到业务的运行状态。
图6制播流程图
例如制播流程建模，制作、发送、一审、二审、三审、制作接口、播出接口、分发
其它流程：媒资到制作流程、媒资内部流程、水印流程等。
每一个业务节点均有关联要素支撑，例如：“发送”节点，则由编辑器、webservice、数据库、操作系统、服务器、网络关联要素组成，任一要素有故障均可在“发送”节点上报告出来，并显示故障点，以此系统管理员能快速定位故障。
当然在设计调研的时候遇到一些问题，例如：在发播流程中，由制作的首节点生成并记录GUID，该GUID在所有的业务系统中保证唯一。当制作向播出发起服务调用时，制作将该GUID组织在接口文件中并进行发送，播出收到后未对其进行识别、存储及后续使用，而是再次生成了播出系统内使用的唯一ID。解决思路：
1、制作系统
1）在与播出系统集成的方式上不需做任何改变。
2）仅需要在与集中监测平台集成时，按统一监测平台的接口规范组织向集中监测平台发送消息，消息中使用GUID作为业务流程实例的唯一标示。
2、播出系统（同样适用于媒资系统）
1）在接收到制作的调用时，要持久化（要保证程序异常中止后依然可以再次重新处理，所以一定要持久化）记录播出自己创建的ID与制作发来的GUID间的关系。制作与播出在进行调用时，播出在调用结束后要告知制作是否调用成功，这种告知也是在GUID的基础上进行告知，所以与本次报告可合并实施。
2）在与统一监控平台集成时，按统一监控平台的接口规范组织向统一监控平台发送消息，消息中使用GUID（根据记录的关系进行查找）。
3、集中监测平台
1）对业务系统发送的消息进行接收及后续与监控相关的处理。
4结束语
综上所述，集中监测平台设计已经较好的满足中央电台制播系统集中监测需求，但在实际使用中，特别是系统故障关联和业务流程建模需要不断的和现有业务系统磨合，总结经验再对监测平台进行科学的、合理的微调，以致集中监测平台更加趋于完善。
参考文献：
【1】韩晓光 系统运维全面解析：技术、管理与实践 电子工业出版社 2015年11月