新浪企业级CMDB实战课程

很多运维同学的简历上写着「熟悉 CMDB」，真到面试被追问「配置项之间多对多关系怎么存」「自动发现和人工录入冲突了听谁的」，就开始含糊。这门课不解决所有运维问题，它只盯住一个缺口：你能把 CMDB 从一张表设计成一套能在企业里跑起来的系统吗。

先确认你是不是这门课的目标读者

三类人看了会更有感觉。第一类是从运维转开发的同学：脚本写得动，但一让你拆分层、定接口、设计数据模型，就容易把 CMDB 写成一张大宽表。第二类是做 DevOps 平台、发布系统、监控告警的同学：下游一堆系统都依赖配置数据，可上游的 CMDB 今天给的字段明天就变，你一直在给别人擦屁股。第三类是要接手或重做现有 CMDB 的人：老系统表结构看不懂，需求方还在不断加字段。

如果你只是想知道「CMDB 是什么」，不需要看这门课；如果你正被上面某一种情况卡住，它才对得上。

它真正要解决的设计问题

企业级 CMDB 的难点从来不是「存机器信息」，而是这几件事：配置项模型怎么抽象，业务、应用、集群、主机、网络设备之间是什么关系，关系数据用什么结构落库；数据从哪来，自动发现采集和人工维护冲突时以谁为准；变更怎么留痕，出了问题能不能追溯到某个时间点的快照。这些才是课程的主线，也是它区别于「CMDB 入门概念介绍」的地方。

课程给了一套完整的实现代码，你可以对着跑、对着改。注意：代码是拿来验证你的设计判断的，不是拿来复制粘贴就上生产的。看的时候多问一句「这一步为什么这么写」，比把代码敲一遍有用得多。

看完你应该能回答的问题

• 为什么 CMDB 的模型层和存储层要分开？直接建一张表会怎样？
• 配置项之间的关联关系，你会用哪种方式建模，代价是什么？
• 自动采集到的数据和人工录入不一致，你的系统怎么裁决？
• 下游系统调用你的接口拿配置，你怎么保证它拿到的不是三天前的脏数据？
• 一次误操作改了 200 台机器的归属，你怎么恢复、怎么定位？

如果这些问题你现在答不上来，或者答案停留在「加个字段就行」，看完应该有变化。

建议的练习方式

别一上来就通看视频。先自己想一版模型：给你一个中等规模公司的场景，画出配置项和关系，再去看课程里的设计，对照差异——差异点就是你的能力缺口。然后动手把代码跑起来，只改一件事：加一种新的配置项类型，看要动几层。最后试着给自己的版本写一条数据校验规则，体验一下「约束写在哪一层」这件事有多纠缠。

配套资料可以用来核对结果，但不要用它替代你自己的设计。照着敲一遍，你记住的是代码；先设计再对照，你记住的是判断依据，后者才是面试和实际项目里能用的东西。

一句话定位

这是一门偏架构和工程实现的课，前提是你写过代码、接触过运维系统。它能帮你补上「从会用 CMDB 到能设计 CMDB」这一段，但补不了编程基础和运维基础。缺什么补什么，对不上就别硬看。