从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
- 建立业务场景
- 建立模型蓝图
- 模型设计
- 关联设计
- 建设CMDB工具
- 建立模型以及梳理业务数据
- 系统打通集成以及业务场景落地
第一步是建立业务场景，必须想清楚建设CMDB是为了什么，仅仅是把数据存放起来以便需要用的时候查看吗？
配置数据应当发挥更大的价值，如基于CMDB建设自动化运维场景、结合监控做可视化大屏等；
第二步是建立模型蓝图，即CMDB中需要包含哪些内容。其中包括：
- 模型设计，如应用、中间件、数据库、虚拟机、物理机、网络设备等；
- 关联设计，如应用与中间件的关联性、虚拟机与物理机的关联性；
第三步是建设CMDB工具，需要有一个高度灵活、高性能的CMDB工具，可以进行模型的动态扩展、配置项的动态扩展、模型关系的动态设置，以便适应企业的发展带来的变更；
第四步是建立模型以及数据梳理和录入，也就是要把之前设计好的模型蓝图，在CMDB工具中落地，并梳理好实例数据进行初始化录入；
最后一步是将CMDB与各个系统打通集成，落地规划的业务场景，让CMDB充分扮演好它的角色，持续的驱动配置数据的价值。
模型设计
模型设计中，模型对象一般包含：应用、集群、模块、进程、软件包、中间件、数据库、虚拟机、物理机、存储、机柜、机房等。模型对应的CI不宜过多，原则是业务上必须用到的保留、可自动化采集的保留、可有可无的尽量舍弃。
关联设计中，以应用为出发点去进行设计，如下图所示，自下而上，直接或间接影响业务应用的因素一目了然。
数据的质量
CMDB工具建设好了，配置数据也落地了。
但配置数据的维护是一个很有挑战的事情，因为我们不仅需要维护频繁变更的配置数据，还须保证数据的准确性和一致性。
这里提供几种方法来改善这个问题。
- 数据的规则校验 这种方法可以在一定程度上提高数据的准确性，防止误操作或不规范的录入行为造成数据质量问题。比如正则校验、类型校验、必填和唯一性校验等；
- 自动采集 利用脚本、接口、协议等方式自动采集配置信息，降低人工维护成本的同时，可以极大提高数据的准确性；
- 外部系统集成 如与流程平台、资产系统、网管系统等做集成，将无法自动采集的配置信息通过接口同步的方式自动录入；
- 数据差异分析 周期性的与基准信息进行对比，分析出差异并进行告警。
配置自动采集
配置的自动采集依赖于采集工具，可以采用第三方的采集工具，但更灵活可控的方式是自己开发一个采集工具。
如下是一种扩展性较好的采集工具的架构方案：
- 在CMDB的旁侧，建立配置自动采集工具，通过接口的方式与CMDB进行集成；
- 同步原理是每次从两边分别获取全量数据进行对比分析，这样可以保证同步的一致性。防止因为初始化或工具的问题导致同步误差；
- 采集工具拥有配置采集器、数据获取和上报、数据对比分析等核心模块，通过任务调度模块的周期性驱动，让各个模块协调工作，定期的完成数据的采集、对比分析，将增量（增加、改动）的数据同步至CMDB仓库；
- 配置采集器的设计，可以让工具扩展性更加良好。针对不同的采集对象，定制开发不同的采集器来进行横向扩展；
- 通常采集的方式有脚本执行、接口对接、通用协议、数据视图等方式。
消费场景的建设
前面说到，配置数据消费非常关键，是一个CMDB项目成败的关键。那么基于CMDB我们可以做一些什么事情？
举些消费场景的例子：
- 做应用的故障分析时，需要用到应用的拓扑信息；
- 做服务器资源自动交付时，需要用到应用、集群、模块等配置信息；
- 做巡检需要用到巡检对象的配置信息；
- 结合监控可以做业务的可视化大屏展示；
- 应用的发布、扩缩容等，需要知道应用部署在哪些服务器以及相应服务器的配置信息；
- 自动化运维工具的建设，也需要用到各种配置信息。如数据库的操作管理，需要知道有哪些数据库以及它的IP地址、数据库类型、实例名等配置信息。
小结
本文提供的建设思路，其关键点是视角的转变，将传统以资产为中心的大而全的CMDB，转变为以应用为中心，更自动、更轻量的方式来进行建设，将更多的精力关注在数据的消费和价值的体现上，从而让CMDB在企业的IT架构中发挥更重要的作用。