全栈式智能运维平台由内控堡垒机、运维管理系统和监控系统组成已分阶段完成投产运行，实现了运维操作权限管理和审计监督、运维流程管理、应用系统运行监控等功能。系统自上线以来运行情况良好，有效解决了运维管理的问题，提高了应用系统故障监控能力。然而，随着公司信息化建设速度的加快，系统的快速增长，运维面临的新问题也逐渐显现出来，运维操作自动化程度不高，运维三系统缺乏有效的制约和联动，系统监控的范围和智能化程度不能满足运维工作的需要，目前的运维系统已不能为运维能力的继续提高提供支持和帮助，急需进行优化调整，实现三系统的联动和制约，建立运维工具库，实现故障分析和运维操作自动执行等功能，提高自动化、智能化，有效降低运维人员的工作强度，提高运维效率。
二、创新点
1.消除运维数据孤岛，构建运维能力统一平台
该系统打通原有各分散运维系统，采用微服务技术构建，管、监、控、服、智各项运维能力均组件化构建，可快速插拔组合，具有良好可扩展性，有效支撑运维需求。
2.以CMDB为核心，构建智能自动化能力
该系统构建了覆盖IT全环境的统一CMDB库，包括纵向资源部署依赖关系树，横向服务访问关系树。提供以CMDB库为核心、包括监测、运维作业、流程调度、运维分析、知识库等多维度运维大数据中心为基础，并通过智能采集引擎、流程引擎、智能分析引擎、知识引擎驱动的自动化运维能力。通过在CMDB各树节点上关联探查类、除障类脚本，沿横纵两维度驱动脚本自动执行，可支撑自动排查、自动除障等智能运维场景。
3.构建全栈监采、统一告警能力
该系统提供基础监控、应用监控、日志监控、APM监控、对接第三方监控系统等多元采集能力，并通过告警中心统一汇总监采数据、统一分析、统一告警。
三、项目技术方案
1.总体架构
本项目总体架构概述如下：
平台总体架构分为如下各层：
智能采控层
实现对各类IT资源的多元化手段采集监测及控制、配置信息采集；
实现对各类IT设备的自动化运维操作执行及控制；
实现与邮政集团短信平台、公司统一身份认证系统、其他外部系统对接接入。
运维大数据中心与数据引擎智能驱动层
以统一CMDB为核心，构建多维运维大数据，包括各类监测数据、运维作业数据、流程调度数据、运维分析数据、知识库等多维度运维大数据。
以多维运维大数据为基础，提供数据驱动的智能运行引擎，包括：智能采集引擎、流程引擎、智能分析引擎、知识引擎等。
上述架构，向上，为模型组件层提供运行支撑和数据支撑；向下，汇聚智能采控层的采控数据，同时支撑智能采控层的采集智能化、自动化执行控制等。
模型组件层
面向运维全场景，提供各类模型组件的定义管理，包括：CMDB模型、流程模型、自动化作业模型、设备监控采集模型、数据分析模型、展现组件等各类基础模型化服务组件。
场景应用层
围绕“监管控防”，提供各种运维管理功能支撑，包括：IT资源管理（CMDB管理、IT资产管理）、智能综合监控、运维服务管理、自动化运维、可视化决策支撑等场景化功能子系统。
在上述典型运维能力基础上，通过运维能力组件间协同，构建智能联动能力，实现协同故障排查、故障自愈、一键式自动化运维等运维能力智能化落地。
统一用户管理
提供本系统的统一的用户管理、认证管理、权限管理。
微服务运行平台管理
平台整体基于微服务架构设计实现，提供微服务运行平台管理支撑，包括：部署管理、运行管理等。
运维数据总线
平台各组件之间数据传输通过运维数据总线实现。
2.总体软件技术架构
2.1、总体技术架构概述
面向服务的架构（SOA）
SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。其中，接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言，这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。其次，这些服务间应是松耦合关系，这样可以保证架构的灵活性和系统进一步演变时，已有的服务能力持续发挥作用。最后，安全、信任和可靠在SOA架构中起着重要的作用。
SOA架构服务间的调用更多面向API接口级，更多依赖与编程语言无关的精心设计的消息结构，例如：XML/JSON文本结构，而消息体中包含服务提供方的逻辑名，而不关心服务提供方的物理部署访问参数。
微服务架构
SpringCloud技术栈作为第二代微服务架构的典型开源实现，目前在业界取得了广泛的应用，其性能和稳定性得到了广泛地验证。甚至新一代的Ali-Dubbo微服务架构也广泛采纳了其组件实现。
上述微服务架构相对于SOA架构而言，具有以下优势：
1、统一的服务网关隔离外部与内部微服务群，提供统一的登陆与访问认证，具有更好的安全性；
2、服务网关并不单一面向API接口级，也提供页面请求等服务动态路由；
3、各个微服务子系统启动和停止时，将在集中的服务注册与发现模块完成注册与注销，并将动态扩散到服务消费方，从而提供更为即时的服务可用性管理机制；
4、实际上，该架构也具有更好的扩展性，例如：在服务网关提供集中的访问与操作日志审计，对接企业单点登陆系统更加方便，可以提供集中的智能运维自动化平台的用户与权限管理等。
2.2、采控层总体设计
智能采控层实现对各软硬件资源的运行监测采集和自动化运维操作执行管控。
针对采集，采控层由多个监控中心组成，各监控中心彼此间不存在直接联系。监控中心按照“分布式就近采集”的原则，一个监控中心负责一个业务系统的应用业务监控采集任务。
每个监控中心由“监控中心采控控制器”和该控制器控制下的采集协议、插件采集、探针采集组成。协议、插件、探针分别适用于不同监控采集场景。
各个监控中心之间，通过“Zookeeper分布式应用程序协调服务”实现负载均衡。
监控中心控制器节点基于JMX标准架构实现，除在背板级提供节点内共享的与RabbitMQ/Kafka消息队列的通讯服务外，提供了注册服务配置文件以支持采用配置方式组装需要的各项服务和扩展新的服务，且通过配置方式实现服务级的两种集群模式：负载均衡式和主从式；监控中心控制器节点装配有专门的服务，负责基于RabbitMQ完成对各个本监控中心从属的插件和探针的配置与控制信息下发和状态的管理，包括：插件/探针的监控启动、停止等操作。
总体上讲，智能采控层实现如下技术功能：
监控中心采控控制器（Agentless、Agent）：主要针对协议采集、Agent、区域中心Agent等采集方式提供集中的管控功能。包括：自动发现、集中协议对接方式监测采集、Agent管控、区域中心Agent管控、采集策略控制、告警策略控制、健康度管理、云CMDB同步、数据清洗转换与上送、消息分发、多采集中心数据汇集。
提供Agentless、Agent、区域中心Agent等多种采集方式进行监测采集。可用于资源运行状态的监测采集和配置扫描发现。
Agentless无插件方式提供各种通信协议对接，包括：SOAP/REST、HTTP(S)、SSH、JDBC、Telnet、JMX、TuxedoATMI、SNMP、WMI、FTP、SMTP、POP3、WQL、MQIjava（IBMMQ）IPMI、SMI-S…等，支持各类软硬件设备的监测采集。
Agent插件方式：实现本地OS级监测采集和本地日志采集，同时可支持运维操作执行能力。（日志采集插件有待进一步整合）
区域中心Agent方式：面向局域设备区，提供基于SNMP、JDBC、SSH、Telnet等协议的集中协议对接采集方式。该方式主要用于诸如防火墙隔离内设备群的监测采集。
Ansible实现自动化运维操作执行与管控，基于Python开发，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。
Saltstack一种全新的基础设施管理方式，部署轻松，在几分钟内可运行起来，扩展性好，很容易管理上万台服务器，速度够快，服务器之间秒级通讯。
基于统一接口以及各应用系统协议（SOA（SOAP），TUXEDO、Webservice，消息队列
2.3、数据层总体设计
由多元数据库组成，提供配置管理、监测、运维服务管理、任务自动化等场景下的各类数据的集中存储，并为运行支撑层提供数据源服务。
Redis内存数据库
主要用作设备指标实时轮询结果的保存，供web管理控制台属性浏览使用。
DRDS或RDS数据库
关系型数据库采用RDS，具有即开即用、稳定可靠、可弹性伸缩等特点。用作汇集中心及监控中心的CMDB数据存储，报表数据、事件及告警的存储，提供读写分离功能。
OpenTSDB/HBase
时序数据存储采用OpenTSDB/HBase进行存储，主要用于监控系统，譬如收集大规模集群（包括网络设备、操作系统、应用程序）的监控数据并进行存储，查询。
提供分布式计算、分布式存储能力，对分析、挖掘业务系统的故障根因分析，容量分析，告警通知，黄金指标分析等提供计算和存储资源。
OrientDB、MongoDB
配置模型等非关系型数据存储采用OrientDB、MongoDB。
ElasticSearch
ElasticSearch是一个分布式、高扩展、高实时的搜索与数据分析引擎。它能很方便的使大量数据具有搜索、分析和探索的能力。充分利用ElasticSearch的水平伸缩性，能使数据在生产环境变得更有价值。
Elasticsearch还可作为调用链追踪采集数据的存储，同时作为FileBeat，PacketBeat等日志及抓包数据的存储，ES提供了全文检索及聚合分析引擎。
OSS
用来实现虚机镜像文件存储等。
2.4、运行支撑层
Zookeeper
提供kafka，Hbase，spark，hive，agent等集群的高可用能力。
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
Activiti
提供运维服务管理、自动化执行编排调度等流引擎程驱动。
Activiti项目是一项新的基于Apache许可的开源BPM平台，从基础开始构建，旨在提供支持新的BPMN2.0标准，包括支持对象管理组（OMG），面对新技术的机遇，诸如互操作性和云架构，提供技术实现。
Spark
Spark实时分析挖掘子系统是基于Spark2.0集群的一组数据实时聚合、分析挖掘和提供hiveforspark查询服务的数据聚合与智能分析服务，采用hadoop提供的Hbase作为基础NoSql数据库。
Spark是专为大规模数据处理而设计的快速通用的计算引擎，Spark，拥有HadoopMapReduce所具有的优点；但不同于MapReduce的是——Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。
2.5、统一用户管理
2.6、应用前端交互层
面向用户的可管理的能力，采用H5、CSS、VUE.js和AngularJS。
基于前后端分离设计，采用目前较为流行的前端框架，面向数据编程，减少与后端开发的粘滞性，使用统一的页面风格，带给用户更好的交互体验。
2.7、前端访问负载均衡层
Nginx
实现Web访问的负载均衡、反向代理等。
Nginx是一款开源的、自由的、高性能的HTTP和反向代理服务器，一般在WEB应用中将其作为反向代理进行负载均衡的实现。Nginx使用基于事件驱动架构，支持跨平台使用，其特点是占有内存少，并发能力强。
2.8、微服务运行平台
微服务运行平台旨在支撑微服务化后的产品间的相互功能调用，同时对微服务的一些基础管理。
微服务设计中主要的功能包括：服务注册与发现、服务网关、服务通信、服务治理、配置管理。
服务注册与发现：解耦服务之间的依赖关系，只需要在固定配置文件中配置，同时对服务进行管理，保留正常提供功能的服务，去除宕机的服务；如SpringCloud体系中的Eureka注册中心。
服务网关：为微服务提供统一入口点，并支持请求动态路由，达到内部和外部隔离，保障后台服务安全性，同时可使用一系列过滤器进行请求前的权限校验、访问信息限制等；如SpringCloud体系中的Zuul网关。
服务治理：针对与微服务的一系列监控治理，不限于服务日志、链路跟踪等信息采集和监控分析，以及请求限流、服务容错等，是从宏观上对微服务的一个管理；如SpringCloud体系Hystrix限流降级、Admin服务监控、Sleuth链路跟踪等。
配置管理：针对多环境、多集群环境下的微服务配置管理，实现分组配置管理、配置实时生效等功能；如SpringCloud体系中Config配置中心、携程自研Apollo配置中心。
2.9、运维数据总线
提供消息订阅/发布机制，实现各组件之间数据传输。
RabbitMQ
主要用来实现两个功能：1）监控中心对插件及探针的采集策略的控制数据通讯；2）监控中心采集的指标数据传输给汇集中心。
Kafka消息队列
主要用作插件及探针采集指标数据的消息队列，同时用作Spark实时分析挖掘系统的数据源消息队列。
三、部署架构
本系统部署架构如下所示：
在系统软硬件配置上，采用利旧加增补原则。
四、项目过程管理
截至目前，项目已经过2期建设。
第一期：2020年当年建设当年投产。
第二期：2023年当年建设当年投产。
五、运营情况
该系统从投产至今已经运行两年多，运维功能范围覆盖中邮保险IT运维各环节，包括：基础监控、应用监控、业务监控等全IT环境监控；支撑各类服务请求管理、事件管理、问题管理、变更管理，发布管理、配置管理、知识库管理、需求管理、软件开发管理等各类运维服务调度管理；支撑巡检、备份回复、系统启停、系统发布更新等各类运维自动化作业。系统使用部门覆盖总公司、省分公司各级部门，包括运维部门各级人员、业务部门各级人员，目前，平均每天在线用户数达1500余人，平均日处理服务单500张以上，系统运行稳率99%以上，较好地支撑了中邮保险运维服务管理。
六、项目成效
通过两年多持续建设，已经构建了“全息化监采、精准故障定位、故障自愈、主动优化”的闭环运维能力框架。随着该系统的建设和推广，呈现出了良好的使用效果：1、有效保障了中邮保险各业务系统的稳定运行，确保中邮保险各项业务连续性始终维持在99%以上，从IT保障环节促进中邮保险业务稳定增长；2、运维数据的深入分析利用，深度挖掘各业务运行瓶颈，为业务系统软件优化方向提供有效数据指导支撑；3、在充分保障业务连续性的基础上，系统规划建设过程始终遵循降本增效原则，软硬件投入充分利旧，始终维持在在低水平，做到低成本投入高效益产出。
该系统的建成和使用，为满足管、监、控、服、智一体化智能运维的进一步场景化落地，为中邮保险运维服务更上一层楼打下坚实基础，为公司业务发展、运营管理提供有利保障。
七、经验总结
1.充分理解运维能力的时态特性
运维能力具有开发时态和使用时态两种特性。
在开发时态，运维能力更多体现为开发特性，包括运维各种场景下的模型组件定义，如：
面向资源基本数据结构的CMDB模型管理，如：资源模型定义、资源关系定义等；
面向运维人力调度与自动化调度流程调度模型组件管理，如：面向一线人员的服务请求、事件管理、问题管理、变更管理等；
面向运维自动化的自动化模型组件管理，如：原子脚本组件库的构建、作业编排、作业模板等；
面向智能分析的算法模型组件，如：数据清洗、聚合、回归分析等。
在运维能力使用时态，则基于上述模型组件定义，围绕“发现问题、定位问题、解决问题、主动预防”的运维工作主线，呈现出：IT资源配置管理管理、智能综合监控与一键诊断、自动化运维、统计分析与运维决策支撑等各大类场景应用。
区分上述两种时态特性，有助于建设运维平台时，从总体上把握运维平台的支撑能力的层次划分。
2.科学规划运维能力框架，保障运维能力持续鲜活
从功能设计方面，在本项目建设中，进行科学合理的运维能力框架体系规划，注重运维能力时态特性的分析、注重覆盖“监管控防”诸方面要求的运维能力的设计规划，是指导项目建设成功、以及保证未来能够持续运维能力建设的重要依据，是运维能力保持鲜活的保障。
3.运维能力建设始终围绕降本增效原则
更多金融科技案例和金融数据智能优秀解决方案，请在数字金融创新知识服务平台-金科创新社案例库、选型库查看。