读完《清单革命》，我删掉了八成检查项

那次回滚结束时是凌晨两点四十。复盘文档里，我写下第四遍「发布前确认数据库迁移已执行」——前三次它就躺在我们 wiki 的检查清单里，只是没人打开。

清单本身没有失效，失效的是「把它放在一个需要人主动想起来的地方」这个做法。我把那本书从书架上抽出来，本来只想找个说法去说服同事，结果先被说服的是我自己。合上书之后的三个星期，我做了三件具体的事。

清单分两种，我一直用错那一种

书里把清单分成两类：一类是「读—做」，一项一项念着往下做；一类是「做—读」，先把事情干完，再回头核对有没有漏。我们那份 wiki 清单是典型的「做—读」，适合事后核对，却被我用在了顺序敏感、步骤之间还有依赖的发布流程上——数据库迁移没跑，后面的服务重启就没有意义，但清单不会拦住你。

改法很土：把清单从 wiki 挪进发布脚本，每一步都停下来等人确认。

#!/usr/bin/env bash
set -euo pipefail

step() {
  echo
  printf '▶ %s\n' "$1"
  read -r -p '  确认后回车，发现问题按 Ctrl-C：' _
}

step '迁移任务已成功：kubectl get job migrate -o wide'
step '回滚用的镜像 tag 已记在上面那条输出里'
step '值班同学知道这次发布'

关键在于 read：它不让你一口气跑完。脚本执行到一半停下来，光标在等，你就必须抬头看一眼刚才那行输出。

代价是发布变慢了，一次多发三五分钟。收益是这几周里我没再遇到「漏了一步但没人发现」的情况——具体多少次我懒得统计，但复盘文档里已经很久没出现那句重复的话了。

顺带一提，把清单放进仓库还有一个副作用：它会出现在 PR 的 diff 里。改检查项成了要 review 的动作，而不是某个人在 wiki 里悄悄加一行。

别再加检查项了，加一个暂停点

我过去的条件反射是：出了问题就加一条检查项。几年下来清单三十来条，副作用是没人读得完，读到第十条就开始往下滑。

书里提到在关键节点设「暂停点」，这个概念我拿去用了，但改了自己的用法：暂停点不是多一条检查，而是一段必须空出来的时间，只问三个问题。

• 这次动的到底是什么？不是「发个版」，而是哪个服务、哪个字段、影响哪批用户。
• 坏了怎么退，退的这一步我亲手做过吗？
• 除了我，还有谁需要现在就知道？

第二问最值钱。有好几次我发现回滚方案好好写在文档里，但那条命令我从没跑过，连参数都对不上。

这个做法有个明显的代价：暂停点很烦人。一周发五次之后，从第三次开始，就有人在暂停里直接敲回车。所以我后来把暂停点只放在不可逆的动作前面——迁移、删数据、改权限、对外公告；可逆的动作一律不加，让它可以快。什么算不可逆，这条线我还在调，目前偏保守。

砍掉能自动检测的，剩下的才写进清单

书里有一个判断我印象很深：清单不是操作手册，它只覆盖「容易漏、漏了又很贵」的那一小块。按这个标准过一遍，我删掉了一大半。

删的标准按顺序问三条：

1. 这条能不能被脚本检测？能，就删掉，改成 CI 里的一项检查。比如「镜像 tag 是不是 latest」「配置里有没有指向测试库的地址」——这种写进人读的清单纯属浪费注意力。
2. 过去半年这条真漏过吗？没漏过、漏了也不致命，删。
3. 这条是不是在描述「应该想清楚」？比如「确认需求理解无误」——不可验证，删。

三十来条最后剩下八条。八条里没有一条是机器能查的，全是「机器不知道你心里怎么想」的东西：这次变更有没有人必须提前知道；灰度的观察窗口有没有人在盯；真出事时谁拍板回滚。

清单的长度上限不是「能写多少」，而是「别人愿意读完多少」。我现在按一屏之内来卡，超了就砍，或者拆成两份互不依赖的。

还有一件事我没定下来：清单归谁维护。现在是我在改，我休假那周它就停在原地。理想状态是谁用谁改，但真放开了，两周就会被加回二十条。暂时的办法是每次复盘只允许净增零条——想加一条，先删一条。这条规则能不能撑过下个季度，我没有把握。

下周一我准备把值班那份清单也搬进仓库，先砍到十项以内。你手上如果也有一份没人打开的清单，不妨先数一下它有几条。