一次核心交换机割接复盘：从方案、回退到演练

在网络工程师的职业生涯中，有两件事最让人心跳加速：一是核心链路Down掉告警狂飙，二是核心交换机割接。
前者是被动挨打，后者是主动“拆弹”。
最近刚结束了一次核心交换机的替换割接，整个过程虽然有惊无险，但回首复盘，从方案的细节打磨到回退策略的制定，再到演练的执行，每一个环节都值得深思。本文就以这次实战为例，聊聊如何把一次高风险的“拆弹”变成可控的“换血”。
一、 方案篇：把“意外”关进笼子里
很多人写割接方案，喜欢把配置脚本写得满满当当，却忽略了最重要的一点：割接不是配置迁移，而是业务流转。
在这次方案设计阶段，我们犯了两个“想当然”的错误，幸好被评审会纠正。
1. 忘了“二层”还是“三层”
老核心跑的是纯二层，新核心规划的是三层网关。这看似简单，实则涉及ARP表、MAC表、路由表的全面重建。如果只是把VLAN配置复制过去，割接完网络肯定不通。
教训： 方案中必须明确新旧设备的协议差异。不仅要配新设备，还要预配置老设备的一些清理工作，确保协议平滑过渡。
2. 忽视了“隐形依赖”
我们列出了所有服务器和业务网段，却唯独漏了一台不起眼的门禁控制器和老旧的监控平台。割接当晚，业务网通了，但这些“边缘系统”因为MAC地址绑定问题死活上不去。
教训： 割接方案的第一步不是写命令，而是梳理资产。不仅要梳理核心资产，还要通过老设备的ARP表和MAC地址表，把那些“僵尸设备”挖出来。
最终方案的核心逻辑：
分段割接：不要试图一口吃成胖子。我们将网络划分为业务区、办公区、服务器区，分三个时间段依次割接。
配置对比脚本：我们写了一个Python脚本，对比新旧配置的VLAN、端口描述、路由条目，确保“一个不少，一个不错”。
二、 演练篇：别把“第一次”留给现场
“纸上得来终觉浅”，这句话在割接里是铁律。很多工程师自信满满，觉得命令都背下来了，到了现场手抖、线乱、环境暗，立马抓瞎。
这次我们做了三次不同层级的演练：
1. 桌面推演：
拉着团队成员，对着PPT走流程。谁负责拔线？谁负责敲命令？谁负责业务验证？
发现的问题：原本计划两人配合，一人敲命令一人看状态。推演发现，在紧张环境下，双人配合反而容易沟通失误。改为单人操作、双人复核模式。
2. 实验室模拟：
找了两台同型号设备，搭建了1:1的微型环境。
发现的问题：新设备的OS版本与旧版光模块存在兼容性告警。如果在现场才发现这个问题，可能要花半小时查文档，甚至导致割接失败。我们提前升级了OS版本解决了问题。
3. 预配置演练：
在割接前一天，我们将新核心交换机上架加电（不接线），把所有配置刷进去，并检查端口指示灯状态。
发现的问题：电源线长度不够。是的，就是这么低级的错误。如果在割接当晚才发现，还得半夜找电工接线，那真是灾难。
演练的价值在于：把所有的“低级错误”在白天、在实验室里犯完，留给割接现场的只有“高级操作”。
三、 回退篇：敢于“认怂”才是成熟
割接最忌讳的是什么？是“赌徒心态”。觉得“马上就好了，再试十分钟”，结果十分钟变成两小时，业务彻底中断。
回退方案必须是割接方案的“镜像”。
在这次项目中，我们制定了严格的“熔断机制”：
时间熔断：
计划割接窗口为00:00-04:00。
03:00如果业务验证未通过，无论进行到哪一步，立即执行回退。
03:30如果回退未完成，必须电话上报决策层。
绝不拖延到早高峰上班。
操作熔断：
如何回退？
物理回退：把新设备的线拔下来，插回老设备。听起来很土，但这是最快、最可靠的方法。前提是老设备的配置没动，且处于热备或随时可加电状态。
逻辑回退：如果只是路由配置错误，通过命令行撤销配置。
这次实战中的一个小插曲：
割接办公区时，部分用户反馈访问内网速度变慢。排查发现是生成树协议（STP）状态迁移震荡。眼看离熔断时间还有40分钟，我们没有死磕，而是果断决定：回退办公区业务。
回退后业务瞬间恢复。我们利用剩下的时间排查发现是端口配置里少敲了一个edge-port（边缘端口）命令。
修正配置后，我们在下一个窗口顺利完成割接。
敢于回退，是对业务负责，也是对自己技术的自信。因为你知道，回退不是失败，而是为了下一次更完美的成功。
四、 复盘总结：割接是技术与管理的双重博弈
这次核心交换机割接最终成功落地，总结下来，技术只是底座，流程才是灵魂。
方案要“细”：细到每一根光纤的标签，细到每一个VLAN的描述。魔鬼藏在细节里。
演练要“真”：实验室模拟救了我们的命，提前发现了光模块兼容性问题。
回退要“快”：不要羞于回退。保留旧设备在线（或随时可上线）的状态，是最后的保险绳。
最后，给所有网工朋友一句话：完美的割接，就是让用户感觉不到割接的发生。 我们的熬夜和焦虑，是为了换取业务的平稳如初。当凌晨4点业务验证通过，走出机房看到城市微亮的晨光时，你会发现，一切严谨的准备都是值得的。