AI 网络故障注入怎么验收：链路、交换机与节点恢复

网络设计中的冗余只有经过故障注入才有交付意义。双上联、双 rail、多个 Spine 或备用管理实例，可能因为路由、绑定、配置或容量不足，在真实故障时没有按预期接管。

故障演练必须有明确边界、停止条件和回滚。生产验收不是随机拔线，而是在可控负载、完整监控和已确认恢复路径下逐项验证。

从故障模型建立测试清单

覆盖单根线缆、单端口、单 Leaf 上联、单 Spine、单 rail、服务器网卡或节点、子网管理或路由邻接。每项说明影响范围与预期业务行为。

共同故障点单独列出，例如双端口共享一张网卡、双上联共享电源或两个管理实例共享主机。

演练前确认保护措施

冻结无关变更，保存配置和基线，确认带外管理、现场人员、备件和回滚命令。向业务方说明可能的性能下降或作业重启。

设置端口错误、路由震荡、作业失败和温度等停止条件。超过条件立即恢复，不为了完成清单扩大影响。

观测控制面与数据面

记录路由或子网管理角色、端口和队列、RDMA、NCCL、业务完成时间、告警与自动化动作。控制面收敛不代表数据面没有长时间丢包或拥塞。

同步记录故障动作、检测、收敛、业务恢复和性能恢复时间。不同时间点反映不同能力。

恢复后检查是否回到原基线

链路或设备恢复后，确认路由、ECMP、端口模式、FEC、错误、PFC/ECN 和作业性能。残留的不对称可能让网络看似正常却更容易热点。

清理临时配置和维护标记，并复测双向和并发流量。恢复完成要有数据证明，不以告警消失为唯一标准。

演练结果反向修正架构

若单故障导致超出预期的带宽损失，检查容量、作业放置和故障域；若检测慢，改进遥测与告警；若恢复依赖个人经验，补充自动化和操作文档。

修正后重复同一故障场景。未复测的整改不能关闭验收问题，演练结论也应绑定当时硬件与软件版本。

按风险从低到高安排场景

先验证单链路和单上联，再进入设备、rail 和管理角色故障。前一层的告警、回滚和证据未通过时，不继续扩大影响范围。

高风险场景使用测试作业或隔离资源池，先验证操作脚本和停止条件。涉及整台 Spine 或管理平面的演练，应确认剩余容量和现场恢复人员。

演练计划记录不执行的场景及原因。暂不注入的故障仍应作为残余风险保留，不能从交付结论中消失。