不可逆操作：预演、快照、冷却与一个人的双人复核

双人复核的本质不是多一个人，而是多一次停顿。

一、二百一十四行的预演

2026 年 8 月的一个周四晚上，一位同事离职，他要把对方名下的任务转给接手的人。他写了一条更新语句，按项目筛选，准备把负责人改成新同事的账号。执行前他加了一句 SELECT count(*)，屏幕返回 214。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

他本来预期是 40 条左右：两个项目、未完成的任务。214 这个数字说明筛选条件漏了东西——漏了状态，也漏了那个已归档的项目。如果直接执行，已完成的 174 条任务会被重新打开，负责人全部换掉，客户第二天会在活动记录里看到一片「负责人已变更」。

离职交接本来就是批量操作最密集的一周：任务、项目、评论、附件归属分散在四张表里，每一张都要转。他那天已经连续改了三个脚本，越改越顺手，手比脑子快的那一下，正好落在最大的一张表上。

他停下来，把条件补齐，重新预演，这次是 40 行。真正让他后怕的不是写错 SQL，而是如果没有那句预演，他会在凌晨一点按下回车，然后在第二天早上才发现。

一个人没有第二双眼睛。公司里的双人复核靠的是「另一个人看一眼」，一个人只能把这一眼拆成四个机械动作：先看影响范围、再留一份能回去的副本、再要求自己打出对象的名称、最后给删除留一段冷却期。

这四个动作合计 4.7 分钟一次。它们替代不了判断力，但能挡住绝大多数「手比脑子快」的事故。

214 与 40 之间差的不是 174 条任务，是一个筛选条件。预演的价值就在于把那 174 条提前摆到眼前，让「我大概知道影响哪些」变成「系统告诉我影响哪些」；这两种认知之间，隔着的就是一次事故。

二、四件套：把第二双眼睛拆成四个动作

第一件是预演。任何写操作之前先跑一次只读版本：批量更新跑 SELECT count(*) 并把前 20 行的前后值打出来；删除跑关联查询，看清子表会被连带删掉多少行；迁移跑 dry-run，看要加什么锁、回填多少行。

第二件是快照。操作前把受影响的表复制一份，或者做一次表级逻辑导出。12 秒的成本，换的是一个明确的回滚点；没有快照的「小心一点」不是保护，是祈祷。

快照用哪种做法看表的大小。小于 1 GB 的表直接 CREATE TABLE tasks_bak_20260813 AS SELECT * FROM tasks，秒级完成；大表用表级逻辑导出，只导受影响的几张表，不导整库。判据是「恢复时能不能只回这张表」——能，就不要把整个库拖进来。

第三件是输入名称确认。脚本要求手动输入被操作对象的名称，例如租户标识或项目名，输错就不执行。这一条专门防「连错了环境」：测试库和生产库的终端长得一模一样，yes 打不出区别，名称可以。

名称不许从当前目录或环境变量自动带出来，必须手打。脚本第一次运行会打印「即将操作：租户 acme、项目 迁移测试、预计 40 行」，要求输入 acme/迁移测试 才继续；连错三次直接退出，把「手滑」变成「重新来一遍」。

第四件是冷却。删除不做物理删除，只写 deleted_at；24 小时内列表里能看到「已删除」并一键恢复，定时任务在第 25 小时才真正清掉。批量更新则用分批加观察：每 50 行提交一次，中间停 60 秒看一眼错误率。

软删除要改两处才成立。一是所有业务查询加 deleted_at IS NULL，用视图兜住比逐条改 SQL 可靠；二是唯一约束换成部分索引，否则删掉的项目名会一直占着，重建同名项目时报唯一冲突。这两处不改，软删除会在半年内被抱怨到改回去。

四件里最便宜的是快照，最容易被跳过的是预演。人会觉得「这条语句我写过一百遍」，可出事的往往不是语句本身，而是那一天的数据形状变了：多了一个归档项目，多了一个同名租户，多了一列非空约束。

还有一个不花钱的动作：把危险语句写进脚本文件，不在终端里手敲。脚本可以 review、可以进版本库、可以带参数校验；手敲的 UPDATE 没有历史，出错后连自己执行了什么都要靠猜。

三、四类操作各自的预演、快照与冷却

不可逆路径有五条：结账、订阅变更、导出、删除账号、权限变更。落到具体动作上，是四类：删除、批量更新、schema 迁移、权限变更。每一类的预演内容与冷却方式都不同，套同一份模板反而会漏。

删除类的预演要连子表一起数。外键上的级联删除会把「删 1 行项目」变成「删 40 条任务加 312 条评论」，只看主表会低估两个数量级；预演语句里写三个 count，分别对应项目、任务、评论。

删除类最需要冷却，因为它没有「部分成功」这个中间态。软删除把不可逆变成可逆，代价是每个查询都要带 deleted_at IS NULL，漏一处就会在界面上看到已删数据。他用一个视图兜住这件事，应用只查视图，物理表只给后台任务用。

批量更新最需要预演，因为它的影响面是一个集合。分批提交的意义不只是减小锁，而是把「一次大错」拆成「二十次小错」——第一批之后看到错误率异常，后十九批可以不跑。

批间那 60 秒看三个指标：应用错误率、数据库锁等待数、只读副本延迟。前两个涨说明写错了或锁重了，第三个涨说明这批写得太快；三个都平，再跑下一批。指标从监控面板上看，不靠感觉。

schema 迁移最需要快照，因为它的回滚脚本往往比重写一遍还难。加列容易，删列难；改类型容易，改回去可能丢精度。所以迁移一律「先加新列、双写、回填、切读、最后删旧列」，每一步都可停。

迁移的预演还要看锁。给大表加带默认值的列、改列类型、加索引，各自持有的锁与耗时不同，是否重写全表取决于数据库版本，以官方文档为准。预演阶段在影子表上跑一遍，记录耗时；超过 5 秒的迁移不进高峰发布窗口。

权限变更最需要审计，因为它的错误不会立刻报错。一个人被误授管理员，系统一切正常，直到某天他点了一个不该点的按钮。角色矩阵的前后对比要落进审计日志，24 小时内可撤销，撤销动作本身也要记录。

做法很土但有效：变更前把「账号 × 角色」矩阵导成一张三列表，变更后再导一张，用 diff 比对。预期是两行变化，实际变了九行，就说明脚本的筛选条件又漏了——这一招和第一节的预演是同一个思路，只是对象从任务换成了权限。

四、四点七分钟、零点九四小时与六点零六小时

单次成本拆开：预演 4 分钟、快照 12 秒（0.2 分钟）、输入名称确认 30 秒（0.5 分钟），合计 4.7 分钟。预演占了大头，因为看清影响范围本来就需要时间；快照与确认便宜到没有理由跳过。

一年按 12 次不可逆操作算：12 × 4.7 = 56.4 分钟，合 0.94 小时。此前两年的记录里，这类误删平均每年 2 次，每次从备份恢复到可用状态 3.5 小时，合计 7 小时。

复算：
单次 = 预演 4 + 快照 12 秒 ÷ 60 + 确认 30 秒 ÷ 60 = 4 + 0.2 + 0.5 = 4.7 分钟
年成本 = 12 × 4.7 = 56.4 分钟 = 0.94 h
误删损失 = 2 次 × 3.5 h = 7 h
净省 = 7 − 0.94 = 6.06 h

预演那 4 分钟花在哪：写只读版本的语句 1 分钟、跑 count 并核对数量 1 分钟、抽前 20 行看前后值 1 分钟、确认没有别的租户被命中 1 分钟。四步都做完才叫预演，只跑一个 count 不算。

一年 12 次是这么数出来的：删除 5 次、批量更新 3 次、schema 迁移 2 次、权限变更 2 次。发布频率是每月一次，但不可逆操作并不跟发布同频，所以按月摊会低估；按去年的操作记录数一遍更准。

6.06 小时不是这套流程的主要收益。真正的收益是「敢操作」：有了预演和快照，50 行的清理敢做，200 行的迁移敢排进发布窗口；没有它们，所有不可逆操作都会拖到「哪天有空再说」，然后在那天最困的时候做。

误删 2 次这个数字值得单独说。它不是流程跑起来之后的统计，而是流程之前的历史：一次删错了项目，连带 60 条任务；一次把测试租户的清理脚本跑在了生产上。两次都靠前一夜的备份恢复，每次 3.5 小时，期间的工单只能手工回。

冷却期也有成本：用户点了删除，24 小时内数据还在，要占用存储，也要在隐私说明里讲清楚。他的处理是把冷却期写进产品文案——「删除后 24 小时内可恢复」，用户看得见，也就不算暗箱。

快照要定期真恢复一次，否则它只是硬盘上的一个文件。每季度挑一份两周前的快照，恢复到临时库，跑三条查询确认行数、约束、索引都在；恢复失败的快照比没有快照更危险，因为它会让人误以为有退路。

五、行动清单与复算验收

把四件套固化进脚本，再用八条检查确认每一次不可逆操作都留下了退路。

清单按操作的时间顺序排：先预演、再快照、再确认、再执行、最后看冷却。顺序颠倒过来也能跑，但会失去意义——先执行后快照，快照里存的就是错的数据。

• 所有写操作先跑只读预演，打印影响行数与前 20 行前后值
• 批量更新按项目与状态双重筛选，预演行数与预期不符就停
• 操作前对受影响表做逻辑快照，快照文件带时间戳与操作名
• 危险语句写进脚本文件，带参数校验，不在终端手敲
• 执行前要求输入租户或项目名称，输错立即退出
• 删除一律软删除，24 小时内可恢复，第 25 小时才物理清理
• 批量更新分批提交，每批 50 行，批间观察错误率
• 权限变更落审计日志，保留变更前后的角色矩阵

验收标准：任意一次不可逆操作都能在 10 分钟内回到操作前的状态，且预演显示的影响行数与实际执行行数一致。

使用边界与实操验收

边界一：软删除不是备份。 冷却期只覆盖 24 小时内的误删，覆盖不了逻辑错误、批量污染与勒索类事件；备份策略与恢复演练属于运维组的范围，本篇只讨论操作前的那一道停顿。

边界二：预演的行数不等于影响面。 count(*) 数的是主表命中行，触发器、级联删除与异步任务的实际影响可能更大；涉及级联时要把子表行数一起预演，必要时在影子库上真跑一次。

边界三：schema 迁移优先用工具，不手写。 迁移框架能给出 dry-run、版本号与回滚路径，具体语法与限制以官方文档为准；本篇的四件套是对工具流程的补充，不是替代。

边界四：本文的耗时、次数与损失均为教学假设。 12 次/年、每次 4.7 分钟、误删 2 次各 3.5 小时都来自一个人的历史记录，换一个产品会完全不同；本文不构成对任何数据恢复能力的承诺。

关键参考与核验范围

• PostgreSQL BEGIN ：用于核对批量更新与迁移放在单事务里、失败整体回滚的写法与限制。
• PostgreSQL EXPLAIN ：用于核对预演阶段如何用执行计划估算扫描行数与锁范围。
• GitHub Actions 工作流语法 ：用于核对生产操作走手动触发与环境审批的配置方式。
• The Twelve-Factor App ：用于核对管理类任务与常驻进程使用同一套环境与配置的原则。

以上链接于 2026-10-26 实测可公开访问；未核验版本、价格与配额。核验日期：2026-10-26。

范围声明：本文只讨论单人团队在删除、批量更新、迁移与权限变更上的操作纪律，不讨论数据库高可用、备份介质与灾难恢复演练；这些属于运维组的范围。

系列导航

• 回到本组目录：一个人的质量守门：验证预算、回归清单与发布门禁
• 上一篇：测试数据与假依赖：一个种子、四个替身与三列脱敏
• 下一篇：验证的边际收益：什么时候可以不写测试
• 相关：数据模型与迁移：三十四张表与一次只能动一处的改动