我踩过的坑：突发状况一来，群里最忙的往往不是解决问题的人
2021年双十一前夜，我们一个小程序支付回调挂了。23:47 报警，群里 14 个人，前 20 分钟消息刷了 87 条，大部分是“好了吗”“谁在看”“要不要回滚”。没人写一句：影响多少用户、卡在哪条链路、下一次同步是几点。CTO 在 00:12 才知道涉及苹果端全部用户，等恢复已经 00:58。 那次之后我改了一个很土但管用的规矩：突发状况的第一条群消息，不许写“出事了”，必须写三行——现象、影响面、下一次更新时点。比如：支付回调失败率 38%；影响 iOS 用户下单；00:10 前给下一次结论。字数不超过 5 行，不解释原因，不追责。 很多人把工作突发状况当成时间管理问题，我不这么看。它更像信息结算问题：谁在什么时间知道什么，谁有权拍板，谁负责对外口径。技术故障、客户投诉、活动爆单、供应链断货，表面不同，底层都是同一件事——信息流比工作流先崩。 所以我现在遇到突发，第一反应不是“赶紧修”，而是先问：这条信息现在在谁手里？谁还不知道？谁需要做决定？这三个问题没答案，越修越乱。
我现在的处理顺序：10分钟止血，30分钟定线，120分钟收口
0-10 分钟，只做三件事：拉群、冻结变更、确认影响面。群不超过 9 人，必须有业务、技术/执行、客服/对外、一个能拍板的人。变更包括上线、配置、折扣、投放、合同审批。影响面先估百分比：影响 30% 以上用户、核心链路不可用、有数据丢失风险、涉及监管或媒体、预计恢复超过 30 分钟，满足任意一条就升 P0。 10-30 分钟，分 A/B 双线。A 线恢复主流程，B 线写对外话术和领导汇报。B 线不能等 A 线修完才动，否则老板、客户、客服会同时来拆你。汇报模板就四句：发生了什么、影响谁、正在做什么、下次同步几点。每 15 分钟更新一次，没进展也要发“仍无进展，下一节点 15 分钟后”。 30-120 分钟，尽量把决策人压到 3 个以内。超过 3 个，会议就会变成表态大会。需要回滚就回滚，别在故障中做架构优化。能降级就降级：关非核心功能、切备用通道、限流、人工兜底。先让业务能走，再谈优雅。 2 小时后收口。不是马上复盘“谁错了”，而是先收五个数据：首次报警时间、首个用户反馈时间、第一次有效决策时间、恢复动作、复发概率。这五个数比“加强沟通”“提高意识”有用得多。复盘会控制在 45 分钟，前 15 分钟只对时间线，后 30 分钟只出 3 个改进项，每项有负责人和截止日期。
小事故、中事故、大事故，别用同一套打法
小事故：单人闭环。比如单个客户后台报错、一个文件没同步、一场小直播卡顿。处理原则是 15 分钟内给结果，不用拉大群。但必须留痕：问题、处理动作、结果，写进工单或文档，周末翻一次，看是否重复出现。 中事故：双线并行。比如支付失败、核心接口超时、活动奖励发错、重要客户投诉升级。A 线修，B 线同步。此时最怕“技术沉默”。我要求每 15 分钟一条，格式固定：状态/影响/下一步/时间点。哪怕是在查日志，也要写“仍在查网关日志，00:40 给结论”。 大事故：作战室加对外口径。比如全站不可用、数据泄露、媒体询问、监管介入。这时候不要再让一线执行同时接老板、客户、媒体。设一个信息出口，所有外部问询都汇总到他那里。内部群禁发“我猜”“可能”“应该是”，只发已验证事实。未验证的写“待确认”，并标负责人。 对比一下救火型和防火型团队：救火型团队崇拜凌晨三点修好的人；防火型团队奖励提前发现隐患的人。救火型团队复盘爱写“加强责任心”；防火型团队复盘会改监控阈值、改值班表、改发布窗口。前者靠英雄，后者靠系统。公司小的时候英雄有用，超过 30 人还靠英雄，突发状况就会变成连续剧。
一个可以直接抄的最小模板
群公告：本群只同步事实和节点，不追责，不刷屏。当前等级 P0/P1/P2。信息出口：某某。决策人：某某、某某、某某，最多 3 人。 第一条消息：现象——支付回调失败率 38%；影响面——iOS 用户无法下单，约占订单 22%；下一次更新——00:10。 同步节奏：P0 每 15 分钟，P1 每 30 分钟，P2 每 2 小时或状态变化时。每次不超过 5 行。没有更新也要发节点，避免别人以为你消失了。 升级条件：影响用户超过 30%；核心链路不可用超过 10 分钟；数据有丢失或泄露风险；客服同一问题 10 分钟内收到 5 次以上；媒体、监管、大客户老板直接询问；预计恢复超过 30 分钟。 收口动作：恢复后 30 分钟内发第一版事实说明；2 小时内给时间线；24 小时内给改进项；72 小时内验证改进项是否落地。别把复盘拖到下周，那时候大家只记得谁背锅，不记得故障怎么发生的。 我现在带项目，遇到突发状况会先问一句：我们现在缺的是代码、权限，还是信息？大多数时候，缺的是信息。把信息流捋直，工作流才有机会恢复。这个观点不一定好听，但比“大家辛苦一下”有用。