回滚成本是什么
回滚不是免费选项：一次回退牵动停机时长、数据损失风险、客户影响与跨团队协调成本。评估回滚要在发布前做：维护一份不可回滚项清单，对每一项检查能否推迟、能否加开关；把这个评估写进发布评审，出问题时才不至于进退两难。
基本信息
| 直接成本 | 停机或降级时长与恢复操作的人力 |
|---|---|
| 数据成本 | 不可逆变更导致的数据丢失或修复 |
| 协调成本 | 跨团队通知、客户沟通与后续复盘 |
| 降低手段 | 减小批次、可回滚的迁移设计、平时演练 |
| 前置动作 | 发布前维护不可回滚项清单 |
| 决策线 | 影响时长乘影响用户，再乘恢复信心 |
不可回滚项清单
不可回滚项清单
发布前逐条评审：
- 破坏性 DDL（DROP / TRUNCATE） # 数据不可逆
- 已发出的对外通知或账单 # 外部动作难撤回
- 客户端强制升级的协议变更 # 用户端不可回退
- 已删除的旧镜像或旧配置 # 回滚时找不到旧版本
处理：能推迟的推迟，能加开关的加开关 # 降低不可逆性典型使用场景
- 发布评审：逐条过不可回滚项，确定决策人
- 数据库变更：先加列后删列的两步式设计降低回滚成本
- 大版本发布：评估回滚窗口与客户沟通成本
- 事故决策：回滚与前滚修复之间的选择依据
- 演练：把回滚流程练熟，缩短真实恢复时间
- 台账：维护每个服务的回滚难度与耗时参数
成本类型与评估
| 成本类型 | 评估问题 |
|---|---|
| 停机 | 回滚需要多久、期间业务是否可用 |
| 数据 | 是否产生不可逆写入、要不要修复脚本 |
| 客户 | 哪些客户受影响、通知与补偿成本 |
| 协调 | 需要哪些团队同时在岗、通知链路多长 |
| 信心 | 回滚后能否恢复原状、有没有验证手段 |
发布评审时逐条过不可回滚项：能推迟的推迟，能加开关的加开关。
默认出问题就回滚：未评估数据不可逆场景，回滚反而扩大影响。
回滚耗时要在平时演练中得出数据：事故时凭印象决策风险高。
旧版本制品与配置保留一个回退窗口：删除前确认已过观察期。