发布就绪评审是什么
发布就绪评审（Release Readiness Review）是上线前的最后一轮系统检查：测试覆盖与结论、遗留缺陷、性能与容量、监控告警、回滚与应急预案、数据兼容等逐项确认，由产品、开发、测试、运维共同给出可发布结论。它不是形式签字，而是把已知风险摆上台面，让发布决策有依据、有记录。
基本信息
| 参与角色 | 产品、开发、测试、运维，关键检查项各有负责人 |
|---|---|
| 核心检查 | 功能测试结论、回归范围、遗留缺陷清单、性能指标、数据迁移验证 |
| 风险准备 | 回滚方案与预计时长、降级开关、应急预案、值班安排 |
| 观测准备 | 监控与告警覆盖新功能、日志可查、看板就绪 |
| 输出物 | 就绪检查表、风险声明、遗留问题清单、发布与回滚步骤 |
| 判定标准 | 关键项全部通过；未通过项须有明确的风险接受人 |
典型使用场景
- 大版本上线：逐项过检查表，避免一句测试过了带过全部风险。
- 跨团队发布：多系统联动变更时，确认各方依赖顺序与时间窗口。
- 回滚准备：确认回滚步骤演练过、数据兼容、有明确触发条件。
- 遗留缺陷决策：带缺陷上线时逐条评估影响面与规避手段并确认。
- 值班交接：把新功能风险点、观测指标与应急联系方式交给支持团队。
检查域与失败后果
| 检查域 | 关键问题 | 不通过的典型后果 |
|---|---|---|
| 测试结论 | 覆盖范围与通过率、回归是否执行 | 漏测功能上线后故障 |
| 遗留缺陷 | 高危是否清零、低危是否有规避手段 | 用户侧复现阻塞问题 |
| 性能容量 | 压测结论与生产容量是否匹配 | 高峰时段服务不可用 |
| 回滚预案 | 步骤可执行、数据可回退、有触发条件 | 故障时无法快速止损 |
| 监控告警 | 新功能指标与日志是否就绪 | 故障发现靠用户报障 |
检查表要随事故演进：每次线上事故后，把漏掉的检查项补进清单。
未通过的检查项不等于不能发布：但必须记录风险、指定接受人并通知相关方。
评审要前置：当天才发现缺监控或数据没准备好，已经没有修复时间。