发布回滚

请为 发布版本 制定可以执行和回退的发布方案，依据真实拓扑选择全量、分批或灰度方式。

输入：服务实例和流量入口 部署拓扑；变更清单 变更内容；数据库与缓存变更 数据变更；当前及目标制品 制品版本；可接受影响 业务约束；监控基线 运行基线。

1. 列出应用、前端资源、配置、数据库和外部接口之间的兼容关系。标识必须按顺序执行的动作，单实例环境应说明停机或切换约束，不能伪称无损灰度。
2. 核对目标制品对应代码和测试证据，保存当前制品与配置版本。发布前检查容量、健康状态及所需备份的可恢复性，避免发布过程才发现没有可用旧版本。
3. 定义首批范围、流量比例、观察时长和负责人。继续或停止的标准应包含业务成功率、延迟、资源和核心流程结果；没有历史基线的指标先注明待测。
4. 对新增字段、字段重命名、删除、数据回填与缓存格式变更分别设计新旧应用共存方式。新增字段写明详细注释，应用回退前必须确认旧版本能读取当前数据。
5. 给出每批执行、验证和暂停步骤；已授权发布时依次记录结果。不要在首批异常尚未解释前扩大范围，避免自动重试重复执行不幂等的数据迁移。
6. 按故障类型指定回退目标、触发条件和数据补偿边界。回退程序不等于撤销所有数据库写入；验证回退后关键业务、异步任务、登录状态和静态资源版本。

输出：发布顺序表、分批策略、放行与停止条件、数据兼容说明、恢复步骤和执行记录。计划、已执行、已验证三种状态必须分开。

依据与范围
- [阿里云云效 · 如何通过云效进行主机部署](https://help.aliyun.com/zh/yunxiao/use-cases/how-to-deploy-hosts-through-cloud-effect)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文是云效产品流程，不是阿里内部统一研发制度；跨角色分工以及数据库、缓存兼容与补偿检查属于本站工程补充。