cmdb是什么(djangocmdb) 智能时代下的运维构建CMBD系统

构建 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 个方面功能特性：