用一份清单管住上线前最后十分钟

上线那天最怕的不是代码有 bug，是十分钟里连着踩三个低级错误：配置没改、依赖版本不对、日志目录不存在。这三件事任何一件单独都不难，但在赶着发的状态下就是会漏。后来我们做了个上线上线前清单，把每一步写成一条可勾选的检查，跑完才能点发布。清单分四段。第一段是环境确认，包括目标环境变量是否指向正确集群、数据库连接串是否用了生产库、以及构建产物的 git commit 是否等于当前分支头。第三项最容易漏，因为构建机和开发机是两台，改了代码没推就直接打包，上线的其实是旧版本。第二段是依赖与配置，包括锁文件是否被意外改动、关键第三方服务地址是否还是测试域名、以及本次改动涉及的环境变量是否都在目标环境配齐。我们遇到过最坑的一次是新增了一个配置项，本地有默认值所以测试全绿，上线后读不到就崩了。第三段是数据与回滚，包括本次是否包含数据库变更、变更是否有对应回滚脚本、以及回滚后旧代码能否兼容新表结构。第四段是观测，包括关键接口的健康检查地址是否可达、错误日志是否有输出位置、以及告警规则是否已经覆盖本次新增的接口。清单本身不复杂，两百行左右的 shell 脚本加上一份人读的 markdown，重点是两个约束。一是必须能自动判定的就不靠人眼看，比如 commit 一致性、端口连通性、配置项是否存在，这些都写成脚本，返回非零就拦住。二是清单必须能被跳过，但不能被悄悄跳过，跳过要留下记录和原因。最后一条体会是清单的价值不在覆盖多少项，而在于它把发布前的判断从凭记忆变成了可复查的流程。人紧张的时候会忘，脚本不会。