【CMDB】配置项关系管理与业务拓扑同步

本文速览：▶ CMDB的核心概念｜▶ 传统CMDB的三大困境｜▶ 自动发现与关系建模｜▶ 业务拓扑构建｜▶ 与告警/工单联动｜▶ 某省级政务云实践｜▶ 实施要点与配置建议

核心要点摘要：IT环境中的服务器、网络设备、数据库、应用服务之间存在着复杂的依赖关系。当故障发生时，运维人员需要快速回答“这台服务器挂了会影响哪些业务”“这个数据库被哪些应用使用”。监控易智能一体化运维平台的CMDB模块，支持配置项（CI）的自动发现与关系管理，并通过业务拓扑将技术资源与业务服务关联，帮助运维团队从业务视角掌控IT全局。 

适用读者：政府、金融、军工、能源、交通、医疗、教育等行业运维人员，IT架构师，信息化部门负责人，以及需通过等保2.0或密评的合规负责人。

一、一个故障引发的“蝴蝶效应”

某省级政务云平台，一台核心存储设备性能下降，导致依赖该存储的30多台虚拟机IO延迟升高，进而影响到12个委办局的业务系统响应缓慢。运维团队花了近2小时才梳理清楚影响范围——因为没有人清楚地知道“这台存储上跑了哪些虚拟机，这些虚拟机又支撑哪些业务”。

如果有一套系统能够自动记录IT资源之间的依赖关系，并在故障发生时快速呈现影响链路，这个问题的排查时间可以缩短到几分钟。

监控易的CMDB（配置管理数据库）正是为此而生。

二、传统CMDB的三大困境

困境一：手工维护，信息滞后

传统CMDB依赖人工录入，设备上线、下线、配置变更后，往往不能及时更新。半年后，CMDB中的信息与实际环境严重脱节，失去参考价值。

困境二：关系缺失，价值有限

许多CMDB只记录了“设备清单”，缺乏设备之间、设备与业务之间的关联关系。当故障发生时，无法回答“这个问题会影响哪些业务”这一关键问题。

困境三：与监控割裂，数据孤岛

CMDB是CMDB，监控是监控，两套系统互不打通。监控告警时，无法从CMDB获取设备责任人、业务归属等信息；CMDB中的配置变更，也无法触发监控策略的自动调整。

三、监控易CMDB的核心能力

监控易智能一体化运维平台CMDB模块通过“自动发现+关系建模+业务拓扑+与告警联动”，让配置管理从“静态台账”变为“动态知识库”。

1. 自动发现：让CMDB“活”起来

· 网络层自动发现：通过SNMP、LLDP、CDP等协议，自动发现网络设备及其连接关系，建立物理拓扑。

· 应用层依赖发现：通过分析服务器上的进程、端口，自动发现应用之间的调用关系。

· 与监控联动：监控平台纳管的设备自动同步到CMDB，无需手工录入。

2. CI类型与关系建模

监控易支持自定义CI类型（配置项），如服务器、网络设备、数据库、中间件、应用服务、业务系统、机房、机柜等。CI类型支持五级层级，下级自动继承上级属性。

关系类型包括：

· 包含：机房包含机柜，机柜包含设备

· 运行在：应用运行在服务器上

· 连接：交换机连接服务器

· 依赖：应用依赖数据库

用户可通过可视化界面手动添加或批量导入关系，也支持基于规则自动生成。

3. 业务拓扑：从技术视角到业务视角

CMDB的核心价值在于将技术资源组织成业务视图。在监控易中，用户可以：

· 创建业务系统（如“网上办事大厅”）

· 将该业务依赖的服务器、数据库、网络设备、中间件等CI关联到该业务

· 系统自动生成业务拓扑图，展示业务与底层资源的依赖关系

· 当某个资源产生告警时，业务拓扑图上对应节点高亮，并显示受影响的业务范围

4. 与告警、工单深度集成

· 告警联动：告警触发时，系统自动从CMDB获取受影响CI的详细信息（责任人、业务归属、历史变更），附在告警内容中。

· 影响分析：当某个CI产生告警时，系统自动分析其关联的上游、下游CI，评估影响范围。

· 变更管控：CI变更时，自动触发审批流程，变更完成后更新CMDB，形成闭环。

四、某省级政务云的CMDB建设

背景：该政务云承载30多个委办局的业务系统，管理服务器500余台、网络设备100余台、数据库80余个、应用服务200余个。

面临的挑战：

· 资产台账分散在多个Excel中，信息不一致，查询困难

· 不清楚各业务系统与底层资源的依赖关系，故障影响范围评估耗时

· 等保2.0要求对核心资产进行管理，审计时无法提供完整的关系图谱

解决方案：

· 部署监控易CMDB模块，通过自动发现导入现有设备

· 定义CI类型（服务器、网络设备、数据库、应用、业务系统）及关系类型

· 手工关联核心业务系统（如“不动产登记”“企业信用查询”）与底层资源

· 配置告警与CMDB联动：告警时自动显示受影响业务和责任人

· 开启操作审计，记录所有CI变更

实施效果：

· 资产台账从5个Excel合并为1个统一CMDB，信息准确率提升

· 故障影响范围评估时间大幅缩短

· 一次核心数据库CPU告警，系统自动显示影响到的3个业务系统，优先处置，避免了业务中断

· 顺利通过等保2.0测评，审计人员对CMDB的完整性和关系图谱给予认可

评价：“以前问‘这个服务器坏了会影响谁’，要翻半天资料。现在CMDB里一看拓扑图，一目了然。”

五、实施要点与配置建议

1. CMDB建设的分阶段路径

2. CI属性建议

建议为每类CI设置以下核心属性：

· 服务器：IP、操作系统、CPU/内存配置、维保到期日、责任人、所属业务系统

· 数据库：版本、连接串、大小、所属业务系统

· 业务系统：名称、负责人、SLA等级、部署环境

3. 关系维护策略

· 物理连接关系：通过自动发现定期更新

· 应用依赖关系：每年至少review一次，或在重大架构变更后更新

· 业务归属关系：业务系统变更时同步更新

4. 与等保2.0合规的结合

根据GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》第8.1.5.3条的要求，系统“应对分散在各个设备上的审计数据进行收集汇总和集中分析”-。监控易CMDB的操作审计日志可满足这一要求。根据GB/T 22239-2019第8.1.4.3条的要求，“审计记录应保存不少于六个月”-。建议定期导出CI变更报告，作为合规检查的佐证材料。

六、结语

CMDB不是一次性的“建库工程”，而是需要持续“喂养”的动态系统。监控易智能一体化运维平台的CMDB模块，通过自动发现、关系建模、业务拓扑、与告警联动，让配置管理从“静态台账”进化为“活的地图”。当故障发生时，CMDB告诉你“谁在影响谁”；当变更执行时，CMDB告诉你“动了谁会出事”。这，才是配置管理的真正价值。

核心要点总结

1. CMDB解决的是“谁依赖谁、谁影响谁”的关系管理问题

2. 监控易支持自动发现物理连接和应用依赖，但业务归属关系需手工配置

3. 业务拓扑将技术资源组织成业务视图，故障时快速呈现影响范围

4. CMDB与告警、工单联动，自动获取责任人、业务归属和历史变更信息

5. 根据GB/T 22239-2019第8.1.5.3条和第8.1.4.3条要求，CMDB的操作审计可满足等保2.0集中审计和日志留存要求

常见问题

Q1：CMDB的关系需要全部手工录入吗？

A：不需要。监控易支持通过SNMP/LLDP自动发现网络设备间的物理连接关系；通过分析服务器上的进程端口，可部分发现应用依赖关系。但业务层面的归属关系（如“业务系统A依赖数据库B”）需要手工配置，因为涉及业务逻辑，无法完全自动发现。

Q2：CMDB与资产管理模块有什么区别？

A：资产管理侧重资产的全生命周期（采购、入库、维保、报废），关注“有什么资产、资产状态如何”。CMDB侧重配置项之间的关系，关注“谁依赖谁、谁影响谁”。两者可以联动：资产管理中的设备信息可同步到CMDB作为CI，CMDB中的关系也可用于资产评估。

Q3：CMDB的数据如何保持与实际环境一致？

A：监控易支持定期自动同步（如每周一次），从监控平台、自动发现结果中更新CI信息。对于变更频繁的环境，可设置更高的同步频率。对于手工录入的关系，建议建立变更流程，要求架构调整时同步更新CMDB。

适用场景：政务云平台、大型企业IT架构管理、金融机构两地三中心、医疗机构多院区IT资源管理

#审计日志 #操作审计 #等保合规 #日志管理 #监控易智能一体化运维平台

内容责任声明

来源：监控易技术团队原创（北京美信时代科技有限公司）

作者：技术部 刘美玲

编辑：市场部 扬扬

初审：技术部 刘美玲

数据核实：技术部 刘美玲

终审：解决方案部 Dino

本文内容基于公开信创政策及实际项目经验编写，数据来源可追溯。未经授权不得转载。