工作失误了怎么办？我先说个反常识的：别急着写检讨，先算“发现时间差”

2023年4月12日晚上，我在一家做母婴电商的公司，负责把抖音小店订单导出到ERP。 订单表18,642行，我用VLOOKUP匹配SKU编码，第四参数顺手写了TRUE。 结果237行匹配到近似值，比如SKU 10086-A匹配到10086-AB，仓库发错63单，客单价89到219元，退款加补发大概1.1万元。 更糟的是第二天10:20客服群才有人问“为什么奶瓶变成奶嘴”，时间差13小时40分。 微软支持文档写得很清楚，VLOOKUP第四参数0或FALSE才是精确匹配，TRUE是近似匹配，还要求首列升序。 从那以后我不信“细心点”这种话，人就是会错，关键是错误多久被发现。

另一个失误：SQL误更新137行，为啥23分钟就恢复了

2022年11月17日，我在另一家公司做数据修正，MySQL生产库执行UPDATE时忘加WHERE。 原意只改1条测试账号的status，结果影响137行正式用户，监控5分钟后报警。 我们binlog格式是ROW，保留7天，开发用mysqlbinlog --start-datetime='2022-11-17 22:35:00' --stop-datetime='2022-11-17 22:42:00'解析反向SQL。 23分钟恢复完，业务侧只暂停了7分钟写入。 对比Excel那次，没有事务、没有回滚，Ctrl+Z还不能跨保存，破坏力完全不一样。 所以我的怪观点是：失误成本=影响半径×发现时间差÷可回滚程度，别只盯态度，先看系统有没有undo。

真出事了，按这5步走，别先解释

1 10分钟内冻结影响面：停止发货、停止群发，相关文件另存为只读，文件名加_frozen_20230412。 2 拉时间线：飞书或企业微信聊天记录搜关键词，精确到分钟；Windows里右键Excel文件看属性里的修改时间。 3 定量：SQL用SELECT COUNT(*)确认行数；Excel用=SUBTOTAL(103,区域)看筛选后行数，别用眼睛数。 4 找可回滚点：MySQL看binlog，Git看git reflog，飞书审批看撤回按钮，不同版本时限不一样，通常是24小时内。 5 对外沟通只讲三件事：现在影响谁、什么时候恢复、下次怎么防，不要写“我太粗心了”，那是情绪不是信息。

预防：我搞了个“失误账本”，比检讨书有用

字段就8个：发生时间、触发动作、发现路径、影响行数或单量、金额、修复耗时、根因、预防成本。 VLOOKUP那条：触发动作=第四参数TRUE，发现路径=客服群，影响63单，金额1.1万，修复4小时，根因=精确匹配没锁死，预防成本=0。 具体做法是把公式模板第四参数写死0，再加一列=IF(ISNA(...),0,...)，上线前随机抽20行核对。 SQL那条：触发动作=UPDATE无WHERE，发现路径=监控报警，影响137行，修复23分钟，预防成本=低。 做法是执行前先BEGIN; SELECT ... FOR UPDATE; UPDATE ... WHERE id=...; COMMIT;，生产账号不给全表UPDATE权限。 工作失误不是人品判决书，它是系统漏洞的收据，你把它交上去，别只交检讨。