福满楼是城里有名的老字号餐馆，招牌红烧肉卖了二十年。有一天老板决定升级菜单，把红烧肉的做法改良一番，再添几道新菜。但他很纠结：直接全换，万一老顾客不买账怎么办？停业装修三天，房租和客流的损失又实在扛不住。 软件开发团队发布新版本时，面对的正是同样的难题。代码更新是家常便饭，但“一上线就翻车”“半夜紧急回滚”也是无数运维工程师的噩梦。渐进式发布的智慧，就像福满楼老板最终悟出的道理：不搞“一把梭”，而是分批、分流量、分人群地把新版本送到用户面前，每走一步都盯紧指标，不对劲就立刻收手。 本文用这个“福满楼换菜单”的故事，带你搞懂三种主流的渐进式发布策略：金丝雀发布（先让几位熟客试菜）、蓝绿发布（准备两个一模一样的后厨直接换班）、A/B测试（不同桌发不同菜单做对比）。我们还会聊聊流量如何控制、出了问题如何回滚，以及 GitOps 如何把“发版”变成一次普通的代码提交。

岗位关联

对云架构师与 DevOps 工程师而言，渐进式发布是把“发版事故”从大概率事件压成小概率事件的必备技能，直接决定系统的稳定性口碑与 SLO 达成率。

目录
  1. 可视化演示
  2. 发布演进历史
  3. 金丝雀发布
  4. 蓝绿发布
  5. A/B测试
  6. 流量控制方法
  7. 回滚与观测
  8. GitOps实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示金丝雀渐进流量切分、蓝绿瞬时切换与三种发布策略多维度对比分析。

本节配有交互动效（进入视口后自动加载，约 3KB）。

金丝雀发布：渐进流量切分 LB按5%→25%→50%→100%渐进将流量从v1切到v2 每阶段监控错误率，异常即回滚至上一阶段 Shift=Σ(stage_i×weight_i) 渐进切分使爆炸半径可控，风险渐进暴露

发布演进历史

福满楼十年前第一次换菜单，老板的做法很“硬核”：贴出公告“停业装修三天”，关起门来把后厨和菜单全换了。三天后重新开业，老顾客看着陌生的菜牌直摇头——“还是以前的红烧肉好吃。”营业额掉了四成。老板这才意识到，让所有人同时面对剧变，是风险最高的一种改法。

软件界的“停机发布”就是这副模样：先停掉线上服务，部署新版本，再重新启动。在部署窗口里，整个系统完全不可用，用户只能干等。而“全量发布”更激进，服务不停，但新版本一次性推给所有用户——万一有 bug，所有用户同时中招，再想回滚，等于把刚才的发布流程原样反向再来一遍，同样要再停一次机。回滚困难，是全量发布的致命伤。

于是，“爆炸半径”成了衡量发布风险的核心指标。新版本的影响范围，由三个因素相乘决定：

福满楼老板吃了亏才明白：换菜这事，动静越大、越急，翻车越惨。正确的姿势是让变化一点点渗透进日常生活，而不是一夜之间天翻地覆——这正是渐进式发布的底色。

R爆炸=N用户×p故障×S严重度\displaystyle R_{\text{爆炸}} = N_{\text{用户}} \times p_{\text{故障}} \times S_{\text{严重度}}
公式含义：爆炸半径等于同时在线用户数、故障发生概率与故障严重程度的乘积。想让爆炸半径变小，要么减少受影响的人数，要么在故障发生前把它拦住。
  1. 用户规模 N指新版本上线瞬间同时接收到流量的用户总数，爆炸半径与此成正比。
    N用户\displaystyle N_{\text{用户}}
  2. 故障概率 p新版本出问题的可能性，与测试覆盖度、改动面大小、依赖变更相关。
    p故障\displaystyle p_{\text{故障}}
  3. 严重度 S故障对业务的影响等级，比如交易中断、数据错乱等场景的量化损失系数。
    S严重度\displaystyle S_{\text{严重度}}

金丝雀发布

第二次换菜单，老板学乖了。他把新菜先端给最熟的八桌客人免费试吃，笑眯眯地问：“咸淡怎么样？”熟客们给面子，有夸的，也有认真提意见的。老板收集完反馈，第二天把试吃扩大到二十桌，第三天五十桌……直到大家都说好，才正式写进菜单。

金丝雀发布（Canary Release）的命名来自煤矿里的金丝雀——矿工带着鸟笼下井，如果瓦斯泄漏，鸟儿先倒下，人还有时间逃命。软件世界里，“金丝雀”就是第一批被新版本“喂食”的小流量用户：先在集群里部署新版本 V2，但只放 1%～5% 的流量过去，让它在真实环境下“试飞”。

金丝雀发布的流程分四步：先部署 V2 但不接流量；再放出 1%～5% 给金丝雀批次；每个阶梯停留一个观察期，核对错误率、P95 延迟（即 95% 的请求都在该时延内完成）等指标；全部健康则按阶梯放量到 10%→25%→50%→100%。其中放量比例的变化遵循一个简单的递推关系：

金丝雀就是“试菜制度”的数字化：让极少数人先尝，用数据代替直觉判断。不好吃就立刻换回老菜，好吃的菜才配得上全场上桌。它特别适合功能开关多、迭代频繁的互联网服务。

Rt+1=min⁡(Rt+ΔR,  Rmax⁡)\displaystyle R_{t+1} = \min\left(R_t + \Delta R,\; R_{\max}\right)
公式含义：下一阶段的流量比例等于当前比例加上一个固定步长，但永远不能超过 100% 这个上限。它描述的是“每观察稳定一段，就往前拱一步”的保守节奏。
  1. 当前流量比例 R_t第 t 个观察期，被引导到新版本的流量占总流量的百分比。
    Rt\displaystyle R_t
  2. 放量步长 ΔR每经过一个稳定观察期后增加的流量幅度，通常取 5% 或 10%。
    ΔR\displaystyle \Delta R
  3. 上限约束 R_max流量占比的天然天花板，即 100% 全量，公式用 min 保证不会越界。
    Rmax⁡\displaystyle R_{\max}

蓝绿发布

试菜能解决口味问题，却解决不了“出菜速度”的焦虑：万一五十桌客人同时点新菜，后厨却顶不住怎么办？老板下决心把后厨一分为二——绿厨房照常做老菜，蓝厨房花了一周反复演练新菜。周六晚上八点，广播响起：“今天起统一由蓝厨房出菜。”客人甚至没有察觉变化。

这就是蓝绿发布（Blue-Green Deployment）：维护两套完全相同、同时运行的生产环境——蓝色环境承载当前版本，绿色环境部署新版本。新版本在绿色环境里完成部署、自测、预演后，通过负载均衡或网关的一键操作，把流量从蓝色整体切到绿色。

切换是一个原子动作（要么全切、要么不切），整个发布期间服务不可感知的中断时间被压缩到极致。由此可得蓝绿发布的核心收益：

蓝绿发布的精髓是“切换而非升级”：每次发布只是把“营业中的厨房”这块牌子从蓝换成绿。回滚也只需要把牌子翻回来，同样秒级完成。代价是资源成本接近翻倍，且双环境里的数据库等有状态组件需要兼容处理。它最适合对可用性要求极高的核心交易系统。

T停机≈T路由切换≪T部署\displaystyle T_{\text{停机}} \approx T_{\text{路由切换}} \ll T_{\text{部署}}
公式含义：蓝绿发布把停机时间压到“切换路由”这一下，通常只有秒级，而部署新版本的耗时（可能是几十分钟）被完全移出了停机窗口。
  1. 部署耗时 T 部署在新环境上安装、配置、执行自测所需的时间，可能长达数十分钟。
    T部署\displaystyle T_{\text{部署}}
  2. 路由切换耗时 T 路由切换更新负载均衡或网关指向的操作时间，通常是秒级甚至毫秒级。
    T路由切换\displaystyle T_{\text{路由切换}}
  3. 远小于关系停机时间被压缩到几乎不可感知，这是蓝绿相对于停机发布质的飞跃。
    ≪\displaystyle \ll

A/B测试

试菜和换厨房解决了“稳不稳”，但老板还想知道“哪道菜更好卖”。这次他让一半顾客拿到新菜单，另一半拿旧菜单，一周后对比两边的点单率、好评率和回头率——用数据做决定，而不是凭感觉。

A/B 测试把用户随机分为对照组（旧版本）和实验组（新版本），在同一时间窗口内并行运行两个版本，通过统计指标判断新版本是否显著优于旧版本。它和金丝雀的关键区别在于：金丝雀问“新菜有没有问题”，A/B 问“新菜是不是更好”——一个是安全检查，一个是效果实验。

要做好 A/B 测试，样本量是成败关键。样本太少，随机波动会掩盖真实差异；样本太大，又浪费流量成本。最小样本量近似公式如下：

A/B 测试是“用数据投票”，把“我觉得新菜更好”变成“新菜单点单率高出 2.3 个百分点，p 值 0.01”。福满楼老板从此对新菜信心十足——因为他知道，每一个百分比都有统计学的底气。

n=z2×p(1−p)δ2\displaystyle n = \frac{z^2 \times p(1-p)}{\delta^2}
公式含义：在置信水平 95%（z≈1.96）下，要检测出对照组转化率 p 与实验组之间 δ 的最小差异，至少需要 n 个样本。差异要求越精细，所需样本就越多。
  1. 置信系数 z²与置信水平对应，95% 置信度时 z 约为 1.96，平方后约等于 3.84。
    z2\displaystyle z^2
  2. 基准转化率 p(1-p)对照组的基础转化率，如 10%，p(1-p) 刻画该基线下的波动方差。
    p(1−p)\displaystyle p(1-p)
  3. 最小可检测差异 δ²业务上希望捕捉到的最小效果差异，如 1%，δ 越小样本量要求越高。
    δ2\displaystyle \delta^2

流量控制方法

老板要控制“哪些人吃到新菜”，总不能每次都扯着嗓子喊“右边那三桌尝新”。他让收银系统执行一条简单规则：桌号除以 3 余 1 的桌上套餐 A，其余上套餐 B。规则写进系统里，切换又快又准确。

流量控制是渐进式发布的执行引擎，决定“多少请求、哪些用户”流向新版本。常见方法有四类：负载均衡权重、网关路由规则、服务网格路由、用户特征分流。负载均衡权重最朴素——给 V1 权重 9、V2 权重 1，流量就按九比一分配，改个数字即可生效。

网关路由规则适合按 URL、Header 或 Cookie 分流，比如只让手机端用户走新版本；服务网格（如 Istio，一个管理服务间通信的基础设施层）则提供更细粒度的按版本、按子集的流量路由。用户特征分流常用一致性哈希，保证同一用户始终命中同一版本，避免会话错乱——比如用户购物车刚被 V2 处理，下一个请求却落到 V1：

流量控制就是“发新菜的规则表”：规则越精细，杀伤半径越小；规则越透明，越可解释、可回放。这也是“桌号取模”能成为经典的原因——简单、确定、任何时刻都能说清某个请求为什么走了那条路。

goToNew=(hash(user_id) mod 100)<r×100\displaystyle \text{goToNew} = \left(\text{hash}(\text{user\_id}) \bmod 100\right) < r \times 100
公式含义：将用户 ID 哈希到 0～99 的区间，若哈希值落在 0 到灰度比例 r 对应的区间内，则请求进入新版本。同一用户哈希值恒定，因此永远命中同一版本。
  1. 用户 ID 哈希取模把不规则的 user_id 均匀映射为 0～99 的整数，保证分布平滑。
    hash(user_id) mod 100\displaystyle \text{hash}(\text{user\_id}) \bmod 100
  2. 灰度比例换算将 0～1 的小数比例 r 放大为 0～100 的整数阈值，如 r=0.05 时阈值为 5。
    r×100\displaystyle r \times 100
  3. 区间比较判断哈希值落在阈值以内则走新版本，否则走旧版本，判定结果确定且可复现。
    <\displaystyle <

回滚与观测

最坏的情况还是来了：周三晚高峰，三桌客人投诉新菜里的虾不新鲜。老板立刻按下对讲机：“全部停上套餐 A，换回老菜单！”同时他打开 iPad 上的复盘表——是哪道菜、哪个批次、货从哪家进的，一目了然。整个过程不到三分钟。

渐进式发布的安全性由两根柱子撑起：快速回滚机制与全链路观测。回滚是刹车，观测是仪表盘。没有刹车的车不能上路，没有仪表盘的车不敢提速——只放量不观测，等于闭着眼睛开车。

回滚不能靠人肉判断，触发条件必须量化。最常见的自动化规则是错误率阈值：当新版本的错误请求占比超过 1% 时，发布系统立即把流量切回旧版本：

观测指标要分层建设：基础设施层看 CPU、内存、磁盘；应用层看错误率、P95 延迟、线程数；业务层看转化率、订单量、支付成功率。故障定位借助分布式链路追踪，把一次请求的完整路径串起来；发布复盘则把每次事故沉淀为改进项——福满楼的教训是，再自信的厨师也要留一手旧菜单。渐进式发布不是不犯错，而是把犯错成本压到最低。

Eerror=CerrorCtotal>0.01⇒Rollback\displaystyle E_{\text{error}} = \frac{C_{\text{error}}}{C_{\text{total}}} > 0.01 \Rightarrow \text{Rollback}
公式含义：错误率 E 等于窗口期内错误请求数除以总请求数；一旦超过 1%，自动触发回滚。这个阈值可以根据业务容忍度调整，但必须在发布前定好。
  1. 错误请求数 C_error窗口期内新版本返回 5xx 或业务自定义错误的请求累计数量。
    Cerror\displaystyle C_{\text{error}}
  2. 总请求数 C_total同一窗口内进入新版本的全部请求数量，用作错误率的基准分母。
    Ctotal\displaystyle C_{\text{total}}
  3. 阈值触发回滚当比值超过 1% 时执行 Rollback，把流量切回旧版本并保留现场日志。
    >0.01⇒Rollback\displaystyle > 0.01 \Rightarrow \text{Rollback}

GitOps实践

老板决定把“换菜”变成制度：任何厨师想改菜，必须先向“菜单管理仓库”提交一份变更说明，主厨和经理双重审批，然后系统自动通知试吃、自动放量、自动记录结果。整个流程有据可查，不再靠老板拍脑袋。

GitOps 把同样的理念引入发布：Git 仓库成为发布的唯一事实来源。服务要跑成什么状态、金丝雀比例是多少、蓝绿切换开关在哪儿，全部以代码形式声明在仓库里。一个名为 Operator 的控制器（负责让实际环境向声明状态自动收敛的程序）持续对比期望状态与实际状态，发现偏差就自动调整。

一次典型的 GitOps 发布流程是：开发提交 Pull Request → 评审通过后合并到主干 → Operator 自动部署新版本 → 按策略金丝雀放量 → 观测指标 → 异常自动回滚。发布从“高危人工操作”变成了“日常代码提交”，全程可审计、可回放。用公式表达 GitOps 的核心思想：

福满楼的制度化换菜和 GitOps 异曲同工：把经验沉淀为流程，把流程沉淀为代码。自此，“发版翻车”不再是一出英雄救火的故事，而是系统里一行安静的可审计日志——这也正是云原生时代交付工程追求的最高境界。

Actual→reconcileDesired\displaystyle \text{Actual} \xrightarrow{\text{reconcile}} \text{Desired}
公式含义：实际运行状态（Actual）在 reconcile 循环的驱动下持续逼近 Git 仓库中声明的期望状态（Desired）。只要两边不一致，系统就自动纠偏。
  1. 期望状态 DesiredGit 仓库中声明的目标版本、副本数、流量比例与路由规则。
    Desired\displaystyle \text{Desired}
  2. 实际状态 Actual集群中真实运行的部署配置与流量分发情况，可能因故障而偏离声明。
    Actual\displaystyle \text{Actual}
  3. 收敛循环 reconcileOperator 周期性对比二者差异，通过部署、扩容、切流量等动作消除偏差。
    →reconcile\displaystyle \xrightarrow{\text{reconcile}}

AI 应用场景

电商大促前的服务升级

阶段：发布与交付阶段（云原生 DevOps）

解决的问题：大促前升级购物车核心服务，全量发布一旦出错，几万用户同时无法下单。传统做法夜里停机发布，既损失流量又承担回滚风险。金丝雀发布让 V2 先接住 1% 的真实流量，验证订单错误率与支付延迟，再逐步放量。

具体案例：某电商平台 618 前重构商品详情页的推荐接口，采用金丝雀发布：V2 先接入 1% 搜索流量，观察 15 分钟错误率稳定在 0.3% 后，分别放大到 10%、50%、100%，全程用户无感知，大促峰值平稳度过。

金融核心系统的蓝绿切换

阶段：基础设施与平台运维阶段

解决的问题：银行核心账户系统升级要求零停机，且一旦失败必须秒级回滚。蓝绿发布用双环境同构把“升级”变成一次路由器切换，自然满足监管对连续性的要求。

具体案例：某城商行夜间批量升级核心系统，绿色环境提前预演两周，验证所有对账、批量任务通过后执行切换，切换耗时 30 秒；随后进入 2 小时稳定观察期，确认无误后切回蓝色环境并释放冗余资源。

推荐模型上线的 A/B 效果验证

阶段：模型评估与上线阶段

解决的问题：新推荐模型离线 AUC（衡量排序质量的指标）提升明显，但在线效果未知。直接用金丝雀放量只能验证稳定性，无法证明“更好”。A/B 测试按用户 ID 随机分流，对比点击率与人均时长，用统计显著性说话。

具体案例：某内容社区将新排序模型分流 10% 用户作实验组，运行一周后实验组点击率提升 2.1%、p 值小于 0.05，随后全量上线；对照组数据保留用于后续模型迭代的基线对比。

Python 演示

python60 行
import randomimport time  class CanaryRollout:    """金丝雀发布模拟器: 阶梯放量, 错误率超阈值自动回滚."""     def __init__(self, steps=(0.01, 0.05, 0.10, 0.25, 0.50, 1.00),                 threshold=0.01):        self.steps = steps        self.threshold = threshold        self.pos = 0        self.ratio = 0.0        self.error_count = 0        self.request_count = 0        self.rolled_back = False     def send_request(self, user_id):        """按当前金丝雀比例分发请求到 V1/V2, 返回 (版本, 是否出错)."""        goes_new = random.random() < self.ratio        self.request_count += 1        err = random.random() < 0.008  # 模拟新版本 0.8% 的基础错误率        if err:            self.error_count += 1        return ("V2" if goes_new else "V1", err)     def observe(self):        """计算窗口期内的整体错误率."""        return self.error_count / max(self.request_count, 1)     def advance(self):        """进入下一个放量阶梯."""        self.ratio = self.steps[self.pos]        self.pos += 1  def main():    co = CanaryRollout()    print("金丝雀发布模拟: 阶梯放量 1% -> 100%")    while not co.rolled_back and co.pos < len(co.steps):        co.advance()        for _ in range(2000):            co.send_request(random.randint(1, 100000))        rate = co.observe()        action = "advance"        if rate > co.threshold:            co.ratio = 0.0            co.rolled_back = True            action = "rollback"        print("V2 流量: %5.1f%% | 错误率: %.3f%% | 动作: %s"              % (co.ratio * 100, rate * 100, action))        time.sleep(0.2)    if co.rolled_back:        print("错误率超阈值, 已自动回滚到 V1!")    else:        print("全量发布完成, V2 转正.")  if __name__ == "__main__":    main()
目的：模拟金丝雀发布的完整生命周期——按 1%、5%、10%、25%、50%、100% 阶梯放量，每个阶梯观察错误率，一旦超过 1% 阈值立即回滚清空流量。
  1. goes_new = random.random() < self.ratio掷骰子决定请求流向哪个版本，比例由当前金丝雀流量决定。
  2. err = random.random() < 0.008模拟新版本 0.8% 的基础错误率，故意低于 1% 阈值，演示正常完成的场景。
  3. def observe(self)用累计错误数除以累计请求数，得到截至当前的总体错误率。
  4. co.advance()每次循环把 V2 流量占比推高到下一阶梯，模拟“观察稳定→放量”的节奏。
  5. if rate > co.threshold错误率超阈值立刻把流量清零，相当于紧急换回旧菜单。
  6. while not co.rolled_back and co.pos < len(co.steps)回滚或放满 100% 时结束循环，保证流程有明确的终态。

常见误区

误区金丝雀发布就是灰度发布，两个词可以随便混用。

正解灰度发布是“按比例切流量”这一类策略的总称，金丝雀是其中强调“小流量先行 + 阶梯放量 + 自动回滚”的具体实现。A/B 测试在形式上也是灰度切流，但目标是效果对比而非稳定性验证。可以说金丝雀是灰度的一种，不能说灰度就是金丝雀。

为何常见：中文技术社区长期把两者混写，加上大多数金丝雀工具同时支持其他灰度方式，概念边界被模糊了。

误区蓝绿发布要准备两套环境，资源成本接近翻倍，能不碰就不碰。

正解双环境成本买来的是秒级切换和秒级回滚，对金融、核心交易等场景不是浪费而是保险。而且绿色环境可以在临近发布窗口才拉起，发布完成稳定后再释放，实际成本远低于“长期双倍”。要看总拥有成本，而不是单看资源账单。

为何常见：人们容易盯着显性的服务器成本，忽略了停机损失和事故修复这些隐性且更大的成本。

误区新版本流量已经到 100%，说明发布圆满收官，可以关掉监控了。

正解100% 只代表“新版本正式承接流量”，不代表“验证完成”。数据一致性问题、慢 SQL、缓存穿透等长尾故障往往在高峰时段才暴露。业界惯例是全量后继续观察至少一个完整业务周期，并保留一段时间内的回滚开关。

为何常见：把“切换完成”当成“验证完成”，忽略了真实流量下的时间维度风险。

误区A/B 测试和蓝绿发布都是新旧版本切换，选一个用就行。

正解两者解决问题的层面完全不同。A/B 测试按人群或用户维度分流，回答“哪个版本更好”，需要统计显著性支撑；蓝绿发布按环境整体切换，回答“如何无缝安全上线”，核心是原子切换与快速回滚。实践中常组合使用：先 A/B 验证效果，再用蓝绿完成最终上线。

为何常见：两者都涉及“新旧版本并存”的表象，容易让初学者忽略它们在目标、手段和评估方式上的本质差异。

面试题

Q1. 金丝雀发布的核心思想是什么？

单选题 · easy

  • A.新版本直接替换旧版本
  • B.小流量验证后逐步放量← 正确答案
  • C.同时运行两个完整环境
  • D.随机抽取用户做A/B对比

答案：B。金丝雀发布是把新版本先暴露给一小部分流量，验证稳定后按阶梯放量。选项 A 是全量发布，C 是蓝绿发布，D 是 A/B 测试。

Q2. 蓝绿发布中“蓝色环境”通常指什么？

单选题 · easy

  • A.当前对外服务的老版本环境← 正确答案
  • B.准备上线的新版本环境
  • C.独立隔离的测试环境
  • D.垃圾回收的临时环境

答案：A。蓝绿约定蓝色为当前生产环境、绿色为待上线的新环境，切换时把流量从蓝色切到绿色，回滚时反向操作。

Q3. GitOps 理想做法是发布流程如何管理？

单选题 · easy

  • A.运维人员在服务器上手工执行
  • B.以 Git 仓库声明并自动执行← 正确答案
  • C.开发人员用脚本逐个变更
  • D.测试人员配置数据库更新

答案：B。GitOps 以 Git 仓库为唯一事实来源，所有发布策略声明在仓库中，由 Operator 自动收敛执行，其余选项都是非声明式的传统做法。

Q4. 金丝雀发布自动回滚的触发条件通常是？

单选题 · mid

  • A.用户反馈人数达到十位
  • B.新版本错误率突破阈值← 正确答案
  • C.预定发布窗口时间已到
  • D.开发人员手工确认完成

答案：B。自动回滚必须基于可量化的指标，最常见的是错误率阈值，超过设定值（如 1%）立即切回旧版本。靠用户反馈或人工确认都无法保证秒级响应。

Q5. 蓝绿发布回滚动作的本质是什么？

单选题 · mid

  • A.重新部署老版本的代码
  • B.将流量整体切回蓝色环境← 正确答案
  • C.杀掉新版本全部运行进程
  • D.从备份恢复数据库的数据

答案：B。蓝绿发布的回滚不是重新部署，而是把负载均衡或网关的流量入口从绿色切回蓝色，因为蓝色环境始终在线待命，所以回滚是秒级原子操作。

Q6. 一致性哈希分流的根本目的是什么？

单选题 · mid

  • A.让流量均匀分布在所有节点
  • B.保证同一用户命中同一版本← 正确答案
  • C.提升网关的并发处理能力
  • D.降低服务端的资源内存占用

答案：B。一致性哈希把用户映射到固定区间，同一用户哈希值不变，多次请求始终落入同一版本，避免会话状态在 V1/V2 间漂移。其余选项与分流稳定性无关。

Q7. A/B 测试中样本量公式 n = z²p(1-p)/δ² 里的 δ 代表什么？

单选题 · mid

  • A.置信水平对应的 z 值
  • B.对照组的基础转化率
  • C.最小可检测的效果差异← 正确答案
  • D.实验组的预期转化率

答案：C。δ 是业务希望捕捉到的最小效果差异（Minimum Detectable Effect），δ 越小，需要的样本量越大。z 是置信系数，p 是基准转化率，δ 与两者都不同。

Q8. 金丝雀比例已到 100%，观测发现新版本 P95 延迟翻倍，正确做法是什么？

单选题 · hard

  • A.立即回调比例并回滚新版← 正确答案
  • B.继续观察数据趋势走向
  • C.只保留新版本重启全部服务
  • D.扩大流量测试业务处理容量

答案：A。P95 延迟翻倍说明新版本存在性能劣化，即使流量已全量也应立即回滚止损。继续观察会扩大影响面，重启服务或压测都无法解决性能退化问题。

Q9. 渐进式发布的流量控制方法包含哪些？

多选题 · mid

  • A.负载均衡权重调整← 正确答案
  • B.网关路由规则配置← 正确答案
  • C.服务网格流量路由← 正确答案
  • D.数据库索引重建优化

答案：ABC。权重、网关路由、服务网格路由都是常见的流量控制手段，数据库索引重建属于性能优化而非流量调度，不参与版本间的流量分配。

Q10. 相比金丝雀发布，蓝绿发布的劣势有哪些？

多选题 · hard

  • A.资源成本接近翻倍← 正确答案
  • B.无法做到秒级回滚
  • C.双环境数据同步复杂← 正确答案
  • D.完全不支持自动观测

答案：AC。蓝绿发布需要两套同构环境，成本翻倍；有状态数据需要在两环境间同步或兼容，复杂度高。蓝绿恰恰以秒级回滚见长，且同样依赖自动观测，B、D 描述与事实相反。