原创 耕牛在田
说到CMDB，部分人会问什么是cmdb？能简单说说吗？这个概念我曾经讲过很多遍，网络上也能搜到很多，但是结果总是似是而非；这次我在文章当中再说明，可能更容易理解，希望效果更好。
一、为什么
为什么要花钱去建设CMDB？它能为企业提供哪些价值？
人力、物力、资金像血脉一样滋养着人类社会这个巨大的躯体。企业是这个躯体的器官。它需要社会提供的资源，本身也拥有资源。重要的是这些资源是流动的、有关系的。CMDB就是要告诉管理者，企业有什么资源、他们之间是什么关系，他们的状态是什么，他们是如何相互影响的。如果能够知道企业和外部资源之间的联动关系那就更好了。
可能小企业主奇怪，我家里有什么还还不清楚吗？规模小的，确实不需要，几个脑袋碰一下，就清楚了；估计也不会有什么自动化。大企业就不一样了，经年累月积累的资源，想了解清楚，到底要叫几个脑袋过来，都需要讨论。机房一台机器的电源线被踢掉了，影响了几个系统，影响了哪些数据，要叫哪些人开会？晚上系统升级涉及几十台上百台机器，要自动化处理，到底要在那几台机上运行脚本？任何验证？人肉处理就不要想了，想出来领导也提心吊胆，不敢采用；人肉几回，领导一定要打板子。
自动化，基于数据的自动化，基于资源虚拟化的自动化，就是背景。CMDB就是为自动化提供燃料。
二、放什么
CMDB里边都放了什么东西？
一般都会放三样东西：软件资源（逻辑化存在，不是介质）、硬件资源、人力资源。每一种资源都有自己特有属性、状态、关系。
1、人力资源
存放人力资源的信息，是为了在特定场景下，找人。或者根据人找到资源。比如：系统报警，这时要找人；人员离职，这时要找资源，完成交接。
2、硬件资源
最容易理解，完成硬件的生命周期管理。一个硬件变更，需要知道往上、往下影响了哪些硬件、哪些系统、涉及哪些人。
3、软件资源（软件产品资源）
软件产品在公司一般组织成一个独立的产品或者系统。但是在这个粒度上有很多工作是做不了的。比如：自动化的编译、打包、发布。所以还要拆分为更细的逻辑单位。一般会在两个方向上拆分：工程方面的拆分、运维方面的拆分。
工程方面的拆分面向开发人员，解决软件生产的自动化；运维方面的拆分，面向运维人员，拆分粒度和自动化运维工作的粒度相匹配。
有了这三类资源，还必须有他们之间的关系数据，孤立的点，失去连接的点是没有生命力的。它们要么在生命的初期，要么在生命的终点。总之，不是生产活动关注的重点。
三、怎么用
数据采集方式非常多样化，根据实际情况而定。数据怎么用cmdb有一定的自主权。
1、在线浏览
数据调研人员 主要是为了了解公司都要哪些家当，有哪些可以为我所用，多数是做数据调研。
运营人员 了解数据准备的进度、审查数据质量、了解用户反馈、了解用户行为、查看资源统计报表。
系统管理人员 管理权限、管理数据接口、监控报错情况等等。
2、接口对接
为自动化服务，数据必须的准确、及时、高效的。基于场景的，定制化接口，能够迅速满足数据消费的需要。因为场景非常多样，为了简化问题，标准的接口协议非常重要。
3、功能对接
CMDB基于典型场景会做一些典型功能。下游应用可以将这些功能的前后端一起嵌入自己的应用中。良好的嵌入对用户是完全透明的。比如：影响分析。这种嵌入是运行时的，不是代码级嵌入。
四、如何运营
运营跟企业的实际情况密切相关，理论真身只有一个，落地化身多种多样。能达到目的就行：
1、提升数据质量和覆盖度
自动化，一键指挥千军万马。数据不真实，不准确，不及时，不完全，那就要出问题。但是还是要有策略的使用，没用过的数据，谁也不知道质量如何。
2、关注下游反馈
下游系统是CMDB的用户，是反映数据问题的地方，是有可能替你背锅的英雄。他们的反馈要及时响应。
3、规范的宣传
cmdb作为数据的规范点，一定会有自己的概念、术语、规范。要尽可能向用户宣传。语言文字的承载能力有限，有些问题要现身说法或者让用户多使用才能理解。如果宣传不够，大家虽然说着相同的词汇，脑子里却是不同的东西。这会为后边的工作带来诸多不便。
4、不断提升cmdb本身的服务能力
如果用户吐槽的是cmdb本身的服务能力，比如：执行速度慢，系统不稳定。那将是危险的，先解决这些问题，其他问题放一放。
五、有哪些影响
有一位领导曾经对我说：做系统就像生孩子，生倒没啥，养孩子是需要资源和毅力的。CMDB这个孩子学识渊博，交际广泛；它的降生，有一些重要的影响，不准备好，就是魔丸降生，你就练好“十三太保金钟罩”等着打屁股吧。
1、制定规范、统一术语
零散系统的数据，在自己的圈子里是可以玩得转的，被cmdb捏在一起就问题百出了。有些数据甚至不能捏在一起，有了规范就可以捏在一起了，就可以分享了。
术语背后，隐藏了一堆的背景知识，不清楚这些术语，概念，望文生义，就不能讨论，不能有效沟通，难以合作。
2、打破竖井、左顾右盼
存量的系统，是逐步建成的，是在小范围使用的。根本就没有考虑信息分享的事儿，cmdb更是听都没有听过。现在做系统相互之间要有沟通，要了解系统的上下游生态，要把共享的部分识别出来。在规范的基础上，落地实施。这样解决增量问题，存量系统改造需要时间，未改造之前要制定临时的应变策略。
3、控制需求、对号入座
有人的地方就有江湖，有系统的地方就有地盘。每个产品经理都想跑马圈地，这符合人性，符合需求；但是资源是有限的，有了分享就需要规范，就需要秩序。所以，有了cmdb就要在需求入口处控制需求的流向，使得需求流向规定的系统。而系统是有规划的，数据是有规范的，接口是有协议的。和谐的生态由此建立。
4、明确归属、明确责任
数据要指定归属，谁提供谁负责，负什么责任，在生命周期的那一段负责要有明确的说明。如果有些难以说清楚，那就从能说清楚的地方开始。不明确的部分要给出计划。
5、建立反馈和改进机制
问题的广播、反馈机制要建立。没有反馈就像进入无人区一样无所适从，改进无从谈起。问题的广播非常重要，通过广播跟进问题，找到根因，列出改进计划。
回头看看，这是一般人干的事儿吗？所以大领导关注，小领导卖力，兄弟们合作，才能成功。
到此为止，读者就可以自己下定义了。什么是CMDB，自己组织一下文字吧。
网友评论