标签：失败 负载均衡 领导 是你 资源管理 src 计算 title 扩展
CMDB成功和失败，关于掌握的CMDB套路的多与少、深与浅！
前几天在对一个项目进行总结，编写CMDB的配置管理规范，发现还是有很多套路，本文就是老王总结的CMDB套路！
什么叫配置?的确现在很多配置管理的工具，这些东西也是沿袭下来，但我更喜欢puppet里面提到的资源概念。资源几乎可以和对象的概念对等，对象有属性，资源也有属性；对象有方法，资源也有动作，额外增加一点，资源还有状态。记住一些，可以把一切对象当成资源来看。
我为什么坚持要改名？从现实的情况来说，大家一说CMDB都是那些传统的讨论，自动发现、配置项、配置属性。另外动不动就是一些一些表单的设计和管理，而忽略一个真正的CMDB是什么？
真正的CMDB就是要把内部所有的IT资源管理起来！
在下图的模型中，CMDB的模型是有层次的，我把他定义成核心模型和扩展模型。
核心模型绝不是基础设施级的资源模型！
坚持核心模型的导入，逐步驱动周边的配套资源完善，这是 应用驱动CMDB的最核心切入点。
从上图中，你可以看到CMDB模型中只有三种关系，三种关系如下：
依赖关系和连接关系有什么不同？
自动发现在一定成都上能降低维护的成本和代价，但我不迷信这个能力。一则自动发现的能力一定有需要人工介入的过程，比如说网卡速率的自动发现，出现异常的时候，肯定不能进入CMDB；其次自动发现在某种场景是不能直接生效的，举个例子，比如说某个机器内的进程和端口信息需要做自动监控，此时如果通过自动发现来实现主机上的进程和端口信息维护（其实简单），但这个就需要监控系统适应变更期内进程被暂停的情况，暂停导致机器的进程信息自动发现不全。
仔细思考过自动发现和人工维护的边界？
第一、涉及到资源状态的变更划分，其实都应该需要人为参与的。比如说IP/服务器资源从资源池进出的过程；状态的变更会涉及到监控策略自动变化的。从状态这个维度进去，很容易找到人工和自动的边界，而非状态属性的填充则无所谓了。
第二、跨组的资源管理则需要流程驱动，目前来看比如说防火墙、IP地址、服务器是典型的跨组/部门管理的资源。资源的管理方和使用方需要一些流程管控。当然这个地方有改进的地方啊，如果是管理平台完善，是可以通过平台来简化流程的哈。DNS、负载均衡资源的管理也是一个典型的例子。
图中的每条线上都是一个CMDB管理流程，【初始化完成】除外！
领导非常重要，领导参与加上团队的一致理解，这个CMDB不成功都难。很多CMDB项目的失败，不是技术层面上导致的，而是和人有关。
说到一致理解，我觉得CMDB的概念、模型、流程、场景、实施方法要足够的简单。CMDB的导入最好开始能带一个场景进去，无论是对事件的支撑、还是对监控的支撑。
套路6：云计算的概念层次就是CMDB的层次
在CMDB系统中其实有很深的层次，云计算的概念层次就是CMDB的模型层次。在你构建模型的时候也需要构建这样的一个分层能力，这个能力划分开来之后，对持续部署的影响也是在的。我们的实践检验出来是持续部署标准化的规范也需要这样的分层思路，越界导致系统管理不清楚，监控也是如此！
有一点我没想清楚的是，PaaS的资源到底是应用附属资源管理，还是作为独立资源管理？特别是公有云的模式下。
这句话说起来好简单，CMDB不仅仅映射出你管理的IT资源模型，其实更是你组织管理模型的映照。当一个对象找不到Owner的时候，你需要思考到底什么问题？当一个流程无法推行的时候，你同样要去思考组织的管理是复杂了还是执行力不够？
CMDB背后有着很多的套路，它和自动化系统有一些不同，做一个管理信息系统比做一个工具系统会更难，理解这些套路，也就接近了成功！
标签：失败 负载均衡 领导 是你 资源管理 src 计算 title 扩展
原文地址：http://www.cnblogs.com/bingabcd/p/7618296.html
