DRY-RUN:先空跑一遍,再动真格

一次真实的误写事故

这条规矩不是我们凭空想出来的,是撞出来的。我们的产线上曾有四个老的入库脚本,不加任何参数就直接写生产库——而且真的误写过:操作的人以为自己在做"预演",看一眼将要写什么,实际上那一眼看到的内容已经进了生产库。

事故本身不复杂,复杂的是它暴露的机制:出错的不是某个人不小心,而是默认行为的方向放反了。脚本的默认动作是"写",谨慎才需要额外记住什么——那么只要操作次数够多,总有一次会忘。

事故之后,所有写库脚本全部补上了 DRY-RUN 默认模式,一个不漏:不加参数,只打印"将要写入什么"的清单;真正入库,必须显式加 --apply。

两条比事故更重要的规则

从这次事故里提炼出来的东西,比事故本身更值得带走:

第一,默认值就是安全线。 不是"提供一个 dry-run 选项",而是"默认就是 dry-run,真写才需要额外动作"。人在疲劳、赶时间的时候,永远会用默认行为——那就让默认行为不可能造成损失。安全不该依赖"记得住",该依赖"忘了也没事"。

第二,闸门要在所有写操作之前,不是大部分。 假如四个脚本只补了三个,剩下那个就是下一次事故的入口——因为你会习惯性地以为"我们的脚本都是默认预演的"。所以我们补的时候是全量补,你也应该是:排查一次,列全清单,一个不漏。

换别的工具怎么做

这条原则完全不依赖任何特定工具,它只关心一件事:在不可逆动作之前,插入一个完整但无后果的预演步。

• 你的"写操作"是发公众号?DRY-RUN 就是先存草稿、用预览链接从头读一遍。
• 是覆盖一个多人共享的文档?先另存副本,diff 对比新旧两版,确认后再替换。
• 是给客户群发邮件?先只发给自己,收到后以收件人视角检查,再放开名单。

形式随工具变,结构不变:预演 → 看输出 → 明确确认 → 执行。

🔧 动手做:给你的不可逆环节立规矩(8 分钟)

1. 列出你产线(或日常工作)里所有"做了就收不回"的环节:发布、覆盖、入库、群发、删除……至少找出 1 个,能找 3 个更好。
2. 为每个环节写一条规则,格式固定:"环节:。默认行为:只预演,输出'将要做什么'清单。真正执行的条件:(一个明确的额外动作)。"
3. 挑其中一个环节,模拟执行一次:走完预演,看输出,确认无误,再真做(或者今天就停在预演这一步,也算完成)。

你会看到:至少一条书面的 DRY-RUN 规则,以及一次亲手走过的"预演 → 确认 → 执行"完整流程。

为什么:规则只有写下来、走过一遍,才会在你下次赶时间时真正生效。这一步是把"我知道要谨慎"变成"我的默认流程就是谨慎"。