先说我遇到的那次：周三 15:17，企业微信群里 200 人，老板 @全体，客户说订单提交不了
那天我在一家 SaaS 公司做运营，正在改周五路演的 PPT。监控群突然弹出：API 错误率 12%，P99 从 380ms 飙到 8.2s，QPS 从 2100 掉到 300。我第一反应不是冷静，是脑子嗡一下，手心全是汗。 技术群里有人说“我本地是好的”，运维说“Nginx 一堆 502，不是我们这层”，开发说“刚发版，但只改了一个文案”。老板在客户群问：还要多久？客服截图一张接一张，销售打电话说客户要退款。 我后来才明白，突发状况里最贵的不是故障本身，是信息乱。每个人都在说话，但没人说“现在谁负责、影响多少用户、下一步几点给结论”。那 40 分钟像 4 小时。 所以我现在的观点很直接：工作突发状况，别指望“冷静”两个字。冷静是结果，不是方法。方法是你提前把角色、阈值、止损动作写成一张纸，然后现场只做信息收敛。
对比一下：救火英雄和“提前埋开关”的人，待遇经常反过来
我见过一个团队，故障时有个大哥冲上去改配置，10 分钟恢复，季度拿了奖。也见过另一个团队，有人提前做了降级开关、回滚脚本、灰度分批，全年没出大事故，绩效反而普通。因为没出事，没人看见。 这就是职场里很拧巴的地方：紧急处理能力容易被奖励，系统冗余能力不容易被量化。但站在公司角度，前者是 MTTR，后者是 MTBF，两个指标都重要，只是后者不刺激。 我的新观点是：突发状况管理不该追求“零事故”，零事故基本是幻觉。该追求的是“影响面可控 + 恢复时间可预期”。比如 MTTR < 15 分钟，核心接口错误率 < 1%，P99 < 2s，RTO < 30 分钟，RPO < 5 分钟。 如果你带团队，别只表扬凌晨爬起来的人，也要表扬那个把回滚包保留最近 10 个版本、把数据库 binlog 留 7 天、把告警阈值设成 CPU > 85% 持续 5 分钟的人。前者救火，后者让火没那么大。
真遇到突发状况，前 15 分钟我建议按这个土办法走
第 1 分钟：只确认三件事——告警是真的还是误报？影响的是全部用户还是部分用户？有没有正在发版/改配置/切流量？别急着找根因，根因可以晚 10 分钟。 第 3 分钟：拉一个 6 人小群，不要 200 人大群。角色写清楚：指挥 1 人、技术排查 2 人、对外沟通 1 人、记录 1 人、备份支援 1 人。指挥不一定职位最高，但必须有止损权。 第 5 分钟：定影响面。别只说“系统挂了”。要说：订单提交失败率 12%，影响约 3400 次请求，涉及 2 个客户，预计每分钟损失 6 单。数字比形容词有用。 第 10 分钟：止损优先。能回滚就回滚，能降级就降级，能切流量就切流量。回滚包最近 10 个版本、数据库变更脚本、Nginx 切流按钮、功能降级开关，这几样平时就要放在同一页文档里。 第 15 分钟：给一次对外口径。老板、客服、销售、客户群用同一句话：问题已定位到某模块，当前已降级，预计 30 分钟内恢复，下次更新 15:45。别各说各的。
别踩这些坑：我踩过，真的会越救越乱
第一个坑：在故障群里问“谁改的？”这会让所有人开始自证，不是排查。正确问法是“最近 2 小时有哪些变更？按时间列出来。” 第二个坑：让老板或销售直接指挥技术。他们可以提影响，但不要跳过指挥给开发派活。否则三个人同时让一个人改配置，很容易二次故障。 第三个坑：先写复盘 PPT 再恢复。不，恢复优先。复盘只需要记三列：时间、动作、结果。事后 24 小时内再补根因。 第四个坑：把“我本地是好的”当结论。本地环境、测试环境、生产环境，数据量、并发、网络、缓存都不一样。要看生产监控，不是看个人电脑。 第五个坑：只处理技术，不处理情绪。客户群要有人安抚，客服要有人给话术，老板要有人每 15 分钟同步。信息真空会自己长出谣言。
事后复盘，我只看 3 个问题，不看 30 页文档
问题一：哪个告警没触发？比如 CPU 到 95% 才告警，但 85% 持续 5 分钟时已经该看了。错误率 > 1% 持续 2 分钟、P99 > 2s、QPS 掉 30%，这些阈值有没有配？ 问题二：哪个止损开关没生效？回滚失败是因为依赖顺序？降级没效果是因为缓存没清？切流量慢是因为 DNS TTL 还是负载均衡配置？每次都要落到一个具体动作。 问题三：哪个信息卡住了？是没人敢拍板，还是没人知道找谁，还是对外话术没人写？这往往比代码 bug 更常见。 我的结论有点反常识：工作突发状况处理得好，不是因为你临场多牛，而是因为你平时把“最坏情况”拆成了小动作。真到那一刻，你只需要照着做，然后允许自己手抖。 最后一句，给正在搜“工作突发状况怎么处理”的你：先保住影响面，再找根因；先统一口径，再内部吵架；先让系统恢复，再让情绪恢复。
