"我们网络有冗余的，断不了。"
我听过太多次这句话了。
每次听到，我都会问同一个问题："你们的冗余，是真冗余，还是共命运冗余？"
"啥意思，共命运冗余是什么意思？”
我说：”就是两条链路，看起来互相备份，但只要一个地方出问题，两条一起断。”
没吭声。
然后通常是：”呃……好像确实是这样。”
这不是个别现象。在工业现场、IDC机房、园区网络里，我见过太多做了冗余，却在故障时一起倒下的网络。设备买了两套，链路拉了两条，预算花了双倍，结果可用性和没做冗余差不多。
问题出在哪里？出在冗余的设计逻辑上。
一、冗余的本质：消除单点故障
在说那些假冗余之前，先把冗余的本质说清楚。
冗余的目标只有一个：消除单点故障。
所谓单点故障，就是系统里某一个组件一旦失效，整个系统就跟着失效。一个真正有效的冗余设计，必须确保任意单一组件的故障，都不会导致整体业务中断。
注意两个关键词：任意，和单一。
任意——不是某几个关键节点做了备份就够了，是每一个节点都不能是单点。
单一——N+1冗余设计保护的是单点故障，不是多点同时故障。如果要防两个节点同时故障，需要N+2，以此类推。
很多“冗余设计”失败，就是在“任意”这两个字上偷了懒。
二、最常见的假冗余：共用一根光纤
“我们核心交换机做了双机热备，主备两台，一台挂了另一台顶上。”
我问：“两台交换机之间的心跳线，走的是同一根光纤吗？”
“……好像是的。”
“上联到汇聚层的两条链路，是不是从同一个光纤配线架出去的？”
“是。”
“那个配线架在哪里？”
“机房门口。”
好。现在假设有人不小心把机房门口的光纤踩断了。主交换机失联，备交换机没收到心跳，触发切换。但切换之后，备交换机的上联链路也断了，因为走的是同一根光纤。
结果：主备都断，业务全部中断。
这就是物理路径共用导致的假冗余。两台设备，两条链路，但共用同一段物理路径，那段路径就是单点故障。
真正的链路冗余，要求两条路径物理上完全分离：不同光纤，不同线槽，不同进楼路由，理想情况下从不同的运营商接入。
三、第二种假冗余：主备设备共用同一块电源
双机热备做好了，链路也分开走了。但有没有想过：两台设备插的是同一个UPS，甚至同一个PDU插排？
UPS故障，或者那条支路的空气开关跳闸，主备两台设备同时断电。
再往上想：两个UPS是不是接的同一路市电进线？市电进线断了，两个UPS同时没有输入，电池撑一段时间之后，一起耗尽。
电源路径的冗余，要和网络路径的冗余同等对待：
- 设备双电源 → 分别接不同的PDU
- PDU → 分别接不同的UPS
- UPS → 分别接不同的市电进线
- 市电进线 → 最好来自不同的变电所或不同的运营商
任何一层共用，那一层就是单点。
四、第三种假冗余：MSTP/STP把备用链路堵死了
这个坑藏得比较深，很多人不知道自己踩了。
二层网络为了防止广播风暴，必须用生成树协议（STP/RSTP/MSTP）消除环路。生成树的工作原理是：把冗余链路中的一条或几条设置为「阻塞状态」，正常情况下不转发流量。
听起来没问题，主链路断了，阻塞链路激活，流量切过去。
但问题来了：
问题一：收敛时间
传统STP的收敛时间是30~50秒。主链路断掉之后，网络要等将近一分钟才能恢复。对于工业控制系统，这是不可接受的。RSTP改善了很多，收敛时间降到1~2秒，但仍然有切换中断。
如果你的业务对切换时间有严格要求，用ERPS（G.8032）可以把环网恢复时间压到50ms以内。
问题二：VLAN与实例配置错误
MSTP允许把不同VLAN映射到不同的生成树实例，实现负载均衡。但如果配置出错，某个VLAN的流量可能被错误地阻塞，而运维人员看交换机：运行正常，根本不知道某些VLAN的备用路径已经失效。
这种问题在平时发现不了，只有真正故障切换的时候才暴露——而这通常是最糟糕的时间点。
问题三：上联链路和下联链路的STP角色没想清楚
接入层交换机一旦成为根桥，流量路径会变得混乱。很多工程师部署完了没有锁定根桥，等到有台新交换机接入，STP重新选举，流量路径全变了，莫名其妙出现网络抖动。
五、第四种假冗余：双核心交换机，但三层网关只有一个
“我们双核心，VRRP做了网关冗余。”
好，VRRP/HSRP做对了，主网关挂了，备网关顶上，没问题。
但我想问：“你们的路由，是在核心交换机上做，还是在上面还有一台路由器？”
“上面有一台出口路由器。”
“只有一台？”
“……对。”
好，双核心交换机做了冗余，但流量最终都要从那一台出口路由器出去。路由器挂了，双核心形同虚设。
这就是冗余做了一半的问题。你保护了某几个节点，但整条路径上还有单点没被覆盖。
正确的思路是：从终端到业务，把整条路径画出来，逐段检查每一个节点是不是单点。
终端 → 接入交换机 → 汇聚交换机 → 核心交换机 → 出口路由器 → 防火墙 → 运营商链路 → 对端
每一跳都检查：这里挂了，业务还能通吗？
只要有一跳的答案是“不能”，那一跳就是单点故障，冗余就没做完。
六、工业网络里的特殊坑：冗余协议互不兼容
工业现场有个特殊情况：现场设备来自不同厂商，各自支持的冗余协议不一样。
西门子的设备支持MRP（介质冗余协议），ABB的设备支持PRP/HSR，某些老设备只支持STP。你在规划环网冗余的时候，如果没有统一协议，就会出现：
- 西门子段的冗余正常工作
- 但西门子段和ABB段之间的接口，没有冗余协议保护
- 那个接口断了，两段都傻掉
更坏的情况是：不同协议的冗余机制在同一个环里混用，互相干扰，出现比不做冗余更糟糕的结果——比如环路没有被正确消除，直接广播风暴，全网瘫痪。
在工业网络里，冗余协议的统一规划必须在设备选型阶段就确定，不能等到现场才发现兼容性问题。
七、一个更隐蔽的坑：冗余做了，但没有测试过
这是最难被发现，也是危害最大的问题。
很多冗余方案部署完之后，从来没有做过真正的故障切换测试。工程师在文档上写着“主链路断开后，备链路自动接管，业务无感知切换”，但这个结论从来没有被验证过。
直到有一天真的断了，切换没有发生，或者切换了但业务中断了两分钟，这时候才发现：
- 备链路的配置其实是错的，部署完之后改过主链路的配置，但备链路忘了同步
- VRRP的优先级设置让备机永远抢不回主机位
- 防火墙的状态同步没有配，切换后所有TCP会话全部重置
- 某台设备的双网口，其实用的是同一个网络芯片，芯片挂了两个口一起挂
冗余不是部署完就有的，是测试过才有的。
一个冗余设计有没有效，只有两种方式能证明：一是在受控环境下做故障演练，二是真的出了故障并且成功切换。其他任何方式，包括看配置文档、看拓扑图、看指示灯，都只能证明【设备在线】，不能证明【冗余有效】。
八、真冗余的设计检查清单
把上面说的坑整理成一个检查清单，下次做冗余设计或者审查现有方案的时候，逐条过：
物理层
- 两条链路是否走了不同的物理路径（不同管槽、不同进楼路由）？
- 光纤熔接点和配线架是否在不同位置？
- 有没有同一段光缆被两条【不同】链路共用的情况？
电源层
- 设备双电源是否接了不同的PDU？
- 两路PDU是否接了不同的UPS？
- 两路UPS是否来自不同的市电进线？
网络层
- 生成树协议的收敛时间是否满足业务要求？
- 根桥是否被锁定在核心设备上？
- MSTP各实例的VLAN映射是否正确，有没有漏配的VLAN？
三层冗余
- 网关冗余（VRRP/HSRP）的主备切换时间是否测试过？
- 防火墙是否做了状态同步，切换后会话能否保持？
- 出口路由器是否是单点？
整链路检查
- 从终端到业务，整条路径是否逐段检查过单点故障？
- 有没有哪一跳是单台设备、单条链路、单路电源？
测试验证
- 冗余方案部署后是否做过故障切换演练？
- 演练的结论是否有记录，切换时间、业务中断时长是否符合预期？
- 上次演练距今多久？配置有没有发生过变更？
总结
冗余不是买两套设备就完成的事。
真正有效的冗余，要求你把整条业务路径从头到尾画出来，逐段找出每一个单点，逐一消除，最后用真实的故障切换来验证。
缺了任何一个环节——物理路径共用、电源共用、协议配置错误、从没测试过——你得到的不是冗余，是一个更复杂、更贵、更难排查的单点故障。
这也是为什么有经验的网络工程师，不太相信“我们做了冗余”这句话。
他们更愿意问的是：“你们上次断主链路测试备链路切换，是什么时候？”
如果对方答不上来，那答案基本上就已经有了。
