背景
随着企业的业务量不断增长，运维所要纳管的网络设备、物理服务器、应用服务器等基础设施都会相应的增加，此时我们需要面对以下几个问题：
- 如何管理基础设施的整个生命周期
- 如何记录基础设施的SN、管理IP、业务IP、维保等信息
- 如何做到虚拟机和物理机的差异性管理
- 如何做到管理IP和业务IP的一致性管理
- 如何关联业务IP和应用服务
这些问题由于不影响业务的正常运行，因此常常被我们所忽略；但是如果管理不得当，在后续的资产盘点、业务扩容等工作中都会让我们头痛不已，为之前工作上的疏忽懊恼不已。
此时我们会不由自主的产生以下几个疑问：
- 我们物理机、虚拟机各有多少？
- 我们的资产都用在哪里了？
- 现在还有没有空闲资产？
与其让问题找到我们，不如我们主动去解决问题，这就是我们运维的一贯作风！
配置管理数据库( Configuration Management Database,CMDB)是一个逻辑数据库，包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。
CMDB存储与管理企业IT架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。
我的理解是，CMDB 在运维体系中承担管理基础设施，为上层应用场景提供可靠的数据支撑的角色。CMDB虽然能够将基础设施进行统一纳管，并且可以和业务应用进行关联，在一定程度上是利好运维的，但"CMDB成为摆设、花瓶"的现象还是存在的。
因此，CMDB好用和用好，差别还是挺大的。
下面我们将结合蓝鲸CMDB从好用和用好的角度来深入了解下。
蓝鲸CMDB
为了更好的了解本文，我们先来了解下蓝鲸CMDB。
蓝鲸配置平台（蓝鲸CMDB）是一个基于运维场景设计的企业配置管理服务。主要功能：
- 拓扑化的主机管理：主机基础属性、主机快照数据、主机归属关系管理；
- 组织架构管理：可扩展的基于业务的组织架构管理；
- 模型管理：既能管理业务、集群、主机等内置模型，也能自定义模型；
- 进程管理：基于模块的主机进程管理；
- 事件注册与推送：提供基于回调方式的事件注册与推送；
- 通用权限管理：灵活的基于用户组的权限管理；
- 操作审计：用户操作行为的审计与回溯；
实验环境
| 业务 | 集群 | 模块 | 主机 | 服务器类型 | 管理IP | 购买日期 |
|---|---|---|---|---|---|---|
| test1 | cluster2 | app1 | 192.169.5.120 | 物理机 | 172.16.5.120 | 2022-04-18 |
| test1 | cluster2 | app2 | 192.169.5.121 | 虚拟机 | 172.16.5.121 | 2022-04-18 |
| test1 | cluster1 | app3 | 192.169.5.122 | 虚拟机 | 172.16.5.122 | 2022-04-18 |
| test2 | X | X | X | X | X | X |
好用
1.模型管理
CMDB中的模型是对同类配置实例进行标准格式的定义，例如主机有不同的配置记录：
- 服务器类型
- 管理IP
- 购买日期
- 质保期限
- 固资编号
- 服务器品牌
- 服务器型号
- 机柜
- 机房
- 等等
此时我们可以定义主机模型，以保证相关配置录入CMDB的时候必须包含所需信息。 另外，除了属性列表以外，模型还能够定义其他相关字段等。
另外，除了主机模型外，我们还可以按需创建其他模型并对其进行分组：
- 组织架构，如业务
- 业务拓扑，如模型、集群
- 网络，如交换机、路由器、负载均衡、防火墙
- 数据库，如MySQL、Oracle
2.业务拓扑
业务拓扑是配置平台进行主机管理的基础，只有建立合适的业务模型，才能结构化的管理好主机。CMDB配置平台提供用户结构自定义、拓扑属性自定义等功能。
通过业务拓扑，我们可以按集群、模块将业务进一步划分，以便将服务器与业务应用进行关联，清晰的了解业务下主机数量。
3.多条件筛选
对于已经纳管的服务器，我们可以按不同需求进行多条件筛选，条件可以根据主机相关字段进行，例如：
- 按模块筛选
- 按管理IP筛选
- 按服务器类型筛选
- 按其他字段筛选
通过筛选可以快速解决我们的需求，如：
- 生产环境服务器数量共有多少
- 物理机、虚拟机各是多少
- x.x.x.x 的管理IP
- x.x.x.x 属于哪个业务应用
- x.x.x.x 服务器哪一年购买的，是否维保过期
4.权限分离
对应于运维岗位可能进一步划分为基础运维和应用运维的，其中：
- 基础运维，主要负责网络设备、物理机、存储等基础设施；
- 应用运维，主要负责应用服务器、业务应用与业务相关的资源；
由于基础运维和系统运维主要区分在于是否和业务相关，CMDB可以帮助我们进行权限隔离，即：
- 系统权限：可管理所有模型的查询、编辑、删除等
- 业务权限：分角色管理业务下所有集群、模型、主机编辑和转移等
通过权限隔离，我们可以更好的根据岗位进行权限划分，各司其职、各尽其责。
5.小结
通过通用的功能，CMDB满足了我们约80%的基础设施管理需求，“好用”可以说是实至名归。但剩余的20%是我们的痛点，CMDB能不能进一步满足我们呢？那么这就需要我们将CMDB用好，来满足我们20%的痛点需求。
用好
1.服务器上架痛点
背景
由于运维的岗位进一步划分为基础运维和应用运维，针对服务器上架场景基础运维和应用运维的工作如下：
基础运维： 1.新服务器上架； 2.CMDB维录入新服务器的资产信息，如管理IP、品牌、型号、维保等信息；
应用运维： 1.CMDB将服务器转移到相关业务、应用下； 2.在监控平台、堡垒机中添加相关主机信息；
此时可能大家觉得没毛病啊，但是我们忽略了CMDB的主机管理是以业务IP为主键的，这就意味着基础运维在新服务器上架时必须确定服务器的业务IP，否则无法导入CMDB，但业务IP的确定是滞后的，由应用运维确定，此刻我们的上架流程就出现了问题。
解决方案
分析痛点导致资产无法导入CMDB的原因为业务IP和管理IP同时存在于主机模型中，因此我们需要将他们分别隶属于不同模型。由于业务IP肯定属于主机模型了，因此我们新增并扩充了以下三个模型，并且专门由基础运维管理：
- 机房，主要是机房位置
- 机柜，主要是机位信息
- 物理机，主要是管理IP、品牌、型号、维保等信息
其中我们将硬件服务器的主要字段都放到物理机这个模型中，而主机模型虽然包含了物理机和虚拟机，但是只有业务IP，而不包含管理IP及其他字段信息。
此时大家可能会有一个问题：物理机的业务IP如何与管理IP进行关联，以应对物理机故障的风险？ 因此我们需要对CMDB进一步深入探索：关联管理。
通过关联管理，我们可以做到：
- 将物理机与机柜、机房进行关联
- 将主机（主要是带有业务IP的物理机）关联到物理机模型，而虚拟机无需关联
通过关联关系，我们可以清晰看到物理机的业务IP、管理IP及机柜、机房信息。
小结
通过新增物理机、机柜、机房模型以及关联关系，在权限隔离的基础上，我们实现了：
- 基础运维与业务运维的操作分离
- 基础运维管理物理机、机房、机柜之间的关系
- 应用运维管理虚拟机、物理机与业务之间的关系
权限隔离、操作分离正好解决了我们服务器上架的痛点。
2.CMDB打通堡垒机与监控平台
前面提到的“CMDB为上层应用场景提供可靠的数据支撑”，虽然我们实现了业务与主机的关联，但是CMDB与运维平台的隔离成了我们运维自己的一个痛点。在给业务做好服务的同时，我们也不能亏待了自己啊。
因此我们需要通过“事件注册与推送：提供基于回调方式的事件注册与推送；”实现CMDB打通堡垒机与监控平台，实现：
- CMDB与堡垒机联动，保证堡垒机资产分组与CMDB一致；
- CMDB与监控平台联动，保证监控平台的主机分组和CMDB一致；
我们的目的是保证CMDB数据的权威性，这样做才能够避免"CMDB成为摆设、花瓶"。
CMDB提供的事件推送可以对接第三方系统，因此我们可以自行开发系统来与其对接，完成CMDB打通堡垒机与监控平台的最后一步。
本章部分在此就不做过多赘述，大家有兴趣的可以参考之前的问题。 《事件推送网关：让cmdb告别“花瓶”》
总结
对CMDB的使用我们也曾停步于好用阶段，但是对于痛点需求没有停止过思考，团队间充分的沟通与讨论让我们克服了这最后20%的痛点，因此运维请相信团队的力量。
