金丝雀、蓝绿与渐进式发布决策
渐进式发布用流量比例和自动化分析控制爆炸半径：先小流量验证，再逐步放大，指标越界自动回滚。它解决的是“新版本有问题时，影响多少用户”，不是“如何更快发布”。
发布策略要和数据库变更兼容：先做向后兼容的 schema 变更，再发布代码，最后清理旧字段。否则回滚代码也回不去。
金丝雀步骤与通过条件：
| 步骤 | 流量 | 停留 | 通过条件 |
|---|---|---|---|
| 1 | 1% | 5 分钟 | 错误率 < 0.1%，P99 < 500ms |
| 2 | 5% | 10 分钟 | 同上，且无新告警 |
| 3 | 25% | 10 分钟 | 业务指标正常 |
| 4 | 50% | 10 分钟 | 同上 |
| 5 | 100% | 观察 30 分钟 | 无回滚 |
Argo Rollouts 配置：
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: payment
spec:
replicas: 10
strategy:
canary:
steps:
- setWeight: 1
- pause: {duration: 5m}
- setWeight: 5
- pause: {duration: 10m}
- setWeight: 25
- pause: {duration: 10m}
- setWeight: 50
- pause: {duration: 10m}
analysis:
templates:
- templateName: success-rate
自动分析模板：
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: success-rate
spec:
metrics:
- name: success-rate
interval: 1m
successCondition: result[0] >= 0.999
failureLimit: 3
provider:
prometheus:
address: http://prometheus.monitoring:9090
query: |
sum(rate(http_requests_total{job="payment",code!~"5.."}[5m]))
/ sum(rate(http_requests_total{job="payment"}[5m]))
回滚决策：分析连续 3 次失败、错误率超基线 2 倍或 P99 超 SLO 时立即 abort，不人工“再看看”；数据库变更不兼容时禁止开始金丝雀，发布窗口内冻结其他高风险变更。
合上页面，先回答，再展开对照。