release-rolloutlisted

# release-rollout：发布与回滚预案 > 硬前提：**没有演练过的回滚步骤不算回滚方案**。真到要回滚的那一刻，没人有时间现想。 ## 产出 `dev/release/发布与回滚预案-{项目}-V{版本}.md`（存量项目文档在 `docs/` 时按实际目录，不搬家）。 一次发布一份，版本号与本次发布的版本一致。 ## Step 1：盘点变更面（五类分开，回滚方式不同） | 类别 | 举例 | 回滚方式 | 可逆性 | |---|---|---|---| | **代码** | 服务镜像、前端产物 | 切回上一个镜像 tag／产物版本 | 可逆（分钟级） | | **配置** | 环境变量、网关路由、限流阈值 | 改回旧值并重载 | 可逆，但**要记下旧值**，没记就回不去 | | **数据** | 迁移脚本、数据清洗、字段语义变更 | 见 Step 4 的 expand-contract | **默认不可逆**，要专门设计 | | **契约** | 接口入参出参、消息体、错误码 | 双端同时回滚，或前向兼容一个版本 | 单端回滚会把另一端打挂 | | **依赖** | 第三方 SDK、外部服务版本、基础镜像 | 钉版本回退 | 看对方是否保留旧版本 | **输出一张变更清单**：每行写「类别 / 具体项 / 回滚方式 / 回滚耗时 / 有没有演练」。 ## Step 2：灰度批次与开关 - **默认全部新功能挂开关（feature flag），开关默认关**——「发布」与「放开」分成两件事， 出问题先关开关（秒级），而不是回滚镜像（分钟级） - 批次按「影响面从小到大」排：内部账号 → 1% → 10% → 50% → 100%，每批之间留**观察窗口**（最短一个完整业务周期） - 每批写明：放量比例、观察时长、**放行判据**（指标全绿才进下一批）、谁点这个按钮 - 无灰度能力的小项目（单实例部署���照实写「不具备灰度，按低峰期整体发布」，不要编一个假的灰度方案 ## Step 3：监控指标与阈值 每条指标必须四要素齐全，缺一条就等于没有监控： | 指标 | 数据来源 | 观察窗口 | 回滚阈值 | |---|---|---|---| | 接口 5xx 率 | 网关日志 / `/metrics` | 发布后 10 分钟 | > 1% 持续 2 分钟 | | 关键接口 P95 | APM / 日志 | 10 分钟 | 比基线高 50% | | 业务成功率（下单/发布/登录） | 业务日志埋点 | 30 分钟 | 低于基线 5 个百分点 | | 错误日志突增 | 日志平台 | 10 分钟 | 同比 3 倍 | **基线必须是发布前实测的值**，不是拍脑袋的数字；没有监控系统的项目写明「人工看日志 + 手动跑冒烟用例」并给出用例编号。 ## Step 4：回滚触发条件与步骤 **触发条件分两类**，写清楚谁有权拍板： - **自动/无需商量**：命中 Step 3 任一回滚阈值、数据出现错误写入、核心链路不可用 → 立即回滚，事后复盘 - **人工判断**：非核心功能异常、影响面可控 → 值班人 + 负责人两人确认，可选择"关开关"而不是整体回滚 **回滚步骤**写成可照做的命令清单（含数据层），细则与模板见 `references/rollback-playbook.md`： 1. 关功能开关（如果问题在新功能） 2. 切回上一版本镜像／产物，确认健康检查通过 3. 配置回退（对照 Step