共计 2174 个字符，预计需要花费 6 分钟才能阅读完成。
自动写代码机器人，免费开通
这篇文章将为大家详细讲解有关 CMDB 的示例分析，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
套路 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 背后有着很多的套路，它和自动化系统有一些不同，做一个管理信息系统比做一个工具系统会更难，理解这些套路，也就接近了成功!
关于“CMDB 的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
向 AI 问一下细节
丸趣 TV 网 – 提供最优质的资源集合！
