14:12，客户已经在腾讯会议里了
我到现在都记得那个周二，14:12，客户已经进了腾讯会议，我还在改演示账号的权限。
运维在飞书群里甩了一张图：MySQL 8.0.32 的 max_connections 是 200，实际连接数 197，HikariCP 报 Connection is not available, request timed out after 30000ms。
按原本的脚本，14:30 要演示下单流程，14:20 前必须把环境恢复。
我第一反应是查代码，后来发现这个反应是错的——工作突发状况里，最先做的不是找根因，是别让窟窿继续变大。
大多数教程漏掉的：先做损失封装，不是先冷静
网上很多处理突发状况的文章会说：冷静、沟通、复盘。这话没错，但没用，像告诉一个着火的人“别慌”。 我后来把应急动作改成 10 分钟止损窗：0-2 分钟写一句事故声明，2-5 分钟定等级，5-8 分钟选临时方案，8-10 分钟对外同步。 注意，顺序不能反。先找根因，往往会掉进 40 分钟的排查黑洞，客户和老板在另一边疯狂@你。 止损窗的核心是“可逆决策”：能回滚先回滚，能降级先降级，能只读先只读，能录屏先录屏。 根因可以晚 2 小时再找，但客户的信任窗口通常只有 10 分钟。
那次我实际做了什么：14:13 到 14:28
14:13，我建了一个飞书临时群，群名写“14:30客户演示-止损”，只拉 4 个人：我、运维、后端、销售。 14:15，我指定运维是唯一对外接口，其他人不要在客户群说话；销售只负责拖时间，话术是“演示环境刚做网络切换，我们先看本地录屏，3 分钟后继续”。 14:18，运维把读流量切到只读副本，主库连接池从 197 降到 43，HikariCP 超时消失；代价是下单写入不可用，但演示只需要查询和展示。 14:22，我用 OBS 录了 2 分 40 秒的本地演示片段，销售在腾讯会议里分享屏幕，客户没看出异常。 14:28，销售把腾讯会议议程改成“先讲方案，再演示”，正式演示 14:31 开始，只比原计划晚 1 分钟。
对比：大厂和小团队的突发状况，根本不是一套题
我在 800 人公司见过 on-call、SLA、status page，故障一发生，系统自动建 incident，15 分钟内值班经理接管。 后来在 12 人小团队，没有值班表，没有 status page，老板就是最大的 SRE，财务就是最大的法务。 所以别照搬大厂流程。小团队要先写“谁能拍板”：客户赔钱、数据回滚、媒体回应，这三类事必须 5 分钟内找到人。 大厂防的是系统性风险，小团队防的是“一个人请假就没人会重启服务”。 这也是为什么我不推荐一上来就套 RACI 矩阵，4 个人以内，直接喊角色：你执行、你沟通、你记录、我指挥。
复盘别写“加强意识”，写失效检查点
那次事后复盘，我们没写“加强责任心”，而是列了 4 个失效点。 第一，备份 cron 在版本升级时被注释，没人发现，RPO 名义 24 小时，实际 0 小时。 第二，监控只看 CPU 和内存，没监控 MySQL 连接数；后来加了阈值：连接数超过 70% 发飞书，超过 85% 打电话。 第三，发布 checklist 没有“会议/大促前 30 分钟冻结变更”，现在写死：14:00 后禁止改生产配置。 第四，客户演示没有本地录屏兜底，现在每次演示前 1 小时，必须准备 3 分钟离线视频和只读账号。 复盘不是分锅会，是找哪颗螺丝松了；但前提是，止损阶段已经结束了。
一套可以直接抄的突发状况话术
对老板：现在影响是 X，已经做了 Y，预计 Z 时间给下一版信息，需要你拍板的是 A 还是 B。 对客户：我们检测到演示环境网络抖动，为了不浪费大家时间，先切换到离线演示，原定内容不变。 对团队：现在进入止损窗，10 分钟内只做三件事：止血、同步、记录；根因分析放到 16:00 以后。 对自己：先问“这个动作可逆吗？”不可逆的决策，比如删数据、群发道歉、直接回滚全量，必须等到有第二个人确认。 如果只能记一句话：工作突发状况里，冷静不是目的，缩小损失才是。