公司刚上线的新系统，说是双链路热备，结果一次光缆被挖断，整个服务直接瘫了。老板问为什么冗余没起作用，运维小李一脸懵：明明配置了啊。这种情况在实际项目里并不少见，表面上做了冗余，关键时刻却掉链子。
设备冗余≠路径冗余
很多人以为上了两台核心交换机就是冗余，其实不然。见过一个案例，两台交换机接在同一根电源线上，UPS一坏，双双宕机。还有更典型的——两条光纤走同一条管道，施工队一铲子下去，主备全断。真正的冗余得把物理路径也分开，比如不同方向的路由、不同的供电回路，否则就是“伪冗余”。
协议配置出错，切换不生效
用VRRP或HSRP做网关冗余，但两边优先级配反了，或者心跳线断了没告警，主设备挂了，备用的压根不知道该接管。现场查日志才发现，备用设备一直以为自己是备胎，实际上主早就没呼吸了。这种问题在跨厂商设备对接时尤其常见，参数默认值不一样，文档又没对齐。
<vrrp vrid 1 priority 100> <!-- 主设备应设高优先级 -->
<vrrp vrid 1 priority 90> <!-- 备用设备优先级要低 -->单点依赖没发现
冗余做了三层，结果DNS解析靠一个外部服务商，那家一出问题，你的内网再稳也没用。或者认证系统只有一套LDAP，用户登录全卡住。这些看似“外围”的组件，往往成了隐形单点故障源。
测试走过场，故障模拟不真实
很多单位所谓的“冗余测试”，就是远程重启下备用设备看能不能起来。真故障可不是这样发生的。应该模拟链路中断、设备宕机、甚至机房断电，看业务是否自动迁移。有家公司测试时只拔了一根网线，没关端口，生成树协议根本没触发，误以为一切正常，结果真实故障时环路了。
人员意识跟不上
运维团队对冗余机制理解不到位，日常巡检忽略关键指标。比如BGP邻居状态长期Down，没人处理；或者备份线路长期闲置，接口老化也不知。人是系统的一部分，再好的设计，没人维护也白搭。
网络冗余不是买几台设备往上一搭就完事的事。它是个系统工程，从规划、实施到维护，每个环节都可能埋雷。别等到服务真断了才去翻配置。