工作突发状况怎么处理？我踩过3次坑后，整理了一套“15分钟止损法”
周一早上 9:12，客户群里有人发截图：订单列表空白。 我当时在楼下买美式，手机只剩 8% 电。 第一反应是问开发“你改了啥”，结果浪费了 7 分钟。 后来查出来是 CDN 缓存规则改动，影响 12 个客户，其中 3 个在续费期；接口错误率从 0.3% 冲到 11%，P95 从 420ms 到 3.8s。 回滚 v2.14.3 到 v2.14.2 花了 6 分钟。 这个事让我改了一个观点：突发状况不是考你冷静，是考你的工作有没有“可暂停按钮”。
很多文章让你“先冷静、再沟通、后复盘”，太正确了，正确到出事时根本想不起来。 我待过两家公司：一家有 38 页的应急预案，真出事没人翻；另一家只有 6 个人，靠群里吼。 对比下来，真正有用的不是厚 SOP，也不是个人英雄，而是把工作切成 15 分钟能交接的颗粒。 我的独立观点：别做情绪稳定的人，做流程有冗余的人。 突发状况分三类：信息型、资源型、事故型。信息型先找源头，资源型先砍范围，事故型先止损。 混在一起，越处理越乱。
我现在用的四步：5 分钟、15 分钟、30 分钟、60 分钟
- 5 分钟确认：只问 3 个问题——谁受影响？还在扩大吗？最晚什么时候必须给答复？别急着追根因。根因是复盘的事，不是救火的事。
- 15 分钟止损：不是解决，是止血。参数可以硬一点：错误率 >5% 且持续 2 分钟，先回滚；客户投诉 >3 个，先统一话术；正在发布，先停发布。动作就几个：拉群、回滚、关入口、发公告。
- 30 分钟同步：发三行邮件——现状、影响、下次更新时间。指定 1 个技术负责人、1 个对外口径人、1 个记录人。每 30 分钟更新一次，哪怕没进展。别让客户从别人嘴里听到版本。
- 60 分钟复盘：记录时间线、根因、改进项、负责人、截止时间。改进项别写“加强意识”，写成“CDN 缓存规则加审批，灰度 5% 观察 10 分钟”。
一张卡片，比 38 页预案好用
我后来把应急信息压成一张【突发状况卡片】，贴在飞书文档和工位显示器边：
- 影响面：
- 是否扩大：
- 止损动作：
- 对外口径：
- 下次更新：
- 负责人：
- 截止时间： 它不高级，但半夜被叫醒时，能让你少问 5 句废话。 我也有过蠢操作：有次为了显得负责，在群里连发 20 条“正在看”，客户反而更慌。 后来学乖了，没结论就发“已确认影响 12 个客户，11:30 给下一次更新”。
最后说点不舒服的
突发状况不是你的高光时刻，别演。 半夜被叫醒，先判断能不能白天处理；不能，再拉起人。 能回滚就别硬修，能降级就别全量恢复，能砍需求就别加人。 你真正要保护的，不是“我很强”的人设，是客户信任、团队节奏和你自己的睡眠。 工作突发状况处理得好，不是因为你临场超常，而是因为你提前留了防火带。
