web

第58章｜Spinnaker 发布策略：金丝雀分析与自动判定（概念与落地）

金丝雀不是“更小的全量”，而是把发布风险拆成可测的航段。 在 Spinnaker 里，你会把它做成一个闭环：先让少量流量进入，让 metrics 说话； 再用 judgment rules 决定继续推进还是自动回滚。 本章把 canary analysis 的“分析步骤”与“自动判定”串到 pipeline stage 里，让发布从“凭感觉”走到有证据的选择。

Step 1

Deploy canary

  • traffic split
  • warm-up window
  • labeling for metrics
Step 2

Analyze metrics

  • golden signals
  • query windows
  • baseline awareness
Step 3

Decide & rollback

  • promote / abort
  • auto rollback policy
  • manual override gate

1. canary analysis 到底在分析什么？

canary analysis 不是在“猜这次发布会不会好”，而是在问：在你的用户视角中，这个版本是否达到了最低可接受标准。 因此你需要把指标从“工程成功”翻译到“用户成功”：延迟的尾部（p99 / p999）、错误率、饱和度（是否在拒绝/排队）、以及对业务旅程的关键 SLI。 Spinnaker 的贡献在于：它把分析结果变成 stage 的决策输入，让流程可以自动推进或中断。

Closed loop: deploy canary → analyze → decide promote or rollback Canary deploy traffic split 1% → 10% label: rollout=canary warm-up & hold time Metrics analyze SLI: latency p99 / error rate / saturation windows: step = 60s, duration = 10m evaluate rules repeatedly success streak vs failure streak Decision if healthy for N steps → promote (traffic increase) else auto rollback / manual gate
图 1：canary analysis 是一个“每一步都判定”的闭环，而不是一次性打分。

2. 从 stage graph 角度看：分析与回滚如何嵌入 pipeline

在 Spinnaker 的 pipeline 观念里，你会把 canary analysis 写成一组可复用 stage：部署阶段负责改变流量， 分析阶段负责在指定窗口拉取指标并计算规则， 决策阶段负责根据分析结果推进下一个 traffic step 或触发 rollback。 关键点是分析结果必须成为下一 stage 的输入，而不是人眼读完再手动点。

Stage decision graph: promote path vs rollback path Deploy canary step setWeight: 10% pause: hold for 2m emit signals: metricsReady Analyze metrics run queries over window compute: success/failure verdict rules: - errorRate < threshold - p99 < SLO Promote increase traffic next step: 40% / 100% Rollback traffic back
图 2：自动判定把“分析结果”变成分叉控制；promote 与 rollback 都是可配置策略。

3. 指标与阈值：如何避免“看起来绿、用户在痛”

canary analysis 最容易翻车的地方在于指标选择与阈值标定。 你需要避免三类情况：平均值掩盖尾部、窗口太短被噪声骗、基线不一致（warm-up / 缓存）。 建议采用 Golden signals 作为起点，再对齐业务 SLO：例如“关键 API 的错误率 < 0.2% 且 p99 < 300ms”。同时把判定窗口与 canary 的流量 step 对齐， 让“观察到的问题”更接近“对用户的真实影响”。

判定策略 用什么信号 风险点
Single-metric gate only error rate 尾延迟未被捕获
Multi-metric vote latency + errors + saturation 阈值过严导致误回滚
Error budget aware burn rate windows 错误预算口径不一致
底线：阈值要能讲清楚“为什么是这个数”。否则工具会把你的不确定性放大成自动化灾难。

4. 自动判定规则（Judge Rules）：连续成功与失败锁定

真正专业的 canary analysis 通常不是“只要某个窗口一次满足就通过”，也不是“一次超阈值就立刻 rollback”。 更常用的做法是状态化：用 success streak 与 failure streak 来做“抗抖动”。 例如：连续 3 个 step 都满足阈值才 promote；连续 2 个 step 超阈值才 rollback。 同时配合 pause / hold 时间，让系统有机会完成 warm-up 与缓存稳定。 

// Conceptual judge rules (illustrative, adapt to your Spinnaker integration)
{
  "analysis": {
    "stepSeconds": 60,
    "windowMinutes": 5,
    "successStreak": 3,
    "failureStreak": 2,
    "minDataAgeSeconds": 120,
    "maxEvaluationMinutes": 15
  },
  "promote": { "nextTrafficWeight": 40 },
  "rollback": { "enabled": true, "trafficBackWeight": 1 },
  "manualGate": { "enabled": false, "timeoutMinutes": 20 }
}

5. metric 查询落地：用 PromQL 例子理解“对齐 label 与 rollout 标签”

很多团队在落地 canary analysis 时卡在最后一公里：指标要能区分 stable 与 canary。 你需要确保采集链路里有足够的维度（例如 rollout、version、canaryReplica）。 否则分析阶段会对着一锅混合汤做判断，自动判定自然变成“随机数发生器”。 

# Illustrative PromQL-like expressions (adjust labels, metric names)
# 5xx error ratio for canary slice
sum(rate(http_requests_total{status=~"5..", rollout="canary"}[5m]))
/
sum(rate(http_requests_total{rollout="canary"}[5m]))

# p99 latency for canary slice
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket{rollout="canary"}[5m])) by (le)
)
经验底线：只要 metrics 无法“可靠地区分发布版本”，你的自动判定就无法证明。

6. 自动回滚策略：别只写“rollback=true”，要写清楚回滚时间线

自动回滚最重要的不是布尔值，而是策略细节：何时触发（失败锁定）、持续多久（避免瞬时毛刺）、回滚后是否重新验证（post-rollback analysis）、以及通知升级路径。 还要与第 57 章的 stage 观念一致：回滚 stage 本质也是一个可观测动作，会产生执行证据（execution logs）。

Auto rollback timeline: evaluate → lock failure → rollback → re-check time Step eval #1 metrics within threshold? Step eval #2 failure streak? continue Failure locked trigger rollback stage Rollback traffic back weight post-rollback analysis (optional): confirm return to safe SLO
图 3：回滚要写时间线，而不是只写开关；失败锁定 + 回滚后复核才可靠。

7. 落地风险清单：你最可能遇到的“分析偏差”

1）指标采样延迟：新版本还没“站稳”，查询已经得出结论；2）缓存/预热差异：canary 的缓存热度不同导致 p99 假性改善或恶化； 3）标签缺失：rollout 分片没有进指标；4）流量模型不一致：Ingress 权重、Service mesh、以及应用内部路由的实际流量不匹配； 5）阈值口径漂移：SLO 是“用户体验”，而你用的是“内部 HTTP 指标”。专业团队会把这些偏差写进 runbook 并进行 game day 演练。

建议：每个发布策略都要配一段“如果分析阶段失败，应该先查什么”的调查顺序（labels → queries → windows → data freshness）。

8. 本章清单

  1. 理解 canary analysis 的核心目标：用用户视角的 SLI/SLO 判断是否值得继续暴露更多流量。
  2. 能把 analysis 与回滚嵌入 Spinnaker 的 stage graph：部署→分析→分叉决定。
  3. 能选择至少两类黄金信号（延迟尾部、错误率、饱和度）并标定阈值与窗口。
  4. 能设计抗抖动 judge rules：success streak / failure streak + pause/hold。
  5. 能做指标落地：确认 rollout/版本标签进入 metrics，确保查询能可靠切片。
  6. 能制定自动回滚时间线：失败锁定触发、回滚执行、可选 post-rollback 复核。
  7. 预告下一章：如果要让发布更强可控，可继续研究 Spinnaker 的 stage 策略与可观测证据链。
← 上一章：Spinnaker 入门 下一章：跨平台对照 1 →