一次突发断网的排查经历
上周三下午，公司突然全员断网，企微消息发不出去，OA 系统打不开。IT 小组紧急响应，第一步就是确认问题范围——是整个办公区还是个别楼层？通过快速询问几个部门同事，发现只有三层和四层断网，一层和二层正常。
这说明不是外网出口问题，更像是内网交换机或 VLAN 配置出了状况。我们直接登录核心交换机查看日志，发现三层接入交换机的某个光口频繁闪断，错误计数持续上升。
定位硬件问题
现场检查发现，该交换机连接光纤的接口有轻微松动，且尾纤上有一点压痕。更换备用光纤后链路恢复，但几分钟后又开始丢包。最终判断是模块老化导致光衰过大。换掉光模块后，网络恢复正常。
这类问题其实挺常见，尤其是用了三年以上的设备。很多公司为了省钱不及时更新硬件，结果小毛病频发，影响效率。
DNS 劫持导致的访问异常
另一个案例是销售部反馈，打开官网总是跳转到一个陌生页面。起初以为是中毒，但杀毒软件没报任何风险。我们用 nslookup 查了域名解析，发现返回的 IP 完全不对。
进一步排查发现，路由器的 DNS 设置被篡改成了一个境外地址。查配置历史记录，发现两天前有人通过默认密码登录了管理界面。立即恢复默认设置，修改管理员密码，并启用双因素认证。
后来复盘才发现，是新来的实习生用手机连了管理 Wi-Fi，顺手试了 admin/123456 这种通用密码，无意中改了设置。现在所有管理设备都强制改密，且不允许使用弱密码。
代码引发的流量风暴
还有一次，监控系统报警内网流量暴涨，接近千兆带宽跑满。抓包分析发现大量来自同一台开发服务器的 UDP 请求，目标端口 53，也就是 DNS 查询。
登录服务器一查，发现一个新上线的脚本存在逻辑错误：
while True:
resolve_domain("api.example.com")
time.sleep(0.01)这个循环每秒发起上百次解析请求，而且没有缓存机制。开发者本意是检测服务状态，结果忘了加条件退出，部署后就一直跑着。
临时解决方案是 iptables 限速，长期则是优化代码加入指数退避和本地缓存。这种“自己人搞自己”的情况，在敏捷开发中并不少见，自动化测试和灰度发布能有效降低风险。
日常建议
遇到网络异常别急着重启设备。先问清楚影响范围，再查日志、抓数据包。保留原始记录很重要，有时候问题重现不了，日志就是唯一线索。
定期做配置备份，哪怕只是手动导出一份 running-config。真出事时，回滚比重配快得多。另外，把常用排查命令写成脚本，比如批量 ping、端口扫描、DNS 检测等，关键时刻能省一半时间。