一次断网事故后的真正考验才刚开始
上周三下午，公司突然全员断网。运维团队花了四十分钟定位到是核心交换机的STP震荡引发的广播风暴。设备重启，网络恢复，大家松了口气。但三天后，同样的问题又出现了。
这不是技术能力的问题，而是后续跟进没做到位。很多网络事件处理停留在“通了就行”的层面，忽略了真正的闭环管理。
事件平息不等于问题消失
网络恢复只是第一步。就像家里水管爆了，临时接上胶带止漏并不算完事。真正的处理应该包括：记录故障时间线、分析根本原因、验证修复方案的长期有效性。
比如那次STP震荡，事后发现是某台测试服务器误接入了冗余链路，触发了环路。虽然当时拔掉了网线，但没有更新接入规范，也没有对新设备上线流程做检查，导致同类设备再次接入时重演故障。
建立轻量级跟进清单
不需要复杂的流程系统，一个简单的待办清单就能避免多数重复问题。每次重大事件后，留出半小时整理以下几项：
- 故障发生的具体时间与影响范围
- 采取的应急操作步骤
- 确认的根本原因（不能停留在“疑似”）
- 已实施的修复措施
- 是否需要修改配置模板或部署监控规则
- 是否需同步给其他团队（如安全、开发）
用自动化防止人为疏忽
手动记录容易遗漏，可以结合现有工具做轻量自动化。例如，在Zabbix或Prometheus中为本次事件添加专项监控：
rule: Detect_STP_Change
alert: Frequent_STP_Topology_Changes
expr: changes(stp_topology_changes_total[5m]) > 3
for: 1m
labels:
severity: warning
annotations:
summary: "交换机 {{ $labels.device }} 在5分钟内发生多次STP拓扑变更"
description: "可能由环路或异常设备接入引起，请立即检查"这类规则不需要一开始就完美，先跑起来，根据实际告警反馈调整阈值即可。
把教训变成团队资产
有个做法很实用：每月整理一次“本月掉过的坑”，做成内部知识库条目。比如写清楚“为什么不能随意将虚拟机桥接到两个VLAN”，配上拓扑图和日志片段。
新人入职时看这些案例，比读十页标准文档更直观。久而久之，团队对常见陷阱会形成条件反射。
别让会议变成甩锅现场
复盘会议的重点不是追究谁按下了重启键，而是搞清楚流程哪里断了。有人担心追责就不愿说实话，结果问题被掩盖。
换个方式开场：“这次我们挡住了故障扩大，接下来一起看看怎么让它不再回来。” 氛围变了，收获的信息也更真实。
网络世界的稳定性，从来不靠一次完美的应急操作，而是靠每一次事后的耐心梳理。设备会老化，人员会流动，唯有沉淀下来的跟进机制，能让系统越出问题越强壮。