如何理解CMDB的套路

运维猿网络

套路1：CMDB名字应该改一下了，叫IT资源管理

什么叫配置?的确现在很多配置管理的工具，这些东西也是沿袭下来，但我更喜欢puppet里面提到的资源概念。资源几乎可以和对象的概念对等，对象有属性，资源也有属性；对象有方法，资源也有动作，额外增加一点，资源还有状态。记住一些，可以把一切对象当成资源来看。

我为什么坚持要改名？从现实的情况来说，大家一说CMDB都是那些传统的讨论，自动发现、配置项、配置属性。另外动不动就是一些一些表单的设计和管理，而忽略一个真正的CMDB是什么？

真正的CMDB就是要把内部所有的IT资源管理起来！

套路2：CMDB模型有层次

在下图的模型中，CMDB的模型是有层次的，我把他定义成核心模型和扩展模型。

核心模型。核心模型是记录了业务、应用和主机Host的关系，其他的关系都可以不记录。有了这个模型基本上可以运转后续的自动化和监控系统了；其次还可以有效的管理公有云上的主机信息。

核心模型绝不是基础设施级的资源模型！

扩展模型。扩展模型就是依赖核心模型扩展出来的，比如说基于应用需要找到关联的一些资源信息；基于主机找到它关联的一些依赖设备信息，比如说机柜、存储和交换机等等，不断的扩展对象模型。

坚持核心模型的导入，逐步驱动周边的配套资源完善，这是应用驱动CMDB的最核心切入点。

套路3：CMDB的对象关系要简化

从上图中，你可以看到CMDB模型中只有三种关系，三种关系如下：

主从关系。这种关系是一种强父子关系，主不存在了，则从就不存在了。用明细表来表达，属于对象级别的关系。可以通过明细表来表达，在easyops平台中用内联表来表达。
依赖关系。是一种对象属性级之间的关联关系，比如说服务器放在机柜上，机柜摆在某个机房内，这是对象级别的关系。通过对象的属性关联来表达。
连接关系。主机和存储、主机和网络设备的关系，是连接关系。这种关系是动态生成的，是一种实例级的关系。

依赖关系和连接关系有什么不同？

依赖是一对多的关系，并且这个关系是靠人维护的，比如说机柜上放了很多服务器。
连接是多对多关系，并且这个关系是因为某种“连接”产生的，比如说服务器连接了交换机。可以通过自动发现来实现，如果是人来维护，基本上不可能。

套路4：不要太迷信自动发现

自动发现在一定成都上能降低维护的成本和代价，但我不迷信这个能力。一则自动发现的能力一定有需要人工介入的过程，比如说网卡速率的自动发现，出现异常的时候，肯定不能进入CMDB；其次自动发现在某种场景是不能直接生效的，举个例子，比如说某个机器内的进程和端口信息需要做自动监控，此时如果通过自动发现来实现主机上的进程和端口信息维护（其实简单），但这个就需要监控系统适应变更期内进程被暂停的情况，暂停导致机器的进程信息自动发现不全。

仔细思考过自动发现和人工维护的边界？

第一、涉及到资源状态的变更划分，其实都应该需要人为参与的。比如说IP/服务器资源从资源池进出的过程；状态的变更会涉及到监控策略自动变化的。从状态这个维度进去，很容易找到人工和自动的边界，而非状态属性的填充则无所谓了。

第二、跨组的资源管理则需要流程驱动，目前来看比如说防火墙、IP地址、服务器是典型的跨组/部门管理的资源。资源的管理方和使用方需要一些流程管控。当然这个地方有改进的地方啊，如果是管理平台完善，是可以通过平台来简化流程的哈。DNS、负载均衡资源的管理也是一个典型的例子。