Update 风险分级:9 个信号决定签字单长什么样

Update 这件事的核心矛盾是:你既要快(每天甚至每小时迭代),又要稳(失败不能丢数据 / 不能停服 / 不能误操作)。这两者天然冲突。

我们的解法是:把每次 Update 自动算一个「风险等级」,根据等级动态调整签字单严苛程度。低风险 1 秒过、中风险加条款、高风险 60 秒硬挡。

9 个信号

扫描器对比新旧描述符,触发以下任一信号:

• runtime_changed — Node.js → Python 这类运行时大类变化(几乎一定要 yellow)
• runtime_version_jump — node 18 → 20 主版本号跨越
• start_command_changed — 启动命令从 pm2 改成 systemd 等
• port_changed — 服务监听端口变化
• new_required_env — 新增必填环境变量(缺值启动失败)
• pre_deploy_added — 新增 pre_deploy 钩子
• pre_deploy_has_unreversible — 包含 DROP COLUMN / RENAME TABLE 等不可逆操作
• breaks_api — API 破坏式变更(删字段 / 改返回类型;由发起者声明)
• major_dep_bump — 关键依赖主版本升级(react 17 → 18)

三级映射

Green · 低风险

单条信号 ≤ 1,默认签字模板,签字框 + 一句「我已确认」,没有倒计时,通常 5 秒过。

Yellow · 中风险

≥ 2 条信号,签字单加额外条款(比如「我确认新增的 NEW_ENV 已在 Vault 中正确配置」),健康检查窗 ×1.5(45s)。

Red · 高风险

≥ 5 条信号 / 含不可逆操作,签字单顶部 60 秒倒计时硬挡(不到时间提交按钮变灰),专属确认短语(不是「我已确认」而是「我已读懂三条 X / Y / Z 不可逆操作的后果」),失败时不自动回滚(因为已经改了数据库 schema),由你人工裁决。

我们不替你决定该不该上这个 Update。但我们能让你不在凌晨 3 点手抖点错按钮的时候搞砸事情。

为什么 60 秒?

心理学。人在 60 秒内会更倾向于反思「我真的想好了吗」,而不是「快点跑完吃饭」。3 秒太短(纯惯性),5 分钟太长(用户开始烦)。60 秒是一个让你不冲动、又不会被拖累的甜蜜点。