金丝雀发布与渐进式推出
指标驱动的流量爬升（1% → 10% → 50% → 100%），错误预算突破时自动回滚。
监控高级
为什么
金丝雀限制爆炸半径：坏部署影响 1% 用户而非 100%。带自动指标门（错误率、p99 延迟、业务 KPI）的渐进推出，捕获通过预发布但在生产规模失败的问题，在客户察觉前回滚。
CNCF 2024 调查显示 Prometheus 和 Grafana 被 70% 以上的云原生组织使用。OpenTelemetry 在 2024 年成为检测标准，减少指标和链路的供应商锁定。
何时使用
高风险变更（支付流、鉴权、schema 迁移）、高流量服务（>10k RPS）和持续部署用金丝雀。低流量内部工具跳过，蓝绿足够且 1% 信号太噪。
如何做
1. 定义指标 — 错误率（5xx/total）、延迟 p99、业务 KPI（转化、结账成功）
2. 设阈值 — 错误率 < 0.1%、p99 < 500ms、KPI 在基线 2% 内；突破 = 回滚
3. 选工具 — Argo Rollouts（K8s）、Flagger、AWS CodeDeploy、Spinnaker；或 LB 权重操作
4. 部署金丝雀 — 1% 流量到新版本，99% 到稳定；跑 5-10 分钟分析窗口
5. 指标门 — 比较金丝雀 vs 稳定；阈值内则爬到 10%；否则回滚到 0%
6. 渐进爬升 — 1% → 10% → 25% → 50% → 100%，每步指标门（各 5-10 分钟）
7. 自动回滚 — 任一步突破阈值，100% 切回稳定，告警 on-call
8. 部署后 — 保留稳定版本 1h（回滚窗口），然后退役
示例
# rollout.yaml — Argo Rollouts 金丝雀含指标分析
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: myapp
spec:
replicas: 10
strategy:
canary:
trafficRouting:
istio:
host: myapp.example.com
steps:
- setWeight: 5
- analysis:
templates:
- templateName: success-rate
args:
- name: service-name
value: myapp
- setWeight: 25
- analysis:
templates:
- templateName: success-rate
args:
- name: service-name
value: myapp
- setWeight: 50
- setWeight: 100
template:
spec:
containers:
- name: myapp
image: myapp:v2.0
ports: [{ containerPort: 3000 }]
---
# analysis-template.yaml — Prometheus 成功率门
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: success-rate
spec:
args:
- name: service-name
metrics:
- name: success-rate
interval: 1m
successCondition: result >= 0.99
failureLimit: 3
provider:
prometheus:
address: http://prometheus:9090
query: |
sum(rate(http_requests_total{service="{{args.service-name}}",code!~"5.."}[2m]))
/
sum(rate(http_requests_total{service="{{args.service-name}}"}[2m]))
常见问题
- ⚠1% 流量太噪 — 100 RPS 时 1% = 1 req/s，错误率剧烈波动，用更长分析窗口
- ⚠指标门太松 — p99 < 1s 通过但 p99.9 是 10s，0.1% 用户延迟极差
- ⚠业务 KPI 未测 — 错误率正常但转化降 20%，金丝雀“通过”且上线 bug
- ⚠无基线比较 — 金丝雀指标对比绝对阈值，而非 vs 稳定版本
最佳实践
- ✓对比金丝雀 vs 稳定（相对），非绝对阈值 — 抓“两者都差但金丝雀更差”
- ✓含业务 KPI 指标 — 错误率 + 延迟 + 转化，非仅基础设施指标
- ✓failureLimit 设 2-3 — 一个坏样本不应回滚，但趋势应回滚
- ✓金丝雀前镜像流量 — 影子真实请求到金丝雀，无用户影响下比较响应
常见问题解答
金丝雀应从多少百分比开始？
从 1-5% 开始 15-30 分钟，指标干净则升至 10%、25%、50%、100%。从 50% 开始失去意义——影响一半用户才发现问题。用自动渐进交付（Flagger、Argo Rollouts）。
金丝雀期间应监控哪些指标？
错误率（5xx）、延迟 p99、业务指标（转化、注册）。部署前设阈值——如错误率超 0.5% 或 p99 延迟增超 20% 则回滚。别看 CPU/内存；不指示用户影响。
金丝雀和 A/B 测试有什么不同？
金丝雀测错误/性能（新版本会坏吗？），A/B 测业务结果（转化更好吗？）。金丝雀是安全机制；A/B 是实验。可在 A/B 测试内跑金丝雀。
如何只让部分用户到金丝雀？
用加权负载均衡（Istio、ALB 加权目标组）或带百分比推出的功能开关。粘性会话确保用户留在同版本——否则会看到闪烁行为。
金丝雀应跑多久再全量？
足以看到有意义流量——至少 10,000 请求或 30 分钟，取较长者。太短漏罕见错误；太长延迟发布。自动化推进以免守着。