演示跑不过夜：一次仿真环境卡死后，我们把 preflight 挪到了 CI

上个月给一个团队交付了一个仿真环境的自动化脚本，交付前最后一轮演示跑批，凌晨两点半挂了。日志只有一行超时，环境直接锁死，第二天早上我们对着屏幕重装了一整套依赖。复盘时大家很沉默，因为这个问题其实「早就预防过」——runbook 里写着的。

问题出在 runbook 本身。那份 40 多步的开跑 checklist 躺在共享文档里，标注着「执行前核对」。但那次演示前走查的人负责写脚本，实际点运行的是做演示的同事，两个人对「核对到位」的理解差了一厘米：文档说仿真器的时区要和日志时区对齐，走查的人按本地机器时间核的，没算演示机在海外机房、时差 8 小时。凌晨超时的时候他人在家。

我们做的改动很小：**把 checklist 从共享文档挪进仓库，做成 CI 里必须跑绿的 preflight gate。**

1. 每个仿真配置文件带一个 `preflight.json`，声明时区、数据路径、依赖版本

2. CI 里跑一个 dry-run：加载配置、构造 pipeline、跑 2 个 step，不写盘，只验「这条路能不能通」

3. dry-run 的输出（单 step 耗时、数据样本数）直接贴进 PR 描述，merge 之后才能进正式排期

4. 排期时调度器比对该配置 dry-run 的实测耗时，超预算直接拒

第二个价值是交接。那位负责演示的同事接手时，不用再猜我们当时为什么这么配——每个配置旁边都跟着它 dry-run 的实测数据，比口头交接准。

第三个价值是**它逼着 runbook 瘦身**。原来 40 步里能自动检查的占了 30 步。挪进 CI 之后，剩下要人脑记的只有 8 条，其中 3 条是关于客户业务的，跟工程无关，后来挪进了客户自己的 wiki。

踩的坑：dry-run 最初用 mock 数据，正式跑批的真实数据里有个超长样本，导致 dry-run 通过、实跑超时。改成「真实数据的 header + 随机填充」之后再没出现。成本是多花了 20 分钟搭数据管道，但比凌晨两点重装环境便宜多了。

数字

- 交付周期从 11 天压到 7 天（省掉了两次卡死重装）

- 演示前置检查从 40 步手工核对降到 1 条 CI 状态

- preflight.json 现在 12 个配置共用一套 schema，新增一个任务的检查成本约 15 分钟

教训很朴素：**写给别人看的清单，默读会打折；写进流水线自动跑的检查，不会。** 不是所有步骤都适合自动化，但适合的那部分趁早挪走，runbook 才能短到让人真的去读。