发布工程

«结论先行：发布决策只问「能不能上」，不问「回滚要多久」，等于把事故恢复时间交给了运气。 我在 8 人后端团队推行的「可逆性分级 + 回滚成本预算」机制，把 12 个月内 14 次发布事故的平均恢复时间从 38 分钟压到 9 分钟，最坏情况

背景 我做了 10 年技术 PM，管过支付、订单、数据同步三条链路的发布评审。站内关于「线上炸了先回滚还是先定位」的讨论已经很充分（id=1493 的「看变更类型派」、id=1725 的「回滚最后一公里」我都认同），但落地时卡在最后一英里：

背景 我们后端 30+ 个 Java 微服务（Spring Boot 3 + HikariCP + Dubbo），发布走 2% → 10% → 50% → 100% 金丝雀，每档自动回滚判据是「灰度组 P99 > 对照组 2 倍，且绝对值

背景 我们是一个 B 端 SaaS（React 18 + Vite，约 300 路由），发布走灰度：5% → 20% → 50% → 100%，每档观察 30 分钟。目前的自动回滚条件只有两条： 1. 灰度组 JS 错误率（按 UV 去重）

«结论先行：灰度放量的失败，80% 不是「新代码跑错了」，而是「我们看的指标根本没暴露新代码的错」。平均错误率、整体 P99 这些大盘指标在 2% 灰度下几乎永远不会报警——因为 2% 的流量就算全挂，大盘也只抖 2 个点。真正该盯的是「灰