1. 从一次资产盘点翻车说起CMDB到底在管什么很多团队第一次认真考虑上CMDB往往不是因为什么宏大的战略规划而是被一次具体的翻车事件逼出来的。我印象很深的一次是某公司做季度安全巡检安全同学拿着一份服务器清单去核对补丁情况结果发现清单上有三台机器早就下线了还有两台新上线的机器压根不在表里。更尴尬的是运维同学手里那份Excel和安全的这份对不上两边差了十几台。最后花了整整两天时间靠人肉登录各平台、翻工单记录、问各个业务负责人才勉强拼出一份大概准确的资产表。这件事的本质不是谁工作不认真而是资产信息散落在太多地方且没有一个被所有人认可的唯一事实来源。CMDBConfiguration Management Database配置管理数据库要解决的就是这个唯一事实来源的问题。它不是一张表也不是一个软件而是一套把IT环境里的各类资源及其关系记录清楚、维护准确、并对外提供可信数据的机制。先把话说在前面CMDB是运维领域里听起来简单、做起来极难的典型代表。市面上讲CMDB的文章一大半在讲概念模型一小半在讲某款工具怎么装但真正落到我到底该怎么落地、怎么保证数据不烂掉的内容少得可怜。这篇就按我自己的实操经验把CMDB从概念到落地、从建模到数据治理、从踩坑到避坑完整地捋一遍。不管你是刚接手CMDB建设的新人还是已经被CMDB数据质量问题折磨过的老手应该都能找到能直接抄作业的部分。需要提前说明的是CMDB的落地高度依赖你所在环境的规模、技术栈和组织协作方式本文给出的模型、字段、流程都是基于常见实践总结的通用方案具体到你的环境需要做裁剪。我会在每个关键选择处解释为什么这么设计而不是只丢一个结论给你。2. CMDB的核心模型配置项、关系与属性该怎么设计2.1 配置项CI到底哪些东西该进CMDBCMDB里每一条记录叫一个配置项Configuration ItemCI。新手最容易犯的错是想把所有东西都塞进去——从机房、机柜、交换机、服务器到中间件、数据库、应用、甚至一个配置文件全都想管。结果就是模型极其庞大没人维护得动半年后数据全烂。我的经验是CI的粒度要服务于你的使用场景而不是追求大而全。先问自己三个问题谁会用这份数据用来做什么决策如果某个字段错了会导致什么后果想清楚这三个问题CI的范围自然就出来了。常见的CI分层可以这样理解层级典型CI类型主要使用方关键属性举例物理层机房、机柜、物理机、网络设备基础设施运维位置、型号、序列号、维保到期虚拟层虚拟机、容器、集群平台运维所属宿主机、规格、镜像、IP软件层操作系统、中间件、数据库系统运维版本、端口、部署路径、账号应用层应用系统、服务、接口研发、业务负责人、依赖关系、SLA等级业务层业务线、业务流程业务方、管理层业务负责人、影响范围这张表不是让你照搬而是给你一个分层思考的框架。层级越往上抽象程度越高维护成本也越高。很多团队做到软件层就够用了硬要往上做到业务层反而因为业务关系频繁变动而维护不动。提示CI的粒度判断有个实用标准——如果一个对象的变化频率高到你根本追不上那它大概率不该作为独立CI而应该作为某个CI的属性。比如进程状态变化太快就不适合做CI但服务端口相对稳定可以作为属性。2.2 关系模型CMDB真正的价值在关系上如果CMDB只是记录一堆孤立的资产那它和一张Excel没本质区别。CMDB的核心价值在于把CI之间的关系记录下来这样你才能回答这台服务器挂了会影响哪些业务这类问题。关系类型不需要设计得太复杂常见的几类就够用依赖关系应用A依赖数据库B服务C调用接口D。这是最有价值的一类关系直接影响故障影响面分析。包含关系机柜包含服务器集群包含节点应用包含多个服务。用于做层级聚合。连接关系服务器连接交换机用于网络拓扑还原。部署关系应用部署在哪些主机上用于发布和回滚。关系建模最容易踩的坑是关系方向不统一。比如应用依赖数据库和数据库被应用依赖如果不同人录入时方向不一致查询时就会漏数据。我的做法是强制约定方向语义比如统一用源依赖目标的方向并在录入界面用明确的动词提示避免歧义。2.3 属性设计字段不是越多越好属性Attribute是CI的具体描述字段。新手常犯的第二个错是给每个CI类型设计几十个字段觉得反正多填点没坏处。实际上没人填的字段等于不存在而且字段越多录入和维护成本越高数据质量越差。我的字段设计原则是三三制必填字段控制在3-5个比如名称、类型、负责人、状态、所属环境。这几个字段错了整个CI就没意义。关键字段按场景补充比如做安全合规就加是否公网暴露等保等级做成本管理就加成本中心计费方式。扩展字段用标签或JSON承载那些偶尔用一次、变化频繁的信息不要做成独立字段用标签Tag或扩展属性存避免污染主模型。这里有个很实际的教训我曾经参与过一个项目CMDB里给服务器设计了40多个字段结果上线三个月后除了必填的5个字段其余字段的填充率不到20%而且填了的内容里还有大量错误。后来做了一次大瘦身砍到12个字段填充率立刻上去了数据反而更可信。字段少而准远胜于字段多而烂。3. 数据从哪来自动发现与人工维护的边界划分3.1 为什么纯人工维护必然失败先说一个残酷的事实任何依赖人工逐条录入的CMDB最终都会烂掉。原因很简单IT环境是动态的每天都有机器上下线、应用发布、配置变更人工录入的速度永远追不上变化的速度。而且人工录入没有强制约束今天忙了就明天填明天忙了就下周填最后就没人填了。所以CMDB的数据来源必须是自动发现为主人工维护为辅。自动发现负责把客观存在的、可探测的信息抓进来人工维护负责补充那些机器探测不到的、需要人判断的信息比如负责人、业务归属、重要性等级。3.2 自动发现能抓什么抓不到什么自动发现的手段很多常见的有几类网络扫描通过网段扫描发现存活主机、开放端口。优点是覆盖广缺点是只能发现网络可达的东西且可能触发安全告警需要提前报备。Agent采集在主机上装采集程序上报硬件信息、进程、监听端口、已安装软件。优点是信息详细准确缺点是需要部署和维护Agent。API对接从虚拟化平台、云平台、容器平台、监控系统拉取数据。优点是数据权威缺点是依赖对方接口的稳定性。配置管理工具同步从自动化运维工具如配置管理、编排工具同步节点信息。自动发现的能力边界要清楚信息类型自动发现人工维护主机名、IP、操作系统版本可以不需要硬件规格、序列号可以不需要监听端口、运行进程可以不需要应用负责人困难必须业务归属、重要性等级不能必须应用间的调用关系部分可探测需要补充维保信息、合同信息不能必须这张表的意义在于别指望自动发现解决所有问题也别让人工去干机器能干的活。把两者边界划清楚各司其职CMDB才维护得动。3.3 数据同步的权威源原则一个非常关键但常被忽略的原则每个字段都要有唯一的权威源Source of Truth。什么意思就是某个字段的值只能由一个地方说了算其他地方都是它的副本。举个例子服务器的IP地址权威源应该是IP地址管理系统IPAM或网络平台服务器的负责人权威源应该是CMDB本身因为别处没有应用的部署关系权威源可能是发布系统。如果同一个字段有多个来源且没有明确谁优先那数据冲突就是必然的。我见过最混乱的情况是CMDB、监控系统、发布系统各维护一份主机清单三份数据互相同步结果形成了环状同步A改B、B改C、C又改回A最后谁也不知道哪个是对的。解决之道就是明确权威源单向同步禁止环状回写。注意自动发现的数据不要直接覆盖人工维护的字段。正确做法是自动发现的数据进入待确认状态或者只更新它负责的那部分字段人工字段保持独立。否则人工辛苦填的负责人信息可能被一次自动同步清空。4. 落地路线图从小范围试点到全面推广4.1 别一上来就搞全量建模CMDB项目失败的头号原因是一开始就想建一个覆盖全公司、全类型的完美模型。这种项目通常周期长、见效慢做到一半业务方就失去耐心最后不了了之。我的建议是小步快跑先解决一个具体痛点。比如你最近被故障影响面分析折磨得够呛那就先聚焦应用-主机-数据库这条链路把这三类CI和它们的关系建起来先让故障排查能用上。等这个场景跑通了再逐步扩展到网络设备、中间件等。试点范围的选择有个技巧选一个变化相对稳定、协作意愿强的业务。别选那种天天大改架构的业务否则你模型还没建完它已经变了好几轮了。4.2 分阶段推进的实操节奏我把CMDB落地分成四个阶段每个阶段有明确的交付物和验收标准第一阶段模型设计与工具选型2-4周明确使用场景和优先级设计CI类型、关系类型、属性字段选定CMDB工具或平台交付物数据模型文档、工具环境第二阶段小范围数据接入4-8周选定1-2个试点业务打通自动发现通道完成首批数据录入和校验交付物试点业务的完整CI数据第三阶段场景验证与迭代4-8周用真实场景验证数据可用性如故障排查、变更影响分析根据反馈调整模型交付物可用的查询和展示能力第四阶段推广与治理持续扩展到更多业务建立数据质量监控和考核机制交付物数据质量报告、维护流程这个节奏的关键是每个阶段都有可验证的产出而不是闷头建了半年模型最后发现没人用。4.3 工具选型自研、开源还是商业工具选型没有标准答案取决于你的团队能力和预算。我列一下常见的几种路线和适用场景路线优点缺点适合谁Excel/在线表格零成本、上手快无关系模型、无权限、易烂极小规模、临时过渡开源CMDB免费、可定制需要二次开发、文档参差有研发能力的团队商业CMDB功能完整、有支持成本高、定制受限预算充足、追求稳定自研完全贴合需求投入大、周期长规模大、需求特殊的团队我的观点是除非你的规模大到开源和商业都满足不了否则不要轻易自研。自研CMDB看起来能完全按自己需求来但实际上你要投入大量人力去维护它而且很容易做成一个只有作者会用的系统。很多团队自研了两年最后发现功能还不如开源方案白白浪费了人力。选型时还要重点考察几个能力关系查询能力能不能方便地查依赖链路、API开放程度能不能和现有系统集成、权限模型能不能按业务隔离数据、变更审计能不能追溯谁改了什么。这几个能力直接决定CMDB能不能用起来。5. 数据质量治理让CMDB不烂掉的长效机制5.1 数据质量问题的三种典型表现CMDB上线不难难的是让它一直保持准确。数据质量问题通常有三种表现缺失该有的CI没有该填的字段空着。比如新上线的机器没录入。错误数据填了但是错的。比如IP填错、负责人填成了离职的人。过时数据曾经对但现在不对了。比如机器已下线但状态还是运行中。这三种问题的成因不同治理手段也不同。缺失靠强制流程解决错误靠校验规则解决过时靠定期核对解决。5.2 把CMDB嵌入运维流程最有效的治理手段是让CMDB成为其他流程的必经环节。什么意思就是让不录CMDB这件事变得做不下去。举几个具体的嵌入点资源申请流程申请新机器时必须先在CMDB创建CI否则流程走不下去。发布流程应用发布前必须确认CMDB里的部署关系是最新的。变更流程任何变更完成后必须同步更新CMDB对应字段。下线流程资源下线时必须先在CMDB标记状态否则回收流程不启动。这样做的逻辑是把数据维护的成本分摊到本来就要做的流程里而不是额外增加一项维护CMDB的工作。人都是懒的额外的工作没人愿意干但如果是流程的一部分那就不得不干。5.3 定期核对与差异处理即便流程嵌入做得再好数据还是会有偏差。所以需要定期做核对把CMDB数据和实际环境比对找出差异并处理。核对的频率取决于环境变化速度一般建议核心资产服务器、数据库每周核对一次一般资产网络设备、中间件每月核对一次关系数据每季度核对一次核对的方式可以是自动发现结果与CMDB比对也可以是人工抽查。关键是差异要有处理闭环——发现差异后要么修正CMDB要么修正实际环境不能放着不管。我见过太多团队核对报告出了一堆差异但没人处理久而久之核对本身也流于形式了。提示核对差异不要追求零差异那不现实。要区分可接受的差异和必须处理的差异。比如临时测试机器没录入可以接受但生产核心数据库的负责人是错的必须马上改。5.4 数据质量的度量指标要让数据质量可管理就得有度量。我常用的几个指标完整率必填字段的填充比例目标95%以上。准确率抽查样本中数据正确的比例目标90%以上。及时率变更发生后CMDB更新的及时程度目标24小时内。关系覆盖率核心应用的关键依赖关系记录比例目标100%。这些指标要定期出报告并且和责任人挂钩。没有考核的数据治理都是纸上谈兵。6. 那些年踩过的坑CMDB落地常见误区6.1 把CMDB当成资产管理系统来建这是最常见的误区。很多人把CMDB和IT资产管理ITAM混为一谈重点全放在资产台账上——采购日期、价格、维保、折旧。结果CMDB变成了一个财务台账运维用不上研发更不看。CMDB和ITAM有交集但重点不同ITAM关注资产值多少钱CMDB关注配置之间怎么关联、变更会影响什么。如果你的CMDB只有资产属性没有关系数据那它就是个资产表不是CMDB。6.2 追求实时同步导致系统不堪重负有些团队追求CMDB和实际环境实时一致于是设计了一套高频同步机制每分钟甚至每秒同步一次。结果CMDB数据库压力巨大而且因为同步太频繁反而产生了大量无意义的变更记录把真正重要的变更淹没了。我的经验是同步频率要匹配业务需求而不是追求技术上的实时。大部分场景下小时级甚至天级的同步频率就够用了。真正需要实时的只有少数关键字段比如核心服务的状态可以单独做高频同步。6.3 忽视人的因素只关注技术CMDB项目失败技术原因往往只占三成七成是人的问题。具体表现为没人愿意填觉得是额外负担能拖就拖。填了没好处填了数据自己用不上自然没动力。责任不清晰出了错找不到是谁维护的。解决这些问题靠的不是技术而是机制设计让填数据的人能从中获益比如查依赖关系方便了让不填的人有代价比如流程走不通让责任可追溯每个CI有明确负责人。6.4 一次性建设缺乏持续运营很多团队把CMDB当成一个项目上线就算完事没有后续的运营投入。结果就是上线时数据很漂亮三个月后开始出现偏差半年后基本不可用。CMDB是运营不是项目。它需要持续的人力投入有人负责模型维护有人负责数据核对有人负责流程优化。这个投入不需要很大但必须持续。我见过做得好的团队通常有一个兼职的CMDB管理员角色每周花几个小时做数据巡检和问题处理就能维持得不错。7. 从CMDB到配置管理它真正的长期价值聊了这么多落地细节最后说说CMDB的长期价值在哪。很多人把CMDB当成一个查询工具需要的时候查一下资产信息。但CMDB真正的价值是成为整个运维体系的数据底座。当CMDB的数据足够准确、关系足够完整时它能支撑起很多上层能力故障影响面分析某个数据库挂了能立刻查出影响哪些应用、哪些业务。变更风险评估要改一台交换机能查出它承载了哪些链路、影响哪些服务。容量规划基于CI的规格和使用数据做资源预测。安全合规快速定位暴露面、核查补丁覆盖。成本分摊按业务归属做资源成本核算。这些能力的共同前提是CMDB的数据可信。数据不可信上面这些全是空中楼阁。所以CMDB建设的核心从来不是建一个系统而是建立一套让数据持续可信的机制。我个人在实际操作中的体会是CMDB这件事慢就是快。别想着三个月建一个大而全的完美系统而是从一个具体场景切入把数据做准让用的人尝到甜头然后逐步扩展。那些一上来就追求全量、实时、完美的项目往往死得最快。反过来那些看起来只解决了一个小问题的项目反而因为扎实最后长成了真正有用的平台。最后再分享一个小技巧给CMDB设一个数据质量看板放在团队每天都能看到的地方。把完整率、准确率、待处理差异这些指标可视化出来比开十次宣贯会都管用。人都是要面子的看到自己负责的模块数据质量垫底自然会去改。这个办法我在几个团队都用过效果出奇地好。
