CMDB热议总览，得不到的永远在骚动！
木
三页约 14 分钟
三页约 14 分钟前言
❝“我们容易在短期上高估CMDB的作用，却更容易在长期上低估CMDB的作用” --bmcsoftware
❞
针对群内小伙伴们关于CDMB的询问，特将近半年的知识库中涉及CMDB部分归纳梳理，希望感兴趣的小伙伴能够充分借鉴下，结合自己的实际环境能够得出一份适合自己的答案！
第四阶段：CMDB 重要的是落地和场景
配置管理cmdb其实也是运维数据治理的一部分，前几年鼓吹的智能运维的基础也是数据，数据要好才能发挥算法的好效果，那怎么衡量这个数据要好，借鉴业务侧的数据治理，是不是也需要打造运维数据治理，而对应的工具就是运维数据中台 实际参与或用过几个头部券商的cmdb，比如上海的gt、ht其实更多是自研驱动的，当然也白p过其他的厂商方案，然后深圳的gx是优维的cmdb，加以封装使用，不知道有没有听说过他们的cmdb效果还不错，个人认为还是他们运维部门管理机制为主，领导强要求多久搞完，去维护 前看到和使用的cmdb主要功能或场景有：模型设置、实例管理维护、全文搜索、拓扑、消息订阅、关系查询、变更历史、数据权限之类的，还有周边的数据质量保证手段，cmdb建设的一个难点就在于数据的维护和更新，用过蓝鲸cmdb和优维cmdb，蓝鲸cmdb还是人工去维护，周边自己去写各种定制脚本去采集；优维的和自动化打通了，可以直接内生去写脚本采集数据，还有cmdb资源纳管的一个原则是能自动发现就自动发现，然后优维的封了很多自动采集的包，其实就是自动化的脚本库，可以快速复用 运维也好，技术也罢，都是服务于业务，业务是创收的，运维是花钱的 市面上能拿出来卖钱的cmdb都是通过脚本、api、协议去做自动采集，不管是优云优维嘉为新炬 CMDB是数据基础，有很多任务是基于CMDB去实现的 监控、ITSM、自动化、DevOps都是消费CMDB 其实，说白了，还是没让领导看到他的价值，或者价值实现的太慢了 看材料，cmdb的一个建设经验就是：取得领导的认可其实cmdb就成功了一半 云cmdb之前Gartner有一个提法，就是只记录对自己来说可控的部分，然后更多记录管理类的信息，如云厂商的sla等等，具体信息查询的时候再从云那边取 国外的做法应该说和国内存在不小的差异，一是Itam，二是作为itsm的一个重要部分，会比较多把cmdb用在服务请求、变更还有事件过程的排障里 国内的cmdb在和itsm的结合上，大多比较弱 国内的IT基础打的不扎实，不规范，路子比较野，所以很多东西你感觉会非常别扭，因为底层的认知是缺失的
「危机感：上了K8S，感觉就应该应用角度了，要抛弃传统CMDB得细分了！」
第三阶段：CMDB建设思路
需求入手
需求：aix suse centos redhat几千个应用系统，COBOL c 西加加 Java js ，十来种编程语言，运维搞cmdb，怎么个思路搞基于应用的cmdb？
痛点： 没有引入数据治理，搞cmdb运维这边的地位不高；应用运维牵头建设的cmdb 最后沦落到各个系统负责人填写表格。问各位相似的复杂的环境，如何做好这块cmdb管理的? 目前我已知的情况，身边没有公司这么颗粒度细的搞过 cmdb 落地可不简单，蓝鲸那些 包括优维 都很一般的。 主要是落地，其他部门不配合你 如何应对： 建设方案这块稳的办法是找厂商，找他们要给同行业单位搞成的建设方案 成熟解决方案比如蓝鲸，花点钱完事；自己折腾就是在浪费时间 浪费精力 我们自己现在在摸索 用opsany 先把资产搞起来，消费场景 以后再说 先收集需求，然后找厂商过来，给你们讲解，对比你们的需求能满足实现多少，总体就是满足领导和公司需求、维护操作是否方便、经费等等 不要用开源，不要用开源，即使是开源也是集成在商业产品的部分功能 运维呀，比较难的地方我的体会还是在应急和建设，平时维护就那些东西 建设cmdb很重要的一个需求就是数据的准确性，这个确实需要元数据这玩意 理解元数据就是定义规范可配置项，这个可能一个团队一个，也可能整个大团队共用 过程： 项目搞了很多期了，其实每次都不满意。 说实话，光买个产品屁用没有，主要是落地的事情如何在公司内正真落实执行下去。 很多大行的cmdb说是也最后烂尾了 如果一个系统不仅没减少工作量，还增加，还操作复杂，人家不愿意用的 总结： 与其他运维工具的推广不同，CMDB的建设本身就是一个长期的过程，会经历初创期、整合期、价值发挥期，无论是商业方案还是开源方案，面对的建设环境都一样，成本也并不是尚方宝剑。 从招行的数据治理的情况来分析，某些工作一定要是超前的，在CMDB未正式开始前已经就有相关准备工作了，未必一定是数据治理。 一定不要想着让CMDB的管理范围面面俱到，例如进程级管理，很多领导或专家只看到了CMDB的价值，但忽略了过程，这只会让建设者画地为牢。 技术是简单，落地运营很麻烦 「CMDB落地，应该与数据治理保持一个同步，如果内部没有足够的资源去支持做这个事情，那就 干不成。总认为只是 某一个部门的事情，那就不可能干好。落地的时候不能 一口吃一个胖子，什么都要。」
cmdb成功的实施过程几乎就是一个改革过程
《ITIL配置管理实施方案详解(一)》《ITIL配置管理实施方案详解(二)》 bmc专门就cmdb建设出过一本书，很久之前的了，虽然整个过程很重，但是有些东西是有道理的 现在搞cmdb项目老是想着短平快、开箱即用，就很容易烂尾 技术栈太多我觉得和CMDB应该没有啥关系；建设CMDB的就应该负责而数据的规范；CMDB提高好api，其他任何系统通过api生产和消费数据。
❝我说句实在话，互联网公司 为什么cmdb有些干的不错，是因为，他们本身技术栈做了相对统一，全部上云，后端开发语言，全栈容器化。但是很多非互联网公司做这块，做的不好，原因: 1.技术栈太多 2.想一口吃掉胖子，告警监控，devops，堡垒机等等都想从这里取数 3.数据没有规范，一个系统n个名字，元数据也没有定义好 4.各个部门扯皮，最后cmdb只能给建设方使用
❞
由CMDB引起的标准、规范
背景：某些行业和互联网不一样，互联网都是先统一技术栈，但是某些行业就是标准不统一，例如各种发行版，标准不统一 环境没有对错，但运维在一定权限职责内要做正确的事： 首先得有个标准，比如用哪种类型操作系统、哪种类型数据库，而不是别人说用啥就是啥 原则：「不是要你用互联网的统一技术栈，而是你自己公司应该有自己一套标准，从底层 到系统架构都应该有一套标准」 即使是老系统 也要推动做标准化 例如一个管理系统用6种框架缝合起来的，非标的东西统统给他搞标准 比如Java 用的dubbo spring boot框架，硬件用的CPU内存磁盘 操作系统都有一套标准的设计。
基于多云的CMDB的一些痛点
多云管理的一致性、时效性，目前云好像不支持事件模式，只能通过API的轮询同步，对一致性和时效性来说，成本很高 多云CMDB说的只是一种数据来源形式吧，关键还是看实现什么业务目的。目前做多云资源管控的有可观测性、FinOps、TBM的应用场景下比较多 多云的采集，特别费工 使用云管cmp，一般都是在晚上去定时同步数据，数据量大耗时很长 底层的采集使用CMP，是基于API的，这种采集模式很重 固定频率同步数据，对于ecs我们一般都安装了我们自己的agent,还有的就是内部走流程，同步执行
第二阶段：多视角看CMDB
「延申：运维工具建设，我们其实就是三大块，鉴权授权+CMDB+作业系统」
开发/产品视角
CMDB这个产品很多路都走歪了，按照国内这些CMDB去做，踩了几个月的坑 搞不清楚产品属性，简单模仿 然后去看国外产品，最后学习到了三点属性，1、唯一数据源 2、动态采集 3、服务与资源的映射，这些属性就是约束你产品的边界，不能乱搞，在具体实现的时候 产品抽象能力不够，尤其是运维赛道没有好的产品经理 产品如果不能抽象出来属性的产品，其实大部分都是功能堆砌组合 都是按需求出来的产物，很接地气，但是需求的低质量和局限，很难做标准化 做着做着感觉不对劲，和我理想中不一样，所以叫停了，让产品经理别做了，我们先去看看老外怎么做的 这个就是需求的低质量和局限 真正好用的CMDB其实是EXCEL 仔细去看老外的产品，其实会发现属性都差不多，只是建设的时候有自己的理解 本身就是抽象出来的标准或者说关键要素，真正你做产品就会发现这些抽象的要素指导意义有多大 每一个属性你想做好，都蛮大挑战的，就说动态采集，多云的资源各种配置项的动态采集，去兼容这些云的API，这个就是一个巨费工的工程 在动态采集上还取了一个巧，用了云联壹云的动态采集中间件能力，自己做，做不好，太费工了，光去适配这些云的API，就要命了 真正复杂的点，在于你自己的服务和这些配置项的映射，这个是你自己按照自己的业务去做规则关联映射 没有CMDB，说实话运维很难做好 我们基于CMDB之上做自动化、做监控、流程等，底层基本都是依靠和cmdb联动去做的
运维/使用者视角
反过来想想可不可能是运维人员对CMDB理解有限，直接从表格上升到一个强大的产品而无法驾驭 至今国内的cmdb产品比较清晰和够用了，有时候是用户不配 现在的运维人员缺少抽象的建模能力，是cmdb建设失败的原因之一 所谓的ssot、自动化采集关联、服务资源的映射 市面上的产品都是完全胜任的 商业的CMDB 给的都是工具和能力，看建设者能力是否可以匹配这东西。很多时候是建设者能力不济 CMDB 在一个环境落地 都需要根据这个环境的运维习惯、流程等去从头建设。适配和采集只是建设过程中的一个环节，通过中间加一层可以兼容，只要投入人力都可以解决，但是建模不是投入人力去解决的 大家追求的是这个目标，但是也造成了一个误区，好的东西拿来就用，我不需要去学习新的工具和流程。现在这个时代，人要学会适当适应工具，因为需求太多，迭代也很快 现在的运维都不是单独的系统平台，而是众多系统平台的一个运维体系。底座是cmdb，数据的消费和生产驱动了很多生产活动 运维这块，大多数都没习惯抽象思维 CMDB主要就是在资源映射 真正好用的CMDB其实是EXCEL cmdb 不是有开源的了吗？还要自己造轮子？ 主要是底层标准化很差，cmdb不得不去适应环境
流程规范
“管理要付出额外成本，但是成效并没有那么快；很可能是成效还没出来的时候，改革就停止了” @业灿
《CMDB配置管理流程设计说明书》 《UC 配置管理规范》 《CMDB的定位及价值》 《BMC_CMDB实施经验交流》 《DevOps CMDB流程规范》 《小微企业IT服务规范 运维服务》 《数据中心智能运维规范》 《保险业信息系统运行维护工作规范-2013行标》 《保险业IT服务管理基本规范》
第一阶段：CMDB各抒己见
CMDB作为配置管理数据库，有太多的事例证明其最终被沦为鸡肋，部分小伙伴对其也不置可否
开源CMDB，大概率很难推广，其真正意义上的应用场景很难发挥出来 一个单纯的CMDB，主要面向的是运维 cmdb折腾了三年，啥问题都没解决 计划做CMDB 快三年了，一直不知道该怎么下手 CMDB给运维更大的负担就是天天对数据，因为数据不准 CMDB是运维基础，自动化必须依赖起来，打好基础，上层才能便捷，高效，稳定 想法很美好，现实很残酷，老板投入了好多钱，发现并没有解决问题，还带来新的问题 CMDB需要规范、流程将其规范化管理起来，总得允许一些小瑕疵
关于CMDB的一些使用场景，大家可以作为参考：
cmdb事件推送网关 – 测试、准生产、生产各环境与堡垒机、监控联动（运维支撑） 应用相关流水线 - 应用自动上线、应用发版、应用启停、屏蔽/恢复监控（运维支撑） 网关 - 接入新服务（架构支撑） 消息系统 - 接入新channel（架构支撑）
个人的一些看法：CMDB的建设不是一个人的事情，但是还是要先入为主，闭门造车不如团队先小范围试用并总结经验，说服别人要先说服自己。
公众号说CMDB
传统的运维管理都是从CMDB做起的，机器、设备、LB等作为基础的管理单元，运维围绕iass层，无业务状态，「显然不能满足新形态下SRE的业务目标」 「SMDB（Service Management Database）」，我们内部也叫「服务档案」，以服务作为最小管理单元开展业务，同时作为「应用运维的第一入口」，从此大多数的工作都以SMDB为基础展开，最初一个功能导读如下。
2.《统一运维平台的建设思路》
一个成熟的自动化运维系统核心组成包括哪些呢？笔者认为主要包括CMDB+自动化平台+统一监控+ITSM CMDB是运维的基石，也是运维的权威数据库，权威不仅体现在数据准确，也要求数据唯一 自动化运维平台是提升运维效率的利器 监控是实现系统和业务连续稳定运行的重要技术保障手段 ITSM对这些系统进行了一个串联，用流程方式规范IT和运维
运维赛道没有好的产品经理，说的太对了，深受困扰 我们做devops也有同感，好的产品经理可遇不可求 好的产品经理，做CRM、客户生命周期管理系统去了；机器生命周期，应用生命周期管理系统没人干
《CMDB应用消费场景(1) - 监控》 消费场景
数据采集、数据处理、数据可视化、告警、数据分析与优化
统一资源管理中的CMDB 资产管理中的CMDB 可视化管理中的CMDB 运维自动化中的CMDB
总结：CMDB建设是首先明确定位、统一规划、持续迭代的项目，而明确定位和使用场景又是重重之中，切忌盲目模仿，导致大量无效工作和无效功能建设，没有解决好期望解决的问题，反而引入了更大的问题。
NFV-CMDB是广东移动网管支撑团队承建的5G网络云CMDB，来支撑5G网络云的建设 建设CMDB的第一生产力是人，第二生产力是技术。 模型设计要深度贴合实际，消费方的信任感依赖于高数据质量。 亮点功能：自定义下钻、采集流水线、开发者中心、数据质量检查器 消费场景：生命周期流程、性能门户、自动验收
对于 CMDB 项目的失败，普遍的解释是：没有数据的消费场景、工具和技术不行、流程管控不足。 CMDB 的失败不能简单的认为是消费场景、技术和管控流程的问题。而应该从成本和收益的角度考虑。 CMDB成功的两个关键因素是：管理对象的规模和组织的执行力。 华为CMDB经历初创期、整合期、价值发挥期 华为CMDB成长的土壤、条件、机遇和运气 强大的执行力 规模大，有强烈的自动化需求和条件 全球化带来的机遇 偶然的运气 经验教训 拆迁不如搬迁 配置模型要接地气 开放心态和数据分级管理 数据维护流程要简化 保障数据的完整性 数据消费要有反馈 可视化 在初创阶段、要克制数据分析的冲动
CMDB理论支撑
CMDB解决方案
蓝鲸CMDB 蓝鲸这个产品做的确实很强，应该是运维赛道的巅峰了，功能非常强大 人家做的是一个体系，相比于简单的平台就是降维打击 运维这个赛道，很难有第二家可以做到它这个程度 投入成本很高，维护成本也很高 它很强大，功能很丰富，特别适合腾讯类的公司场景，标准化差很多，产品力上不太够 优维CMDB 优云CMDB 新炬CMDB iTop 维易CMDB， 运维的权威数据库按需设计、灵活配置，适配各种复杂运维场景 OpsAny
运营商级别资产登记模板参考
CMDB纳管基础设施可用字段参考，看专业的资产登记模板。
机房 物理名称 系统名称 机柜位置 柜内位置(U) 主机类型 设备厂商 主机型号 SN 业务名称 业务负责人 业务负责人电话 业务IP地址 业务掩码 业务网关 管理/心跳IP 管理/心跳IP掩码 管理/心跳地址网关 业务IPv6地址 带外IP地址 带外掩码 带外网关 带外用户名/密码 RAID配置 主机配置 备注 本端端口 机柜 柜内位置 业务交换机-主 对端端口 本端端口 机柜 柜内位置 业务交换机-备 对端端口 本端端口 机柜 柜内位置 存储交换机-主 对端端口 本端端口 机柜 柜内位置 存储交换机-备 对端端口 本端端口 机柜 柜内位置 存储交换机-主 对端端口 本端端口 机柜 柜内位置 存储交换机-备 本端端口 机柜 柜内位置 管理/心跳交换机-主 对端端口 本端端口 机柜 柜内位置 管理/心跳交换机-备 对端端口 本端端口 机柜 柜内位置 IPMI交换机 对端端口 所属工程阶段
添加好友，邀你入群，运维人的圈子，每日精彩分享，更有大咖解惑！
对的那条路，往往不是最好走的！
精彩文章合集
文章推荐
札记：“关于提升故障排查思路，事前熟悉系统的基础架构及业务流程；事中评估影响范围，快速恢复；事后提升可观测性，基于数据分析。”
-- 优秀的运维小伙伴