经过两年多的努力，在 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 的优势主要体现在如下三个方面：

以应用为中心。建立自动化、智能化运维体系，从应用的角度规划管理各种运维场景。因此，在 CMDB2.0 的模型设计上，我们坚持以应用为中心，全面梳理和分析行内的运维对象及关系，从物理层、逻辑层和应用层几方面分层构建模型。通过该模型中所定义的配置项及关系，可帮助应用运维在日常工作中快速查询和了解整体应用资源对象和拓扑关系，提升变更发布、故障分析等运维工作效能。

图 1 微众银行配置模型框架

重视系统的灵活性百思特网和可扩展能力性。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 已发展为运维同事管理和获取配置数据的首选系统，平台对接需求应接不暇。目前管理配置项总计 22百思特网6 个，其中关键配置项通过流程维护和接口同步更新占比 72%。同时服务行内其他运维系统 50 个，提供系统接口超 300 个。

在服务数据化运营以及支持智能化运维方面，CMDB 已成为微众银行自智能化运维体系体系中不可缺少的成员。

• 驱动业务流程：CMDB 为各业务流程提供高质量的配置数据，所有业务系统架构设计、资源申请、上线部署和运行维护等流程，均是通过 CMDB 与多个系统的协同运作来驱动落地。当前仅 ITSM 系统中对接 CMDB 更新或查询数据的流程已超过 200 个。
• 服务数据化运营：支持服务容量规划、成本核算、业务运营分析等场景，例如容量管理系统基于 CMDB 数据可提供业务整体资源利用率数据和各业务使用量数据分析报告。
• 支持智能化运维：基于 CMDB 数据关系，通过监控系统端到端视图辅助故障诊断定位、根因分析，使故障快速恢复和及时发现，已成功实现了对我行智能化监控系统这种复杂需求场景的有效支持。

图 6 CMDB 数据辅助智能监控系统故障定位、根因分析

CMDB 的构建仍是一个持续迭代优化过程，2020 年我们基于微服务构建 CMDB3.0，期望 CMDB 能够通过开源平台的方式提供服务，同时实现配置项自动发现，图像化元数据关系展示以及数据异常自动化修复等方面进一步提升。未来 CMDB 的运行效果我们会继续分享给大家，希望大家持续我们的演进脚步。如果希望了解我们在智能运维中使用的机器学习算法以及支持根因分析的具体方法，请参阅该系列其他文章。

作者简介

本文作者为微众银行智能运维系统高级产品经理 杨芳

延伸阅读：

我们的CMDB模型是不是都错了-InfoQ

爱奇艺MySQL高可用方案概述-InfoQ

从Oracle到MySQL，金融核心场景在线换库落地实战-InfoQ

我并转发此篇文章，私信我“领取资料”，即可免费获得InfoQ价值4999元迷你书，点击文末「了解更多」，即可移步InfoQ官网，获取最新资讯～