凌晨三点，手机突然响起。一看监控平台推送，核心交换机丢包率飙升，部分服务器开始失联。这种场景在运维圈里太常见了，关键不是问题多大，而是响应够不够快、流程对不对。
第一步：发现与确认
告警来了不能直接动手。先登录Zabbix看具体指标，再用SSH连上核心设备执行show interface status和ping gateway -c 10，确认是不是瞬时抖动还是真故障。曾经有次半夜冲进机房，结果发现是运营商线路临时切换，白跑一趟。
第二步：分级与通报
我们按影响范围分三级：一级是全站不可访问，二级是部分服务异常，三级是预警类问题。这次属于一级，立刻在企业微信群发消息，@相关开发和DBA，同时电话通知值班主管。模板固定：[紧急] 网络故障 - 核心交换机异常，正在排查，预计5分钟内出初步结论。
第三步：隔离与临时处置
查日志发现某台接入层交换机持续发送广播包，疑似环路。马上通过带外管理登录该设备，关闭对应端口：
configure terminal
interface gigabitethernet 0/24
shutdown操作后主干流量立刻恢复正常。这时候不急着重启设备，避免掩盖现场。
第四步：根因分析与修复
第二天白天调取前24小时日志，结合拓扑图发现是新接入的一台测试服务器网线接错了两个口，形成物理环路。修正连接后，在交换机全局启用spanning-tree portfast防呆，并补充接入规范文档。
第五步：复盘与流程优化
把这次事件写进内部知识库，更新应急预案。现在新员工培训都会讲这个案例。还加了一条自动化规则：当单端口广播包超过阈值，自动触发告警并标记设备位置。
一套清晰的网络维护响应流程，不是写在PPT里的标准，而是一次次故障中磨出来的习惯。平时演练十分钟，真出事能省下两小时。