高速光链路故障排查实战：从DOM光功率到FEC与BER

高速光链路出现吞吐抖动时不建议一开始就更换全部模块和光纤。先固定现场、建立时间线再按物理层到业务层逐级排查才能知道真正的故障点。第一步保存端口和模块快照。记录两端设备、端口、速率、通道分拆、实际FEC、自动协商状态、模块识别信息、序列号、温度与运行时长。交换机侧可使用对应系统的收发器查看命令在支持的NVIDIA Cumulus Linux环境中可通过NVUE查看平台收发器信息也可使用ethtool读取模块诊断数据。第二步核对双向DOM。分别记录A端TX、A端RX、B端TX和B端RX。A端TX应与B端RX形成一组B端TX应与A端RX形成另一组。不能只凭某个数值判断好坏应依据具体模块的告警阈值、链路距离、连接器数量和光纤类型评估。若读数为零还要确认模块是否实现了相应监控字段。第三步检查FEC。确认两端实际启用同一种纠错方式。FEC可纠正错误在高速链路上可能出现关键是增长速度、负载相关性和历史基线不可纠正码字、有效BER异常或CRC增长更值得立即处理。清零计数前先保存原值清零后用固定流量持续观察避免把多年累计值与短时故障混在一起。第四步检查物理连接。关闭或隔离链路后使用合适工具检查并清洁端面核对连接器类型、极性、跳线规格、插入深度和弯曲半径。模块温度过高时还应检查风道、端口密度和环境温度。不要用肉眼直视光纤端面。第五步执行单变量替换。先换已知正常跳线再换模块最后换端口或对端每次只改一项并复用相同的包长、流量方向和持续时间。若错误随模块移动优先定位模块若固定在端口或路径则检查端口、配线架和中间连接。最后做业务回归。单纯的Ping不能覆盖高速并发压力应结合持续带宽、丢包、尾延迟以及RDMA或NCCL测试。将光功率、温度、FEC、BER、CRC和应用指标对齐到同一时间轴才算完成可复现的故障闭环。在自动化巡检中建议保留原始命令输出而不是只保存“正常/异常”结论。脚本可以计算相邻采样点的增量对FEC、CRC与链路重训练建立速率告警同时记录流量计数避免把高负载下的正常增长与空闲状态直接比较。如果链路经过配线架或中间跳接应把每个连接点写入路径记录。直连正常、经过配线架异常时可以缩小到中间连接器、极性或跳纤只有在更换模块后错误随模块移动才有较强证据指向模块本身。