公司刚上线的新业务系统，说好双机热备、链路冗余，结果一次核心交换机故障，整个服务直接瘫痪两小时。运维同事一脸懵：不是做了冗余吗？怎么一点用没有？其实，这种情况并不少见，很多所谓的“冗余设计”只是表面上看着靠谱，真到关键时刻就掉链子。
单点故障没真正消除
很多人以为加了一台备用设备就是冗余，但忽略了控制层面的依赖。比如两台路由器做了VRRP，看似虚拟IP能切换，但如果它们共用同一台上游交换机，而这台交换机坏了，备份路由也上不去。就像家里装了两个热水器，结果都接在同一个电闸上，跳闸照样没热水。
冗余路径未隔离物理资源
有家公司光纤走冗余设计，主备两条线路，结果两条光缆居然绑在同一根电线杆上。施工队挖断杆子，主备全断。真正的冗余得考虑物理路径分离，比如一条走东边马路，一条走西边小区，避免共因失效。这跟买鸡蛋不能放在一个篮子里是一个道理。
配置不同步导致切换失败
一台防火墙配置更新了规则，另一台忘了同步。故障切换后，新连接全部被拦截，业务打不开。别小看这种低级错误，日常变更频繁时最容易遗漏。可以设置自动化校验脚本定期比对：
<script>
# 比较两台设备ACL配置差异
compare_config(device_a, device_b, section="acl")
if diff_found:
send_alert("配置不一致警告")
</script>测试流于形式
有些团队每年做一次“冗余演练”，但只是在后台敲个命令看状态变绿，从没真正断过主设备。真实故障往往伴随异常流量、ARP混乱、会话中断等问题，模拟太理想化根本发现不了隐患。应该定期搞突袭式断电测试，比如随机拔掉主交换机电源，看看备机能撑多久。
监控覆盖不到切换过程
冗余系统切换时，监控只盯着设备是否在线，却不关心业务连通性。曾经有个案例，主数据库宕机后，备用节点成功接管VIP，但应用连接池没释放旧连接，新请求还是发往死机那端。监控显示“一切正常”，用户却完全无法登录。监控得深入到应用层，比如定时发起真实登录请求验证可用性。
过度依赖厂商宣传
买设备时销售说“支持毫秒级切换”“99.999%可用”，结果实际部署中发现STP收敛要30秒，BFD检测阈值设得太保守，故障感知延迟严重。别信参数表上的数字，自己压测才是硬道理。把关键链路跑满流量再模拟断线，看看业务抖动能不能接受。
冗余不是贴膏药，不是出了问题才补一下。它是一套完整的运行机制，涉及设计、部署、维护和验证全过程。做得不到位，反而让人产生虚假安全感，等真出事才发现，原来“备份”一直就没活过。