CI/CD 回滚演练按钮存在不代表真的能回去一、回滚能力要演练很多流水线都有回滚按钮但真正事故发生时才发现数据库已经迁移、配置已经变更、镜像被清理、旧版本不兼容、回滚脚本没人跑过。回滚能力不是页面上有个按钮而是能在压力下可靠执行。CI/CD 回滚演练要像发布一样认真。二、先定义回滚对象flowchart TD A[发布内容] -- B[应用镜像] A -- C[配置] A -- D[数据库变更] A -- E[网关路由] B -- F[回滚计划] C -- F D -- F E -- F只回滚镜像不一定够。配置、数据、路由、缓存和任务队列都可能参与发布。rollback_scope: image: true config: true database: conditional traffic_route: true每次发布前都要知道哪些东西可回滚哪些不可回滚。三、数据库变更最难数据库 schema 变更如果不兼容回滚应用也没用。更稳妥的方式是 expand-contract先兼容新增字段再切流量最后清理旧字段。db_migration_policy: backward_compatible: required destructive_change: blocked rollback_script: required删除字段、改字段含义、不可逆数据迁移都不适合和普通发布混在一起快速上线。四、演练要有指标回滚演练不是点一下按钮就结束。要记录发现问题到回滚完成的时间、回滚后错误率是否恢复、数据是否一致、用户影响是否停止。rollback_drill_metrics: detect_to_decide_minutes: true decide_to_restore_minutes: true post_rollback_error_rate: true还要演练“半失败”场景。比如镜像回滚成功但配置回滚失败或者流量已经切回但后台任务仍在跑新版本逻辑。真实事故往往不是干净失败。回滚文档要写到值班人员能照着执行。只写“必要时回滚”没有意义要写命令、入口、确认指标和联系人。最后回滚不是失败文化。能快速回滚说明团队对生产负责。发布越频繁越需要把回滚练熟。回滚演练还要包括权限检查。事故时最尴尬的情况是值班人员知道该回滚却没有权限操作流水线或网关。演练时要确认角色、审批和紧急通道都能工作。rollback_permission_check: oncall_can_trigger: true approval_fallback: true audit_required: true还要准备回滚后的数据核对。应用回去了不代表数据状态也回到过去。订单、任务、消息、缓存这些状态型数据需要单独确认是否受影响。最后演练频率要固定。季度一次、重大架构变更后一次至少要有节奏。回滚能力会随着系统变化慢慢失效不练就会生锈。回滚演练还要覆盖通知链路。谁决定回滚谁执行谁通知业务谁确认恢复这些角色要提前明确。事故里最浪费时间的往往不是命令本身而是没人知道谁能拍板。rollback_roles: decision_owner: release_manager executor: oncall_engineer business_notifier: product_owner还要为回滚设置停止条件。比如错误率恢复到阈值以下、核心接口 P95 恢复、用户投诉停止增长。没有停止条件团队会不知道回滚后是否真的安全。最后演练结束要更新 Runbook。演练中发现的权限缺口、脚本问题、文档不清都要立刻修正不要留到真正事故时再想起来。五、总结CI/CD 回滚演练要覆盖镜像、配置、数据库、路由和后台任务并用恢复时间和恢复效果衡量。按钮存在不代表真的能回去。只有演练过的回滚事故时才靠得住。