运维放下对CMDB+N的执念：将CMDB当监控的增值场景

求知解惑
咱们虽然身在运维行业多年，对监控的理解可能还停留在 “看看曲线、报个警” 的浅层认知。有时交流我们也会问：“我们CMDB和监控怎么对接？” ，但每次回应好像都是对方的摇头苦笑。这是因为我们一直站在建设者的角度，对产品既要又要，从而忽略了产品的演进过程，毕竟我们要对结果负责。

如今从乐维-丁老师的交流中好像有了答案：“我们原则上不单独卖CMDB，而是把CMDB当监控的增值场景，不鼓励用户直接上CMDB！”

稍微深入理解下：CMDB从来不是独立的产品，而是监控体系生长到一定阶段的自然产物，是给用户的增值馈赠。从不鼓励用户直接上CMDB，因为脱离监控的CMDB，就像没根的浮萍。

监控才是根，CMDB是长出来的枝叶？
运维建设过程中，我们始终坚持以CMDB为中心，将监控、架构、CI/CD、管理端等作为消费增值场景，具体消费维度如下：

架构、CI/CD、管理端消费的对象是模块名、IP、集群、环境等应用维度；
监控消费的对象是网络设备、服务器、操作系统、拓扑、应用等多维度；
从这些消费对象的差异能看出，监控相比其他场景对资产数据的实时性、完整性要求更高。而脱离监控的CMDB，既无法满足监控的多维数据需求，也难以在其他场景真正“活”起来。

从下往上看，我们的理念是CMDB来驱动消费场景，由于场景的不确定性，导致字段的野蛮生长。从上往下看，我们以监控需求为导向，倒推CMDB所需字段。只有基于监控场景沉淀下来的字段，才是真正有生命力、能持续服务于业务的，这样既避免了字段冗余，也让CMDB与监控深度绑定，成为一个有机整体。

试想一下，如果把监控做到极致，覆盖从网络、物理机、虚拟机到容器等全栈链路，每一次数据采集都是对资产状态的实时校验：

监控探针发现新部署的应用实例时，自动补全其所属业务线、依赖的数据库信息；
网络拓扑监控识别到设备间链路变更时，同步更新 CMDB 中的连接关系；
甚至连硬件保修到期时间，都能通过监控系统抓取厂商API自动续期提醒；
这时候我们会发现，CMDB的资产在监控的滋养下自己就长全了。用户根本不用专门花力气 “上CMDB”，当他们能通过监控面板看清 “某台服务器承载着哪些服务、进程、容器” 时，CMDB 的核心价值已经握在手里了。

为什么不鼓励直接上 CMDB？

太多团队栽在“为了CMDB而CMDB” 的坑里，从建设、推广、维护，到头来却发现，CMDB里的数据很快就成了 “僵尸数据”，不仅没给运维带来便利，反而成了沉重的负担。

直接上CMDB的本质，是试图用静态管理应对动态系统：

你得先定义数百个配置项字段，可业务迭代快到每周换架构，字段刚定好就过时；
你得制定严格的变更流程保证数据准确，但一线运维为了赶上线，常常 “先斩后奏”；
最尴尬的是，花大价钱建起来的 CMDB，最后只剩审计时才有人点开看两眼。
反观真实的管理路径：当监控系统能实时回答 “系统现在有什么问题”，自然就会追问 “出问题的是什么设备、关联哪些业务”。 这就是CMDB生长的原始需求，当用户通过监控解决90%的日常故障、性能问题后，CMDB里的资产关系、配置信息会像配套说明书一样，在需要的时候精准浮现，这才是它该有的样子。

放下执念
乐维-丁老师：“乐维做了十几年的监控CMDB对我们来说就是吹个灰！”

这句话看似轻松诙谐，实则道出了监控与CMDB深度融合、水到渠成的真谛。从产品的角度在乐维十几年的深耕中，监控与CMDB可能早已浑然一体，无需刻意追求，CMDB便能在监控的土壤中自然生长、枝繁叶茂。

而站在运维前线的我们，本着对项目结果负责的态度，更应放下对CMDB+N的执念，当然这不是说我们将精力转投到监控体系的精细化建设。因为监控的建设曲线和运维平台都是一致的，是一个长期投入、持续改进的过程。不妨我们稍微放下执念，在运维理念中买下一颗夯实监控的种子！

添加好友，邀你入群，运维人的圈子，每日精彩分享，更有小伙伴们的热议！