工作突发状况怎么处理？我复盘了47次线上事故，总结出“10-30-60分钟止损法”
2023年9月14日，周四，17:43。我正准备关电脑，客服群里突然237条未读。 运营总监@所有人：“订单导出接口504，客户在催，多久恢复？” 我点开监控：错误率68%，P99从800ms飙到12s，MySQL CPU 92%，连接池200被打满。 我第一反应是重启服务——结果3分钟后，又挂了。 后来查出来，是运营导了30天数据，一条SQL扫了1.2亿行。 18:26恢复，影响43分钟，客诉11单。 我们写了8页复盘，但真正有用的就3条。
大部分“工作突发状况”教程都在教你怎么冷静、怎么沟通，但没人告诉你：突发状况最怕的不是问题本身，是“责任真空”。 群里20个人，每个人都在问，没人说“我来”。 所以我的独立观点是：先定指挥，再定方案。 没有指挥，所有方案都是噪音。 你越急着解决问题，越容易变成所有人一起改配置、一起重启、一起把事故搞大。
10-30-60分钟止损法
前10分钟：定级、建群、指定角色。 别查日志，先搞清楚影响面。 P0：核心交易不可用，影响>30%用户，或金额>5万/分钟，15分钟内升级CTO。 P1：部分功能不可用，影响5%-30%用户，30分钟内升级总监。 P2：体验问题，不影响交易，2小时内处理。 然后拉一个临时群，只留3种人：指挥、执行、记录。 指挥不一定职位最高，但必须敢拍板。执行只干一件事。记录精确到分钟。
第30分钟：止损优先，根因往后放。 能回滚就回滚，能降级就降级，能限流就限流，能切流就切流。 别在事故群里讨论“为什么”，先讨论“怎么让用户能用”。 我们那次最后是杀掉慢查询、把导出功能降级成异步任务、连接池临时从200调到350，才把错误率压到1%以下。 记住：恢复服务比证明谁对谁错重要100倍。
第60分钟：对外同步、记录时间线、决定是否升级。 对外话术别只说“在修了”。 模板：“我们已定位到订单导出服务异常，影响17:43-18:10的导出功能，订单创建和支付正常。当前已降级，预计18:30恢复。” 对内话术：“我是本次指挥@张三，执行@李四，记录@王五。当前动作：回滚v2.3.1到v2.3.0，观察5分钟。” 如果60分钟还没恢复，直接升级，别硬扛。
大厂和小团队，别照搬同一套
大厂有SRE、有SLO 99.95%、有错误预算每月21分钟、有PagerDuty自动升级。 小团队只有微信群和一部手机。 你让10个人的团队学大厂搞完整事故指挥体系，大概率会变成PPT。 小团队真正该准备的是“3人角色卡”：指挥、执行、记录。打印出来贴在工位。 谁轮值，谁就是消防员。指挥可以不懂技术，但必须会问三个问题：影响多少用户？最坏结果是什么？下一步谁做、多久？
还有一个反常识的点：建立“突发预算”。每月允许2次P2、1次P1，超出才问责。 为什么？因为如果每次突发都追责，团队下次就会瞒。 瞒到用户投诉、老板发现，才是真灾难。 复盘只改系统，不批斗人。把“谁写的bug”改成“哪个环节让bug能上生产”。
我踩过的坑，你大概率也会踩
- 所有人都去改配置，没人记录。最后连改了什么都不知道。
- 老板在群里问“好了没”，你回“在修了”，等于火上浇油。要给时间点和影响面。
- 复盘变批斗，下次没人敢说真话。事故不是抓坏人，是修漏洞。
- 忘了看监控就重启。重启能解决80%的问题，但会让100%的根因消失。
我后来把手机铃声换成《好运来》，因为凌晨3点电话响太吓人。 现在每次突发，我先在纸上写“最坏结果是什么”。 写了47次之后发现，80%的突发最坏结果只是被老板骂，不是公司倒闭。 真倒闭的那种，你也没时间刷群。 所以，先深呼吸，找纸笔，写三个字：谁、啥、多久。这比任何鸡汤都管用。