先说个丢人的事
2022年9月13日，周二，早上9:12。我还在楼下买美式，手机开始震：客户群说后台打不开，客服说电话被打爆，老板在钉钉群里@了我三次。我跑回工位，发现不是“后台打不开”，是昨晚发版时把支付回调的域名配错了。测试环境没问题，生产环境 3 台机器里只有 1 台更新了配置。那天我们花了 47 分钟恢复，但后面 3 天都在擦屁股：手动补单、给客户解释、写事故报告。
那次之后我才明白，工作里的突发状况，大部分不是“突然发生”，而是“突然被发现”。域名配错、备份没测、只有一个人知道密码、客户口头答应的需求没写进邮件——这些雷早就在那儿，只是那天炸了。
真突发和假突发，先分清楚
我现在把突发状况分成两类。真突发：机房断电、平台封号、核心同事出车祸、甲方老板突然换人。这类你控制不了，只能拼响应速度。假突发：需求临时改、数据对不上、线上报错、客户投诉、同事离职。这类看着急，其实 80% 有前兆，只是没人管。
对比一下：大公司遇到 P0 事故，会拉 war room，有 incident commander，有专门记录时间线的人。小团队呢？通常是老板在群里吼，技术闷头查，运营到处问“好了没”，客服被客户骂。不是说小团队不行，而是角色缺位。我们后来就 3 个人也硬分：一个人指挥，一个人动手，一个人对外说话。效果比 5 个人乱问好得多。
15分钟止血清单，照着做
第一步，0-2 分钟：定级。P0 是核心业务挂了、钱收不进来、用户大面积不能用，5 分钟内拉群。P1 是部分功能异常、少数客户受影响，30 分钟内处理。P2 是体验问题、文案错误，当天排期。别所有事都喊“天塌了”，人会麻。
第二步，2-5 分钟：指定角色。指挥只做决定，不亲自查日志；执行只动手，不负责解释；沟通只对外同步，不参与技术讨论；记录只写时间线，不评价。我们最惨的一次就是所有人都在技术群里问“什么情况”，结果真正能改代码的人被消息淹没。
第三步，5-10 分钟：止血，不找根因。能回滚就回滚，能降级就降级，能关入口就关入口，能限流就限流。先让用户能用，再慢慢查为什么。记住三个动作：回滚上一个版本、切到备用通道、把非核心功能关掉。别一上来就啃代码，用户等不起。
第四步，10-15 分钟：对外同步。模板就三句话：目前影响是什么，我们正在做什么，下次更新时间几点。比如：“支付回调异常，影响部分订单，已回滚配置，预计 15:30 前恢复，16:00 再同步。”不要写“疑似”“可能”“正在排查中”这种废话，客户看了更慌。
复盘不是批斗会
恢复之后 24 小时内，一定要复盘。但复盘不是问“谁干的”，而是问“哪个环节允许这件事发生”。我们那次域名配错，根因不是某个人手滑，是发布流程里没有配置检查，测试和生产配置不一致，而且没有自动告警。后来加了 3 个东西：发布前 diff 配置、支付回调每 5 分钟探活、关键操作双人确认。之后 8 个月没再出同类事故。
还有个反常识的点：突发状况时，最贵的不是 downtime，是信息不对称。老板不知道进度，就会频繁来问；客户不知道影响，就会升级投诉；执行的人不知道边界，就会重复劳动。所以哪怕技术还没修好，也要每 15 分钟扔一句进度。哪怕只是“还在处理，16:10 再同步”，也比沉默强。
最后说点难听的
很多团队喜欢表扬“救火英雄”，但救火英雄越多，说明防火做得越差。真正该奖励的是那个把备份恢复演练做了、把告警阈值调了、把口头需求逼成邮件的人。突发状况处理能力很重要，但更重要的是让突发状况少发生。
如果你现在正被突发状况按在地上摩擦，先别慌。打开备忘录，写：影响谁、多大范围、现在能做什么、下次同步时间。然后拉个 3 人小群，按上面 15 分钟走一遍。能回滚就回滚，不能回滚就降级，不能降级就诚实说。别装，别拖，别在群里吵架。