智能运维系列专题简介：智能运维（AIOps），根据Gartner的最新阐释，意指整合大数据和机器学习能力，通过松耦合、可扩展方式去提取和分析数据量（volume）、种类（variety）和速度（velocity）这三个维度不断增长的IT数据，进而为IT运维管理产品提供支撑。在此，微众银行智能运维团队根据一线工作的实践经验与心得体会，特别撰写了《智能运维系列》文章，本公众号后期将陆续发布，敬请持续关注。
点击回顾：智能运维系列（三）| 浅析智能异常检测——“慧识图”核心算法
点击回顾：智能运维系列（五）| 浅析基于知识图谱的根因分析系统
点击回顾：智能运维系列（六）| 根因分析过程中的运维管理实践
点击回顾：智能运维系列（七）| 化繁为简–业务异常的根因定位方法概述
点击回顾：智能运维系列（八）| 事件指纹库：构建异常案例的“博物馆”
点击回顾：智能运维系列（九）| 基于交易树的根因告警定位方法
点击回顾：智能运维系列（十一）| 日志文本异常聚类及相似度检测
点击回顾：智能运维系列（十二）|智能运维的四大挑战和应对之道
经过两年多的努力，在2020年微众银行智能化运维建设终于取得了明显成效，在智能监控领域的异常识别及根因定位方面发挥了巨大作用，甚至可以做到了秒级异常发现与定位。CMDB系统（配置管理平台Configuration Management Datebase）作为智能化运维体系的基石与保障，除了承担存储和元数据支撑以外，也为智能化运维体系的正常运作、敏捷扩展提供了有力保障。本文将结合具体实践，介绍微众银行面向智能化运维的CMDB系统构建历程以及实施效果。
构建CMBD系统的三个阶段
1. CMDB1.0所面临的痛点
在2015年微众银行成立之初，微众银行构建了CMDB1.0。CMDB1.0吸取了开源项目oneCmdb的经验， CI模型配置结合key-value形式存储CI数据，灵活地支持了当时的银行基础架构建设的初级阶段。但随着不断扩大的银行业务规模，配置项越来越多样，科技类的工具系统如雨后春笋般建立起来。在此过程中，CMDB1.0的架构在系统间对接方面，配置项多样性模型建设方面，以及数据量急速增加方面的可扩展性表现得越来越差，同时用户体验方面也暴露出很多问题。在这个阶段，痛点和不足主要表现为：
- 模型定义不完整：CMDB中管理的配置范围、配置数据覆盖不全，配置关系及属性定义不完整，无法有效支撑日常运维的基础诉求。
- 数据维护成本高：未建立配置信息的生命周期管理流程，无法达到自动更新维护数据的目的。当时，CMDB中数据的采集和变更严重依赖人员维护，维护成本高，数据滞后于真实运行情况，甚至部分配置信息在系统外维护，CMDB未能发挥应有的作用。
- 数据质量无法保证：缺乏数据之间逻辑规则校验机制以及数据同步校验机制，数据准确性和数据质量无法保证，运维人员不信任CMDB。
2. 面向智能化运维的CMDB2.0系统构建
从2016年开始，为构建自动化智能化运维体系，同时满足微众银行分布式架构的运维管理要求，我们重新规划搭建起了为支撑各运维场景，提供准确灵活基础数据能力的新一代CMDB系统，并彻底解决了CMDB1.0阶段所面临痛点。我们以应用为中心，通过自研提供完整的、准确的，能全网管理运维对象和关系存储的模型，实现了与运维系统的灵活衔接。CMDB2.0的优势主要体现在如下两个方面：
（1）以应用为中心。建立自动化、智能化运维体系，从应用的角度规划管理各种运维场景。因此，在CMDB2.0的模型设计上，我们坚持以应用为中心，全面梳理和分析行内的运维对象及关系，从物理层、逻辑层和应用层几方面分层构建模型。通过该模型中所定义的配置项及关系，可帮助应用运维在日常工作中快速查询和了解整体应用资源对象和拓扑关系，提升变更发布、故障分析等运维工作效能。
图1 微众银行配置模型框架
（2）重视系统的灵活性和可扩展能力。CMDB2.0一方面需要提升配置模型的管理能力，即快速灵活的实现模型随着业务变化而调整、修正和扩展，满足各个运维团队对于配置数据的深度和广度的需求；另一方面，也需要提高配置数据的易用性，帮助用户或其他运维系统便捷、高效地查询和引用CMDB数据。在这个思路下， CMDB2.0管理平台具备如下6个方面功能特性：
- 配置模型动态扩展：在线动态定义配置项，以及配置项的属性、关系、数据类型、唯一性、组合关键字等；
- 定义多维度查询：支持在线自定义多项配置数据联合查询，以及全站检索；
- API接口动态生成：支持在线定义API接口，支持在线测试、验证接口准确性；
- 细粒度权限管控：实现行级列级的数据权限控制；
- 多维度日志查询：全站数据变迁的历史追溯；
- 版本基线比对及回退：支持配置模型版本和配置数据的版本基线比对及回溯。
图2 CMDB系统API接口在线调试功能
3. 微服务架构下的CMDB 3.0
随着外围系统对CMDB2.0的依赖越来越大，系统间调用关系越来越复杂， CMDB2.0各模块耦合高，一个服务节点同时支持规则、审计，报表、接口等功能，如果一个功能点异常可能会影响整个平台服务。于是，CMDB3.0进行了微服务架构升级，把系统接口调用、web用户访问，规则处理、数据处理等按功能模块抽离成单个微服务应用，使用Dubbo框架进行微服务治理，另外3.0WEB前端是基于VUE自研的框架，改善了用户体验，提高了团队开发协作能力，降低了开发风险。
图3 CMDB演进过程
CMDB系统的设计思路：多维度确保数据的准确性
数据准确性是CMDB的生命，我们通过数据维护流程自动化、促进数据消费、数据审计等多维度保证数据的准确性，并提升使用价值，主要包括以下几个方面：
1.建立数据生命周期管理，自动化流程驱动数据更新
CMDB2.0在建设之初，就定义了每个配置项从生产、运营、消亡的整个生命周期，并通过设计与之匹配的ITSM流程自动化驱动生命周期状态流转，实现了数据闭环管理。同时，识别每个阶段会影响的属性及关系，保证配置模型的完整性。
图4 服务器生命周期状态变更流程
2. 与多个运维工具对接，促进数据消费，提高数据流动性
结合实际运维场景，与其他运维平台联动，数据被积极消费，在其他工具中体现CMDB信息的最大价值。数据被广泛应用才能保持鲜活的生命力。如同池塘里的水，只有水不断流动和交替，水质才能清澈。基于灵活API服务，微众银行CMDB2.0已实现与ITSM、监控平台、容量平台、应用发布平台、基础科技工具平台以及智能化运维平台等系统对接。用一个子系统从设计到运行的整个生命周期为例，展示数据联动的消费及流动过程如下。
图5 CMDB和各运维系统交互实现数据消费及流动
3. 通过规则校验以及人工审计确保及时发现和修复异常数据
为了保证数据准确性，通过规则校验、系统之间的信息同步比对以及人工抽样审核的方式的定期审计。持续检视和优化生命周期管理，不断改善数据质量。微众银行关键配置项准确率达到99%以上。
表1：CMDB自动审计规则示例
实施效果及未来展望
自2017年起，CMDB得到全面推广和运作。从这三年的运营效果来看，CMDB有效支撑了上层业务运维, 其健壮性、灵活度及准确性得到了广泛认可，已成为运维同事信任的好伙伴。在应用规模上看，CMDB已发展为运维同事管理和获取配置数据的首选系统，平台对接需求应接不暇。目前管理配置项总计226个，其中关键配置项通过流程维护和接口同步更新占比72%。同时服务行内其他运维系统50个，提供系统接口超300个。在服务数据化运营以及支持智能化运维方面，CMDB已成为微众银行智能化运维体系中不可缺少的一员，主要体现在以下几个方面：
- 驱动业务流程：CMDB为各业务流程提供高质量的配置数据，所有业务系统架构设计、资源申请、上线部署和运行维护等流程，均是通过CMDB与多个系统的协同运作来驱动落地。当前仅ITSM系统中对接CMDB更新或查询数据的流程已超过200个。
- 服务数据化运营：支持服务容量规划、成本核算、业务运营分析等场景，例如容量管理系统基于CMDB数据可提供业务整体资源利用率数据和各业务使用量数据分析报告。
- 支持智能化运维：基于CMDB数据关系，通过监控系统端到端视图辅助故障诊断定位、根因分析，使故障快速恢复和及时发现，已成功实现了对我行智能化监控系统这种复杂需求场景的有效支持。
图6 CMDB数据辅助智能监控系统故障定位、根因分析
CMDB的构建仍是一个持续迭代优化过程，2020年我们基于微服务构建CMDB3.0，期望CMDB能够通过开源平台的方式提供服务，同时实现配置项自动发现，图像化元数据关系展示以及数据异常自动化修复等方面进一步提升。未来CMDB的运行效果我们会继续分享给大家，希望大家持续关注我们的演进脚步。如果希望了解我们在智能运维中使用的机器学习算法以及支持根因分析的具体方法，请参阅该系列其他文章。
（作者系微众银行智能运维系统高级产品经理 杨芳）
该文章转自公众号：金融科技微洞察
转载请注明出处
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/294004.html