先说个真事：上周二 16:12，客户群里炸了
上周二下午 16:12，我正对着周报发呆，客户在群里 @ 我，说支付回调 502，后台显示 3000 多笔订单卡在待支付。我第一反应不是回“收到”，而是打开日志面板。 但这里有个反常识：突发状况下，最贵的不是解决方案，而是信息整理时间。你越急着修，越容易把 10 分钟能搞定的事拖成 2 小时。 我后来给自己定了 90 秒规则：90 秒内只做三件事——确认影响面、找最近 24 小时变更、拉关键人。超过 90 秒还没头绪，立刻升级，不硬扛。 那天我 16:14 拉了 3 人语音，16:17 定位到是第三方回调地址配错，16:23 回滚配置，16:31 订单恢复。看起来很快，但中间有 4 分钟是我在群里反复解释“正在排查”，其实毫无意义。 所以我现在更信一句话：突发状况的第一产出不是修复，是让所有人知道现在发生了什么。
救火型和系统型，差的不只是脾气
我复盘过 7 次线上事故和 2 次线下突发，发现一个很扎心的对比：80% 的混乱来自信息不同步，不是技术难。 救火型的人习惯说“我来搞定”，然后埋头 2 小时，群里安静得像周末。系统型的人会说“我先拉个 3 人语音，5 分钟后同步一次”，哪怕他还没找到原因。 这两种做法在老板眼里可能前者更努力，但团队感受完全不同。前者让其他人不敢问、不敢动，后者让每个人知道边界在哪。 我现在的做法很土：建临时群，指定一个人只做记录，时间线精确到分钟。每 5 分钟同步一次，哪怕只说“还没定位，下一步查数据库连接数”。 另外设一个止损点：30 分钟无进展就回滚或降级。别把“找到根因”当成第一目标，先让业务止血。这个顺序错了，后面全是加班。
15 分钟应急流程，我贴在显示器边上
0-2 分钟：确认范围。多少用户、多少订单、哪些功能、有没有客诉。别写“部分用户”，要写“3000+ 待支付订单”。 2-5 分钟：查最近 24 小时变更。发布、配置、数据库、第三方接口、证书过期。我吃过一次亏，是 CDN 证书凌晨自动续期失败，白天才爆。 5-10 分钟：选最小止损动作。回滚、开关、限流、降级、公告。能回滚就别 debug，能降级就别重构。 10-15 分钟：对外同步。模板是：“目前影响 X，已定位 Y，正在做 Z，下次同步 HH:MM。” 不要写“请稍等”，这句话没有信息量。 还有个小细节：把关键联系人的微信置顶，把回滚命令存到备忘录，把降级开关路径写成一页纸。这些东西平时看着笨，出事时能省掉你翻聊天记录的 10 分钟。
我的独立观点：抗突发不是反应快，是提前放好决策权
小公司靠人，大公司靠流程，但流程也会僵化。我见过一个 200 人团队，事故响应要填 3 个表，结果大家宁愿先修再补。 真正抗突发的人，不是反应快，而是提前把“决策权”和“信息出口”放好。谁有权回滚？谁负责对外说？谁记录时间线？这些如果没提前定，现场就会吵架。 我每周五花 20 分钟写一页“下周如果出事”：谁会找我、我找谁、权限在哪、哪个开关能降级。写完后把 3 个关键联系人置顶。 这习惯听起来有点被迫害妄想，但确实让我在两次突发里少发了 5 次脾气。情绪稳定不是靠忍，是靠提前知道最坏情况长什么样。 最后说句实话：不要追求每次都完美解决。目标是让团队在混乱里还能做对 1-2 个关键动作。写到这，我手机又响了，先不说了。
