公众号回复：干货，领取价值58元/套IT管理体系文档
公众号回复：ITIL教材，领取最新ITIL4中文教材
知道CMDB的人很多，商业或者自研产品也很多，前几年也有人提出ITIL已死，CMDB为王的口号，大张旗鼓地推行。可是几年过去了，这个“下水道”式“良心工程”的产品化的道路并不理想，大量虎头蛇尾的项目，大量的重构一波一波地进行。今天根据自身十几年的CMDB实践路程，浅谈实施“良心工程”的心得，篇幅有限本次主要从宏观和数据的角度来聊聊。
No. 0 自上而下+自下而上
CMDB项目最好是自上而下发起项目，然后自下而上地来实施。
管理层一定要了解其能带来的价值，和我们的城市下水道工程一样，没有管理层巨大而长期的支持和丰富资源投入做出来的我们通常叫做“豆腐渣”工程，别人家的“CMDB” 永远是别人家的。
而如果项目团队实施的时候也选择自上而下，而不是自下而上地做，那一定是空中楼阁，我们要做的是“地下工程”，一定要打好基础一点点做。
No. 1 需求的善与恶
需求是源头，一定要搞清楚，但是需求即是善的源头也是恶的源头。善的是你可以根据需求做出满足用户场景的合适的产品，恶的是不靠谱的需求往往导致项目陷入泥潭草草结尾。所以项目组的成员选择很重要，有了高层支持，项目组的产品和运营建议是一组人，最好是一线运维出身的运维架构师，了解当前的状况，具备前瞻性，有跨部门的影响力和调动力，有时候最好有一定的独裁能力。如果你让一个开发经理来带项目结果一般不会特别如意，开发和运维的思维逻辑以及对需求理解角度有着很大的不同。
No.2 架构之美
成体系的架构设计，这块往往是运维不足的地方，要向正规的开发体系好好学习。我们的运维工具发展往往经历几个阶段才会到达这个层面。CMDB架构建议每年都做，不停的迭代你的架构，因为要做核心，那么你的考虑因素就很多，影响的系统也很多，没有想清楚的东西生命很短暂，别人不清楚你的体系，融入也会是个问题。
架构设计的原则就是“客户第一，员工第二，股东第三”，自下而上的设计。
客户第一：因为要让众多的服务和用户来依赖和使用CMDB，必须用开放平台的思路和模式来增强用户体验，把他们牢牢地吸在CMDB周围。
员工第二：CMDB 一定要模块清晰，关系简单而易于维护，方便各模块的负责人协同开发，比如设计变更中心，设计UI框架，设计统一的认证，消息等基础组件。
股东第三：站在整个运维平台的角度设计广义的CMDB，狭义的CMDB是无法生存的；另外一定要有丰富的报表，体现强大的执行效率，精准的数据统计，高额的技术乃至经济收益。
No. 3 数据的层次感
CMDB的核心是围绕着数据展开的，如果你的老板问你数据准确性是多少，你怎么回答？如果你回答不出，那八成就是没做数据的分层，Total的数据准确性是没有意义的，也几乎很难去做，所以一定要分层，例如切出资产数据，OS层数据，APP层数据等不同纬度，这样一来哪一层需要怎么样的准确性，用怎样的技术手段来保障就比较客观了，工作量也可控了。而且你会发现基本上可以对应到公司内的各团队或人，这样数据的Owner和Consumer就有了。分层的另外一个好处就是可以更好的流动，可以清楚的为每一层数据制定流动规则，提供工具和平台支持。
No. 4 数据之重，善始善终
CMDB做的好不好在于数据和服务的生命周期是不是体系内闭环的。
CMDB是否精准在于数据是否流动，静默的数据失真的可能性很大，每次流动会天然带动一次各种方式的校验，可谓流水不腐！
第一步就是数据的获取，这块强调的只有一点，千方百计，千方百计，千方百计（重要的事情说三遍）的自动化，把人工维护降低到最低。一个好的CMDB一定要有自己的数据掘取能力，依靠其他平台或人导入的CMDB都是二等残废。至于获取数据的办法就“千方百计”了，agent入侵式，非入侵式都会有，其中分布式agent的体系非常重要。这里还要提一下的是获取的数据和我们设定应该获取中间是有GAP的，这里我们一般会设置一个审批池，把GAP扔进去由Owner来判断和处理。
第二步是变更，这块涉及大量运维和非运维的业务线，工作量大，头绪多。这块的建议就是做标准化，从大量的业务线中提取共性，用标准化工具自动的流转，这块承担用户七八成的工作量就成功了。剩下二三成非标准的东西可以放一放依赖有经验的工程师介入半闭环体系,不要着急做特例兼容。
如果有完全无法闭环的重要数据或服务，一定要有校验机制和规章制度强力保证准确。
最后数据和服务的终结都是要谨慎，逻辑数据和服务建议设置回退机制，如果是物理性质消除，对应的数据和服务一定要有静默阶段，以测试潜在的影响。
No. 5 产品化和全民运营
一些理论体系或项目的最后总要提一句“客户/用户培训”，这个对于互联网时代的CMDB项目来说有点掉渣，不如学学Jobs，产品为王，全民运营。
一个好的CMDB项目是要用产品和用户体验去征服用户的心，而不是附和用户要求，当然难就难在征服上，不可能有那么多优势人才，所以产品化、精品化是一个方向。产品化的道路对于内部项目来说是比较困难的，受制于人才、资源和体制，对于外部项目来说落地比较难，且定制化程度过高往往陷入“善与恶”交织的泥潭。所以建议是从整个IT运维的体系升级咨询入手，前期重在梳理IT运维各业务情况，抽象出产品化的模型，然后再考虑落地技术方案，旨在通过咨询拟出一份适合本组织的运维进化项目，CMDB作为核心需求首先确定产品化内容，所有人都了解目标后先行，其他自动化体系围绕这个核心合纵连横的发展，独立的CMDB项目往往都是鸡肋。
互联网时代为什么会重运营，因为用户的切换成本很低，让不忠诚的用户忠诚地使用你的服务就是运营，运营的重点我觉得是参与感。CMDB也面临同样的问题，面对众多的系统和用户，我们不能简单培训他们用，而是全民运营。
首先要运营的就是CMDB的数据，那么我们先问几个类似的简单问题：
这个数据是否有消费者，高频还是低频？
用户只有在我这里才能获得这个数据么？
我该不该提供这个数据？
我的数据准确么？
我是否能让用户方便和及时的存取数据？
我是否有能力提供大体量的数据存取？
从不同的数据中我能挖掘什么新的数据提供出来？
数据是否安全的分享？
。。。。。。
如果对每个问你要数据的用户回答完这里问题，基本上你就知道你接下来的改进点是什么，怎么更好提升用户数据消费和数据制作的体验。
其次CMDB 需要运营的就是他的服务，从狭义的CMDB跳出来，围绕CMDB可以有很多基础服务甚至直接业务服务，这些基础服务可以形成纽带，这些纽带就是你未来牢牢抓住多变客户的利器。通过纽带用户自己参与到这个平台，即可利用平台的基础设施，也可获取本职服务的渠道和客户，营销客户自己的产品，达到全民运营的目标。
之所以称CMDB为“良心工程”，就如本文的封面故事，誉为工业七大奇迹之一的“伦敦下水道工程”，需要全民的共识，坚定的战略支持，优良的架构，精准的战术，更需要巨大的毅力。以此文与广大运维路上的兄弟共勉！
福利
圈子构建、学习资料获取1000+份【ITIL/数字化转型/IT管理各类文档解决方案报告】，欢迎加入知识星球（扫下方二维码）~~~
作者介绍：陈炜，原支付宝运维经理，阿里集团运维架构师，1号店高级运维总监，现任平安健康资深运维总监，深耕大型电商、互联网金融与支付、在线医药等行业，对运维自动化、云计算平台有着10+年的实践和探索。
更多推荐
免责声明：
本公众号部分分享的资料来自网络收集和整理，所有文字和图片版权归属于原作者所有，且仅代表作者个人观点，与ITIL之家无关，文章仅供读者学习交流使用，并请自行核实相关内容，如文章内容涉及侵权，请联系后台管理员删除。
4276
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
