坏部署的回滚决策工作流

目标

在事件当中进行的回滚辩论是最贵的辩论：信号持续恶化而人们还在讨论。部署前写死触发阈值、指定决策人，事件响应就从“开会形成观点”变成“执行早已做出的决定”——几分钟内回滚，决策与原因全部入档。

步骤要点

1. 发布计划里预先写好回滚触发条件：错误率阈值、延迟越界、转化下跌的量化指标与观察窗口，不用形容词只用数字。
2. 每个发布窗口指定唯一决策人，可不开会直接拍板回滚，并安排缺席时的替补。
3. 部署带标记：指标里打入部署标记，前后窗口可自动对照触发条件，一条查询即出对比。
4. 观察窗口内按触发行动：越界时决策人立即回滚，或记录有截止时间的限界前进修复决定。
5. 回滚后确认信号回基线，记录触发原因与前进修复内容，反哺下一次发布计划。

排错提示

触发条件用“明显变差”这类形容词说明阈值没量化，逼着自己写数字并按历史基线校准；事件中仍在找人拍板是决策人未授权或未广播，把决策人写进值班表并明确其权限；回滚执行超时是因为路径没演练过，把回滚演练纳入发布排练并记录实测时长。

适用边界

回滚决策依赖可对照的指标，监控未覆盖的维度（如数据正确性）需要人工抽检触发；前进修复的限界判断有主观成分，事后复盘应检验决策质量并调整阈值。

代码示例

release plan v1.8.0 (excerpt):
  rollback triggers (observation 30 min):
    error_rate   > 2%      for 5 min
    p99 latency  > 800ms   for 5 min
    checkout cvr -15% rel  for 10 min
  decision owner: on-call release engineer
  rollback path: redeploy v1.7.3 tag (rehearsed 11 min)

incident log 14:07Z: error_rate 2.4% (6 min)
  14:08Z owner calls rollback (no meeting)
  14:19Z v1.7.3 live, error_rate 0.3%
  14:40Z forward-fix bug filed (timeout regression)