如何理解CMDB的套路
2016-09-18 15:38:00   来源：来源：互联网运维杂谈   评论：0 点击：

CMDB成功和失败，关于掌握的CMDB套路的多与少、深与浅!

前几天在对一个项目进行总结，编写CMDB的配置管理规范，发现还是有很多套路，本文就是老王总结的CMDB套路!

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

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

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

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

套路2：CMDB模型有层次

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

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

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

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

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

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

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

主从关系。这种关系是一种强父子关系，主不存在了，则从就不存在了。用明细表来表达，属于对象级别的关系。可以通过明细表来表达，在easyops平台中用内联表来表达。

依赖关系。是一种对象属性级之间的关联关系，比如说服务器放在机柜上，机柜摆在某个机房内，这是对象级别的关系。通过对象的属性关联来表达。

连接关系。主机和存储、主机和网络设备的关系，是连接关系。这种关系是动态生成的，是一种实例级的关系。

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

依赖是一对多的关系，并且这个关系是靠人维护的，比如说机柜上放了很多服务器。

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

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

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

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

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

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

 图中的每条线上都是一个CMDB管理流程，【初始化完成】除外!

套路5：CMDB要领导参与，团队理解一致

领导非常重要，领导参与加上团队的一致理解，这个CMDB不成功都难。很多CMDB项目的失败，不是技术层面上导致的，而是和人有关。

说到一致理解，我觉得CMDB的概念、模型、流程、场景、实施方法要足够的简单。CMDB的导入最好开始能带一个场景进去，无论是对事件的支撑、还是对监控的支撑。

套路6：云计算的概念层次就是CMDB的层次

在CMDB系统中其实有很深的层次，云计算的概念层次就是CMDB的模型层次。在你构建模型的时候也需要构建这样的一个分层能力，这个能力划分开来之后，对持续部署的影响也是在的。我们的实践检验出来是持续部署标准化的规范也需要这样的分层思路，越界导致系统管理不清楚，监控也是如此!

有一点我没想清楚的是，PaaS的资源到底是应用附属资源管理，还是作为独立资源管理?特别是公有云的模式下。

套路7：CMDB是你的IT资源和组织的快照

这句话说起来好简单，CMDB不仅仅映射出你管理的IT资源模型，其实更是你组织管理模型的映照。当一个对象找不到Owner的时候，你需要思考到底什么问题?当一个流程无法推行的时候，你同样要去思考组织的管理是复杂了还是执行力不够?

CMDB背后有着很多的套路，它和自动化系统有一些不同，做一个管理信息系统比做一个工具系统会更难，理解这些套路，也就接近了成功!

【编辑推荐】