我见过最蠢的网络事故，都不是技术问题

叠个甲：下面讲的事，时间、地点、人物、业务都做了打散和重组。像你的，是巧合。

干了这些年网工，我发现一个规律——真正让人骂娘的事故，几乎没一个是技术上有多复杂的。

什么 BGP 路由震荡、什么 MPLS VPN 跨域、什么 VXLAN 大二层，这些听起来吓人，但真出了问题，老工程师坐下来抓两个小时包，基本都能搞定。

最要命的是那些你事后一听，脱口而出“这也能出事？”的事故。

技术上零难度，代价却是最大的。

今天挑 8 个讲讲。

某次凌晨核心交换机割接，工程师提前三天在运维大群里发了通知，群里没人回复。他默认“没回就是默许”，凌晨 2 点准时动手。

2:20，电话开始爆。2:30，一个跨境对账任务直接失败。

那个对账每天跑一次，窗口只有 20 分钟，错过就得推到第二天早上 9 点。业务负责人根本不在那个运维群里——他属于业务部门，运维群里一个业务方的人都没有。

事故定性：割接期间影响跨境结算。

技术动作零失误，割接也成功了。但追责的时候没人关心这些，关心的是：为什么没有一个书面确认？

工程师的那句“群里发了通知”在事故报告里苍白得像张废纸。

后来那家公司的制度改成——凡割接，必须有业务方签字回执，否则不给开变更窗口。

一个在北京办公室，一个在上海驻场。

两个人都收到了同一个工单（工单系统没做分配，谁都能领），都以为是自己的活。两个人几乎同时 SSH 上了同一台核心交换机，各自改各自的。

北京那位先敲完 commit，上海这位的会话还在编辑模式。上海这位 commit 的时候，直接把北京的配置覆盖了一半。

更骚的是，两个人都以为自己的配置生效了，各自关掉 SSH 下班。

第二天早上业务反馈异常，网工上去看配置——是个没人认识的“四不像”。配置里有两段互相打架的 ACL，一段谁都想不起来是自己写的，另一段谁都不敢认。

事故本身 5 分钟就恢复了，但事故报告和事故会议耗了三天。

因为要回答一个问题：为什么我们一台核心交换机可以同时接受两个人的登录和配置？

从那以后那家公司上了变更锁，同一台设备同一时段只允许一个人持有编辑权限。

带他的老师傅让他“熟悉一下环境，可以在测试网上练练手”。

师傅走开去接了个电话，十分钟后回来，实习生怯生生地说：“哥，我 shutdown 了一个口，怎么交换机没反应？”

师傅扫了一眼屏幕——

那是核心交换机到存储网络的上联口。

师傅那一瞬间据说脸都白了。好在反应快，30 秒内 no shutdown 回去，加上存储本身有多路径冗余，业务只抖了一下，没造成大面积感知。

事后师傅没骂实习生，骂的是自己——

为什么一个实习生的账号，能登上核心交换机？

所谓的“测试网”和“生产网”，共用了一套 AAA 认证，账号权限没分级。实习生以为自己在测试网，其实命令敲在哪里全看他登的 IP 对不对。

那次之后，那家公司把 AAA 分成了三套独立体系：生产、测试、沙箱。生产网的登录要双人授权。

这个真是教科书级别的蠢，但真有人干。

工程师割接前很认真地做了配置备份，把 running-config 保存成了一个 .cfg 文件。

存在了同一台设备的 flash 里。

割接出问题，设备进不去，想回退。备份在设备里，设备进不去，死循环。

最后是找厂商 TAC 用 Console 恢复的，花了 4 个小时。那 4 个小时里整个办公区的内网都是断的。

这个事故的笑点和哭点在于——备份动作他做了，意识也有，但备份的位置毁掉了整个备份的意义。

备份这件事的常识应该是：“备到一个割接对象以外的地方”。但真到了现场，脑子一热就忘了。

某年 1 月 31 号晚上，工程师按惯例做防火墙策略清理。

1 月 31 号是什么日子？是财务月结日。

那天晚上整个财务部在加班跑报表，跨部门数据对接量是平时的 10 倍。工程师清掉一条他认为“最近没命中”的策略，结果恰好是财务系统到 HR 系统的一条对接口——平时确实用得少，月结那天必跑。

事故持续了 40 分钟，财务月结延迟了两天。

事后追查，那条策略不是没命中，是命中频率是“每月一次”。工程师看的是最近 30 天的命中次数，1 月 31 号往前推 30 天，正好把 12 月 31 号那次月结挡在了统计窗口外面。他看到的就是一条干干净净的“零命中”策略。

后来那家公司加了两条制度：

一是变更窗口要避开业务高峰日（月结日、季末、双十一、春节前）；

二是策略清理观察期拉长到 90 天以上，且必须跨越一个完整的业务周期。

某家公司核心网段的改造，技术方案是外聘顾问做的，落地执行是本公司的张工。

张工手里有全套文档，有改造计划，有回退预案。张工请了 5 天年假去三亚，走之前跟领导说：“割接是下周三，我周二就回来，不耽误。”

领导说：“周三改到周一，你早点回来。”

张工说：“我机票退不了。”

领导说：“那让小李先顶一下，他跟你学了半年了。”

小李真的硬着头皮上了。方案他看过，但没落地过；文档他背过，但没在实际拓扑上验证过。割接动作的第三步出了意外——一台边界路由器 BGP 邻居没起来，路由迟迟不收敛，小李慌了，给张工打电话。

张工在亚龙湾，手机信号不好，视频会议断断续续。

小李在机房，汗流浃背。

领导在会议室，脸越来越黑。

事故本质不是技术，是单点依赖。

一个关键系统的改造，只有一个人真正懂，这件事本身就是最大的风险。

后来那家公司硬性规定：任何核心变更，必须有两个人全程在场，且其中一个必须是能独立完成全套动作的。这个制度看着浪费人力，但后来救了他们不止一次。

这个事故非常典型，几乎每个运维团队都踩过。

工程师做割接前，为了避免割接期间疯狂告警打扰值班同事，手动屏蔽了相关设备的所有告警。割接完毕，一切正常，他下班回家。

他忘了把告警恢复。

两周后，被屏蔽的那台设备电源模块真的坏了，告警一条都没发出来。又过了一周，另一个电源模块也坏了——同批次电源寿命接近，一个坏了另一个风险也高。设备直接宕机。

业务中断之前，监控平台上一个告警都没有。

事故定性：监控失效 3 周，严重违反运维规范。

那个工程师被罚得很惨。但其实他冤——屏蔽告警是一个合理的割接动作，问题出在没有一个机制提醒他恢复。

后来那家公司的告警平台改造，所有“临时屏蔽”必须填到期时间，到期自动恢复，且每天给当事人发一封“你还有 X 条告警处于屏蔽状态”的邮件。

某次某工程师在核心设备上调整一条策略路由的下一跳。动作非常小，就是把下一跳 IP 改一下。

旁边的同事问：“要不要先看一下现在的配置，做个备份？”

他的原话是：“这个操作不会有事的，我做过很多次。”

然后出事了。

他指过去的那个下一跳 IP，所在的接口前一天刚被另一个变更改过——地址段变了，策略路由还指着老 IP。配置生效的一瞬间，一整条业务流量指向了一个不通的地方。

恢复不难，查出来不到 20 分钟。但那 20 分钟里，他一直在想自己讲过的那句话。

事后他自己复盘的时候说：“我真的做过很多次，就那一次，不知道怎么就不行了。”

这就是这行最吓人的地方——侥幸不是每次都翻车，但只要翻一次，前面所有的“没事”都归零。

“我做过很多次”这六个字，害过的网工，比任何一个具体的技术 bug 都多。

这 8 个事故，没一个是技术上有多难的。

有的是没人回“收到”，有的是两个人都以为自己是主角，有的是实习生不知道自己在哪儿，有的是备份存错了地方，有的是窗口选错了日子，有的是关键的人不在现场，有的是忘了把告警打开，还有的是——以为自己做过很多次。

技术上讲清楚一个 BGP 路由震荡，可能需要半小时。

但要让一个团队彻底杜绝“告警屏蔽忘了打开”，可能需要三年。

真正难的从来不是技术，是让一群人、在不同时间、不同状态下，始终按规矩来。

如果你是带团队的，别只盯着大家的技术水平。那些你觉得“不至于犯”的错，才是真正会要命的错。

如果你是一线工程师，下次听到自己要说“这个操作不会有事的”之前——

停一下。

就一下。

· · ·

聊两句：

你见过最哭笑不得的网络事故是什么？评论区聊聊，不说单位、不说品牌、不说具体人，就讲“哭笑不得在哪儿”。