配置检查不能靠肉眼
很多人在部署网络前习惯打开设备配置文件，一行行看着觉得没问题就准备上线。这种做法风险不小。比如某次给一家连锁超市做门店网络升级，工程师核对了IP地址和VLAN划分，但漏掉了DHCP中继的转发地址，结果新系统一上线，收银机全连不上服务器。其实这类问题完全可以通过自动化脚本提前发现。
<script>
check_ip_conflict("192.168.10.0/24");
detect_missing_route("default");
verify_vlan_range(10, 50);
</script>用仿真环境跑一遍真实流量
实际业务流量比理论模型复杂得多。建议用抓包工具在旧网络中采集典型时段的流量样本，导入到仿真平台里重放。某物流公司曾在一个模拟环境中发现，新的防火墙策略虽然允许基础通信，但在高并发小包场景下会出现连接超时。这个隐患在正式部署前就被修正了。
常见的做法是使用Wireshark或tcpdump收集数据包，再通过Ostinato、Trex等工具进行回放测试。重点观察丢包率、延迟波动和会话建立成功率。
物理层也要“动手摸”
别以为光模块插上去亮灯就是好使。曾经有项目现场所有交换机端口都显示UP，可传输大文件时速度始终上不去。后来用专业仪表测了光纤衰减值，才发现有一段跳线老化严重，损耗接近临界点。这类问题在白天测试时可能不明显，等到晚上业务高峰才暴露。
建议提前准备好光功率计、网线测试仪这些基础工具。尤其是改造项目，老线路的性能往往不如预期。
权限与安全策略要提前验证
新网络上线后最怕出现“能上网但打不开系统”的情况。某医院部署新内网时就遇到这个问题——终端都能获取IP，也能ping通服务器地址，但HIS系统始终登录失败。排查发现是新的ACL规则拦截了某个动态端口范围。这类问题最好在部署前用测试账号从客户端发起完整业务请求来验证。
可以用curl或Postman模拟API调用，也可以写个小脚本自动检测关键端口和服务响应：
#!/bin/bash
for port in 80 443 3306 8080; do
timeout 3 bash -c 'echo > /dev/tcp/10.20.30.$host/$port' && echo "Port $port open" || echo "Port $port closed"
done留够回退时间窗
哪怕验证做得再细，也得为意外留余地。建议把变更窗口安排在业务低峰期，并预留至少三分之一的时间用于回退操作。曾经有个客户坚持在早高峰前切换网络，结果出问题后没时间恢复，导致前台挂号系统瘫痪近一个小时。后来我们约定，任何变更必须提前4小时完成部署验证，否则延期处理。