简介这是一份聚焦CMDB在DevOps与ITIL体系中核心价值的PDF资料适合运维平台建设者、架构师及DevOps实践者阅读。内容围绕一体化运维平台为何需要强CMDB、CMDB模型如何构建、平台如何建设与落地展开涵盖以服务为中心的模型设计原则、IT对象属性与关系梳理方法、两层逻辑架构、数据准确性管理闭环以及大型银行落地案例等体系化内容。资源共1个pdf文件压缩包大小5.27MB目前已有1729人学习下载。PDF排版完整、目录层级清晰既有理论框架也有面向应用的资源模型示例。通过阅读可系统理解CMDB与ITIL、DevOps之间的定位关系掌握从资源建模到配置管理落地的关键路径为企业搭建以CMDB为基石的运维数据平台提供可直接借鉴的思路和方法。 做了十来年运维听过最漂亮也最害人的一句话是“上个CMDB一切就都规范了。”结果呢平台搭了一堆数据下面却是漏的监控、变更、故障处理各查各的表最后发现问题不是工具不够强而是缺了一个统一管理配置项的地方。CMDB全称Configuration Management Database配置管理数据库它不是一张静态资产清单而是企业一体化运维平台的数据底座。这份内容把CMDB放在“基石”这个位置上我认为是相当准确的。一体化运维平台里监控、告警、变更、工单、自动化、ITSM全都挂在这块地基上地基不稳上层建筑做得再花哨也是空中楼阁。这篇文章我会结合自己落地过的一套CMDB项目从为什么、怎么建、怎么用、怎么维护几个角度把这块基石完整拆开讲一遍特别适合正在选型或已经开始建设CMDB的运维、DevOps同学参考。1. 一体化运维平台为什么把CMDB当成地基1.1 CMDB不是一份资产表而是数据模型加关系网很多团队对CMDB的理解停留在“把服务器登记在一个系统里”这大概是最常见的误区。CMDB里的核心概念是配置项CIConfiguration Item一台服务器是CI一个数据库实例是CI一个中间件是CI一个业务系统也是CI。CI会带属性比如IP、主机名、操作系统、责任人、状态、上架时间等等。但如果只有这些它顶多算一个资产管理系统离“基石”还差得远。CMDB真正值钱的地方在“关系”这两个字。CI之间会有部署、连接、依赖、包含这类关系组合起来就形成一张业务拓扑网。举个例子web01这台主机是一台CI它上面跑的订单应用是一个CI订单应用连着的数据库实例是另一个CI反代到它的Nginx又是一个CI。CMDB要能告诉我如果web01挂了影响的是哪个应用模块、哪个数据库、哪些业务链路。这种“谁依赖谁”的视图才是监控、变更、故障处理都需要的那份公共上下文。当年我在自建CMDB时最早就犯过“大而全”的错把机房机柜、空调功率、采购合同全塞进去结果所有人都不愿意录入数据很快就烂了。后来才明白CMDB的本质不是尽量多记而是记准记清、为流程服务。它应该围绕“支撑核心业务的配置项”来建模而不是变成一个什么都装的杂物间。1.2 没有CMDB的时候一体化平台为什么总是打架没有CMDB的一体化运维平台往往拥有一个漂亮的门户但底层数据各自为政。监控系统里存一套主机清单变更系统里存另一套设备清单工单系统里又有一份“常见影响设备”关键金数据还不一致。平时看着没事一出故障就暴露了监控说“主机宕机”但“影响哪些业务”大家各执一词运维说是应用问题应用说是数据库问题现场全是救火队员。我经历过一次真实的事故半夜一台核心应用服务器做了内核升级重启启动后服务一直起不来。当时我们手上没有统一的依赖关系只能靠几个老员工翻Excel表、凭记忆勾关联。结果漏了一条链路导致订单消息积压了快两个小时才被定位。那次之后我才坚决把CMDB当作平台的第一个模块来做而不是等集成厂商最后顺便来接个库里数据完事。一体化运维平台里的监控告警、变更管理、故障定位、自动化作业、容量管理全是围绕CI和关系展开的。打比方说四个汽车轮子性能再好没有底盘把它们联成一体车还是跑不起来。CMDB就是这个底盘它让所有流程模块能用同一套语言描述“影响什么”、“归属谁”、“能不能变”这才是“一体化”三个字真正的含义。1.3 基石具体承担什么功能为所有流程提供“上下文”CMDB并不是直接处理告警或者执行脚本它提供的是上下文是数据底座。监控抓到“磁盘使用率超过90%”光看这个值没有业务含义接上CMDB之后就能知道这块盘属于哪个数据库实例、服务于哪个业务系统、由哪个团队负责告警就可以自动带责任人和影响范围变更管理里要重启数据库CMDB能把上下游依赖一次性拉出来审批的人才能判断“这个变更有没有风险”自动化平台执行重启前也要先问CMDB“这台机器现在承担什么角色恢复后应该拉起哪些进程”没有这个底座自动化只能是无脑执行做不了精细判断。所以看一个CMDB建得好不好不是看配置项的数量级而是看消费方有多少被多少流程频繁使用。如果建完之后没人调它的API没人看它的拓扑那它本质上只是一个高级Excel离“一体化运维平台的基石”还差着十万八千里。2. 从0搭一套靠谱CMDB的四步关键决策2.1 先回答CI分成几类边界在哪里落地CMDB第一步不是选型不是买服务器而是定数据模型。模型定得太大后面全是填不完的坑模型定得太小又撑不起业务场景。我建议从“支撑核心业务的最小闭包”开始不追求覆盖机房里的每一根网线先保证核心应用链路是完整的。我把CI分成四层基础设施层包括主机、网络设备、云资源、存储应用组件层包括数据库实例、中间件、缓存这些是提供能力的组件业务应用层是真正对外提供功能的模块比如订单服务、支付服务最上面是业务系统层相当于服务目录里对外可见的产品。这四层之间用关系串起来比如“业务系统包含订单应用”、“订单应用部署在主机上”、“订单应用依赖MySQL实例”。分类定好后属性也要克制。常见错误是给每个CI类型设计几十个字段结果一半没人填。通用属性我通常只保留名称、编号、环境、状态、负责人、数据来源、更新时间和可信度特殊需求再用扩展字段。有一个小技巧每个字段都要标注来源和可信度是自动发现的、API同步的还是人工录入的这对后续对账非常有帮助。2.2 数据从哪来自动发现、API同步、人工补录三条腿配合CMDB的数据来源一定要多元纯靠人工录入必死无疑。我采用的方式是三条腿走路第一条腿是自动发现在服务器上装Agent或者通过SSH远程采集主机的系统信息、软件实例、开放端口把这些当作“事实数据”第二条腿是API同步针对云上资源、虚拟化平台、Kubernetes集群直接调用云平台或K8s的API定时拉取实例列表能够自动感知扩容缩容第三条腿是人工补录主要补的是业务负责人、服务等级、成本中心这类“业务元数据”这些数据在系统里确实拿不到。把三个来源放一起就涉及一个优先级和对账规则的问题。我的经验是硬件的物理属性、进程端口这类以自动发现为准业务归属和责任人以人工补录为准两类数据定期比对发现不一致时出来一条对账差异记录而不是直接覆盖。这么做虽然短期内会多出很多“待处理差异”但能逼着团队把每一条差异都搞清楚反而是在给数据质量上保险。2.3 关系怎么建模从“有什么”到“谁依赖谁”如果说CI类型定义是骨架那么关系定义就是神经和血管。关系才是CMDB能够用于影响分析、变更评估的关键。我通常最少定义这么几类部署关系deploy_on表示应用或中间件跑在哪台主机上连接关系connect_to表示应用与数据库、中间件之间的网络连接依赖关系depends_on表示某个服务要正常工作就必须依赖另一个服务包含关系belongs_to表示上层业务系统包含哪些应用模块。关系建模一定要有方向性。影响分析的本质就是沿着依赖关系做有向遍历。比如订单服务depends_on支付服务那么支付服务出问题的时候系统要能反查出来“上游订单服务会受影响”而下线一台主机通过deploy_on关系能查出来它上面部署了什么应用不能顺手就删。关系类型别贪多宁可用有限的几种表达清楚也不要造出一堆只有自己能看懂的关系否则后面查询、维护都会非常痛苦。2.4 谁来维护组织保障比技术选型更重要技术选型解决不了数据谁来录入、谁来审核、谁来考核的问题。CMDB项目失败十有八九不是工具烂而是责任没落到人身上。我强烈建议在一体化运维平台项目里设“配置经理”这个角色可以由运维负责人兼任主要负责整体数据标准和流程同时给每一类CI指定Owner。主机CI的Owner是系统管理员应用CI的Owner是应用负责人数据库CI的Owner是DBA每个Owner要负责自己领域内数据的新增、变更和下线审核。同步还要把CMDB的操作嵌进变更流程。无论变更走工单审批还是自动化平台凡是涉及生产环境CI增删改的变更完成后都要自动回写CMDB状态。这一步做扎实了CMDB里的数据才有机会保持“活”的状态而不至于上线时满腔热血半年之后又是千人千面的Excel时代。考核指标建议用三个CI信息完整率、配置项准确率、关系覆盖率达到一定数值并且每周自动出报告发给所有负责人。3. 实战演示订单系统CI模型设计与接口打通3.1 一套订单系统的CI类型和属性怎么定理论说完了我们落到一套线上订单系统上看实际的CI模型应该长什么样。我这边定义的CI类型如下CI类型关键属性典型关系business_service 业务系统名称、业务负责人、服务等级、状态contains 包含应用模块app_module 应用模块应用名、Git仓库、构建版本、端口、状态deploy_on 部署到主机db_cluster 数据库集群集群名、集群类型、主节点地址manages 管理实例db_instance 数据库实例实例名、版本、端口、备份策略connect_to 被应用连接middleware 中间件类型、版本、配置路径、端口deploy_on 部署到主机host 主机主机名、IP、OS、CPU内存、机房mounts 挂载存储network_device 网络设备名称、IP、型号、固件版本connect_to 连接主机这套模型的优势在于精简七类CI基本覆盖了订单系统从应用到基础设施的完整链路。字段上我没有放太多运维之外的“业务拓展”而是空出了ext_attrs扩展字段未来接财务成本或容量管理数据时通过扩展字段动态加不用频繁动主模型。3.2 用API把第一个配置项“建”出来模型定完接下来就是要把数据真正灌进去。现在的CMDB产品基本都会提供一套REST API我用一个Python脚本把APP模块和主机建立关系模拟发布平台在部署完成后自动写CMDB的场景import requests CMDB_URL http://cmdb.devops.local/api def create_ci(ci_type, attrs): resp requests.post(f{CMDB_URL}/ci, json{ type: ci_type, attrs: attrs }) resp.raise_for_status() return resp.json()[data][id] # 创建主机和订单应用模块 host_id create_ci(host, { name: web-prod-01, ip: 10.20.1.12, os: CentOS 7.9, status: prod }) app_id create_ci(app_module, { name: order-service, git_repo: gitgitlab:order/order-service.git, version: 2.4.1, port: 8080, owner: zhang_san }) # 建立“部署在主机上”的关系 resp requests.post(f{CMDB_URL}/relation, json{ source: app_id, target: host_id, relation_type: deploy_on, direction: app_to_host }) print(resp.json())这段代码的逻辑很简单先把两个CI建出来再写一条关系。看起来基础但它背后的意义是把CMDB的数据维护动作从人工点击变成了部署流水线自动执行。你可以把它接在GitLab CI或者Jenkins的部署后置任务里应用每发布一次版本号和关系都自动更新。CMDB的CI标识建议用平台生成的唯一ID不要用IP因为IP会被回收和复用用IP当主键非常容易串数据。3.3 和监控、工单、变更系统怎么联动CI建起来之后必须想办法被持续消费否则又回到“建完没人用”的循环。监控系统是最容易先打通的消费方。我在告警规则里加了一个步骤收到主机宕机告警后自动调用CMDB的拓扑查询接口拿到这台主机上运行的应用模块和业务系统然后在告警通知里附带影响链路这样值班人员不用登录三个系统去拼信息。我还提供了一个标准的查询接口给工单系统让故障申报时可以直接按业务系统选择受影响范围。变更审批页面上审批人也能实时查看变更对象的拓扑依赖变更单里写“影响哪些系统”的时候不再是拍脑袋填。自动化运维平台则是在执行作业前先调用CMDB查“目标主机有哪些服务”作业脚本只需按服务清单做启停而不是写一个固定的进程名列表。这一套打通之后我明显感觉到所有平台模块的数据口径统一了连带着开会吵架的次数都少了。4. 上线之后数据维护和常见问题排查实录4.1 数据准确率为什么总是跌CMDB上线三个月准确率普遍会经历一次“高开低走”。最典型的原因是变更之后没人更新配置。开发发一个新的数据库连接池DBA改了配置但CMDB里的连接关系没同步线上做了一次容量扩容新增了一台云主机自动发现没跑出来或者被安全策略拦住了这类型的差距就会越积越多。解决思路是别指望自觉要在流程上硬卡所有变更工单在关闭前都必须回写CMDB关联项否则流程不能结束。另一个常见的脏数据来源是“下线流程缺失”。开发环境的主机往往用完就扔但没有人在CMDB里把状态改成已下线导致僵尸CI越来越多查询结果越来越难用。我后来强制要求所有云资源释放和物理机退库必须同步走一个CMDB状态变更记录并把状态从“在用”改成“待回收”再定期由配置经理统一清理。另外也要防权限松的问题不是所有人都有编辑生产CI的权限建议默认只读写操作通过API和审批流来完成。4.2 常见问题排查速查表维护CMDB半年之后我把最常见的几类现象汇总成一个排查表团队里查问题直接对表操作非常省事问题现象可能原因处理建议监控系统主机数大于CMDB数量自动发现未覆盖或采集被防火墙拦截查看发现日志扩大网段范围检查Agent上报链路应用负责人联系方式错误人员变动后没人更新业务元数据设置责任人复核任务每季度自动提醒拓扑关系断了一截部署脚本没有执行关系写入检查部署流水线补触发CMDB API的动作数据库应用连接关系缺失应用配置变更后未同步接入配置变更事件监听配置中心变更自动更新关系CI数量无故暴涨自动发现把临时进程或容器也采成了CI调整发现规则制定CI过滤条件接口查询变慢关系表没有索引或全表扫描给relation表建联合索引热点关系走缓存4.3 几个让我印象深刻的教训第一不要一上来就建十二层模型。模型太细看起来专业但数据录入成本极高大家很快就会失去耐心。我后来拆掉一半层级把相似类型合并反而使用率立刻上去了。第二手工补录的数据一定要有自动对账入口否则就是一次性金库过两周再看就全是过期值。第三权限和审计日志必须一开始就做好我经历过一次批量修改把一套测试环境的关系全部覆盖成生产数据的惨状没有审计日志的时候只能手工翻找回滚。做CMDB工具占三成流程和制度占七成。经常听人说“选个开源CMDB部署一下就行”其实真正的坑都在数据治理和流程落地上。指标一定要看长期曲线前三个月准确率低不要慌只要对账机制在跑后面会稳定向上反而是那种前三个月看起来金光闪闪、全靠实施团队手工洗数据的项目通常会在撤场之后迅速恶化。5. 从资源台账到服务拓扑CMDB还有哪些扩展想象5.1 从资源库走向服务拓扑的演进路径一套CMDB通常要经历四个阶段第一阶段能做资源台账起码把主机、数据库、中间件记清楚第二阶段能把应用部署和依赖关系描述出来第三阶段能汇聚成业务服务拓扑故障影响可以直观以链路图呈现第四阶段CMDB变成整个运维自动化的大脑入口机器在操作前都会先问它“该动谁不能动谁”。前两个阶段解决“有没有”的问题后两个阶段才是真正发挥“基石”价值的地方。演进过程中可以顺手做的是服务目录对外以业务服务为中心展示支撑组件。比如“订单服务”这个业务服务下挂着应用模块、数据库集群、缓存、主机等所有支撑CI前端业务的故障申报直接选服务目录项后端再自动匹配到具体CI。我发现这个功能对业务部门特别友好也大幅提升了CMDB在组织内的存在感。5.2 容器化之后CMDB还要不要手里管着一套几百个Pod的Kubernetes集群之后很多人会问“Pod一天创建销毁几千次CMDB怎么管”我的答案是别去管PodPod本身就是临时资源。CMDB在容器时代应该管理的是Deployment、StatefulSet、Service这些有明确生命周期的工作负载对象以及它们对应的镜像版本、所属命名空间、暴露的端口。Pod的数量和健康状态是监控系统和K8s自己的事不需要沉淀进配置数据库。接入方式也很标准写一个同步服务定时调用K8s API拉取Deployment和Service清单把它们当作CI写入CMDB并和业务应用建立deploy_on关系。这样做的好处是不管你用哪种容器编排平台上层业务影响分析的逻辑完全不用变仍然是“业务系统 - 应用模块 - 工作负载 - 资源”拓扑模型稳定底层平台换掉也不伤筋动骨。5.3 一点个人感想回到标题里的“基石”我越做越觉得这两个字很传神。CMDB不像监控那样能立刻看到告警价值也不像自动化那样能肉眼可见省人力它是在后台默默供给数据的角色。它做得好的时候你会觉得所有流程都是顺畅的它做得烂的时候整个运维平台就会变成一堆零散的孤岛工具。别把CMDB当成一个“项目”做完就散场它更像是一种长期的数据纪律需要持续投入治理。最后再分享一个小技巧判断CMDB有没有做成功不用看张贴在墙上的架构图和数据量指标就看故障发生时大家是先去翻CMDB找关系还是继续在微信群里喊人。做到前者这个基石才算真正立住了。本文还有配套的精品资源点击获取