网络故障处理流程图

凌晨两点，网络手机弹出告警：核心交换机端口流量归零。故障我爬起来打开电脑，处理先ping网关——不通。流程再ping同网段另一台设备——也不通。网络这时候不用看监控也知道，故障问题出在接入层往上，处理不是流程某一台终端的事。

处理网络故障，网络第一步永远不是故障敲命令，而是处理确认范围。一个人断网和一栋楼断网，流程排查方向完全不同。网络我习惯先问三个问题：哪些设备受影响？故障什么时候开始的？最近有没有变更？这三个答案能把问题空间砍掉一大半。上周有个案例，处理财务部三台电脑上不了OA，但能上网。范围锁定在应用层，跟网络底层无关，最后查出来是DNS解析到了旧服务器。

范围确认之后，从物理层往上捋。网线松了、光模块烧了、交换机断电了——这些低级问题占比不低，但很多人一上来就查路由表。我见过一个运维，折腾两小时BGP邻居关系，最后发现是机房空调漏水把光纤配线架泡了。先看指示灯，再摸设备温度，听风扇声音，这些土办法比敲命令快。

物理层没问题，进二层。查MAC地址表，看VLAN配置，确认生成树有没有震荡。二层故障有个典型症状：时通时断，延迟忽高忽低。去年双十一前，仓库扫码枪频繁掉线，抓包发现大量STP拓扑变更。根因是有人把一根网线两头都插在同一台交换机上，环路导致广播风暴。这种问题，流程图里画个圈就行，现场找起来能把人逼疯。

三层及以上，工具就多了。traceroute看路径在哪一跳断了，tcpdump抓包看TCP握手卡在哪个阶段。有个细节：如果是间歇性故障，别指望一次抓包能逮住。我通常挂个脚本循环跑mtr，跑半小时再看统计。某次视频会议卡顿，mtr显示到运营商网关有5%丢包，但白天正常。后来发现是晚高峰时段某条链路拥塞，直接找运营商调度就完了。

应用层故障最容易背锅。网络通了，但用户说“打不开”。这时候得区分是DNS、证书、还是后端服务挂了。curl -v 看完整请求链路，比在浏览器里刷新一百遍有用。上个月有个内部系统登录转圈，查了半天网络没问题，结果是认证服务连数据库的连接池满了。网络工程师这时候要做的，是把证据甩给开发，而不是继续折腾路由器。

整个流程走下来，快则五分钟，慢则通宵。经验告诉我，80%的故障集中在20%的原因里：配置变更、硬件老化、环路、DNS。剩下20%才是真正的疑难杂症，需要抓包分析和厂商支持。流程图不是用来背的，是拿来在慌乱中给自己定节奏的。先做什么后做什么，心里有张图，手就不抖。

最后说个反直觉的：不是所有故障都要立刻找到根因。业务中断时，先恢复再排查。切备用链路、重启服务、回滚配置——先把用户从故障里捞出来，再慢慢复盘。我见过太多人为了“找到真正原因”硬扛着不切流量，结果SLA爆了，原因找到了也没意义。