自动梳理关系

为什么必须自动

多数企业的资产台账还停留在Excel阶段，几个人花几周时间盘点一次，结果上线一个月就过时了。更关键的是，台账上只有"有什么"，没有"什么依赖什么"——某台交换机挂了，影响哪个业务？某台虚拟机迁移了，上面跑的应用还认不认得？这些关系信息靠人工根本维护不过来。

自动梳理关系的核心思路是：让系统自己去发现、自己去关联、自己去更新。六类发现引擎各司其职，从最底层的网段扫描到最上层的应用调用关系，逐层构建出一张完整的IT资源关系网。

一、网段发现引擎

这是最基础的一层。不需要人工告知系统"内网有哪些网段"，引擎会自动发现内网中正在使用的网段，以及每个网段中当前激活的IP地址。连"有哪些网段"这件事本身都是自动的——这比传统工具要求管理员先手动配置扫描范围要彻底得多。

• 自动识别内网中正在使用的网段，无需人工预设扫描范围
• 在每个已发现网段中，进一步识别当前激活的IP地址，明确"谁在线"
• 发现新网段或新激活IP时，自动触发后续引擎深入探测，形成"发现-识别-入库"的自动化链路
• 对消失的IP标记告警，提示管理员确认是正常下线还是异常离线

二、网络设备发现引擎

在网段发现的基础上，引擎进一步识别哪些IP是网络设备（交换机、路由器、防火墙等），并采集其型号、厂商、端口配置、运行状态等信息。

• 通过标准管理协议自动读取设备信息，兼容主流网络设备厂商
• 采集端口状态、VLAN配置、路由表等关键运行数据，不仅知道"有什么设备"，还知道"设备怎么连的"
• 自动识别设备角色（核心交换、接入交换、边界路由等），为拓扑发现提供输入
• 设备信息变更时自动更新CMDB记录，无需人工干预

三、拓扑自动发现引擎

知道了有哪些网络设备，下一步是搞清楚它们之间是怎么连的。拓扑自动发现引擎基于设备的端口互联信息，自动推导出网络的物理连接拓扑。

• 利用设备间的邻居发现协议信息，自动建立端口级的物理连接关系
• 逐层推导核心-汇聚-接入的网络层次结构，生成可视化拓扑图
• 当网络结构调整（如新增交换机、改线）后，拓扑图自动更新
• 拓扑数据是故障影响分析的基础——某条链路断了，能立刻知道哪些设备会受影响

四、虚拟化自动发现引擎

现代IT环境中大量使用虚拟化，一台物理机上跑着几十台虚拟机，虚拟机还会动态迁移。如果只发现物理机而不发现虚拟机，CMDB的数据就是不完整的。

• 对接主流虚拟化平台，自动获取宿主机与虚拟机的对应关系
• 采集虚拟机的资源配置、运行状态、所属集群等信息
• 跟踪虚拟机迁移事件，当虚拟机从一台宿主机迁移到另一台时，自动更新关联关系
• 将虚拟机与宿主机的层级关系纳入CMDB，确保"物理-虚拟"两层资源都可见可控

五、应用发现引擎

前面四层解决的是基础设施的发现问题。但企业真正关心的是业务系统，而业务系统最终落地为服务器上运行的进程和应用。应用发现引擎通过识别服务器上的进程信息，自动判断上面运行的是什么应用。

• 通过操作系统进程信息识别数据库、中间件、Web服务等应用组件
• 自动匹配已知应用特征库，将进程信息翻译成业务可理解的应用名称
• 建立"应用-服务器-虚拟机-宿主机"的纵向关联链路
• 当应用部署位置变更时，关联关系自动跟随更新

六、调用关系自动发现引擎

这是最高层也是最有价值的一类发现。知道了应用部署在哪里，还需要知道应用之间谁调用谁——这才是真正的业务逻辑关系。调用关系发现引擎通过网络层面的连接信息，自动识别应用之间的调用关系。

• 通过分析服务器间的连接信息，自动识别应用系统的调用链路
• 构建"应用A调用应用B、应用B依赖数据库C"的横向逻辑关系图谱
• 当某应用出现故障时，通过调用关系快速定位上下游受影响的应用系统
• 调用关系数据为变更影响评估、故障根因分析、业务健康度分析提供核心支撑

六层发现的整体价值

六类发现引擎不是孤立工作的，而是逐层递进、相互校验的完整体系。从"网段里有哪些设备"到"设备怎么连的"到"上面跑什么应用"到"应用之间怎么调用"，每层的输出是下一层的输入，最终在CMDB中构建出一张从物理到逻辑、从基础设施到业务系统的全景关系图。

• 数据可信：自动发现替代人工录入，数据准确性不再依赖个人责任心
• 持续校准：引擎周期运行，数据始终反映最新状态，不存在"台账过时"问题
• 关系可溯：故障发生时，沿关系图谱快速定位影响范围和根因设备
• 变更可控：变更前预判影响哪些业务系统，避免"改了一个配置挂了一片应用"