优秀的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的作用。”
—bmcsoftware
来源:本文转自公众号木讷大叔爱运维,点击查看原文。
还不过瘾?“被动救火式”运维不可取!运维如何提升自我驱动力?GOPS 2023 · 上海站,10月26日-27日,业务中台、持续测试、持续交付、DataOps、DevSecOps、自动化运维实践,全栈式提高学习氛围~
![](http://www.cnaaa19.com/wp-content/uploads/2023/09/71695871564.jpg)
近期好文:
欲速则不达!职场高手如何用“沉得住气”超越你?
“高效运维”公众号诚邀广大技术人员投稿
投稿邮箱:jiachen@greatops.net,或添加联系人微信:greatops1118。
![](http://www.cnaaa19.com/wp-content/uploads/2023/09/11695871566.png)
发表评论