工作失误了怎么办？先别急着道歉：我踩过3次坑后总结的15分钟止损SOP

2021年3月18日晚上21:47，我在杭州一家做独立站SaaS的公司值班，手里还拿着没吃完的煎饼。 当时我要清理测试库的旧订单，结果 Navicat 15 的连接标签一个是 test_order，一个是 prod_order，我点错了。 执行的 SQL 是 DELETE FROM orders WHERE created_at < '2021-01-01'，没有加 LIMIT，也没有先 BEGIN。 MySQL 8.0.23 返回影响行数 1,847，涉及金额 23.6 万美元，客服群里 4 分钟后开始有人问为什么老订单看不到了。 我第一反应不是道歉，是手抖，第二反应是打开 binlog，第三反应才是想辞职。 后来真正救我的，不是检讨书写得好，而是我在 15 分钟内做了止损，而不是在群里发了一长段“对不起”。

失误分三种，别把系统漏洞全扛成个人道德问题

2019 年我第一次犯大错，把一封测试邮件通过 SendGrid 发给了 2,314 个真实用户，标题里还带着「测试勿点」。 2023 年我又犯过一次，K8s 的 ConfigMap 把 MAX_UPLOAD_MB 从 50 改成 5，3 小时内 412 个上传失败，回滚到 --to-revision=18 才恢复。 三次失误让我发现：操作层失误、流程层失误、认知层失误，处理方式完全不同。 操作层是点错按钮、写错 SQL；流程层是没人复核、没有回滚方案；认知层是你根本不知道这个动作会影响财务结算。 很多公司复盘时只骂操作层，结果下个月换个人继续错，因为流程和认知层根本没动。 但这话不能拿来当借口，个人该止损还是得止损，系统问题留到复盘时再说。

我的15分钟止损SOP：先停血，再解释

第0到15分钟，只做三件事：停止扩大、保留现场、发固定格式同步。 线上服务先回滚：kubectl rollout undo deployment/upload-service --to-revision=18；数据库先设只读：SET GLOBAL read_only=ON;；文件误删先撤权限：chmod 400。 不要急着重启，不要删日志，不要覆盖现场，不要群里发长文解释，这些都会让后面定位变难。 同步消息我后来固定成：“我在X点X分执行了Y，影响范围可能是Z，正在止损，每15分钟同步一次。” 第15到120分钟，界定影响面：用户数、金额、可逆比例，这三个数字先拉出来。 比如用 SELECT COUNT(*), SUM(amount) FROM orders WHERE created_at >= '2021-01-01' AND created_at < '2021-03-18'; 先估范围，再决定是恢复、补偿还是人工处理。

跟领导说失误，别只说“我错了”

我第一次失误时给领导发了 800 字，写自己多自责，结果他回了三个字：“影响呢？” 后来我学会用四句话：发生了什么、影响多少、现在怎么样了、需要谁配合。 大厂通常有事故等级和 on-call 机制，P1 故障 10 分钟升级，P2 故障 30 分钟同步；小公司往往靠微信群和口头确认。 对比很明显：500 人公司复盘会看时间线和防呆动作，20 人公司容易变成“下次注意点”和“这个锅谁背”。 如果你在小公司，至少自己建一个 Jira 工单，把回滚步骤、影响范围、验证 SQL 写进去，别只靠记忆。 道歉可以放在止损之后、复盘之前，它不是操作步骤，是情绪修复，但情绪修复不能代替止血。

复盘文档只写四列，别写“责任心不强”

我现在的复盘模板只有四列：时间线、触发条件、为什么没拦住、防呆动作。 时间线精确到分钟，比如 21:47 执行、21:51 客服反馈、21:55 设只读、22:40 开始 binlog 恢复。 触发条件要写成可重复的，比如“生产库和测试库连接名太像，且生产库账号有 DELETE 权限”。 防呆动作要能验证：生产库只读账号、SQL 审核、变更窗口 22:00-23:00、单表超过 50 万行禁止直接 DELETE、分批 5000 条。 数据库变更前我固定查 6 项：SELECT @@hostname, DATABASE();、备份、影响行数预查、事务包裹、执行人+复核人、回滚脚本贴工单。 7 天后检查防呆有没有落地，没落地就再开一张工单，别让复盘文档躺在 Confluence 里吃灰。

最后说点不讨喜的

工作失误不是人生污点，它是系统漏洞的探针，但探针有代价，可能是 23.6 万美元，也可能是 412 个客户投诉。 真正拉开差距的，不是谁从不犯错，而是谁能在 15 分钟内止血，在 24 小时内说清楚，在 7 天内把同一个坑堵上。 如果你现在正犯了一个大错，先别写检讨，先确认影响面，先回滚，先同步，先找复核人。 等血止住了，再道歉，再复盘，再把防呆写进流程。 这套办法不体面，但比在群里发“对不起大家”有用得多。