什么是金丝雀发布？原理、流程和示例

什么是金丝雀发布？

金丝雀发布（也叫金丝雀测试，国内常称灰度发布）是先把新版本开放给一小部分真实线上用户或流量，和同时在跑的当前版本对比健康状况，确认没问题才继续放量。如果金丝雀表现更差，就把流量切回旧版本，大部分用户根本不会遇到问题。

名字来自矿工带下井的金丝雀：它们比人更早对有毒气体起反应。金丝雀那一小部分用户，就是提前报警的那只鸟。

金丝雀发布和其他发布方式的区别

实际工作中这些常组合使用：代码通过金丝雀部署，里面的新功能再用功能开关逐步打开。

金丝雀发布怎么做

1. 新版本和当前版本并行部署，两者都承接线上流量。
2. 把一小部分流量分给金丝雀，通常 1–5%，随机分配，并且同一个用户固定在同一版本。
3. 在同一时间窗口里对比金丝雀和基线。要和「此刻正在跑的当前版本」对比，而不是和昨天对比，这样时段和流量构成的差异就互相抵消了。Google SRE 的做法正是这种并排对比。
4. 只看几个关键指标：错误率、延迟（p95 / p99）、App 的无崩溃用户占比，再加一两个业务信号，比如结账完成率。
5. 分步放量（比如 5% → 25% → 50% → 全量），一旦越过阈值就自动回滚。

示例：放量还是回滚？

示例数据：金丝雀占 5% 流量，观察一小时。事先定好的规则：金丝雀错误率超过基线的 1.2 倍就回滚。

比值 = 0.42 ÷ 0.31 = 1.35，超过 1.2 的阈值，金丝雀回滚。受影响的只有 5% 的用户、一个小时。还要注意：金丝雀这一小时只有 42 个错误；如果只给 1% 的流量，大约只有 8 个，根本分不清是问题还是噪声。金丝雀的比例要保证每个观察窗口里有足够多的事件可供判断。

移动端：分阶段发布

App 装到用户手机上就没法回滚，所以应用商店提供了「金丝雀」机制：

• 苹果分阶段发布：对开启自动更新的用户，在 7 天内按 1%、2%、5%、10%、20%、50% 直至全部用户逐步推送更新，期间累计可暂停最多 30 天。
• Google Play 分阶段发布：按你选择的比例发布，可以逐步提高，发现问题可以暂停。
• 国内安卓市场多数也支持灰度或按比例发布，原理相同。

对比方法一样：在同样的几天里，看新版本和上一版本的无崩溃用户占比、错误数。

常见坑

• 和过去比，而不是和正在运行的基线比。
• 金丝雀太小，窗口里攒不够事件。
• 只看技术指标：一个版本可能零报错却把结账弄坏了，至少加一个业务护栏指标。
• 分配不固定，同一个用户在一次访问中来回切换版本。
• 金丝雀拖太久，变成没人规划过的长期分流。

用 TapCub 衡量金丝雀发布

TapCub 不负责部署代码或分配流量，它负责衡量结果。

• App：应用统计 › 用户分析 › 版本分布 显示每个版本的活跃用户占比和崩溃数；应用统计 › 质量与归因 › 稳定性 按版本筛选，给出无崩溃用户占比。参见无崩溃率和跟踪 App 版本。
• 网站：性能报表显示 JavaScript 错误数和错误率（错误数 ÷ 浏览量）。参见查找 JavaScript 错误。
• 告警：用内置的 error_rate 或 errors 指标建一个监控，发布导致错误超过阈值时通知你；再加一个图表标注，在所有图上标出这次部署。

资料来源

• Sato, D.（2014），Canary Release，martinfowler.com。
• Google，《SRE 工作手册》第 16 章：金丝雀发布。
• Apple，分阶段发布版本更新。
• Google Play 管理中心帮助，通过分阶段发布来发布应用更新。