从VRRP到BFD：双核心网络高可用设计与故障切换实战

先讲一个我实际遇到过的场景。某个业务高峰日上午，园区网核心交换机的一块业务板卡突然报错重启，主备两台核心之间明明配置了VRRP，可整个办公区还是断了将近十分钟网。后来查下来，问题出在上行链路检测上面：出口防火墙到核心之间的链路是正常的，可业务板卡所在的某个接口已经起不来了，VRRP主设备没有感知到，流量照样往故障路径上送，备机又一直处于空闲状态，结果谁也没接管。

那次故障之后，我把“可靠性技术”这几个字重新盘了一遍。需求方嘴上说的是“高可用”，但真正决定可用性的不是设备品牌，不是冗余协议本身，而是“故障发生时系统能不能快速感知、快速切换、快速恢复”，以及这些机制在日常运维里能不能长期保持有效。这篇内容我准备从真实落地角度来拆解可靠性技术，把它从概念变成能落地的一整套方法，适合正在做网络方案设计、准备高级运维考试，或者打算优化现有核心网络稳定性的朋友参考。

1. 可靠性设计：先搞清楚到底要防什么

1.1 网络可用性的本质是压缩故障影响时间

很多人一提到可靠性，第一反应就是“加设备、做冗余”，似乎核心交换机买两台，链路拉两条，可靠性就解决了。但我更倾向于先回答一个更本质的问题：你的网络到底允许中断多久？

衡量可靠性的硬指标通常写作可用性（Availability），公式并不复杂：可用性 = MTBF / (MTBF + MTTR)。MTBF是平均无故障运行时间，MTTR是平均恢复时间。要提升可用性，无非两条路：要么延长MTBF，让设备少出问题；要么压缩MTTR，让出了问题能快速恢复。可靠性技术解决的核心问题，其实是第二件事——当故障发生时，如何让网络自动完成感知、切换和收敛，把终端和业务感知到的中断时间压缩到可接受范围内。

这个思路决定了整个方案的走向。单台设备再稳定，也存在升级、重启、板卡故障这类必须要中断的场景。可靠性技术要做的不是“保证不出事”，而是“出了事也不至于全盘瘫痪”。所以设计核心网可靠性的时候，我习惯先问业务方：RTO（恢复时间目标）是多少？30秒、10秒、还是0丢包？这个问题不明确，后面选什么冗余机制、配多少探测间隔、要不要做双活，其实都缺乏依据。

1.2 可靠性不是堆设备，是消除单点故障

网络里最常见的隐患就是单点故障。一台汇聚交换机下面挂了几十台接入交换机，这台汇聚如果发生硬件故障，影响的可能就是整片业务区；一台防火墙的某个接口光模块老化，流量走这个接口就会间歇性丢包。冗余的核心思路，就是给网络里每一个可能发生单点故障的位置都留下“备用通道”和“备用角色”。

但冗余技术本身也会引入新问题。两台设备同时承担同一个网关地址，如果协调不好就会产生地址冲突；两条链路都往同一个交换机转发数据，如果环路控制没做好，广播风暴比断网更可怕。做可靠性设计最忌讳的是只盯着“有没有冗余”，而忽略了“冗余后的协商、切换、防环机制是否严密”。举个最简单的例子，一台交换机同时连到两台核心，如果不启用STP相关的保护机制，双上行链路反而会把网络打成环路。

所以我的看法是，可靠性技术是一套组合技术，而不是单个协议。典型的核心网可靠性方案通常包含三层能力：设备级可靠性（硬件冗余、板卡热插拔）、网络级可靠性（链路聚合、VRRP、堆叠）、链路感知与快速切换（BFD、接口监测）。这三层缺一不可，少了任意一环，表面上看起来“都是双份配置”，实际故障发生时却很难真正实现快速切换。

1.3 我见过最容易翻车的三类不靠谱设计

做网络久了，你会发现真正出大故障的往往不是“没有冗余”的方案，而是“看似有冗余、实则冗余失效”的方案。这类方案大体有三类特征：

第一类是备机长期不做验证。VRRP备机配置好了，但从来没有把业务流量切过去试过。等到主设备真发生故障时，备机的配置可能早就和主设备不一致了，路由表不全、网关接口状态异常、与上层网络断连，切换过去之后业务起不来，甚至比主设备故障影响更大。

第二类是检测链路只看接口状态。接口的物理状态是Up，不代表转发路径是通的。Real场景中，光模块老化、中间传输设备故障、单纤收发异常，都可能导致接口Up但实际链路已经无法正常转发业务流量。若VRRP或路由协议只按照接口Switch状态来决策主备切换，这种“半死不活”的故障根本无法触发切换，只能等到用户投诉后才被动处理。

第三类是切换设计只考虑核心，不考虑上下游。主备核心切换成功了，但上联防火墙、下联接入交换机、终端网关ARP表项没有同步收敛，流量仍然可能走旧的路径。可靠性是个全链路的事，必须在所有层面统一设计、统一验证，而不是只盯着一两台核心设备。

2. 核心可靠性技术选型：该用冗余的时候就别含糊

2.1 链路聚合：把多条物理链路变成一条逻辑链路

链路聚合可以说是性价比最高的可靠性手段。它把多条物理链路捆绑成一个逻辑端口，既能提升带宽，又能实现链路冗余。当其中一条物理链路故障时，流量自动在剩余链路上重新分布，对业务基本无感知。

链路聚合有两种模式需要区分。一种是手工静态聚合，只要把端口加入聚合组并启用，链路就会聚合，简单粗暴，但双方配置不一致时可能形成环路或转发异常，一般不建议用在核心环境。另一种是LACP动态聚合，两端通过LACPDU协议报文协商，能够自动识别对端状态，链路状态异常时自动剔除故障成员口，这才是生产环境的主流选择。配置时还会涉及负载分担方式，根据源目MAC、源目IP、或者更细的四层端口信息做哈希转发，需要根据实际业务流量特征来选。

核心到核心之间、核心到汇聚之间的链路聚合，基本已经成为标准配置了。配置链路聚合还有一个额外好处：万一其中一条成员链路需要更换光模块或者做链路扩容，可以先把流量切换到其他成员上，然后对故障链路进行维护，业务无感知。

2.2 VRRP：给终端一个不会消失的网关

VRRP解决的是网关冗余问题。终端设备通常只配置一个默认网关，如果这台三层设备故障了，需要另一台设备无缝接替IP地址并继续转发流量。VRRP的核心是把多个路由器（或三层交换机）编成一个虚拟路由器组，对外共享一个虚拟IP地址，同时只有一台设备处于Master状态负责转发，其他设备处于Backup状态实时监视Master的状态。

VRRP要理解的关键点有几个。一个是优先级机制，优先级高的设备会成为Master，默认优先级是100，可以通过priority命令调整。另一个是抢占行为，如果一台更高优先级的设备恢复了，它会重新抢占Master角色。在真实环境中，不建议把抢占完全关闭，否则恢复后的设备不会重新接回流量，备机反而一直处于转发状态，和设计初衷不符。更合理的做法是把抢占打开，但是配合一定的主备切换延迟时间，避免因为链路抖动、协议震荡导致频繁切换，影响业务稳定性。

VRRP本身只能检测虚拟路由器内部成员之间的连通性，无法感知上行链路或出口链路的故障。所以生产环境里很少单独使用VRRP，通常会结合“接口跟踪 + BFD联动”。也就是说，当Master设备的上行接口出现异常或整条上行链路中断时，自动降低Master的优先级，让Backup设备升为主设备，避免出现“网关活着，但出口已经断了”的尴尬局面。

2.3 堆叠与集群：把多台设备变成一台逻辑设备

除了VRRP这种“两台设备、一个虚拟IP、主备干活”的方案，还有另一类实现高可用的路径——堆叠或集群。华为叫iStack/Cluster，H3C叫IRF，思科叫StackWise，本质上都是把多台物理设备虚拟成一台逻辑设备来管理。对于横向扩展和简化管理来说，这个方案的优势很明显，配置统一、协议统一、只需要一个管理IP。

堆叠的可靠性原理在于成员设备间通过专用堆叠口互联，控制平面和数据平面协同工作。一台成员设备故障后，另一台接管全部转发任务。比如两台核心交换机做堆叠，对外就是一台设备，上联、下联的链路甚至可以做跨设备的链路聚合，彻底解决VRRP模式下备机利用率低的问题。

但堆叠方案也有自己的“命门”。堆叠系统最怕的就是脑裂，即堆叠链路中断后，两台设备无法感知对方状态，各自认为自己还是整个堆叠系统的主设备，带着同样的配置同时对外提供服务，这会造成IP地址冲突、MAC漂移、路由环路。解决脑裂问题通常依赖堆叠口监测、双主检测机制（比如通过专用链路互相发送心跳报文），以及聚合链路中的MAD（Multi-Active Detection）机制。堆叠适合对管理简化要求高、链路冗余需求强的场景，但它维护起来远比VRRP复杂，技术上需要积累更多经验。

用表格对比一下两种常见的核心高可用模式，可以根据业务诉求来选：

从我个人的经验来说，小型园区核心、门禁/安防网络、临时性的重点保障网络，用VRRP会更稳妥；而机房规模较大、链路数量多、追求简化管理的场景，可以考虑堆叠方案。选择哪条路线，取决于团队运维能力，而不是技术先进程度。

2.4 BFD：毫秒级感知链路故障，就靠它了

很多网络工程师对BFD（Bidirectional Forwarding Detection，双向转发检测）的理解停留在“一种快速检测协议”的层面，但BFD在生产环境中的地位远比想象中重要。它的核心价值在于：以极低的开销、极快的速度，为VRRP、OSPF、BGP等控制协议提供底层链路状态感知能力。

在没有BFD的时代，VRRP检测链路故障通常依赖接口状态或定时器超时。接口检测只能发现本端接口Down，如果是对端设备断电或者光路中断，本端接口可能仍然是Up状态。VRRP自身的Master_Down定时器默认可能需要几秒甚至十几秒才能确认Master失效。放在业务永续的场景里，这个中断时间很难接受。BFD把检测间隔压缩到了毫秒级，它通过周期性发送检测报文，连续几个周期没有收到对端回应就宣告会话Down，并立即把Down事件通知给上层协议，触发快速切换。

BFD的使用有几个工程上的原则需要注意。检测间隔并不是越小越好。普通以太网环境存在一定抖动，如果BFD报文发送间隔太短、检测倍数太低，可能因为偶发拥塞就把正常链路误判为故障，导致VRRP频繁切换、路由震荡。生产环境通常建议先设置一个相对保守的间隔，比如发送间隔100毫秒、检测倍数3，然后根据链路质量逐步优化。只有确实承载了高价值业务、链路质量又非常稳定的专线环境，才建议把间隔调得更低。我在实际项目中观察过，不少“无端切换”的故障，查到最后都是BFD参数设得太激进，链路一有微突发就触发切换。

3. 从零落地一套双核心可靠性方案

3.1 拓扑规划与需求盘点

再多的理论，最终都要落到一套可执行的方案上。我这里用一个典型的园区核心场景作为示例：两台核心交换机（Core-A和Core-B）负责全网三层转发，下联接入交换机，上联出口防火墙和互联网边界，核心之间通过Eth-Trunk互联，终端网关统一放在核心交换机上。目标很简单：任意一台核心设备故障、任意一条核心互联链路故障、任意一条上联或下联关键链路故障，业务中断时间控制在10秒以内。

第一步是确认需求，不能省。你要明确这台网络承载的是什么级别的业务。内部办公网络对中断的容忍度相对高，几十秒可能还能接受；但如果是医院挂号系统、工厂产线控制网络或者数据中心接入层，中断时间要求可能有明确红线。建议在方案设计前先做一个简单的可用性需求表，把业务类型、允许中断时间、主要流量方向、有无视频会议/语音等时延敏感业务逐项理清，再据此确定技术路线。

第二步是整理现网接口和VLAN规划。核心交换机上通常会划分业务VLAN、管理VLAN、互联VLAN，每类VLAN需要规划网关地址、VRRP虚拟IP、Master优先级等参数。我建议做成一张参数表，至少包含：VLAN ID、网段、网关地址、VRRP虚拟IP、主设备、备设备。配置阶段照着这张表填参数，能避免反复改配置导致的漏配和误配。

3.2 核心设备基础配置与Eth-Trunk部署

核心设备的基础配置包括设备命名、管理VLAN、接口模式、生成树、链路聚合几件事。这里以华为VRP命令风格为例，H3C、锐捷、其他厂商的概念大同小异，命令略有差异。

两台核心之间的互联链路，我推荐启用Eth-Trunk，把两条或四条物理链路捆成一个逻辑口，跑Trunk模式放行业务VLAN。配置思路是这样的：

bash复制# Core-A上配置
interface Eth-Trunk1
 port link-type trunk
 port trunk allow-pass vlan 10 20 30 100
#
interface GigabitEthernet0/0/1
 eth-trunk 1
#
interface GigabitEthernet0/0/2
 eth-trunk 1

对应地，Core-B上也做同样的Eth-Trunk配置，成员口和放行的VLAN保持一致。这里有一个关键经验：聚合链路对两端的物理端口数量、速率、双工模式要求匹配，至少保证成员口数量一致。比如Core-A捆绑了两个口，Core-B只捆绑了一个口，链路聚合虽然能协商成功，但带宽只有单条，且无法提供口级冗余，可靠性是打折扣的。

Eth-Trunk配置完成后，可以用display eth-trunk 1命令查看成员链路状态。确认所有成员口都处于Selected状态，才算聚合成型。如果某个成员口始终处于Unselected状态，常见原因是两端光模块协商失败、对端口没有加入聚合组、两端接口速率不一致。需要特别注意的是，不要把成员口和对端直接互连的口配置成不同的接口类型，比如一边是Trunk另一边是Access，聚合后VLAN Tag行为会不一致，可能导致跨VLAN通信故障。

接下来是生成树配置。在主备核心加双上联的场景下，冗余链路和环路往往同时存在。建议在下联到接入交换机的端口上启用生成树，同时把根桥明确指定到两台核心，避免接入交换机竞选成根桥。核心侧推荐启用STP的快速收敛机制，并对面向终端的端口配置边缘端口，配合BPDU保护，防止终端误接交换设备导致生成树拓扑频繁变化。

3.3 VRRP配置与优先级调整

设备基础通信和Eth-Trunk就绪之后，才能规划VRRP。以一个业务VLAN10为例，网关规划在192.168.10.0/24，虚拟网关地址是192.168.10.1。正常的做法是让Core-A作为VLAN10的主设备，Core-B作为VLAN20的主设备，这样两台核心都能承载转发任务，避免一台设备空转。

Core-A上的配置大致是：

bash复制interface Vlanif10
 ip address 192.168.10.2 255.255.255.0
 vrrp vrid 10 virtual-ip 192.168.10.1
 vrrp vrid 10 priority 120
 vrrp vrid 10 preempt-mode timer delay 20
 vrrp vrid 10 track interface GigabitEthernet0/0/24 reduced 40

这里的逻辑要拆开讲。priority 120让Core-A在VLAN10的VRRP组里优先成为Master；preempt-mode timer delay 20表示允许抢占，但如果Core-A从故障中恢复，需要等待20秒再重新抢回Master角色。这个延迟非常关键，如果不加延迟，Core-A恢复后会立刻抢占，流量在Core-A和Core-B之间来回切换，可能导致ARP表、MAC表反复刷新，业务出现一大段时间的丢包和时延抖动。

最后一行是接口跟踪，把上联口GigabitEthernet0/0/24纳入VRRP决策范围。当这个口Down掉时，Core-A的VRRP优先级自动降低40，从120降到80，低于Core-B的默认优先级100，于是Core-B会切换成Master，承担VLAN10的网关转发。这种设计让VRRP不再只是“设备自身级故障”的冗余，而是上升到“关键链路级”的冗余。

Core-B上则做镜像配置，但角色反过来。VLAN10的优先级保持默认100，VLAN20的优先级调成120。

3.4 BFD与VRRP联动

VRRP结合接口跟踪，只能感知到本端接口的物理Down。如果上联防火墙整机故障，但对端接口通过传输设备互连、本端接口依然Up，或者中间光路中断但本端接口没有Down，接口跟踪就失效了。这时候需要BFD来弥补盲区。

把BFD与会话联动，核心思路是对上行关键链路建立BFD会话，当BFD检测到故障时，通过nqa或bfd触发VRRP优先级降低，实现快速切换。华为设备上的命令大致如下：

bash复制bfd
#
bfd Vlanif10-to-FW bind peer-ip 192.168.10.254 interface Vlanif10
 discriminator local 10
 discriminator remote 20
 min-tx-interval 100
 min-rx-interval 100
 detect-multiplier 3

实际BFD会话的detect time可以通过“本端发送间隔、对端接收间隔、检测倍数”综合计算，一般可达300毫秒级别。也就是说，上行链路出现故障后，最多几百毫秒BFD就能感知到，并通知VRRP完成主备切换，业务中断时间从原来的秒级压缩到亚秒级。

配置BFD要关注两端会话参数是否一致。BFD会话需要协商local discriminator和remote discriminator，对端的remote discriminator要填本端的local discriminator，镜像配置，否则会话建立不起来。检查时可以用display bfd session all查看会话状态是否为Up。如果会话一直Down，先检查两端互联地址能否互通、BFD版本和参数是否兼容、中间是否有防火墙拦截UDP 3784等特定端口报文。很多BFD建立不成功的问题，最后都出在中间安全设备过滤了BFD控制报文上。

3.5 切换实测：验证方案到底可不可靠

配置全部完成，事情只做了一半。另一半是实测验证。我每次做完可靠性相关配置，第一件事就是挑一个业务低峰窗口，把主设备的上行链路直接shutdown，记录业务中断时长和VRRP状态变化。

测试方法很直接：找一台测试终端接入业务VLAN，持续ping网关或内网服务器地址，然后模拟以下故障场景：

1. 拔掉Core-A的上行链路（触发接口跟踪/优先级变化）。
2. 直接重启Core-A（触发VRRP备机接管）。
3. 拔掉Eth-Trunk中的一条成员链路（触发链路聚合重分布）。
4. 关闭Core-A的Vlanif10接口（触发VRRP整体切换）。

每模拟一个故障，观察三层网关是否在预期时间内迁移到Core-B，终端ping丢包数量是否在可接受范围内，测试业务是否恢复正常。执行完故障恢复操作后，还要观察主设备重新启动或链路恢复后，是否按预期延迟抢占并回切，回切过程中是否有明显丢包。

实测结果一定要记录成表格，方便和后续版本做对比。比如我上一次优化前的切换中丢包在几十个左右，优化后压到了个位数，这个结果就是“可靠性提升了”的最直接证据。如果测试结果不达标，不要急着改配置，先分析是故障感知慢、VRRP切换慢，还是下层生成树收敛慢，逐层定位后再调整对应参数。

4. 可靠性落地中的坑与实战排查

4.1 生成树把切机时间拖到十几秒

可靠性方案做完了，也配置了VRRP，但首次切换演练时发现：核心设备故障后，业务中断时间远超预期。查下来发现瓶颈在生成树收敛，而不是VRRP本身。

原因在于接入交换机双归到两台核心，但接入侧没有启用RSTP/MSTP的快速收敛机制，或者边缘端口没有配好，一旦主核心故障导致链路拓扑变化，生成树需要重新计算，广播帧和未知单播帧在收敛完成前无法正常转发。VRRP本身切换很快，但底层的二层路径没有Ready，数据照样走不通。解决思路是对接入交换机启用快速生成树，将连接终端的端口设置为边缘端口并启用BPDU保护，同时把核心互联链路明确指定为生成树的主干路径。这类问题多发生在“只调了三层协议、但二层防环机制没有同步升级”的方案里。

4.2 VRRP主备切换后流量“绕路”了

还有一个高发问题：VRRP Master切到备机后，终端网关通了，但对公网或跨网段的访问仍然异常。定位后发现问题在于上联/下联路由协议的收敛没有和VRRP联动到位。举例来说，核心A是Master时，去往出口默认路由的下一跳是防火墙A，去往核心A的路径正常。核心切换到B后，如果B设备上没有配置等价路由、策略路由或对应路由优先级，业务流量到B之后不知道该往哪送，报文被丢弃。

解决问题的关键是在方案设计阶段就把“主备切换后的路由路径”画出来。哪台设备承担Master时走哪条出口路径，切换后路由表是否会自动更新，策略路由的下一跳是否和VRRP状态联动，这些都需要逐一验证。现在很多方案会引入路由跟踪、策略路由或者等价多路径，让VRRP状态和路由优先级强关联，避免出现网关通了但出口不通的尴尬。

4.3 链路聚合一端Selected另一端口状态异常

Eth-Trunk成员口状态不一致是实操中常见的坑。表面看聚合组已经建立，两台设备也能通信，但始终只有一条链路承载业务，其余成员口处于Unselected或Down状态。排查命令往往能看到类似的日志：某个成员口和对端发生了LACP协商超时，对端没有回应报文。

常见原因有三类。一是两端成员口数量不匹配，导致协商无法完成。二是光模块或光纤故障属于“半物理故障”状态:一端能收到光信号但不能正常协商，LACP报文周期性丢失。三是对端设备根本没有把对应接口加入Eth-Trunk，却把光口连过来了。排查手段从物理层做起，先用display interface检查光模块收发光功率、端口误码率，再检查LACP状态，最后对照两端配置逐项核对。该清洁光纤的清洁光纤，该更换光模块的更换光模块，大部分问题都能定位出来。

4.4 BFD误切换 vs 漏切换，参数怎么权衡

BFD引发的故障往往更隐蔽。要么是BFD建不起来，导致该切换的时候不切换；要么是参数太激进，链路稍微抖动一下，BFD就判定故障，触发VRRP切换，造成本来不该发生的流量中断。

判断BFD参数是否合理，需要参考链路承载介质和现网抖动指标。普通双绞线、光模块直连的链路相对稳定，可以把间隔设置得小一些；经过第三方传输网络、无线回传链路的路径，时延和抖动变化大，就应该适当放宽BFD的检测参数。我也见过将BFD min-tx-interval设为10ms、检测倍数设为2的配置，在实验室表现挺好，放到实际传输链路上后频繁误报。生产环境的可靠性，不是越快越好，而是越准越好。建议上线前先对关键链路做一段时间的质量监控，掌握时延和丢包基线，再决定BFD参数。用一套参数套到所有链路上，迟早会出问题。

4.5 可靠性也需要日常巡检配合

配置层面的可靠性可以瞬间完成切换，但设备硬件和光模块的健康状态是会逐渐劣化的。光模块的收光功率逐渐下降、设备电源模块故障、板卡温度过高，这些都需要依赖日常监控和巡检来发现。

推荐建立“网络可靠性巡检清单”，至少包含以下项目：

• 双核心设备CPU、内存使用率趋势，是否有异常增长。
• 关键链路光模块收发光功率是否在正常阈值内，如果接近临界值，提前更换。
• VRRP状态是否和设计一致，各业务VLAN的主备角色是否匹配规划。
• Eth-Trunk成员口状态是否全部可用，LACP协商是否正常。
• 设备日志中是否有端口翻动、STP异常、BFD会话震荡等告警。
• 配置文件是否定期备份，是否和当前运行配置一致。

这些巡检项如果手工逐台执行，效率太低。建议用脚本批量执行，通过SSH登录设备采集信息，把VRRP状态、端口状态、光模块功率、日志关键字段统一汇总到一个表格里，再和上一次的结果做diff比对。大多数厂商网管平台也有类似能力，可以根据实际预算来选型。

另外，配置备份这件事我见过太多团队忽略，直到核心设备故障重启才发现配置没备份，只能凭记忆恢复，恢复效率极低。无论用什么厂商设备，都要把配置备份做成周期任务，至少每周自动备份一次。配合配置变更记录，能让你在故障后快速还原到最近一个稳定版本。

4.6 一张实用的故障排查速查表

这张表并不能覆盖所有场景，但可以作为排查方向的起点。遇到可靠性相关故障，最忌讳的是没有数据支撑乱猜，先采集设备状态、日志、接口统计，再动手调整配置，绝大多数问题都能定位到具体环节。

5. 把可靠性做成一套长期有效的体系

5.1 上线前必须完成的验收检查项

可靠性方案不是配置完就算完成，上线前至少要过一轮系统性验收。我的习惯是把验收清单分成五块来执行：

物理链路层面，检查所有冗余链路是否确实连接到位，光模块收发光功率是否正常，有没有接口协商到半双工这类隐患。协议配置层面，检查Eth-Trunk成员口是否全部Selected、VRRP主备角色和规划是否一致、BFD会话是否全部Up、STP根桥位置是否正确。业务路径层面，做一次完整的跨VLAN、跨设备、上公网的连通性测试，确认主备路径都能转发业务流量。切换演练层面，至少执行一次主设备掉电、关键链路shutdown、BFD会话中断三类测试，记录切换时间和丢包情况。运维文档层面，把拓扑图、IP规划表、VLAN规划表、VRRP优先级规划、明文版配置命令整理成档，至少两人能看懂能操作。

很多团队做完前四步就觉得万事大吉，文档却拖到最后随便补一版。真到故障发生时，写不清楚的文档比没有文档更害人，操作人员照着错误文档操作，反而会扩大故障范围。我认为文档应该与配置同步更新，哪怕方案是小规模改造，也要把变更记录同步到文档里。

5.2 变更管理中隐藏的可靠性杀手

网络可靠性真正的大敌，很多时候不是设备故障，而是人为变更。我见过不止一次：核心设备稳稳跑了一年，某次为了调整一个无关痛痒的VLAN配置，顺手把BFD会话的参数动了一下，或者为了临时调试把某条链路的端口shutdown之后忘记恢复，结果引发全网大面积中断。可靠性方案越是设计精妙，就越依赖变更流程的严谨性。

建议网络变更至少遵循以下几项铁律：变更前做好配置备份，并导出变更前后diff对比；变更尽量在业务低峰期执行；涉及主备设备的变更要一次只动一台，先动备机观察没问题再动主机；变更完成后立即检查VRRP状态、BFD会话、Eth-Trunk成员口、关键链路状态；所有变更必须在变更记录中留痕。另外，准备一套回退方案。如果变更导致可靠性机制失效，能否在几分钟内把配置恢复到变更前的状态，在动手之前就要有答案。

前面提到的切换演练，不只是上线前做一次就结束的东西。建议按季度或半年为周期做一次主备切换演练，既验证设备状态，也让运维团队熟悉切换流程。很多团队把切换演练当成不敢碰的“高危动作”，宁可让它生锈也不愿意验证，结果真到故障发生时手忙脚乱。演练时先把业务影响评估清楚，申请窗口、通知相关方、准备回退方案，其实风险是可控的。练过的系统和没练过的系统，在真实故障面前的表现差距非常明显。

5.3 最后一条经验

从我做网络建设与运维这些年的体会来看，可靠性技术的难点从来不在“会不会配VRRP、会不会做链路聚合”，而在于你有没有一套贯穿设计、部署、验证、运维、变更的可靠性思维。协议参数配错了可以改，设备坏了可以换，但如果整个方案没有经过充分验证，没有文档沉淀，没有演练机制，那无论配置多漂亮，在真正的故障面前都可能一碰就碎。

每次准备动核心网络之前，不妨把几个问题在脑子里过一遍：设备出问题后谁接管？接管需要多久？接管之后业务能不能通？切换过程会不会引发新的问题？这套机制上一次验证是什么时候？这几个问题如果能毫不犹豫地回答上来，那这份可靠性方案才算真正落地了。