城市公交集团买了一批崭新的电动公交车，准备逐步替换跑了一百万公里的老柴油车。新车很先进，但上线一个月后发现：雨天抛锚率异常高，高峰期乘客投诉被打爆。如果你是调度中心负责人，会怎么办？最省事的办法是把新车连夜全部停运、立刻换回旧车——但这意味着第二天早高峰，半个城的乘客要重新排队。于是调度中心采用了更聪明的做法：先让 10% 的新车退出高峰线路，换上旧车；观察两个高峰期，确认投诉回落；再撤下一批，再观察……直到所有新车静悄悄退场。这个“分步撤车”的思路，就是大型 AI 系统里保证服务平稳的模型回滚灰度策略。本篇文章将借调度中心的故事，讲清回滚的概念、触发条件、流量节奏、流程设计、自动中止与工程实践，让一个完全不懂 AI 的读者也能在 15 分钟内建立完整直觉。

岗位关联

学会灰度回滚，等于给线上服务装了“安全气囊”：新模型翻车时你能优雅止血，而不是陪它一起坠毁。这是 MLOps 与 SRE 工程师最核心的兜底技能，也是大型 AI 服务免于重大事故的重要保障。

目录
  1. 可视化演示
  2. 回滚概念价值
  3. 回滚触发条件
  4. 流量切换节奏
  5. 回滚流程设计
  6. 监控自动中止
  7. 工程实践要领
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

动态演示模型回滚灰度策略的核心机制，通过入门/进阶/实战/优化四种模式展示关键概念与交互流程。

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

模型回滚灰度策略：灰度回滚 灰度回滚与直接回滚对比 流量切换节奏控制策略 核心机制可视化 模型回滚灰度策略整体架构与关键组件

回滚概念价值

城市公交集团把 200 辆崭新的电动公交车投入 30 条线路，替换服役多年的柴油旧车。一个月后问题浮出水面：新车在雨雪天接连抛锚，高峰期三分之一的车趴在路上。如果你是负责人，第一反应或许是“把所有新车连夜停运，全部换回旧车”。可这样一来，第二天早高峰全市一半线路会断档——这就是全量回滚的代价。下撤也要讲方法，先把风险最高的线路换回旧车，再逐步扩大范围。

AI 服务中的“新车”就是刚上线的新模型版本 v2，“旧车”则是线上运行稳定的老版本 v1。所谓回滚，就是把线上流量从 v2 重新切回 v1。这里的“流量路由”类似调度台决定哪辆车去哪条线路——每次用户请求送给哪个模型，由路由引擎来分配。直接全量切回，会在一瞬间反转整张流量路由表：连接风暴、缓存冷启动、下游拥挤，服务可能从“坏”变成“更坏”。于是工程师们把回滚也做成“灰度”——按比例、分步骤地一点点切回。

灰度回滚的第一个技术动作，是让流量引擎按比例分配请求。实时统计每个模型实际承接的请求数，就能精确计算出新模型的流量占比 \(p_{\text{new}}\)，旧模型占比则是它的补集。

回到公交调度台：只要把 30% 的新车线路调度权切回旧车，\(p_{\text{old}}\) 就从 70% 慢慢涨到 100%，乘客和线路都不感知突变。灰度回滚的底层思想一句话概括：回滚不是一刀切，而是可控的流量再平衡。

pnew=NnewNnew+Nold,pold=1−pnew\displaystyle p_{\text{new}} = \frac{N_{\text{new}}}{N_{\text{new}} + N_{\text{old}}}, \qquad p_{\text{old}} = 1 - p_{\text{new}}
公式说明：\(p_{\text{new}}\) 表示流到新模型的请求占比，\(N\) 是单位时间内各模型承接的请求数。占比永远相对总量而言，新旧两方相加恒等于 1。
  1. N_new 与 N_old统计窗口内被路由到新模型和旧模型的请求数，它们是占比计算的两个原始计数。
    Nnew+Nold=QtotalN_{\text{new}} + N_{\text{old}} = Q_{\text{total}}
  2. 分子 N_new当前打进新模型的请求量，它越大说明新模型分担的流量越多，事故影响面也越大。
    pnew=Nnew÷Qtotalp_{\text{new}} = N_{\text{new}} \div Q_{\text{total}}
  3. 分母 Q_total新旧模型承接请求的总和，占比必须相对总量来看，避免只看绝对值误判。
    Qtotal=Nnew+NoldQ_{\text{total}} = N_{\text{new}} + N_{\text{old}}
  4. p_old 补集关系流量非新即旧，新旧占比相加恒等于 1，所以每次降流都是此消彼长。
    pold=1−pnewp_{\text{old}} = 1 - p_{\text{new}}

回滚触发条件

调度大屏上有两排灯：一排显示各线路抛锚率，一排显示乘客投诉量。过去靠司机用对讲机喊“我抛锚了”，等调度员汇总完毕，高峰早结束了。现在指标一红，调度员就知道该启动撤车预案。对模型服务来说，这套“红灯”就是回滚触发条件——它回答的问题只有一句：什么时候该下撤？

触发条件不是拍脑袋，而是量化指标。常见的有三类：业务指标（客诉率、点击率、转化率下滑）、系统指标（CPU、内存、延迟水位上涨）、错误率（接口 5xx 或超时比例变高）。其中最核心、最灵敏的是错误率——它直接反映模型“答非所问”或“服务不可用”的程度。你可以把错误率想象成抛锚率：一台车抛锚是偶然，多台车同时抛锚就是事故信号。

为了稳定地观察错误率，工程师用滑动窗口统计：固定一个时间窗（比如 5 分钟），统计窗口内失败请求数与总请求数的比值，这个比值超过设定阈值，就点亮红灯。

正如调度中心用“连续 15 分钟抛锚率超 2%”作为撤车信号，模型服务的触发条件也要连续、量化、可复现。红灯亮起不是让人慌乱，而是进入回滚评估流程的第一步——知道何时止损，比知道如何止损更重要。

E=FwinQwin>θ\displaystyle E = \frac{F_{\text{win}}}{Q_{\text{win}}} > \theta
公式说明：\(E\) 是窗口错误率，\(F_{\text{win}}\) 是窗口内失败请求数，\(Q_{\text{win}}\) 是总请求数，\(\theta\) 是触发回滚评估的错误率阈值。
  1. Q_win 窗口请求数固定时间窗内进入系统的总请求量，窗口太长会迟钝、太短会抖动。
    Qwin=∑i=1nqiQ_{\text{win}} = \sum_{i=1}^{n} q_i
  2. F_win 失败请求数同一窗口内返回错误状态（如超时、5xx、空响应）的请求数量。
    Fwin≤QwinF_{\text{win}} \le Q_{\text{win}}
  3. E 错误率失败请求占总请求的比例，是一个介于 0 和 1 之间的无量纲数。
    E=Fwin÷QwinE = F_{\text{win}} \div Q_{\text{win}}
  4. 阈值 θ回滚评估的错误率红线，超过它说明新模型已经影响用户体验。
    E>θ⇒触发回滚评估E > \theta \Rightarrow \text{触发回滚评估}

流量切换节奏

撤新车最忌讳“一次撤光”。调度员的习惯动作是：每个高峰让 10% 的新车退出线路，换一批旧车顶上，观察两个高峰，再撤下一批。每一步都小、都稳，这就是节奏。为什么不能快？因为指标有滞后性——你切完流量，系统要过一段时间才能展现出真实状态，立刻连撤三批，等于闭着眼睛开车。

灰度回滚同样讲究节奏，核心手法叫阶梯式降流。先定一个起点比例，比如从当前 30% 降到 23%，停住，观察；达标后再降到 16%、9%、2%。每次只动一小步，给指标留出反应时间。这就像把大象请出浴缸：要一点一点放水，大象感觉不到水位变化，水面才不会溢出来。

用递推式表达每一步的占比变化：当前占比等于上一步占比减去一个固定步长，总共走 K 步。

小步快跑的核心不是“快”，而是“每步都可验证”。调度员每撤一批车都要等投诉率回落；工程师每降一个阶梯都要等错误率跌破安全线。节奏对了，回滚就像慢慢放水，水桶始终不溢出一滴。

pnew(k)=pnew(k−1)−Δp,k=1,2,…,K\displaystyle p_{\text{new}}(k) = p_{\text{new}}(k-1) - \Delta p, \qquad k = 1,2,\dots,K
公式说明：\(p_{\text{new}}(k)\) 是第 k 步降流后的新模型流量占比，\(\Delta p\) 是每步的降流步长，K 是总阶梯数。
  1. p_new(k) 当前占比完成第 k 次降流后，新模型剩余的流量比例，永远在 0 到初始值之间。
    pnew(k)∈[0,p0]p_{\text{new}}(k) \in [0, p_0]
  2. p_new(k-1) 上一步占比降流前的基准值，保证每次切换都是“从上一步出发”，不跳跃。
    pnew(k−1)=p0−(k−1)Δpp_{\text{new}}(k-1) = p_0 - (k-1)\Delta p
  3. Δp 步长每一步主动削减的流量份额，工程上通常取 5%～10%，步长越小越稳。
    Δp=pnew(k−1)−pnew(k)\Delta p = p_{\text{new}}(k-1) - p_{\text{new}}(k)
  4. K 总步数从当前占比一路降到接近 0 所需的总阶梯数，数值越大节奏越细。
    pnew(K)≈0p_{\text{new}}(K) \approx 0

回滚流程设计

一次漂亮的撤车行动，调度中心执行的是写进手册的 SOP：先评估哪些线路风险最高、优先撤哪里；再定方案、定负责人、定止损线；然后通知检修队待命，逐线执行；最后盯一个完整高峰确认恢复。四步缺一不可——没有评估会拍脑袋，没有方案会手忙脚乱。

模型回滚同样有一份标准四步流程。回滚前评估：确认触发条件真实、定位问题范围，避免因为一次抖动就误伤新版本。制定回滚方案：确定目标版本、阶梯节奏、负责人与沟通渠道。执行流量调度：按计划逐级降流，必要时同时回退模型配置和特征开关。恢复效果验证：指标回到健康区间才算真正落地。

流程中最关键的一道闸门是“验证”：只有连续多个观察周期都证明旧模型稳定，才允许进入下一阶梯。一票否决，绝不侥幸——这就像撤车后投诉率还在涨，就说明旧车也没接住，得先排查别的问题。

四步流程把“撤车”从一次冒险变成一场有排练的演出：评估防拍脑袋，方案防手忙脚乱，调度防乱序，验证防半途而废。调度台和 MLOps 平台，在这一点上惊人地相似。

⋀j=1M(Ej<θsafe)⇒进入下一阶梯\displaystyle \bigwedge_{j=1}^{M} \left( E_j < \theta_{\text{safe}} \right) \Rightarrow \text{进入下一阶梯}
公式说明：\(\bigwedge\) 表示“且”（逻辑与），\(E_j\) 是第 j 个观察周期的错误率，\(\theta_{\text{safe}}\) 是比熔断阈值更严格的安全阈值。所有 M 个周期都达标，才放行下一步。
  1. E_j 单周期错误率第 j 个观察周期内统计到的错误率，每个周期对应一次独立验证。
    Ej=FjQjE_j = \frac{F_j}{Q_j}
  2. θ_safe 安全阈值比熔断阈值更严格的健康线，要求指标明显好转，而不是“勉强不崩”。
    θsafe<θcrit\theta_{\text{safe}} < \theta_{\text{crit}}
  3. M 连续周期数需要连续几个周期全部达标，防止一次偶发抖动骗过判断。
    j=1,2,…,Mj = 1,2,\dots,M
  4. 逻辑与 ∧所有 M 个条件同时成立，才允许切到下一阶梯，任何一个不达标都要停下。
    ⋀j=1M(Ej<θsafe)\bigwedge_{j=1}^{M} \left( E_j < \theta_{\text{safe}} \right)

监控自动中止

调度的夜晚总有没有人值守的时刻。公交集团给调度系统装了一个“自动刹车”：某条线路新车故障率连续三分钟超阈，系统不等调度员，直接命令该线路所有新车退出、换旧车上线，同时给值班调度员发短信。这个设计叫熔断自动中止——机器先兜底，人再复核。

模型服务的自动中止，是无人值守状态下快速止损的保险丝。它由三部分组成：实时指标监控（秒级采集错误率与业务指标）、熔断器（按条件自动切断异常流量）、告警联动降级（通知值班人员介入确认）。注意，自动中止不是取消人工，而是把“第一时间止血”交给机器，把“根因分析”留给人。

熔断器的判据通常是“连续超阈”，目的是过滤单次抖动。用计数变量 \(K_t\) 记录连续超阈次数：当前窗口超阈就加一，正常就清零，达到上限 \(N_{\max}\) 就立即中止。

自动刹车和熔断器的本质一样：把“怕错过”变成“规则兜底”。有了它，凌晨三点新模型出问题，系统自己就把车安全停进车库，再打电话叫醒你——这就是工程化的安全感。

Kt={Kt−1+1,Et>θcrit0,Et≤θcritKt≥Nmax⁡⇒自动中止\displaystyle K_t = \begin{cases} K_{t-1} + 1, & E_t > \theta_{\text{crit}} \\ 0, & E_t \le \theta_{\text{crit}} \end{cases}\qquad K_t \ge N_{\max} \Rightarrow \text{自动中止}
公式说明：\(E_t\) 是当前时间片的错误率，\(\theta_{\text{crit}}\) 是熔断阈值，\(K_t\) 是连续超阈计数。计数达到 \(N_{\max}\) 时，熔断器打开，所有流量强制切回旧模型。
  1. E_t 当前时间片错误率当前处理周期内的实时错误率，由这一小段时间的失败请求决定。
    Et=FtQtE_t = \frac{F_t}{Q_t}
  2. θ_crit 熔断阈值判定严重异常的错误率上限，比观察期使用的安全阈值更宽松、更紧急。
    Et>θcritE_t > \theta_{\text{crit}}
  3. K_t 连续超阈计数超阈则加一，正常则清零，用“连续”二字过滤毛刺。
    Kt=Kt−1+1K_t = K_{t-1} + 1
  4. N_max 熔断上限连续超阈达到该次数即触发自动中止，相当于“连续三分钟抛锚就自动撤车”。
    Kt≥Nmax⁡⇒abortK_t \ge N_{\max} \Rightarrow \text{abort}

工程实践要领

公交集团每年做两次“撤车演习”：封路、模拟故障、把新车按排练好的剧本逐批退场。旧车也从不报废——车况最好的 100 辆永远封存待命，关键零部件按型号备足。演习和存档，就是回滚背后的工程底气。没有演练的预案，只是纸上谈兵；没有存档的旧版，根本无路可退。

模型回滚的工程实践要领有四条。全链路协作：算法、平台、业务方一起定回滚预案，明确谁决策、谁执行、谁通报。回滚应急演练：定期模拟新模型故障，让“点击回滚”变成肌肉记忆。版本治理规范：旧模型的权重文件、镜像、配置全部留档，确保随时可以重新加载。复盘持续改进：每次回滚后总结根因，修补预案漏洞。

工程上衡量回滚质量，最常用的指标是 MTTR（平均恢复时长）——从发现异常到服务完全恢复的平均时间。它像公交集团的“故障平均停运分钟数”：这个数字越小，说明撤车动作越果断、节奏越熟练。

练习让回滚从“应激反应”变成“标准动作”。下一次新模型翻车时，你会发现：下撤和上线一样，都需要艺术。而艺术的背后，是一套被反复排练的安全流程。

MTTR=1K∑i=1KTi\displaystyle \text{MTTR} = \frac{1}{K} \sum_{i=1}^{K} T_i
公式说明：\(T_i\) 是第 i 次事故的恢复时长，\(K\) 是统计期内的回滚次数，MTTR 就是它们的平均值。灰度回滚设计得越好，MTTR 越低。
  1. T_i 单次恢复时长第 i 次事故从触发回滚到指标恢复正常的耗时，包含评估、调度、验证全过程。
    Ti=Tend,i−Tstart,iT_i = T_{\text{end},i} - T_{\text{start},i}
  2. K 事故次数统计周期内的回滚事件总数，样本越多平均越可信。
    K=回滚次数K = \text{回滚次数}
  3. 求和与平均把所有恢复时长加总再除以次数，得到全局平均止损速度。
    ∑i=1KTi÷K\sum_{i=1}^{K} T_i \div K
  4. 目标最小化 MTTR灰度回滚做得越好，平均恢复时间越短，服务质量越稳。
    MTTR→min⁡\text{MTTR} \to \min

AI 应用场景

大语言模型线上服务的紧急回滚

阶段：模型监控与告警响应

解决的问题：新版本大语言模型上线后出现偶发“幻觉”和答非所问，离线评测看不出问题，线上投诉却在深夜飙升。直接全量回滚会导致对话服务短时中断，用户正在进行的会话被强制断开；灰度回滚让流量在几分钟内阶梯式切回稳定版本，会话不断、体验无感。

具体案例：某智能客服平台上线 v2 对话模型，监控大屏显示“答非所问”投诉率飙升并触发告警。值班工程师在 MLOps 平台点击“启动回滚”，流量按照 30% → 23% → 16% → 9% → 2% 逐级切换回 v1，每一步自动观察 3 分钟。21 分钟后错误率跌破阈值，回滚完成，全程零会话中断。

推荐系统新特征下线的平滑回退

阶段：模型上线后的灰度验证与回滚

解决的问题：推荐模型加入新特征后点击率不升反降，直接全量切回旧配置会同时失效大量特征缓存，产生“推荐闪烁”和首屏变慢。按用户分片灰度回滚，可以只回退受影响的分片，保留部分新特征样本供后续归因分析。

具体案例：某电商 App 大促前发现推荐位人均点击下降 8%，算法团队按 20% → 10% → 5% 的用户分片切回上一版特征配置，每步观察一个完整高峰时段。大促当天异常消失，同时保留了 5% 分片用于复盘新特征为何失效。

风控反欺诈模型的误杀纠偏

阶段：模型效果监控与响应

解决的问题：新版风控模型对正常用户的误杀率翻倍，直接影响支付体验。整体回滚会放过真正的新风险模式，于是按风险场景分组灰度回滚：只对误杀高发的场景切回旧模型，其余场景继续观察新模型表现。

具体案例：某支付平台新模型对“新设备登录”场景误杀率从 0.5% 升至 1.2%，判断为训练样本分布偏差。回滚策略只对该场景流量阶梯降流，三天后从误杀率已回落的场景逐步重新引入新模型，实现了“精准撤车、不误伤全局”。

Python 演示

python56 行
"""Model gray rollback simulator: step-down traffic + auto abort with monitoring."""import randomimport time  class GrayRollbackSimulator:    def __init__(self, start_share=0.30, error_threshold=0.10, abort_limit=3):        self.share = start_share        self.error_threshold = error_threshold        self.abort_limit = abort_limit        self.fail_count = 0        self.levels = [0.23, 0.16, 0.09, 0.02]     def measure_error(self, share):        # Higher new-model traffic share leads to higher error rate        return 0.03 + max(0.0, share - 0.02) * 0.55 + random.uniform(-0.01, 0.01)     def observe_once(self):        error = self.measure_error(self.share)        if error > self.error_threshold:            self.fail_count += 1            print("  observe error %.3f > %.2f" % (error, self.error_threshold))            if self.fail_count >= self.abort_limit:                self.abort()                return False        else:            self.fail_count = 0            print("  observe error %.3f healthy" % error)        return True     def step_down(self):        target = self.levels.pop(0)        print("step down: new share %.0f%% -> %.0f%%, enter observe"              % (self.share * 100, target * 100))        self.share = target        for _ in range(2):            if not self.observe_once():                return False            time.sleep(0.3)        return True     def abort(self):        print("abort: force all traffic back to old model v1")        self.share = 0.0        self.levels.clear()     def run(self):        print("gray rollback start: new model share = %.0f%%" % (self.share * 100))        while self.levels:            if not self.step_down():                break        print("done: new model share = %.0f%%" % (self.share * 100))  if __name__ == "__main__":    GrayRollbackSimulator().run()
目的：模拟一次完整的灰度回滚——从 30% 流量起步，按 23% → 16% → 9% → 2% 阶梯降流，每步观察两个周期；若错误率连续超阈则自动熔断，强制全部切回旧模型。
  1. self.levels = [0.23, 0.16, 0.09, 0.02]定义回滚阶梯表，对应每次撤下一批新车
  2. self.share = target执行降流，把新模型流量占比切到目标值
  3. return 0.03 + max(0.0, share - 0.02) * 0.55 + random.uniform(-0.01, 0.01)模拟“新流量越大错误率越高”的规律
  4. if error > self.error_threshold:把观察到的错误率与回滚阈值比对
  5. self.fail_count += 1累计连续超阈的窗口数，正常则清零
  6. if self.fail_count >= self.abort_limit:达到熔断上限，触发自动中止
  7. self.levels.clear()清空后续阶梯，终止回滚计划，防止继续冒险
  8. for _ in range(2):每个阶梯观察两个周期，达标后才放行下一步

常见误区

误区反正旧模型是好的，直接改一下路由配置，把 100% 流量瞬间切回旧版本，问题不就立刻解决了吗？为什么要搞得那么复杂？

正解全量切回会在瞬间反转整张流量路由表，导致连接风暴、缓存冷启动、下游服务队列被打爆，服务可能从“坏”变成“更坏”。就像调度中心一次性撤光所有新车，全市乘客会同时困在路上。灰度回滚用 5%～10% 的步长逐步切换，正是为了给系统和用户留出缓冲。

为何常见：人的直觉天然把“切换”看作两种离散状态——要么新要么旧，忽略了大规模分布式系统里“切换动作本身”也会造成冲击。

误区上线前只要灰度测试做得足够充分，把每条链路都验证一遍，新模型就不会出问题，回滚是给那些准备不充分的人用的。

正解灰度只能降低风险，不能消除风险。线上流量分布、用户行为、数据漂移都是动态的，测试环境永远无法 100% 复现生产环境。回滚不是失败的标志，而是成熟系统必备的安全机制——就像安全气囊平时不弹，但车上不能没有。

为何常见：把“回滚”和“失败”绑定在一起，会让团队羞于准备预案，反而在事故来临时手足无措。

误区监控红灯一亮，马上把所有流量切回旧模型，越快越好，晚一分钟都是事故。

正解单次抖动可能是网络波动或流量毛刺，需要连续窗口确认，否则会因为误报频繁打断正常服务。但反过来，一旦确认连续超阈、达到熔断条件，就必须坚决自动中止，不能犹豫。判断的节奏是“观察要稳，熔断要快”。

为何常见：把“触发条件”和“熔断动作”混为一谈，要么反应过度频繁误伤，要么错过最佳止损窗口。

误区切回旧模型后，错误率指标恢复正常，回滚就大功告成，可以关掉监控去睡觉了。

正解切回只是完成了“止血”这一步，后面还必须有恢复效果验证、根因复盘和预案修订。如果不搞清楚新模型为什么翻车，下一版可能重蹈覆辙。就像旧车重新上路后，调度员还要盯完一个完整高峰，确认投诉率真正回落。

为何常见：只看到“切流量”这一个动作，忽略了回滚是一条包含评估、执行、验证、复盘的完整闭环。

面试题

Q1. 灰度回滚的核心思想是什么？

单选题 · easy

  • A.一次性将流量全部切回旧模型，速度最快
  • B.逐步减少新模型流量，分阶段切回旧模型← 正确答案
  • C.同时运行新旧两个模型，从不切换流量
  • D.直接下线新模型并删除其所有版本

答案：B。灰度回滚的精髓是“分步下撤”，就像调度中心不一次性撤光新车，而是逐批换回旧车，B 正确。A 是一刀切的全量回滚，风险大；C 没有回滚动作；D 删版本等于放弃退路，违背灰度思想。

Q2. 某时间窗口内总请求数 Q=10000，失败请求数 F=200，则该窗口错误率 E 是多少？

单选题 · easy

  • A.0.2%
  • B.1%
  • C.2%← 正确答案
  • D.20%

答案：C。E = F / Q = 200 / 10000 = 0.02 = 2%，选 C。0.2% 是把失败数误当成 20 的结果，20% 是把 Q 误算成 1000 的结果，0.2% 和 20% 都是数量级错误。

Q3. 灰度回滚中设置“观察期”的主要目的是什么？

单选题 · mid

  • A.给新模型更多时间自我修复
  • B.验证当前流量下指标稳定性← 正确答案
  • C.让用户提前适应新模型
  • D.节省回滚服务器资源开销

答案：B。观察期负责验证当前流量比例下指标是否稳定，避免指标滞后造成误判，如同撤车后要等一个完整高峰才决定下一步。A 把回滚当成修复新模型的手段，方向就错了；C、D 都与观察期的目的无关。

Q4. 熔断“自动中止”机制通常基于什么条件触发？

单选题 · mid

  • A.运维人员发现一次异常后手动点击
  • B.错误率连续 N 个窗口超过熔断阈值← 正确答案
  • C.新模型流量降至零后自动触发
  • D.旧模型收到流量后自动触发

答案：B。熔断器用“连续 N 个窗口超阈”来降低误报，类似调度系统连续三分钟抛锚才自动撤车，B 正确。A 是人工介入，不属于自动触发；C、D 的描述都不是熔断的触发条件。

Q5. 在递推式 p_new(k) = p_new(k-1) - Δp 中，Δp 表示什么？

单选题 · mid

  • A.每步下降的流量占比大小← 正确答案
  • B.每个观察周期的时长
  • C.当前窗口的错误率
  • D.单位时间总请求数

答案：A。Δp 是降流步长，即每步削减小多少个百分点的流量，相当于每次撤下 10% 的新车。B 是观察期、C 是错误率、D 是请求量，它们都不是递推式中的 Δp 所代表的量。

Q6. 关于“恢复效果验证”进入下一阶梯的条件，下列说法正确的是？

单选题 · hard

  • A.连续 M 个周期错误率均低于安全阈值← 正确答案
  • B.只有某个周期错误率低于阈值就继续
  • C.新模型流量占比高于旧模型即可继续
  • D.错误率低于熔断阈值即可无需持续观察

答案：A。连续 M 个周期全部低于安全阈值，才允许进入下一阶梯——用“连续”过滤偶发抖动，如同调度台要求连续两个高峰投诉率正常才继续撤车。B 只看单点、D 只看熔断阈值，都过滤不了抖动；C 与验证目标无关。

Q7. 关于全量回滚的风险，下列说法正确的是？

单选题 · easy

  • A.全量回滚没有任何风险存在
  • B.全量回滚可能引发连锁冲击← 正确答案
  • C.全量回滚只影响新模型
  • D.全量回滚比灰度回滚安全

答案：B。全量回滚看似最快，实则瞬间反转路由会引发连接风暴、缓存冷启动和下游拥塞，可能让故障扩大，B 正确。A、D 与工程常识相悖；C 忽略了切换动作对全局资源的影响。

Q8. 以下哪些属于灰度回滚的常见触发条件？

多选题 · mid

  • A.业务指标异常如转化率客诉上升← 正确答案
  • B.系统资源告警如延迟内存异常← 正确答案
  • C.错误率连续窗口超过设定阈值← 正确答案
  • D.新模型代码评审最终顺利通过

答案：ABC。业务指标异常、系统资源告警、错误率超阈都是典型触发条件，对应调度大屏上的“客诉率、抛锚率、运营异常”三类红灯。D 是上线前的质量保障动作，不构成回滚触发条件。

Q9. 下列哪些属于良好的回滚工程实践？

多选题 · mid

  • A.保留旧模型可回滚的版本配置← 正确答案
  • B.定期开展回滚应急演练工作← 正确答案
  • C.回滚完成后进行复盘改进← 正确答案
  • D.出现问题后永久禁用回滚能力

答案：ABC。保留旧版本制品、定期演练、复盘改进都是回滚工程的标配，像公交集团封存车况最好的旧车并年年演习。D 永久禁用回滚能力等于拆掉最后一道安全闸，是典型的反面做法。

Q10. 关于自动中止（熔断）机制的描述，正确的有哪些？

多选题 · hard

  • A.熔断后应逐步小幅切回旧模型
  • B.熔断需指标持续超阈降低误报← 正确答案
  • C.熔断后自动降级并通知人工确认← 正确答案
  • D.熔断触发后无需任何人工介入

答案：BC。自动熔断要求指标持续超阈以降低误报（B）；熔断后平台自动降级并通知值班人员确认（C），故答案 [1,2]。A 把熔断后的强制切回误解成“逐步下撤”，熔断是快速止损动作而非日常节奏；D 忽略熔断后必须人工介入复核根因。