AI 网络运维为什么从端口状态转向遥测与业务基线

AI 训练网络中，端口可以始终保持 Up，业务仍可能因 FEC 错误、ECMP 热点、队列拥塞、PFC 扩散、PCIe 降速或 GPU/NIC 绑定出现性能波动。传统只监控连通与总流量的方法，难以解释作业为什么变慢。

运维因此转向把物理链路、交换遥测、主机、NCCL 和作业放在同一时间线。变化的本质不是采集更多指标，而是建立能用于变更验证和故障回归的端到端基线。

性能故障替代纯连通故障

高速链路具备纠错和多路径，轻度物理问题或单路径热点不一定立即断链，却会增加延迟与重传。应用首先表现为尾部节点或训练步时波动。

需要同时观察 FEC、BER、队列、ECN/PFC、路由和每节点业务，不把所有低利用归因于应用。

拓扑成为指标解释上下文

同一端口利用率在 Leaf 下行、Spine 上联或分拆主端代表的意义不同。资产、端口表、rail、GPU/NIC 和作业放置必须与指标关联。

设备换槽、换线或扩容后，拓扑身份同步更新，否则历史趋势会连接到错误对象。

变更前后需要自动对比

网络操作系统、固件、PFC/ECN、路由、线缆和服务器配置变化，都可能改变业务。变更前保存基线，变更后复用同一负载和查询验证。

只确认配置下发成功不能证明结果正确。遥测与业务基线应成为发布门禁的一部分。

工具需要跨团队共同定义

NetQ 或其他遥测平台由网络团队维护，但 GPU、NCCL、调度和存储指标来自其他团队。告警与工单应能跨域关联，而不是各看一套大屏。

共同约定时间同步、资产身份、保留周期和共享查询。没有这些基础，跨团队复盘仍会依赖截图。

落地从少量可行动指标开始

优先覆盖端口错误、拥塞、路由、拓扑变化、关键作业和最近配置，确保每个告警有负责人和操作路径。随后根据真实故障补充数据。

评价可观测性的指标是检测、定位和恢复时间，以及变更能否提前发现回归。采集量、仪表盘数量和保存时长不是独立目标。

先保证时间与资产数据可信

跨设备、主机和作业关联之前，要统一时间同步、设备身份、端口命名和采样周期。时钟偏差或资产映射滞后，会让同一故障看起来像多个不相关事件，甚至把告警归到已更换的链路。

还应监控采集系统自身的缺失、延迟和字段变化。仪表盘没有异常不一定代表网络正常，也可能是数据没有到达；对关键指标设置完整性检查，才能把遥测作为变更门禁和事故证据。