运维：CMDB好用和用好，差别还是挺大的！

test2

好用 1.模型管理

CMDB中的模型是对同类配置实例进行标准格式的定义，例如主机有不同的配置记录：

此时我们可以定义主机模型，以保证相关配置录入CMDB的时候必须包含所需信息。

另外，除了属性列表以外，模型还能够定义其他相关字段等。

另外，除了主机模型外，我们还可以按需创建其他模型并对其进行分组：

2.业务拓扑

业务拓扑是配置平台进行主机管理的基础，只有建立合适的业务模型，才能结构化的管理好主机。CMDB配置平台提供用户结构自定义、拓扑属性自定义等功能。

通过业务拓扑，我们可以按集群、模块将业务进一步划分，以便将服务器与业务应用进行关联，清晰的了解业务下主机数量。

3.多条件筛选

对于已经纳管的服务器，我们可以按不同需求进行多条件筛选，条件可以根据主机相关字段进行，例如：

通过筛选可以快速解决我们的需求，如：

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进行关联，以应对物理机故障的风险？

因此我们需要对CMDB进一步深入探索：关联管理。

通过关联管理，我们可以做到：

通过关联关系，我们可以清晰看到物理机的业务IP、管理IP及机柜、机房信息。

小结

通过新增物理机、机柜、机房模型以及关联关系，在权限隔离的基础上，我们实现了：

权限隔离、操作分离正好解决了我们服务器上架的痛点。

2.CMDB打通堡垒机与监控平台

前面提到的“CMDB为上层应用场景提供可靠的数据支撑”，虽然我们实现了业务与主机的关联，但是CMDB与运维平台的隔离成了我们运维自己的一个痛点。在给业务做好服务的同时，我们也不能亏待了自己啊。

因此我们需要通过“事件注册与推送：提供基于回调方式的事件注册与推送；”实现CMDB打通堡垒机与监控平台，实现：

我们的目的是保证CMDB数据的权威性，这样做才能够避免"CMDB成为摆设、花瓶"。

CMDB提供的事件推送可以对接第三方系统，因此我们可以自行开发系统来与其对接，完成CMDB打通堡垒机与监控平台的最后一步。

本章部分在此就不做过多赘述，大家有兴趣的可以参考之前的问题。

《事件推送网关：让cmdb告别“花瓶”》

总结

对CMDB的使用我们也曾停步于好用阶段，但是对于痛点需求没有停止过思考，团队间充分的沟通与讨论让我们克服了这最后20%的痛点，因此运维请相信团队的力量。