技术大佬视角

开发/产品视角

• 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的作用。”

—bmcsoftware

来源：本文转自公众号木讷大叔爱运维，点击查看原文。

还不过瘾？“被动救火式”运维不可取！运维如何提升自我驱动力？GOPS 2023 · 上海站，10月26日-27日，业务中台、持续测试、持续交付、DataOps、DevSecOps、自动化运维实践，全栈式提高学习氛围~

近期好文：

欲速则不达！职场高手如何用“沉得住气”超越你？

“高效运维”公众号诚邀广大技术人员投稿

投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118。

点个“在看”，一年不宕机