企业官网建设流程全解析

简介：这是一份聚焦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里的核心概念是配置项CI（Configuration 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基本覆盖了订单系统从应用到基础设施的完整链路。字段上我没有放太多运维之外的“业务拓展”，而是空出了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": "git@gitlab: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半年之后，我把最常见的几类现象汇总成一个排查表，团队里查问题直接对表操作，非常省事：

4.3 几个让我印象深刻的教训

第一，不要一上来就建十二层模型。模型太细，看起来专业，但数据录入成本极高，大家很快就会失去耐心。我后来拆掉一半层级，把相似类型合并，反而使用率立刻上去了。第二，手工补录的数据一定要有自动对账入口，否则就是一次性金库，过两周再看就全是过期值。第三，权限和审计日志必须一开始就做好，我经历过一次批量修改把一套测试环境的关系全部覆盖成生产数据的惨状，没有审计日志的时候只能手工翻找回滚。

做CMDB，工具占三成，流程和制度占七成。经常听人说“选个开源CMDB部署一下就行”，其实真正的坑都在数据治理和流程落地上。指标一定要看长期曲线，前三个月准确率低不要慌，只要对账机制在跑，后面会稳定向上；反而是那种前三个月看起来金光闪闪、全靠实施团队手工洗数据的项目，通常会在撤场之后迅速恶化。

5. 从资源台账到服务拓扑：CMDB还有哪些扩展想象

5.1 从资源库走向服务拓扑的演进路径

一套CMDB通常要经历四个阶段：第一阶段，能做资源台账，起码把主机、数据库、中间件记清楚；第二阶段，能把应用部署和依赖关系描述出来；第三阶段，能汇聚成业务服务拓扑，故障影响可以直观以链路图呈现；第四阶段，CMDB变成整个运维自动化的大脑入口，机器在操作前都会先问它“该动谁，不能动谁”。前两个阶段解决“有没有”的问题，后两个阶段才是真正发挥“基石”价值的地方。

演进过程中可以顺手做的是服务目录，对外以业务服务为中心展示支撑组件。比如“订单服务”这个业务服务下，挂着应用模块、数据库集群、缓存、主机等所有支撑CI，前端业务的故障申报直接选服务目录项，后端再自动匹配到具体CI。我发现这个功能对业务部门特别友好，也大幅提升了CMDB在组织内的存在感。

5.2 容器化之后，CMDB还要不要

手里管着一套几百个Pod的Kubernetes集群之后，很多人会问“Pod一天创建销毁几千次，CMDB怎么管？”我的答案是：别去管Pod，Pod本身就是临时资源。CMDB在容器时代应该管理的是Deployment、StatefulSet、Service这些有明确生命周期的工作负载对象，以及它们对应的镜像版本、所属命名空间、暴露的端口。Pod的数量和健康状态是监控系统和K8s自己的事，不需要沉淀进配置数据库。

接入方式也很标准，写一个同步服务定时调用K8s API，拉取Deployment和Service清单，把它们当作CI写入CMDB，并和业务应用建立deploy_on关系。这样做的好处是，不管你用哪种容器编排平台，上层业务影响分析的逻辑完全不用变，仍然是“业务系统 -> 应用模块 -> 工作负载 -> 资源”，拓扑模型稳定，底层平台换掉也不伤筋动骨。

5.3 一点个人感想

回到标题里的“基石”，我越做越觉得这两个字很传神。CMDB不像监控那样能立刻看到告警价值，也不像自动化那样能肉眼可见省人力，它是在后台默默供给数据的角色。它做得好的时候，你会觉得所有流程都是顺畅的；它做得烂的时候，整个运维平台就会变成一堆零散的孤岛工具。别把CMDB当成一个“项目”做完就散场，它更像是一种长期的数据纪律，需要持续投入治理。

最后再分享一个小技巧：判断CMDB有没有做成功，不用看张贴在墙上的架构图和数据量指标，就看故障发生时，大家是先去翻CMDB找关系，还是继续在微信群里喊人。做到前者，这个基石才算真正立住了。

本文还有配套的精品资源，点击获取