CMDB的建设不能闭门造车，因此无论是从有心者的反馈，还是和运维小伙伴的交流，大叔都默默地进行了梳理。在此特将技术大佬、产品、开发、运维等多个视角关于CMDB的看法进行总结分享，希望能给大家在这炎热的季节解下暑。

技术大佬视角

在正式开启本文前，我们先来看下技术大佬们对CMDB的理解：从CMDB使用者角度来说，大佬们的看法可谓是一阵见血，因此CMDB的场景消费离不开大佬们在技术架构上的支持。如果CMDB的场景消费只集中在运维侧，我认为还是缺少一定的外部驱动力的。

开发/产品视角

• CMDB这个产品很多路都走歪了，按照国内这些CMDB去做，踩了几个月的坑
• 搞不清楚产品属性，简单模仿
• 去看国外产品，最后学习到了三点属性：唯一数据源、动态采集、服务与资源的映射，这些属性就是在具体实现的时候约束你产品的边界，不能乱搞，
• 产品抽象能力不够，尤其是运维赛道没有好的产品经理
• 产品如果不能抽象出来属性的产品，其实大部分都是功能堆砌组合，都是按需求出来的产物，很接地气，但是很难做标准化，这个就是需求的低质量和局限
• 仔细去看老外的产品，其实会发现属性都差不多，只是建设的时候有自己的理解
• 本身就是抽象出来的标准或者说关键要素，真正你做产品就会发现这些抽象的要素指导意义有多大
• 每一个属性你想做好，都蛮大挑战的，就说动态采集，多云的资源各种配置项的动态采集，去兼容这些云的API，这个就是一个巨费工的工程
• 真正复杂的点，在于你自己的服务和这些配置项的映射，这个是你自己按照自己的业务去做规则关联映射
• 基于CMDB之上做自动化、做监控、流程等，底层基本都是依靠和CMDB联动去做的

运维/使用者视角

• 反过来想想可不可能是运维人员对CMDB理解有限，直接从表格上升到一个强大的产品而无法驾驭
• 至今国内的cmdb产品比较清晰和够用了，有时候是用户不配
• 现在的运维人员缺少抽象的建模能力，是cmdb建设失败的原因之一
• 商业的CMDB 给的都是工具和能力，看建设者能力是否可以匹配这东西。很多时候是建设者能力不济
• CMDB 在一个环境落地都需要根据这个环境的运维习惯、流程等去从头建设。适配和采集只是建设过程中的一个环节，通过中间加一层可以兼容，只要投入人力都可以解决，但是建模不是投入人力去解决的
• 大家追求的是这个目标，但是也造成了一个误区，好的东西拿来就用，我不需要去学习新的工具和流程。现在这个时代，人要学会适当适应工具，因为需求太多，迭代也很快
• 现在的运维都不是单独的系统平台，而是众多系统平台的一个运维体系。底座是cmdb，数据的消费和生产驱动了很多生产活动
• 运维这块，大多数都没习惯抽象思维
• CMDB主要就是在资源映射
• 真正好用的CMDB其实是EXCEL
• CMDB不是有开源的了吗？还要自己造轮子？
• CMDB主要是底层标准化很差，不得不去适应环境
• 真正好用的CMDB其实是EXCEL
• 没有CMDB，说实话运维很难做好

华为CMDB如何炼成

如果上文的各个视角你感觉还都是泛泛之谈，那么接下来我又整理了《冰与火之歌，华为 CMDB 是如何炼成的》一文中的主要观点：

• 对于 CMDB 项目的失败，普遍的解释是：没有数据的消费场景、工具和技术不行、流程管控不足
• CMDB 的失败不能简单的认为是消费场景、技术和管控流程的问题，而应该从成本和收益的角度考虑
• CMDB成功的两个关键因素是：管理对象的规模和组织的执行力
• 华为CMDB经历初创期、整合期、价值发挥期
• 华为CMDB成长的土壤、条件、机遇和运气
• 强大的执行力
• 规模大，有强烈的自动化需求和条件
• 全球化带来的机遇
• 偶然的运气
• 经验教训
• 拆迁不如搬迁
• 配置模型要接地气
• 开放心态和数据分级管理
• 数据维护流程要简化
• 保障数据的完整性
• 数据消费要有反馈
• 可视化
• 在初创阶段、要克制数据分析的冲动

总结

作为运维，如果不知道CMDB产品开发者的苦衷，就可能不会好好去珍惜、揣摩、融入CMDB；作为开发者，如果不知道运维使用者的吐槽与声音，就可能不会有接地气的迭代，打造完美的产品；作为技术大佬，如果不从更宏观的视野给予指导，或融入技术架构更好的为运营、开发带来全新的体验，作为外部驱动力去促进运维、开发人员，那可能就没有更好的整体效能提升。