CMDB，关于你掌握的或多或少，有深有浅的CMDB套路！前几天在总结一个项目，写CMDB配置管理规范，发现套路还是很多的。本文是老王总结的CMDB套路！套路一：要改CMDB的名字。它被称为IT资源管理。什么是配置？确实继承了很多配置管理工具，但我更喜欢puppet中提到的那些。资源概念。资源几乎可以等同于对象的概念。对象有属性，资源也有属性；对象有方法，资源也有动作。另外一点，资源也有状态。记住一点，你可以把所有的对象都看成是资源。为什么我坚持要改名字？从实用的角度，大家说CMDB就是传统的讨论，自动发现，配置项，配置属性。另外，总是一些表格的设计和管理，忽略了什么是真正的CMDB？真正的CMDB是管理所有内部IT资源！套路二：CMDB模型是有层次的在下图中的模型中，CMDB模型是有层次的，我把它定义为一个核心模型和一个扩展模型。核心模型。核心模型记录了业务、应用、主机之间的关系，其他关系不需要记录。有了这个模型，后续的自动化和监控系统就基本可以运行了；其次，可以有效管理公有云上的主机信息。核心模型绝不是基础设施级别的资源模型！扩展模型。扩展模型是依赖于核心模型进行扩展的。比如根据应用需要查找一些关联的资源信息；以宿主机为基础，寻找与其关联的一些依赖设备信息，如机柜、存储和交换机等，不断扩展对象模型。坚持引进核心模式，逐步带动周边配套资源完善。这是应用程序驱动的CMDB的核心入口点。套路三：CMDB的对象关系要简化从上图可以看出，CMDB模型中只有三种关系，三种关系分别是：主从关系。这种关系是一种强烈的父子关系。如果master不存在，那么slave也不存在。用明细表来表达，就是一种对象级的关系。可以通过明细表来表达，在easyops平台中，可以用内联表来表达。依赖项。它是对象属性级别之间的一种关联关系。比如服务器放在机柜上，机柜放在某个机房。这是对象级关系。通过对象的属性关联来表达。连接关系。主机与存储、主机与网络设备之间是一种连接关系。这种关系是动态生成的，是一个实例级别的关系。依赖关系和连接关系有什么区别？依赖是一种一对多的关系，这种关系是由人维护的。例如，许多服务器都放在机柜上。连接是多对多的关系，这种关系是因为某种“连接”而产生的，比如服务器连接到交换机。可以通过自动发现来实现，如果靠人工维护基本不可能。套路四：不要太迷信自动发现。自动发现可以在一定程度上降低维护成本和成本，但我并不迷信这种能力。一是自动发现能力必须有一个需要人工干预的过程。比如网卡速率的自动发现，出现异常时一定不能进入CMDB；其次，自动发现在某些场景下不能直接生效。比如，比如说需要自动监控某台机器中的进程和端口信息。这时候如果通过自动发现的方式维护宿主机上的进程和端口信息（其实很简单），但是这就需要监控系统适应变化期间被挂起的进程。在某些情况下，暂停会导致机器进程信息的自动发现不完整。您是否仔细考虑过自动发现和手动维护之间的界限？***，而涉及到资源状态变化的划分，其实应该是需要人为参与的。例如IP/服务器资源进出资源池的过程；状态变化将涉及监控策略的自动变化。从状态的维度上，很容易找到人工和自动的边界，非状态属性的填充无所谓。其次，跨集团资源管理需要流程驱动。目前，例如防火墙、IP地址、服务器是典型的跨组/部门管理资源。资源管理者和用户需要一些过程控制。当然，这个地方还有改进的余地。如果管理平台完善，可以通过平台简化流程。DNS和负载均衡资源的管理也是一个典型的例子。图中每一行都是一个CMDB管理流程，除了【初始化完成】！套路5：CMDB需要领导参与，团队理解一致的领导非常重要。有领导参与和团队共识，这个CMDB很难失败。.很多CMDB项目的失败，不是技术层面的问题，而是人的问题。说到一致理解，我觉得CMDB的概念、模型、流程、场景、实现方式应该足够简单了。导入CMDB可以初步引入一个场景，无论是对事件的支持，还是对监控的支持。套路六：云计算的概念层面是CMDB层面。其实CMDB系统里面有很深的层次。云计算的概念层面是CMDB的模型层面。当你建立一个模型的时候，你也需要建立这样一个分层的能力。这个能力划分之后，对持续部署的影响也是有的。我们的实践证明，持续部署的标准化规范也需要这样的分层思考。越界导致系统管理不清晰，监控也是如此！有一件事我没有想过，PaaS资源到底是应用附属资源来管理，还是作为一个独立的资源来管理？特别是在公共云模型中。套路七：CMDB是你的IT资源和组织的快照这句话说起来很简单，CMDB不仅反映了你管理的IT资源模型，也反映了你的组织管理模型。当一个对象找不到Owner时，你需要思考什么问题？当一个流程无法执行的时候，你还要思考是组织管理复杂还是执行力不够？CMDB背后有很多套路，它和自动化系统有一些区别。做一个管理信息系统比做一个工具系统更难。了解这些套路离成功不远了！
