从0到1的CMDB建设思路

CMDB存储与管理企业IT环境中各种对象的配置信息，为运维场景提供配置数据服务，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值。

好的CMDB建设可以发挥很大的价值，本文提供一种新的建设思路，供大家参考。

传统CMDB为什么不好用？

大家都知道CMDB是企业IT管理的基石，是非常重要的IT功能模块，但是却总是感觉不够用、不好用，不能建立一套真正适合自己企业的CMDB。

传统的CMDB有如下五大痛点：

覆盖不足

配置对象、对象属性和关联关系无法自定义扩展；

数据质量差

难以确保数据的准确性和一致性，难以做到自动发现配置信息；

配置孤岛

配置数据仅仅存储静态资产信息，没有把配置消费起来；

审计困难

变更记录不能完整体现，信息更改难以完全审计；

管理复杂

要求纳管的配置项过多，配置管理流程复杂，需要有专职的配置人员（配置经理、配置管理员）来维护CMDB，而配置数据价值难以体现，企业一般难以单独投入这些资源；配置信息不全，实时信息不完整，无法与流程联动。

优秀的CMDB长啥样？

配置管理数据库（CMDB）是一个数据集合，存储所有配置管理的数据和信息。配置管理数据库是配置管理流程的核心，也为事件管理、问题管理、变更管理提供了查询、诊断、记录的基础。配置管理流程负责管理配置项的策略定义、收集、维护以及审核，以确保配置管理数据库能够准确地反映现存配置项的实际状况。

一个优秀的CMDB，应该是：

• 可扩展、可消费、有质量和可持续维护的CMDB；
• 可以提供丰富的模型管理，并支持充分自定义配置和修改的CMDB；
• 可以保障数据质量的CMDB；
• 可扩展性强，能充分调用自动化、监控、流程的接口，是作为配置消费的一环的CMDB。

有这样的CMDB吗？

咱们往下看，一个优秀的CMDB的整体设计与架构：

CMDB整体设计与架构

蓝鲸CMDB支持对象配置信息自动采集、支持打通ITSM流程、同时面向消费的新型CMDB。

蓝鲸配置平台是一款面向应用的CMDB，在蓝鲸智云统一监控和运维体系里，配置平台扮演着基石的角色，为应用提供了各种运维场景的配置数据服务。

蓝鲸配置平台本身提供开箱即用的功能，同时社区版平台完全开源，可以根据企业当前和未来的需求自定义开发和部署。

蓝鲸CMDB整体逻辑架构

蓝鲸CMDB功能概述

CMDB在蓝鲸体系中的定位

CMDB整体建设规划

新的CMDB建设思路

视角的转变--以应用为中心

传统CMDB是围绕IT资产为核心进行建设的，无法与业务进行挂钩，体现不出多大的价值。

而新思路视角则是以应用为中心进行，围绕应用来设计模型、配置项、模型关联等，以及建设配置数据消费场景，充分体现CMDB的价值。

建设流程--五步构建好用贴心的CMDB

1. 建立业务场景
2. 建立模型蓝图
   1. 模型设计
   2. 关联设计
3. 建设CMDB工具
4. 建立模型以及梳理业务数据
5. 系统打通集成以及业务场景落地

第一步是建立业务场景，必须想清楚建设CMDB是为了什么，仅仅是把数据存放起来以便需要用的时候查看吗？

配置数据应当发挥更大的价值，如基于CMDB建设自动化运维场景、结合监控做可视化大屏等；

第二步是建立模型蓝图，即CMDB中需要包含哪些内容。其中包括：

• 模型设计，如应用、中间件、数据库、虚拟机、物理机、网络设备等；
• 关联设计，如应用与中间件的关联性、虚拟机与物理机的关联性；

第三步是建设CMDB工具，需要有一个高度灵活、高性能的CMDB工具，可以进行模型的动态扩展、配置项的动态扩展、模型关系的动态设置，以便适应企业的发展带来的变更；

第四步是建立模型以及数据梳理和录入，也就是要把之前设计好的模型蓝图，在CMDB工具中落地，并梳理好实例数据进行初始化录入；

最后一步是将CMDB与各个系统打通集成，落地规划的业务场景，让CMDB充分扮演好它的角色，持续的驱动配置数据的价值。

模型设计

模型设计中，模型对象一般包含：应用、集群、模块、进程、软件包、中间件、数据库、虚拟机、物理机、存储、机柜、机房等。模型对应的CI不宜过多，原则是业务上必须用到的保留、可自动化采集的保留、可有可无的尽量舍弃。

关联设计中，以应用为出发点去进行设计，如下图所示，自下而上，直接或间接影响业务应用的因素一目了然。

数据的质量

CMDB工具建设好了，配置数据也落地了。

但配置数据的维护是一个很有挑战的事情，因为我们不仅需要维护频繁变更的配置数据，还须保证数据的准确性和一致性。

这里提供几种方法来改善这个问题。

• 数据的规则校验 这种方法可以在一定程度上提高数据的准确性，防止误操作或不规范的录入行为造成数据质量问题。比如正则校验、类型校验、必填和唯一性校验等；
• 自动采集 利用脚本、接口、协议等方式自动采集配置信息，降低人工维护成本的同时，可以极大提高数据的准确性；
• 外部系统集成 如与流程平台、资产系统、网管系统等做集成，将无法自动采集的配置信息通过接口同步的方式自动录入；
• 数据差异分析 周期性的与基准信息进行对比，分析出差异并进行告警。

配置自动采集

配置的自动采集依赖于采集工具，可以采用第三方的采集工具，但更灵活可控的方式是自己开发一个采集工具。

如下是一种扩展性较好的采集工具的架构方案：

1. 在CMDB的旁侧，建立配置自动采集工具，通过接口的方式与CMDB进行集成；
2. 同步原理是每次从两边分别获取全量数据进行对比分析，这样可以保证同步的一致性。防止因为初始化或工具的问题导致同步误差；
3. 采集工具拥有配置采集器、数据获取和上报、数据对比分析等核心模块，通过任务调度模块的周期性驱动，让各个模块协调工作，定期的完成数据的采集、对比分析，将增量（增加、改动）的数据同步至CMDB仓库；
4. 配置采集器的设计，可以让工具扩展性更加良好。针对不同的采集对象，定制开发不同的采集器来进行横向扩展；
5. 通常采集的方式有脚本执行、接口对接、通用协议、数据视图等方式。

消费场景的建设

前面说到，配置数据消费非常关键，是一个CMDB项目成败的关键。那么基于CMDB我们可以做一些什么事情？

举些消费场景的例子：

• 做应用的故障分析时，需要用到应用的拓扑信息；
• 做服务器资源自动交付时，需要用到应用、集群、模块等配置信息；
• 做巡检需要用到巡检对象的配置信息；
• 结合监控可以做业务的可视化大屏展示；
• 应用的发布、扩缩容等，需要知道应用部署在哪些服务器以及相应服务器的配置信息；
• 自动化运维工具的建设，也需要用到各种配置信息。如数据库的操作管理，需要知道有哪些数据库以及它的IP地址、数据库类型、实例名等配置信息。

小结

本文提供的建设思路，其关键点是视角的转变，将传统以资产为中心的大而全的CMDB，转变为以应用为中心，更自动、更轻量的方式来进行建设，将更多的精力关注在数据的消费和价值的体现上，从而让CMDB在企业的IT架构中发挥更重要的作用。