金丝雀发布
§1摘要与结论
金丝雀发布先把新版本部署到不接用户或仅接少量用户的基础设施上，再按健康指标逐步放大流量与用户比例直至全量，从而把新版本故障的爆炸半径限制在受影响的小范围内。
别名：canary release、canary deployment、金丝雀部署、灰度发布、渐进暴露 | 英文：Canary Release | 类型：技术 / pattern
§2局部关系图
§3原理 · 为什么
用受控的渐进暴露替代一次性全量风险。新版本先在少量真实生产负载下运行，让不达标的版本在影响小范围时就暴露问题，而不是等全量后才被发现。其核心是把「发布」从二元事件变成可暂停、可回退、可观测的连续过程：每一步扩大暴露都以上一阶段的健康证据为前提，一旦指标恶化立即停止并回退。相比蓝绿的一次性切换，它把风险摊薄到时间维度，用更长的观察换取更小的故障面；相比静态的测试，它在生产环境做真实的容量与兼容性验证，环境保真度最高。渐进暴露也把发布决策从「一次性拍板」变成「按证据逐步推进」，使风险判断有据可依。这种按证据推进的方式还要求团队预先就「什么情况算健康、什么情况必须回退」达成共识，否则推进与止损都会变成临场争论。
§4机制 · 如何运作
通过流量路由或加权把请求按比例导向新旧版本，用户选择可采用随机抽样、先内部员工或按画像筛选；随信心提升，基础设施占比与用户占比同步扩大，旧基础设施以不可变方式退役。推进应由健康模型驱动：每个阶段须通过健康检查才进入下一阶段，组间设置逐步加长的观察等待时间以覆盖不同时区与使用模式，检出问题即停止并回滚或前滚。常配合特性开关把「部署」与「暴露」进一步解耦。把监控指标与自动回退联动可形成自动止损机制。数据库变更需让 schema 同时兼容两版，通常采用并行变更策略。需要注意的是，基础设施层面的金丝雀与用户层面的渐进暴露可以分开控制，二者的组合决定实际暴露面。为避免新旧版本在同一用户会话中来回跳变，通常会对同一用户保持路由粘性，使整个会话稳定落在某一版本上。
§5工程 · 怎么落地
先建立可观测性基础——没有可信的健康指标，渐进暴露就失去推进与止损的依据。定义各阶段的流量比例、观察时长与通过判据，并尽量自动化；把用户选择策略与业务口径对齐，避免把预算或特定群体长期锁在新版本上。控制并发版本数量，及时清理已被替换的旧基础设施，降低多版本并存的认知与运维成本。对安装在用户端、升级时机不可控的软件，应评估该模式是否适用，必要时改用服务端能力开关或强制升级机制。观察窗口内应包含足够多样的流量特征，否则样本偏差会给出虚假的安全感。推进节奏应与业务影响匹配，对高风险变更宁可放慢并延长观察，而非机械套用固定比例。同时应定期演练回退路径本身，验证流量切回旧版本后关键功能与数据仍可正常，而不是只在纸面上假设可回退。
§6权衡卡
同时应把发布节奏与团队响应能力匹配，确保一旦触发回退，有人、有流程、有权限能够及时处置，否则再精细的暴露策略也无法在故障中兑现价值。
金丝雀把爆炸半径压到最小并支持自动回滚，代价是需要同时管理多个并发版本、依赖成熟的流量治理与监控能力，实现与观测成本较高。
它把风险摊到更长时间，意味着发布周期变长、验证需要耐心，指标不敏感或噪声大的场景会让推进判据失真。
- 对用户端安装型软件，服务端无法控制升级时机，模式效果有限。
- 它容易与 A/B 测试混淆：二者技术手段相似，但金丝雀检测故障与回归、通常在分钟到小时级完成，A/B 验证假设、需要达到统计显著而耗时更久；混用会污染 A/B 结论，也会让金丝雀回滚变得犹疑。
- 因此必须明确目标，不能顺手兼作。
- 最后，金丝雀的效果取决于监控是否覆盖真正的用户影响，只盯技术指标可能漏掉业务层回归。
- 因此金丝雀应被视为一套需要持续校准的发布机制：流量比例、观察时长与止损阈值都要随系统与业务演进而调整，而非一次配置长期沿用。
- 对数据密集型服务，金丝雀还要特别小心：新旧版本对同一份数据的读写可能产生不可逆差异，回退未必能把数据也一并退回。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7冲突 / 对比表
| 对照维度 | 金丝雀发布 | 蓝绿部署 |
|---|---|---|
| 定位 / 依据层 | 金丝雀发布 · Canary Release | 蓝绿部署 · Blue-Green Deployment |
| 核心定义（原文） | 金丝雀发布先把新版本部署到不接用户或仅接少量用户的基础设施上，再按健康指标逐步放大流量与用户比例直至全量，从而把新版本故障的爆炸半径限制在受影响的小范围内。 | 蓝绿部署维护两套尽可能相同、均可承担全量负载的生产环境，任一时刻仅一套承载流量；新版本在另一套环境验证通过后整体切换流量，异常时切回原环境实现快速回滚。 |
| 首条机制断言（原文） | 用受控的渐进暴露替代一次性全量风险。 | 用环境隔离换取发布的可逆性。 |
| 对照关系 | 整体切换与逐步导流的取舍对照（对照） | 同一条 对照 边的另一端 |
| 典型反例（原文） | 金丝雀把爆炸半径压到最小并支持自动回滚，代价是需要同时管理多个并发版本、依赖成熟的流量治理与监控能力，实现与观测成本较高。 | 蓝绿让回滚最快、隔离最好，但资源成本约为双份，且新环境需预先具备承担全量负载的能力。 |
| 处置要点（原文） | 先建立可观测性基础——没有可信的健康指标，渐进暴露就失去推进与止损的依据。 | 先保证两套环境尽可能等价，减少「只在 green 复现」的偏差；把环境创建、部署、验证与流量切换都脚本化，避免手工操作引入错误。 |
§8案例带
插件 DAG RC5→RC7 升级
一次知识库随上游源码版本升级的级联维护：以三层差异分析把 219 个包收敛为 26 个实质变更包，经编译、运行时、组合三类依赖判定更新 DAG 数据后全量重生成页面，并以静态门控加渲染验证收口。
§9信源与核验
核验结论：二者技术实现相似但目的不同：金丝雀检测故障/回归，应在分钟/小时级完成；A/B 验证假设，需达统计显著（天级）。混用会干扰 A/B 结果 [WEB-033]
核验结论：其主要代价是需同时管理多个并发版本、依赖流量路由与可观测性，且数据库变更需让 schema 同时兼容两版；实现与观测成本较高 [WEB-033]
§10原始关系清单
展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 组合 | ← TEC-J-01 | Kubernetes 部署编排 E-846 | 编排层承载金丝雀流量切分 |
| 对照 | ← TEC-J-03 | 蓝绿部署 E-845 | 整体切换与逐步导流的取舍对照 |
| 实现 | → MTH-J-05 | 渐进暴露部署策略 E-837 | 按健康指标逐步扩大流量暴露 |
| 实现 | → MTH-J-07 | 可回滚性与爆炸半径控制 E-838 | reroute 回退控制爆炸半径 |