回滚计划是升级前必须闭环的关键环节，需明确定义触发条件、验证可执行脚本、隔离存储带上下文的版本资产、支持秒级流量切换。
软件包升级回滚计划不是“出了问题再补救”的备选动作，而是升级前必须闭环的关键环节。它直接决定一次更新是平稳过渡，还是演变成线上事故。
回滚触发条件要定义清楚
不能只写“出问题就回滚”，得明确哪些指标异常算真正需要回滚。比如：
- HTTP 5xx 错误率连续5分钟超过3%
- 核心接口平均延迟升高50%且持续2分钟
- 数据库连接池耗尽或事务失败率突增
- 健康检查端点连续3次失败
这些阈值需结合历史基线设定，避免误触发，也防止漏判。
回滚操作必须可验证、可执行
写在文档里的“执行旧版本启动脚本”没用，得确保它真能跑通：
- 回滚脚本需与升级脚本同级存放，命名带版本号（如 rollback-v2.1.3.sh）
- 脚本内包含前置检查（如确认旧版本二进制/配置是否存在）和后置校验（调用 /health 端点并断言返回200）
- 每月至少一次在预发环境实操演练，记录耗时与失败点
版本资产要隔离存储、带完整上下文
回滚失败常因找不到可用旧包。关键不是“备份了”，而是“随时能精准拉取”：
- 每个发布版本对应唯一制品ID（如 app-2.1.3-20260610-1422），存于私有制品库（Nexus/Artifactory）
- 包内附带元数据文件：构建时间、Git commit hash、依赖清单（mvn dependency:tree 输出）、配置变更摘要
- 禁止覆盖上传，旧版本永不删除；生产环境仅允许从制品库拉取，禁用本地路径引用
流量切换机制要支持秒级切回
回滚不仅是换代码，更是切流量。响应速度决定业务受损程度：
- 使用负载均衡器权重控制（如 Nginx upstream 中旧节点权重从0恢复为1）
- 服务网格场景下，通过 Istio VirtualService 快速修改路由权重或 host 匹配规则
- Kubernetes Deployment 场景，保留旧 ReplicaSet 并用 kubectl rollout undo --to-revision=x 回退
- 所有切换操作需封装为单条命令或一键脚本，避免人工编辑配置引发二次错误
回滚不是兜底手段，而是升级设计的一部分。把回滚当功能做，而不是当补丁打。
