自动健康检查+自动回滚：部署后通过API或监控验证服务状态，5分钟内未恢复则自动回滚至上一版本并通知团队；2. 蓝绿部署+手动确认：新版本上线为“绿”环境，测试通过后手动切流，异常时保留“蓝”环境流量并废弃“绿”版本；3. 基于日志和告警的条件回滚：集成APM工具，错误率或延迟超标时触发回滚并暂停后续任务；4. 数据库变更配套回滚：每次数据库变更配对回滚脚本，使用Liquibase等工具管理版本，禁止不可逆操作。
部署失败时，快速回滚是保障系统稳定的关键。CI/CD流水线中应预设清晰的回滚策略，确保在发现问题后能自动或手动恢复到上一个稳定版本。以下是几种常见的回滚策略示例，适用于不同场景。
自动健康检查+自动回滚
在部署完成后，流水线触发健康检查任务，验证服务是否正常运行。若检测失败，则自动执行回滚操作。
- 部署新版本到生产环境
- 调用API健康接口或监控系统（如Prometheus）判断服务状态
- 若5分钟内未达到健康状态，流水线自动触发回滚命令
- 使用镜像标签或Git标签回退到上一版本（如v1.2.3）
- 通知团队回滚原因（通过Slack或邮件）
该策略适合对稳定性要求高的核心服务，减少人工干预延迟。
蓝绿部署+手动确认回滚
采用蓝绿部署模式，新版本先上线为“绿”环境，流量仍指向“蓝”环境。验证无误后再切流。
- 部署新版本至“绿”环境
- 自动化测试通过后，等待运维或负责人手动确认
- 若发现异常，保持流量在“蓝”环境，直接废弃“绿”版本
- 通过配置网关（如Nginx、Istio）将流量维持在旧版本
- 记录问题并修复后重新进入流水线
这种策略风险低，适合变更频繁但不能接受长时间中断的业务。
基于日志和告警的条件回滚
集成APM工具（如Sentry、ELK、Datadog），当错误率或延迟超过阈值时触发回滚。
- 部署后开启监控监听（例如：错误率 > 5% 持续2分钟）
- 告警系统发送事件至CI/CD平台（如Jenkins、GitLab CI）
- 流水线接收到回滚信号，拉取上一版本镜像重新部署
- 同时暂停后续部署任务，防止连锁故障
此方式实现智能感知，适合高可用系统和微服务架构。
数据库变更的配套回滚机制
代码回滚的同时，数据库结构或数据变更也需处理，避免版本不兼容。
- 每次数据库变更需配对提供回滚脚本（如down.sql）
- 回滚时先执行数据库降级脚本，再恢复旧版应用
- 建议使用迁移工具（如Liquibase、Flyway）管理版本
- 禁止在部署中执行不可逆操作（如DROP COLUMN）
缺少数据回滚设计可能导致服务无法启动，务必纳入整体策略。
基本上就这些。关键是根据业务容忍度选择合适方式，把回滚当作部署的一部分来设计，而不是应急补救。流程越自动化，恢复就越快。
