Update 风险分级:9 个信号决定告知多严

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

我们的解法是:把每次 Update 自动算一个「风险等级」,按 severity 分色如实告知影响,告知力度随等级递增。低风险一眼看完即可继续,中风险多列几条需你确认的影响,高风险逐条告知后果。只有「硬不可逆」项才真阻断,其余知情授权即可继续 — 不卡脖子。

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,绿色提示,影响一眼看完,勾选知情授权即可继续,无阻断。

Yellow · 中风险

≥ 2 条信号,黄色提示,逐条列出需你确认的影响(比如「新增的 NEW_ENV 需已在凭据托管中正确配置」),知情授权后继续,健康检查窗 ×1.5(45s)。

Red · 高风险

≥ 5 条信号 / 含不可逆操作,红色提示,逐条告知 X / Y / Z 不可逆操作的后果。只有「硬不可逆」这一类项目才真阻断、必须显式处理;其余项目知情授权即可继续。Red 段失败时不自动回滚(因为已经改了数据库 schema),需人工裁决。

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

失败回滚怎么办?

失败自动回滚靠部署前的版本快照备份点 + 健康检查(Pro / 交付版能力),回滚到上一可用版本;它属于 Update 语义,且我们不承诺成功率。Bootstrap 首次失败是清理重来、不回滚;Red 段含不可逆 schema 变更时同样不自动回滚,需人工裁决。