CMDB

CMDB 的设计有一个最大的误区是想建立一个大而全的属性表，恨不得想把全部运维对象的全部属性都找出来，比如：
从零散的运维对象来拼凑 CMDB 基本都是吃力不讨好的，因为这样的设计方式根本没有从业务出发。
而真正能解决业务问题的 CMDB 必须回到业务上面来，从核心的三层关系开始组建 CMDB，这三层概念从大到小分别是：业务、集群、模块（游戏行业术语一般叫项目、分区、服务）
设计思路应该是这样的，我所运维一个业务，它有哪些集群？集群下有哪些模块？模块下有哪些机器？机器有哪些属性？各种属性之间有什么关联关系？
通过这样的思维方式慢慢把真正的 CMDB 组织起来......

 

配置项属性
我们把 CMDB 的某个对象称为配置项，一个典型的配置项如一台主机、一个域名、一个 IP 。
举个例子，一台主机，其属性获取的三种方式：
agent 获得：如 cpu、memery、disk、ethX 之类的硬件信息，一般用 python psutil 模块可以获取大部分所需要的属性；
云服务商 api：有部分属性不能通过 agent 获得的如 EIP、Region、Zone 等，如果不是用云主机的就不需要这一部分；
手工维护：有些属性不能自动获取，只能通过人工录入，不过这类属性还是尽量越少越好；
由点到面可以看出，配置项的属性类别基本可以分成三类：

人工录入 ： 自动化系统所需的业务 - 集群 - 模块关系，每台主机运行什么服务等等。
外系统 API： 需要通过云服务商 API、Zabbix API、K8s API、其他业务系统 API 等途径。
自发现： 机器内部获得，如 python psutil、puppet fact、ansible setup 等途径。

 

构建CMBD系统的三个阶段
1. CMDB1.0所面临的痛点

开源项目oneCmdb的经验， CI模型配置结合key-value形式存储CI数据，灵活地支持了当时的银行基础架构建设的初级阶段。但随着不断扩大的银行业务规模，配置项越来越多样，科技类的工具系统如雨后春笋般建立起来。在此过程中，CMDB1.0的架构在系统间对接方面，配置项多样性模型建设方面，以及数据量急速增加方面的可扩展性表现得越来越差，同时用户体验方面也暴露出很多问题。在这个阶段，痛点和不足主要表现为：

模型定义不完整：CMDB中管理的配置范围、配置数据覆盖不全，配置关系及属性定义不完整，无法有效支撑日常运维的基础诉求。
数据维护成本高：未建立配置信息的生命周期管理流程，无法达到自动更新维护数据的目的。当时，CMDB中数据的采集和变更严重依赖人员维护，维护成本高，数据滞后于真实运行情况，甚至部分配置信息在系统外维护，CMDB未能发挥应有的作用。
数据质量无法保证：缺乏数据之间逻辑规则校验机制以及数据同步校验机制，数据准确性和数据质量无法保证，运维人员不信任CMDB。

2. 面向智能化运维的CMDB2.0系统构建

从2016年开始，为构建自动化智能化运维体系，我们以应用为中心，通过自研提供完整的、准确的，能全网管理运维对象和关系存储的模型，实现了与运维系统的灵活衔接。CMDB2.0的优势主要体现在如下两个方面：

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

（2）重视系统的灵活性和可扩展能力。CMDB2.0一方面需要提升配置模型的管理能力，即快速灵活的实现模型随着业务变化而调整、修正和扩展，满足各个运维团队对于配置数据的深度和广度的需求；另一方面，也需要提高配置数据的易用性，帮助用户或其他运维系统便捷、高效地查询和引用CMDB数据。在这个思路下， CMDB2.0管理平台具备如下6个方面功能特性：

配置模型动态扩展：在线动态定义配置项，以及配置项的属性、关系、数据类型、唯一性、组合关键字等；
定义多维度查询：支持在线自定义多项配置数据联合查询，以及全站检索；
API接口动态生成：支持在线定义API接口，支持在线测试、验证接口准确性；
细粒度权限管控：实现行级列级的数据权限控制；
多维度日志查询：全站数据变迁的历史追溯；
版本基线比对及回退：支持配置模型版本和配置数据的版本基线比对及回溯。

3. 微服务架构下的CMDB 3.0

随着外围系统对CMDB2.0的依赖越来越大，系统间调用关系越来越复杂， CMDB2.0各模块耦合高，一个服务节点同时支持规则、审计，报表、接口等功能，如果一个功能点异常可能会影响整个平台服务。于是，CMDB3.0进行了微服务架构升级，把系统接口调用、web用户访问，规则处理、数据处理等按功能模块抽离成单个微服务应用，使用Dubbo框架进行微服务治理，另外3.0WEB前端是基于VUE自研的框架，改善了用户体验，提高了团队开发协作能力，降低了开发风险。

CMDB系统的设计思路：多维度确保数据的准确性
数据准确性是CMDB的生命，我们通过数据维护流程自动化、促进数据消费、数据审计等多维度保证数据的准确性，并提升使用价值，主要包括以下几个方面：

1.建立数据生命周期管理，自动化流程驱动数据更新
CMDB2.0在建设之初，就定义了每个配置项从生产、运营、消亡的整个生命周期，并通过设计与之匹配的ITSM流程自动化驱动生命周期状态流转，实现了数据闭环管理。同时，识别每个阶段会影响的属性及关系，保证配置模型的完整性。

2. 与多个运维工具对接，促进数据消费，提高数据流动性
结合实际运维场景，与其他运维平台联动，数据被积极消费，在其他工具中体现CMDB信息的最大价值。数据被广泛应用才能保持鲜活的生命力。如同池塘里的水，只有水不断流动和交替，水质才能清澈。基于灵活API服务，CMDB2.0已实现与ITSM、监控平台、容量平台、应用发布平台、基础科技工具平台以及智能化运维平台等系统对接。

3. 通过规则校验以及人工审计确保及时发现和修复异常数据
为了保证数据准确性，通过规则校验、系统之间的信息同步比对以及人工抽样审核的方式的定期审计。持续检视和优化生命周期管理，不断改善数据质量。

 

在服务数据化运营以及支持智能化运维方面，CMDB已成为智能化运维体系中不可缺少的一员，主要体现在以下几个方面：

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