问题来了，网络不能等
早上九点，公司刚开完会，突然所有员工都打不开邮箱，OA系统卡在 loading 界面。运维小李一查监控，发现内网流量暴增，核心交换机 CPU 直接拉满。这不是普通的高峰拥堵，而是典型的网络突发事件。
类似的情况不少见：某台设备异常广播、病毒横向传播、配置误操作、甚至是光纤被挖断。问题一旦发生，每一秒都在影响业务。这时候拼的不是理论，是反应速度和处置流程。
建立基础监控，让问题无所遁形
没有监控的网络就像盲人开车。我们团队在关键节点部署了轻量级探针，每30秒上报一次延迟、丢包和带宽使用率。当某个指标突变，比如某条链路丢包率从0%跳到40%，系统立刻通过企业微信告警。
用 Zabbix 或 Prometheus 搭建监控并不复杂，关键是设置合理的阈值。太敏感容易误报，太迟钝又失去意义。比如我们设定：连续三次采样丢包率超过15%，才触发一级告警。
分层排查，缩小故障范围
收到告警后第一步不是重启设备，而是快速判断影响范围。是整个办公区断网？还是只有财务部访问不了服务器？
我们有个简单的三层定位法：
第一层：终端测试 —— 让用户 ping 网关，能通说明本地链路正常；
第二层：核心设备检查 —— 登录核心交换机看端口状态，有没有大量错包或广播；
第三层：路径追踪 —— 用 traceroute 查看数据包在哪一跳中断。
有一次市场部集体无法上网，排查发现是新接入的一台测试路由器开启了 DHCP，把整个VLAN的IP分配搞乱了。关掉它，五分钟恢复。
预设应急方案，关键时刻不抓瞎
我们整理了一份《常见网络突发事件应对清单》，打印贴在值班台。比如：
- 公网出口中断 → 切换备用线路，检查运营商状态页面
- 局域网广播风暴 → 在交换机上启用 storm-control 功能
- 疑似内网攻击 → 隔离可疑IP，抓包分析
像 storm-control 这种命令，提前写好模板，出事时直接复制执行，避免手抖输错。
interface GigabitEthernet0/1
storm-control broadcast level 70
storm-control action shutdown这条命令的意思是，当广播流量超过带宽70%时自动关闭端口，防止风暴扩散。
事后复盘比抢修更重要
问题解决后，我们会在当天下午开个15分钟短会：什么时间出的问题？怎么发现的？用了哪些操作？有没有更优解？
上个月一次 DNS 解析异常，最初以为是外网问题，折腾半小时才发现是内部DNS缓存被污染。后来我们在防火墙加了规则，禁止非授权DNS响应通过。这类经验积累下来，下次再遇到，三分钟就能定位。
网络突发事件不可完全避免，但只要监控到位、流程清晰、反应迅速，就能把影响压到最低。别等大问题来了才想着怎么做，平时多走一遍流程，关键时刻才能稳住不慌。