金丝雀发布实战：用指标决定继续还是回滚

发布前先定义成功

如果团队在发布后才讨论哪些指标算异常，就无法自动化。为服务选出少量直接反映用户体验的指标，例如请求成功率、P95 延迟和关键业务成功率，并为新旧版本使用相同查询窗口。

技术指标：5xx 比例、延迟、资源饱和度；业务指标：下单成功率、支付完成率；护栏指标：队列积压、数据库连接数；样本要求：最小请求量与最短观察时间。

逐步放量，每一步都有暂停点

流量比例应结合请求量决定。低流量服务即使观察十分钟也可能没有足够样本，需要延长窗口或使用影子流量。数据库迁移、消息格式和缓存键也必须保持前后版本兼容。

steps:
  - setWeight: 5
  - pause: { duration: 5m }
  - analysis: { templateName: api-health }
  - setWeight: 25
  - pause: { duration: 10m }
  - setWeight: 50

回滚路径要提前演练

自动分析失败后应立即停止放量并切回稳定版本，同时保留新版本日志和指标。若发布包含不可逆数据写入，应用回滚可能不够，因此要在设计阶段使用兼容迁移和功能开关。

记录从异常出现到稳定版本恢复流量的时间。只有真实演练过，团队才知道回滚按钮背后是否完整。