蓝/绿与金丝雀部署：清晰的发布策略

什么是蓝/绿与金丝雀部署

发布新代码存在风险，原因很简单：直到真正的用户开始使用，你才会知道它如何在真实环境中表现。蓝/绿和金丝雀是两种常见的方式，用来在将停机时间降到最低的同时降低风险。

用通俗话说蓝/绿部署

蓝/绿部署使用两个独立但相似的环境：

• 蓝（Blue）：当前为用户提供服务的版本（“线上”环境）。
• 绿（Green）：第二个随时可用的环境，你将在这里部署新版本。

你在后台准备 Green 环境——部署新构建、运行检查、预热——当你有把握时再把流量从 Blue 切到 Green。如果出现问题，可以迅速切回。

关键不是“两个颜色”，而是一个干净且可逆的切换。

用通俗话说金丝雀发布

金丝雀发布是逐步放量。不是一次性把所有人切过去，而是先把新版本发给一小部分用户（例如 1–5%）。如果一切正常，逐步扩大直到 100% 的流量都在新版本上。

关键是在全面迁移前从真实流量中学习。

共同目标：更安全的发布与更少的停机

这两种方法都是为达成以下目标的部署策略：

• 降低故障发生时对用户的影响
• 支持零停机部署（或尽可能接近零停机）
• 使回滚更可预测、更不令人紧张

它们通过不同方式实现这些目标：蓝/绿侧重于环境间的快速切换，而金丝雀侧重通过流量切换进行受控曝光。

没有万能的“最佳”选项

两者都不是绝对优越。正确的选择取决于产品如何被使用、你对测试的信心、你需要多快得到反馈，以及你想避免哪类故障。

很多团队也会混合使用——在基础设施上用蓝/绿保持简单性，同时对用户曝光采用金丝雀技巧。

在接下来的章节中，我们将直接比较它们，并说明各自通常适合的场景。

蓝/绿 vs 金丝雀：快速比较

蓝/绿和金丝雀都是在不打断用户的情况下发布更改的方法，但它们在如何把流量切到新版本上有所不同。

流量如何切换

蓝/绿运行两个完整环境：“Blue”（当前）和“Green”（新）。你验证 Green 后，一次性把所有流量切过去——就像翻动一个受控的开关。

金丝雀先把新版本发给一小部分用户（例如 1–5%），然后在观察真实表现的同时逐步增加流量。

真正重要的利弊

简单决策指引

当你想要一个干净、可预测的切换时选择蓝/绿——尤其适用于大型变更、迁移或需要“旧版 vs 新版”明确隔离的发布。

当你经常发布、希望从真实使用中安全学习，并通过指标引导每一步以降低影响面时选择金丝雀。

如果不确定，可以先用蓝/绿以获得操作简单性，然后在监控和回滚流程成熟后对高风险服务加上金丝雀。

何时选择蓝/绿

当你希望发布像“翻开开关”的感觉时，蓝/绿是个强有力的选择。运行两个接近生产的环境：Blue（当前）和 Green（新）。当验证 Green 无误后把用户路由过去。

你需要接近零停机

如果你的产品无法忍受可见的维护窗口——比如结账流程、预订系统、登录仪表盘——蓝/绿很合适，因为新版本会先启动、预热并检查完毕，在把真实用户导过去之前完成大部分“部署时间”。

你希望回滚尽可能简单

回滚通常就是把流量路由回 Blue。这在以下场景很有价值：

• 发布必须在几分钟内可逆
• 你想避免在压力下做紧急修补
• 你需要清晰、可重复的故障响应流程

关键好处是回滚不需要重建或重新部署——只是一次流量切换。

数据库变更能保持兼容

当数据库迁移向后兼容时，蓝/绿最容易实施，因为短期内 Blue 和 Green 可能同时存在（并可能都进行读写，取决于路由和任务设置）。

合适的情况包括：

• 增加模式（新可空列、新表）
• 扩展数据格式，使旧代码可以忽略新增字段

不适合的情况包括删除列、重命名字段或就地改变字段含义——这些会破坏“切回”承诺，除非你设计了多步迁移策略。

你能承担重复环境和路由控制的成本

蓝/绿需要额外容量（两套栈）和能控制流量的手段（负载均衡、Ingress 或平台路由）。如果你已有自动化来准备环境并有清晰的路由手段，蓝/绿会成为高信心、低戏剧性的默认选择。

何时选择金丝雀发布

金丝雀发布是把更改先发布给一小部分真实用户、观察结果并再扩展的策略。当你想在不全局停止的情况下降低风险时，它非常合适。

你有大量流量和明确的指标信号

金丝雀最适合高流量应用，因为即便 1–5% 的流量也能很快产生有意义的数据。如果你已经监控清晰的指标（错误率、延迟、转化、结账完成率、API 超时），就可以用真实使用来验证发布，而不是仅依赖测试环境。

你担心性能和边缘案例

有些问题只有在真实负载下才会出现：慢数据库查询、缓存未命中、地区延迟、罕见设备或少见的用户路径。通过金丝雀你可以在向所有人推广前确认是否有错误或性能退化。

你需要分阶段发布而非一次性切换

如果你的产品发布频繁、由多个团队共同贡献，或包含可以逐步引入的更改（UI 调整、定价实验、推荐逻辑），金丝雀发布很自然。你可以按 1% → 10% → 50% → 100% 的顺序扩展，视观察结果而定。

功能开关是你的工具链一部分

金丝雀与功能开关配合效果尤其好：你可以先安全地部署代码，然后对一部分用户启用功能、对另一部分不启用。回滚通常不需要重新部署——只需关掉开关即可。

如果你在朝渐进式交付发展，金丝雀通常是最灵活的起点。

参见：/blog/feature-flags-and-progressive-delivery

流量切换基础（通俗版）

流量切换就是控制谁在什么时候看到新版本。不是一次性把所有人切走，而是逐步或有选择地把请求从旧版本迁移到新版本。这是蓝/绿部署和金丝雀发布的实践核心，也是实现零停机部署的关键。

“方向盘”：流量在哪里被路由

你可以在堆栈的几个常见点进行流量切换。选择取决于你现有的架构以及你需要多细粒度的控制：

• 负载均衡器：在两个环境或两组服务器之间分配请求。
• Ingress 控制器（Kubernetes）：基于规则把流量路由到不同的 Service。
• 服务网格：通过精细规则控制服务间流量并提供更好的可观测性。
• CDN / 边缘路由：当你希望在靠近用户的地方做路由决策时（通常用于 Web 流量）。

你不需要每一层都用上。选择一个作为路由决策的“单一真实来源”，这样你的发布管理就不会变成一堆猜测。

常见的流量分配方式

大多数团队使用以下一种或多种方法进行流量切换：

• 百分比：1% → 5% → 25% → 50% → 100%。经典的金丝雀模式。
• 基于 Header：把带有特定 Header（例如来自 QA 工具或内部测试者）的请求路由到新版本。
• 用户分群：先对特定组发布——员工、测试用户、某个地区或某个客户等级。

百分比分配最容易说明，但分群通常更安全，因为你可以控制哪些用户看到更改（并避免在首小时惊扰重要客户）。

会破坏计划的两大“陷阱”：会话与缓存

两个常见问题经常破坏看似靠谱的发布计划：

粘性会话（session affinity）。 如果系统把用户绑定到某台服务器/版本上，10% 的流量分配可能并不等同于 10% 的用户。这也会在用户在会话中在版本间切换时引发混淆性错误。若可能，使用共享会话存储或确保路由保持用户在同一版本上。

缓存预热。 新版本常会遇到冷缓存（CDN、应用缓存、数据库查询缓存），这可能看起来像性能回退，即使代码本身正常。放量前规划好预热时间，尤其是高流量页面和昂贵端点。

把流量变更当作受控操作

把路由变更当作生产变更来处理，而不是随手一按的按钮。

记录清楚：

• 谁有权限改变流量分配
• 如何批准（值班？发布经理？变更工单？）
• 在哪里执行（负载均衡配置、ingress 规则、网格策略）
• 什么是“停止信号”（暂停发布并执行回滚计划的触发条件）

这点治理可以防止好心人“顺手把比例调到 50%”时，其他人还在观察金丝雀是否健康。

发布期间需要监控什么

发布不是“部署成功了吗？”而应问“真实用户的体验是否变差？”在蓝/绿或金丝雀发布中保持冷静的最简单方法是监控一小组能告诉你系统是否健康、变更是否伤害用户的信号。

四个核心信号：错误、延迟、饱和度、用户影响

错误率：监控 HTTP 5xx、请求失败、超时和依赖错误（数据库、支付、第三方 API）。一个看似“小”的错误率上升也会带来大量客服工单。

延迟：观察 p50 和 p95（如果有 p99 更好）。平均延迟稳定并不代表长尾延迟不存在，后者会直接影响用户感受。

饱和度：观察系统资源“饱和”程度——CPU、内存、磁盘 IO、数据库连接、队列深度、线程池等。饱和度问题通常比完全宕机更早地显现。

用户影响信号：衡量用户实际体验——结账失败率、登录成功率、搜索结果返回率、应用崩溃率、关键页面加载时间。这些常常比单纯的基础设施指标更有意义。

构建一个“发布仪表盘”，人人都能看懂

创建一个能在单屏显示的仪表盘，并在发布渠道共享。每次发布保持一致，这样就不用浪费时间找图表了。

包括：

• 错误率（总体 + 关键端点）
• 延迟（关键路径的 p50/p95）
• 饱和度（栈中最主要的 3 个约束，如应用 CPU、DB 连接、队列深度）
• 用户影响 KPI（你最核心的 1–3 个业务流程）

如果你做金丝雀发布，把指标按版本/实例组分割，这样可以直接对比金丝雀与基线。对于蓝/绿部署，在切换窗口内比较新旧环境即可。

为暂停/回滚决策设定明确阈值

在开始切流之前就决定规则。示例阈值可能是：

• 错误率比基线上升 X% 且持续 Y 分钟
• p95 超过固定上限（或比基线上升 X%）
• 用户影响 KPI 低于可接受的最小值

具体数值取决于你的服务，但关键是提前达成一致。若每个人都知道回滚计划和触发条件，就能避免在客户受影响时发生争论。

针对发布窗口的告警

在发布期间增加（或临时收紧）告警：

• 5xx/超时突增
• 关键路由的延迟急剧回退
• 饱和度信号（连接池、队列）快速增长

让告警具有可执行性："发生了什么变化，在哪里，下一步做什么"。如果告警太吵，关键时刻人们会忽略真正重要的信号。

发布前检查，提前抓住问题

大多数发布失败不是由“大错误”直接导致，而是由小不匹配引起：缺失配置、错误的数据库迁移、过期证书或在新环境中表现不同的集成。发布前检查能在影响面还很小的时候把这些问题捕获。

从健康检查与烟雾测试开始

在切任何流量之前（无论是蓝/绿切换还是小比例金丝雀），确认新版本基本存活并能处理请求。

• 确保应用健康端点返回 OK（不只是进程在跑）
• 验证依赖：数据库、缓存、队列、对象存储、邮件/SMS 提供商
• 确认 secrets 与环境变量存在且范围正确

对新环境运行简短的端到端测试

单元测试很好，但不能证明部署后的系统在真实环境中可用。对新环境运行一套短小的自动化端到端测试，最好能在几分钟内完成。

关注跨服务边界的流程（Web → API → 数据库 → 第三方），并至少对每个关键集成运行一次“真实”请求。

验证关键用户旅程（能带来收入的那些）

自动化测试有时会漏掉明显的问题。对核心工作流做有针对性的人为验证：

• 登录与重置密码
• 结账或支付流程（包括失败路径）
• 常见的“创建/更新/删除”操作

如果支持多种角色（管理员 vs 客户），至少抽样每种角色的一个旅程。

保持发布准备检查清单

把经验转成可复用的清单，保持简短且可执行：

• 数据库迁移已应用且可回退（或明确安全）
• 可观测性准备就绪：日志、仪表盘、关键指标告警
• 回滚计划已审查（谁、怎么做、什么是“停止”）

当这些检查成为常规，流量切换就变成受控步骤，而不是一次冒险的飞跃。

蓝/绿发布：实践步骤清单

把蓝/绿发布视为一份检查清单来执行：准备、部署、验证、切换、观察、清理。

1) 部署到 Green（不触及用户）

把新版本发布到 Green 环境，Blue 继续为真实流量服务。确保配置和 secrets 对齐，使 Green 成为真实的镜像环境。

2) 切流前验证 Green

先做快速高信号的检查：应用能正常启动、关键页面能加载、支付/登录可用、日志无异常。如果有自动化烟雾测试，现在运行它们。同时验证 Green 的监控仪表盘和告警是否可用。

3) 以安全方式规划数据库迁移（扩展/收缩）

当数据库发生变化时蓝/绿会变得复杂。采用扩展/收缩策略：

• 扩展（Expand）：以向后兼容的方式添加新列/表。
• 部署 Green，使其能与新旧模式都兼容。
• 收缩（Contract）：在 Blue 注销且对新代码稳定有把握后再移除旧字段。

这样就避免了“Green 能工作但切回后 Blue 无法运行”的情况。

4) 预热缓存并处理后台任务

在切流前预热关键缓存（首页、常见查询），以免用户承受“冷启动”成本。

对于后台作业/定时任务，决定谁来执行：

• 在切换期间仅在一个环境中运行作业，以避免重复处理

5) 切换流量，然后观察

翻转路由把流量从 Blue 切到 Green（负载均衡/DNS/ingress）。观察错误率、延迟和业务指标的短期窗口。

6) 切换后验证与清理

做一次仿真真实用户的抽查，然后短时间内保留 Blue 作为回退选项。一旦确认稳定，停用 Blue 的任务、归档日志并释放 Blue 以降低成本与混淆。

金丝雀发布：实践步骤清单

金丝雀发布的核心是安全学习。不是一次性把所有用户都迁移，而是先给一小部分真实流量，密切观察，再扩展。目标不是“放得慢”，而是“用证据逐步证明安全”。

一个简单的放量计划（1–5% → 25% → 50% → 100%）

1. 准备金丝雀

与当前稳定版本并行部署新版本。确保你可以把定义的百分比流量路由到新版本，并且两个版本都在监控中可见（分开的仪表盘或标签会很有帮助）。

2. 阶段 1：1–5%

从极小的比例开始。这个阶段通常能快速发现明显问题：端点故障、缺失配置、数据库迁移意外或延迟激增。阶段中记录：

• 本次发布的变更（包括“微小”的配置变更）
• 预期发生的情况
• 观察到的情况（错误、延迟、用户影响等）

3. 阶段 2：25%

如果第一阶段无异常，增加到约四分之一流量。此时你会看到更多的“真实世界”多样性：不同的用户行为、长尾设备、边缘案例和更高并发。

4. 阶段 3：50%

半数流量能让容量与性能问题更清晰地暴露。如果有扩展瓶颈，通常会在此阶段出现早期警告信号。

5. 阶段 4：100%（提升）

当各项指标稳定、用户影响在可接受范围内时，把所有流量切到新版本并宣布升级完成。

选择放量间隔（每阶段等待多长）

放量时间取决于风险和流量量级：

• 高风险或低流量：每阶段等待更久以获得足够信号（例如 30–60 分钟，有时更久）。低流量服务可能需要数小时才能观察到有意义的模式。
• 低风险且高流量：阶段可短一些（例如 5–15 分钟），因为数据会更快积累。

还要考虑业务周期。如果产品存在流量高峰（比如午餐时间、周末、计费时段），让金丝雀覆盖这些条件，以更全面地验证。

自动化提升与回滚

手动放量会带来犹豫与不一致。尽可能自动化：

• 在关键指标在定义窗口内保持在阈值内时自动提升
• 在阈值被触发时自动回滚（例如错误率或延迟超过限定值）

自动化并不取代人工判断，但能消除延迟。

把每个阶段当成实验

每步放量都写下：

• 变更概要（到底改了什么）
• 成功标准（哪些指标必须保持稳定）
• 观察结果（你看到了什么，包括“无异常”）
• 决策（提升、保持或回滚）以及原因

这些记录会把你的发布历史转化为下一次发布的指南，并让未来的事件排查更容易。

回滚计划与故障处理

回滚在你事先决定什么是“坏”的并明确谁有权按下按钮时才会变得容易。回滚计划不是悲观，而是防止小问题发展成长期中断的办法。

定义明确的回滚触发条件

选一份简短的信号清单并设置明确阈值，避免事件中争论。常见触发器包括：

• 错误率：5xx、结账失败、登录失败或 API 超时激增
• 延迟：p95/p99 超过商定上限并持续一段时间（例如 5–10 分钟）
• 业务 KPI：转化率、支付成功率、注册数骤降或取消量上升

把触发器量化（例如 “p95 > 800ms 持续 10 分钟”），并把责任人（值班、发布经理）与直接行动权限绑定。

保持回滚快速且平淡无奇

速度比优雅重要。你的回滚应当是下列之一：

• 反向流量切换（蓝/绿与金丝雀常见）：把流量切回已知良好的版本
• 重新部署上一个稳定版本：如果基础设施改变，推回上一个稳定构建并重新跑健康检查

避免把“先做人工修复再继续放量”作为首选动作。先稳住，再调查。

为部分回滚做计划

在金丝雀发布中，某些用户可能已经在新版本下创建了数据。提前决定：

• “金丝雀”用户是立即回退，还是继续保留在金丝雀上以便评估？
• 若数据格式发生变化，数据库是否向后兼容？如果不兼容，回滚可能需要额外的缓解措施。

事后复盘以改进下次发布

稳定后写一份简短的事后说明：触发回滚的原因、缺失哪些信号、下次发布要改进的清单。把它当作发布流程的产品改进循环，而不是找责任人。

功能开关与渐进式交付

功能开关让你把“部署（deploy）”与“发布（release）”分离。这很重要，因为你可以用相同的部署管道（蓝/绿 或 金丝雀），通过一个开关来控制曝光。

无压力地部署，有意图地发布

有了开关，即便功能尚未对所有人开放，你也可以合并并部署代码。代码存在但处于休眠状态。当你有把握时，可以逐步启用该开关——通常比推新构建要快；若出问题，也可以快速关掉。

有针对性的启用（非全有或全无）

渐进式交付是有计划地增加访问范围。开关可以针对：

• 特定用户群（内部员工、测试用户、付费等级）
• 区域（先在一个国家或数据中心启用）
• 一定比例的用户（1% → 10% → 50% → 100%）

当金丝雀告诉你新版本健康，但你仍想把功能风险单独控制时，这非常有用。

防止“开关债务”的保障措施

功能开关很强大，但需要治理：

• 归属：每个开关都有责任团队或负责人
• 到期：设置移除日期或审查日期，旧开关不应堆积
• 文档：写清楚开关做什么、影响谁、如何回滚

一条实用规则：如果有人无法回答“关掉这个开关会发生什么？”，说明这个开关还不够成熟。

关于把开关作为发布策略一部分的更深入指导，参见 /blog/feature-flags-release-strategy。

如何选择策略并入门

在蓝/绿与金丝雀之间选择不是“哪个更好”的问题，而是你想控制哪种风险，以及在现有人力与工具条件下你能实际做到什么。

一个快速的决策方法

如果你的首要目标是干净、可预测的切换且要有容易回到旧版本的按钮，蓝/绿通常最简单。

如果你的首要目标是减小影响面并在更广泛推广前从真实流量学习，且你经常发布或难以事先完全测试，金丝雀通常更安全。

一个务实的规则：选择你能在凌晨两点也能稳定运行的一种方法。

小规模开始：试点一项

挑一个服务（或一个面向用户的工作流）作为试点，运行几次发布。选择重要但不是决定性命运的目标，目的是培养关于流量切换、监控和回滚的操作习惯。

写一份简明的运行手册并指定责任人

保持简短——一页就够：

• 什么是“良好”（关键指标与阈值）
• 发布期间由谁负责
• 如何暂停、回滚与沟通

确保任务归属明确。没有负责人，策略只会变成建议。

先用现有工具

在引入新平台前，先看看你已有的工具：负载均衡配置、部署脚本、现有监控与事故流程。只有当新工具能切实消除你在试点中遇到的摩擦时，才引入它们。

如果你在快速构建与交付新服务，集成应用生成与部署控制的平台也能减少运维成本。例如，Koder.ai 是一个让团队通过聊天界面生成 Web、后端与移动应用的平台，并支持部署与托管，提供像快照与回滚、定制域名和源代码导出的实用安全特性。这些能力契合本文的核心目标：让发布可重复、可观测且可逆。

建议的下一步

若想查看实现选项与支持的工作流，请审阅 /pricing 和 /docs/deployments。然后安排你的首次试点发布，记录哪些做得好，逐次迭代你的运行手册。