想象一家刚开业的网红餐厅：后厨灶台上方装着两排报警器，一排盯着油炸锅油温，一排闻着燃气泄漏；门口挂着意见本，传菜员会顺口带一句“3号桌说汤咸了”；打烊后还有一名大厨留守电话，钥匙和交接本都交到他手上。深夜油温飙到180℃报警器响起，值班大厨五秒接电话、十分钟赶到后厨——这一整套“报警、值守、处置、复盘”的体系，就是AI产品上线后最需要的生存技能。AI产品部署到生产环境后，模型会变慢、会报错、会烧钱、会被用户吐槽，就像餐厅会停电、会漏水、会被差评一样。你无法阻止所有意外，但你可以让每个意外都有人听见、有人负责、有人按预案处置，并且把每次意外变成下一次更稳的台阶。本文将带你用“后厨管理”的视角，把运维告警、on-call值班、应急响应、反馈闭环、Token成本与评测迭代这六件事一次讲透。

岗位关联

学会告警分级、on-call值班与应急演练这套体系，你就能让AI产品从“能上线”走向“稳运行”——这是AI产品经理从执行者晋升为负责人的关键能力。

目录
  1. 可视化演示
  2. 告警体系设计
  3. 告警疲劳治理
  4. On-call值班机制
  5. 应急响应SOP
  6. 反馈机制构建
  7. Token成本优化
  8. 评测驱动迭代
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示多维度告警指标监控与阈值触发、On-call主备轮值时间线、以及故障处理六步流程的可视化。

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

告警体系：多维度指标监控 P50/P95/P99=延迟指标 ERR=错误率 QPS=吞吐 红色=超过阈值触发告警 虚线=告警阈值 metric > threshold -> alert AI运维需监控延迟错误率吞吐量等多维指标

告警体系设计

深夜的网红餐厅后厨，灶台边装了两排报警器：一排在油炸锅上方，油温超过180℃就滴滴响；一排在燃气阀门旁，闻到泄漏立刻拉响。报警器不是越多越好，而是要根据“烧坏了什么后果最严重”来分类安装——炸锅冒烟是大事，蒸汽大只是小事。

AI产品也一样。上线后，模型API的错误率、响应延迟、成本消耗、用户投诉量，就是需要“装报警器”的关键指标。告警体系设计，本质是回答三个问题：什么值得报（指标）、什么程度报（阈值）、怎么报（渠道和内容）。先做分级，业内常用四级：提醒（仅记录日志）、警告（提示关注）、严重（影响部分用户）、紧急（服务不可用）。级别越高，通知渠道越重——警告走IM群，严重走短信加电话，紧急直接拉群开会。阈值不能拍脑袋，要基于压测基线和线上历史：比如把P99延迟的1.5倍设为警告线、2倍设为严重线。告警内容必须五要素齐全：时间、指标名、当前值、影响面、建议动作。

就像给后厨装报警器要写明“油温高→关小火→开排烟”，每条告警都应该让值班人一眼看懂“发生了什么、该怎么办”，而不是一条干巴巴的“数值异常”。

error_rate=EN×100%,alert=(error_rate>Tw)∨(latencyp99>Tl)\text{error\_rate} = \frac{E}{N} \times 100\%, \qquad\text{alert} = (\text{error\_rate} > T_w) \vee (\text{latency}_{p99} > T_l)
这条公式告诉你：告警不是“感觉有问题”，而是错误率超过警告阈值，或最慢的1%请求延迟超过延迟红线，任一条件成立就触发。
  1. 错误率计算$E$ 是失败请求数，$N$ 是总请求数，两者相除再乘100%，得到错误率百分比。
    error_rate=EN×100%\text{error\_rate} = \frac{E}{N} \times 100\%
  2. 警告阈值判定当错误率超过警告线 $T_w$ 时，产生警告级告警。
    error_rate>Tw\text{error\_rate} > T_w
  3. 延迟红线判定$\text{latency}_{p99}$ 表示最慢的1%请求的延迟值，它超过 $T_l$ 时同样触发告警。
    latencyp99>Tl\text{latency}_{p99} > T_l
  4. 逻辑或合并$\vee$ 表示“或”，两个条件任一成立，告警就成立，确保错误率和延迟互相兜底。
    (error_rate>Tw)∨(latencyp99>Tl)(\text{error\_rate} > T_w) \vee (\text{latency}_{p99} > T_l)

告警疲劳治理

后厨的报警器如果三天两头误报——炒辣椒也响、蒸汽大也响——大家就会把它当成背景音。真有一天油锅起火，报警器在响，厨师长却问：“又是误报吧？”——这就是告警疲劳。

AI产品上线后最常见的坑，不是没有告警，而是告警太多。凌晨三点连发40条同类告警，值班人第一反应是静音手机而不是爬起来处理。告警疲劳会让最关键的告警也失去效力，就像“狼来了”喊多了，真狼来了也没人信。

治理的招法主要有四招。第一，聚合去重：同一故障源10分钟内只发1条，后续变化用“已更新”追加。第二，冷却窗口：同类告警触发后进入静默期，指标不进一步恶化就不再重复打扰。第三，动态阈值：根据历史基线自动调整，业务高峰时段阈值适当上调，避免“正常波动”被当成故障。第四，噪音识别：把告警命中率纳入监控报表，定期清理那些“从未被确认过的告警规则”，让每条规则都有人负责。

好的报警器就该“该响的时候响一声就够了”——这声得响在点子上，大家才会当真。

notify=I(statet=ALERT)∧(t−tlast≥Δtcool)\text{notify} = I(\text{state}_t = \text{ALERT}) \wedge (t - t_{\text{last}} \ge \Delta t_{\text{cool}})
这条公式表示：某时刻处于告警状态，并且距离上一次同类告警已经超过冷却窗口，两个条件同时满足才真正通知值班人。
  1. 告警状态指示$I(\text{state}_t = \text{ALERT})$ 是状态函数，当前指标处于告警状态时为1，否则为0。
    I(statet=ALERT)I(\text{state}_t = \text{ALERT})
  2. 距上次告警时长$t - t_{\text{last}}$ 计算当前时刻与上次同类告警时刻的时间差。
    t−tlastt - t_{\text{last}}
  3. 冷却窗口条件时间差不小于冷却周期 $\Delta t_{\text{cool}}$，即冷却期已过。
    t−tlast≥Δtcoolt - t_{\text{last}} \ge \Delta t_{\text{cool}}
  4. 逻辑与合并$\wedge$ 表示“且”，两个条件同时满足才发出通知，有效过滤重复告警。
    I(statet=ALERT)∧(t−tlast≥Δtcool)I(\text{state}_t = \text{ALERT}) \wedge (t - t_{\text{last}} \ge \Delta t_{\text{cool}})

On-call值班机制

餐厅打烊后，冰箱里还冻着明天要用的食材，万一半夜停电就得有人来救。于是店里排了值班表：每晚有一名大厨留守电话，钥匙和交接本都交到他手里。这就是餐厅的"on-call"。

AI产品上线后同样不能没人管，但也不需要所有人天天盯屏。on-call值班机制的核心是“明确当班人、明确响应时限、明确交接方式”。排班建议按周或双周轮换，白班夜班分开，避免疲劳值守；响应SLO要量化成数字，比如“5分钟内接警确认、15分钟内给出处置结论”；告警认领要落到统一平台，谁认领谁负责，避免“三个和尚没水喝”；交接时必须写交接文档——当前告警状态、已做处理、遗留风险、可联系专家，一项都不能少。

就像值班大厨交接时要报一句“冰箱压缩机有点响，今晚留意”，on-call交接的价值，就是把“只有我知道的事”变成“大家都知道的事”。

on_time_rate=MslaMtotal×100%\text{on\_time\_rate} = \frac{M_{\text{sla}}}{M_{\text{total}}} \times 100\%
这是值班质量的“月考分”：所有告警中，按时响应的那部分占比越高，说明值班机制运转越健康。
  1. 总告警数$M_{\text{total}}$ 表示统计周期内触发的全部告警条数。
    MtotalM_{\text{total}}
  2. 按时响应数$M_{\text{sla}}$ 表示其中在SLO时限内被接警并确认的告警条数。
    MslaM_{\text{sla}}
  3. 比例换算两者相除再乘100%，得到按时响应率，通常要求不低于95%。
    MslaMtotal×100%\frac{M_{\text{sla}}}{M_{\text{total}}} \times 100\%

应急响应SOP

消防演练手册上写着：小火用灭火器，大火拉警报、关燃气、疏散客人。没人指望起火时现场翻手册，但如果没演练过，真到那一刻就是一团乱。应急响应SOP就是提前写好的“着火怎么办”剧本。

AI产品出故障时，团队不需要临场思考“该怎么办”，而是按流程执行。SOP包含四块内容。第一，故障分级：P0指服务不可用或用户数据受损，P1是部分功能异常，P2是体验下降。第二，升级流程：一线值班在时限内没搞定，自动升级二线专家，再超时升级技术负责人，形成三级阶梯。第三，处置预案要具体到动作：回滚版本、关闭非核心功能的降级策略、切换备用集群的流量调度。第四，故障复盘：拉时间线、写根因分析、列行动项并指定owner和截止时间，复盘不为追责，只为下次更快。

手册是拿来练的，不是拿来挂的。每月一轮故障演练，真出事时才能靠“肌肉记忆”完成响应。

level={1tack≤525<tack≤153tack>15\text{level} =\begin{cases}1 & t_{\text{ack}} \le 5 \\2 & 5 < t_{\text{ack}} \le 15 \\3 & t_{\text{ack}} > 15\end{cases}
这条分段函数告诉你：接警耗时在5分钟内由一线自行处置，5到15分钟升级二线，超过15分钟直接上报管理层。
  1. 接警耗时$t_{\text{ack}}$ 指从告警触发到值班人确认接手的时间，以分钟计。
    tackt_{\text{ack}}
  2. 一级响应当 $t_{\text{ack}} \le 5$ 时，故障级别为1级，一线值班自行处置。
    tack≤5t_{\text{ack}} \le 5
  3. 二级响应当接警耗时落在5到15分钟之间，升级到二线专家介入。
    5<tack≤155 < t_{\text{ack}} \le 15
  4. 三级响应超过15分钟仍未处置，拉管理层与全链路负责人线上会商。
    tack>15t_{\text{ack}} > 15

反馈机制构建

餐厅门口放着一本意见本，传菜员也会随口带一句“3号桌说汤咸了”。好口碑一半来自菜好吃，一半来自“客人说的话真的被听了”。对AI产品而言，这个“意见本”就是反馈机制。

反馈机制是产品迭代的燃料：没有它，团队只能闭门造车，改对改错全凭感觉。一套完整的反馈机制分四层。用户反馈层：客服工单、应用内问卷、应用商店评论，系统化自动汇总归类。日志监控层：在LLM调用链路埋点，记录每次请求的模型、prompt、响应质量、是否走了兜底逻辑。业务指标层：追踪留存率、转化率、CSAT满意度、投诉率，业务指标异常本身就是一种“带业务含义的告警”。闭环流程层：收集→归类→改进→验证，每条重要反馈都要能追溯到“改进了没有、上线了没有”。

意见本如果一个月不翻，客人就不再写了。反馈闭环最怕的不是没反馈，而是反馈了没下文。

T‾close=1n∑i=1n(tresolve,i−treport,i)\overline{T}_{\text{close}} = \frac{1}{n}\sum_{i=1}^{n}(t_{\text{resolve},i} - t_{\text{report},i})
平均关闭时长衡量反馈机制“转起来有多快”：从用户报告到问题解决，平均耗时越短，闭环越健康。
  1. 单条反馈时长$t_{\text{resolve},i} - t_{\text{report},i}$ 是第 $i$ 条反馈从提交到解决的时间差。
    tresolve,i−treport,it_{\text{resolve},i} - t_{\text{report},i}
  2. 求和汇总$\sum_{i=1}^{n}$ 把 $n$ 条反馈的时长全部相加。
    ∑i=1n(tresolve,i−treport,i)\sum_{i=1}^{n}(t_{\text{resolve},i} - t_{\text{report},i})
  3. 取平均值总和除以 $n$，得到单条反馈的平均处理时长，可作为团队周报的核心指标。
    T‾close=1n∑i=1n(tresolve,i−treport,i)\overline{T}_{\text{close}} = \frac{1}{n}\sum_{i=1}^{n}(t_{\text{resolve},i} - t_{\text{report},i})

Token成本优化

餐厅的招牌菜用鱼子酱，按克计价；但炒饭里的虾仁、例汤里的排骨，也得精打细算。好大厨的功夫之一，就是让每一分食材预算都花在客人尝得出的地方。AI产品的“鱼子酱”就是token。

大模型按token计费，输入输出都花钱。产品上线后调用量上涨，成本会从“小事”变成“大事”。Token成本优化不是抠门，而是让每块钱花得值。具体有四条主线。成本构成分析：拆分输入、输出token占比，按功能模块统计，先搞清钱花在哪。上下文缓存复用：把系统提示语和知识库前缀缓存起来，命中后输入token费用大幅下降。模型分级路由：简单问题如分类、抽取走小模型，复杂推理才调大模型，组合使用通常能省30%到50%。预算告警机制：设定日、月成本阈值，成本增速超预期自动告警，防止“一夜烧掉一个季度的钱”。

高汤是餐厅的秘密武器：熬一次、留起来、反复用。上下文缓存就是这个道理——花一次的钱，用很多次。

C=pin×nin+pout×nout,save=1−CafterCbeforeC = p_{\text{in}} \times n_{\text{in}} + p_{\text{out}} \times n_{\text{out}}, \qquad\text{save} = 1 - \frac{C_{\text{after}}}{C_{\text{before}}}
这条公式拆解了每次调用的“账单”，并给出成本节省率：优化后成本越低，节省率越接近100%。
  1. 输入成本$p_{\text{in}}$ 是输入token单价，$n_{\text{in}}$ 是输入token数量，两者相乘得到输入费用。
    pin×ninp_{\text{in}} \times n_{\text{in}}
  2. 输出成本$p_{\text{out}}$ 是输出token单价，$n_{\text{out}}$ 是输出token数量，两者相乘得到输出费用。
    pout×noutp_{\text{out}} \times n_{\text{out}}
  3. 总成本输入费用加上输出费用，就是单次调用的总成本 $C$。
    C=pin×nin+pout×noutC = p_{\text{in}} \times n_{\text{in}} + p_{\text{out}} \times n_{\text{out}}
  4. 节省率$C_{\text{after}}$ 是优化后成本，$C_{\text{before}}$ 是优化前成本，节省率 = 1 减去两者比值。
    save=1−CafterCbefore\text{save} = 1 - \frac{C_{\text{after}}}{C_{\text{before}}}

评测驱动迭代

招牌菜想换配方？老师傅会先在后厨试做给团队成员吃，再在周末小范围试卖，客人评分高了才正式更新菜单。AI产品改prompt、换模型、调参数，都属于“换配方”。

评测驱动迭代，就是让每次改动都先过评测、再上小流量、最后全量，而不是“拍脑袋改、上线看命”。四个环节缺一不可。评测集构建：准备100到200条覆盖典型场景和边界case的评测样本，标注参考答案。回归测试体系：每次改动后跑全量评测集，得分不低于历史版本才允许继续。A/B实验验证：灰度流量按比例分配，新老版本对比关键指标，用数据说话。灰度发布决策：按10%→50%→100%逐步放量，每一步都以“新版本不劣于旧版本”为通过线，否则立即回滚。

好菜是试出来的，好AI产品是一版一版评测出来的。每一次灰度放量都是“试卖”，每一次评测都是“试吃”。

pass=(accnew≥accold−ϵ)∧(errnew≤errold+δ)\text{pass} = (\text{acc}_{\text{new}} \ge \text{acc}_{\text{old}} - \epsilon) \wedge (\text{err}_{\text{new}} \le \text{err}_{\text{old}} + \delta)
灰度通过判定公式：新版准确率不显著低于旧版，且错误率不显著高于旧版，两者同时成立才允许继续放量。
  1. 准确率底线$\text{acc}_{\text{new}}$ 是新版准确率，$\text{acc}_{\text{old}}$ 是旧版准确率，$\epsilon$ 是允许的容差。
    accnew≥accold−ϵ\text{acc}_{\text{new}} \ge \text{acc}_{\text{old}} - \epsilon
  2. 错误率上限$\text{err}_{\text{new}}$ 是新版错误率，$\text{err}_{\text{old}}$ 是旧版错误率，$\delta$ 是允许上浮的容差。
    errnew≤errold+δ\text{err}_{\text{new}} \le \text{err}_{\text{old}} + \delta
  3. 双条件合取$\wedge$ 要求两个条件同时满足，任何一项不达标都判定为不通过，回滚再调。
    (accnew≥accold−ϵ)∧(errnew≤errold+δ)(\text{acc}_{\text{new}} \ge \text{acc}_{\text{old}} - \epsilon) \wedge (\text{err}_{\text{new}} \le \text{err}_{\text{old}} + \delta)

AI 应用场景

AI客服机器人上线首夜保障

阶段：上线与运维阶段

解决的问题：大模型客服机器人上线初期，流量突增导致P99延迟从300ms飙升到2秒，用户等待超时纷纷挂断。没有告警体系时，团队往往在第二天看后台数据才发现事故；有了告警分级与on-call值班，严重线一破，值班SRE 5分钟内接警、10分钟内扩容，把事故消灭在用户感知之前。

具体案例：某金融公司AI客服上线当晚，配置了“错误率70%警告、90%严重”双层告警，并建立双周轮换的on-call排班表。凌晨2点延迟突破严重线，电话告警直达值班工程师，15分钟内完成实例扩容，当夜零客诉。

LLM应用Token成本治理

阶段：成本优化阶段

解决的问题：API费用随调用量线性爆炸，月度账单从几千跳到几十万。传统方式是“砍预算”，但容易误伤核心功能。用成本构成分析加模型分级路由，先拆解各模块消耗，再把简单请求分流到小模型，并开启上下文缓存复用，让成本降下来且体验不降级。

具体案例：某知识库问答机器人，FAQ类问题占70%流量，全部路由到轻量模型并命中前缀缓存，复杂文档问答才调用大模型。月底账单显示整体成本下降45%，平均响应时间反而快了200ms。

评测驱动的大模型Prompt迭代

阶段：评测迭代阶段

解决的问题：产品经理凭感觉改prompt，这周把问题“修好”了下周又把别处“改坏”，回归问题频发。引入评测集和回归测试后，每次改动先跑100条基准用例，得分下滑直接拦截，再通过A/B灰度验证后全量上线。

具体案例：某电商导购助手团队建立120条评测集（含价格问询、售后、比价等边界case），每次prompt修改先过回归，再按10%流量灰度3天，转化率不劣于旧版才全量。三个月内上线17次迭代，仅出现1次回滚。

Python 演示

python80 行
# -*- coding: utf-8 -*-"""AI产品上线监控:告警触发,冷却去重,on-call升级模拟"""import random  class AlertingEngine:    """告警引擎:阈值判定,冷却去重,升级时限管理"""     def __init__(self, warn_th=70, crit_th=90, cooldown=3, ack_timeout=4):        self.warn_th = warn_th        self.crit_th = crit_th        self.cooldown = cooldown        self.ack_timeout = ack_timeout        self.alert_list = []       # 已触发告警        self.silent_until = 0      # 冷却截止时刻        self.ack_deadline = None   # 严重告警确认时限        self.clock = 0     def _eval_level(self, error_rate, latency):        """返回 0 正常 / 1 警告 / 2 严重"""        if error_rate >= self.crit_th or latency >= 1500:            return 2        if error_rate >= self.warn_th or latency >= 800:            return 1        return 0     def feed(self, error_rate, latency):        self.clock += 1        level = self._eval_level(error_rate, latency)        if level == 0:            return "ok"        if self.clock < self.silent_until:            return "suppressed"        self.alert_list.append({            "clock": self.clock,            "level": level,            "error_rate": round(error_rate, 1),            "latency": round(latency),        })        self.silent_until = self.clock + self.cooldown        if level == 2:            self.ack_deadline = self.clock + self.ack_timeout        return "critical" if level == 2 else "warning"     def escalate_if_needed(self):        """超过确认时限仍未恢复,升级给二线专家"""        if self.ack_deadline is not None and self.clock >= self.ack_deadline:            self.ack_deadline = None            return "escalate"        return "normal"  def main():    random.seed(7)    engine = AlertingEngine()    print("=== AI产品上线监控模拟 (0-30分钟) ===")    error_rate = 20.0    for minute in range(31):        if 12 <= minute <= 15:            error_rate = random.uniform(85, 98)            latency = random.uniform(900, 1800)        else:            error_rate = max(5.0, error_rate + random.uniform(-4, 4))            latency = random.uniform(100, 600)        result = engine.feed(error_rate, latency)        if result == "warning" or result == "critical":            print("t=%2d  [%s] error_rate=%.1f%% latency=%.0fms"                  % (minute, result, error_rate, latency))        elif result == "suppressed":            print("t=%2d  [suppressed] 冷却窗口内去重,不打扰值班"                  % minute)        action = engine.escalate_if_needed()        if action == "escalate":            print("t=%2d  [escalate] 超过确认时限,升级给二线专家" % minute)    print("模拟结束:共触发告警 %d 条,冷却去重避免了告警风暴"          % len(engine.alert_list))  if __name__ == "__main__":    main()
目的：模拟一个AI产品上线后的30分钟监控，演示“阈值判定→冷却去重→on-call升级”的完整告警链路。
  1. random.seed(7)固定随机种子，让每次运行结果可复现，方便回归验证。
  2. engine = AlertingEngine()创建告警引擎，默认警告线70%、严重线90%、冷却窗口3分钟、确认时限4分钟。
  3. def _eval_level(self, error_rate, latency)核心判定：错误率或延迟任一突破红线即返回对应级别。
  4. if self.clock < self.silent_until: return "suppressed"冷却窗口内直接吞掉同类告警，避免告警风暴。
  5. self.alert_list.append({...})只有真正触发的告警才入记录，供事后复盘统计。
  6. if level == 2: self.ack_deadline = self.clock + self.ack_timeout严重告警设置确认时限，超时即触发升级。
  7. engine.escalate_if_needed()每次采样后检查是否超时未处理，超时则升级给二线专家。
  8. print("t=%2d [%s] ..." % ...)按分钟打印告警日志，直观看到“第12分钟故障爆发、冷却期被抑制、超时升级”的全过程。

常见误区

误区我总是觉得，告警规则越多、监控越全面，系统就越安全。于是我把每个指标都配上三条告警，结果手机一晚上响几十次，我干脆把通知全关了。

正解告警过多会引发告警疲劳，让值班人对所有告警麻木，真正严重的告警反而被淹没。就像后厨装了十个报警器天天误报，真起火时没人当回事。正确的做法是“贵精不贵多”：每个故障模式只配一条高价值告警，配合聚合去重和冷却窗口，让每条告警都有明确的处置动作。

为何常见：人天然倾向“多一层保险”，觉得多设规则总比漏报强。但忽视了告警的接收方是注意力有限的人类，噪音会挤占真正信号的通道。

误区我以为做on-call值班就是要一直盯着监控大屏，眼睛不能离开，所以特别抗拒排班，觉得这会把人累垮。

正解值守的重点不是“盯着”，而是“兜底”。日常靠自动化监控和告警系统发现问题，人只需要在告警触发时按SLO响应。就像值班大厨不是站在灶台前等起火，而是留了电话、接了报警器，响了才行动。好的值班机制还包含升级链路和交接文档，把单点压力分散给整个团队。

为何常见：很多人把“on-call“误解为”人工监控”，是因为见过落后的团队真的让人盯屏。实际上成熟的SRE团队都在做告警压缩和自愈，人只是最后一道防线。

误区我花一周时间写了厚厚的应急响应手册，从分级到回滚写得清清楚楚，然后就把它存档了。后来真的出故障，大家还是手忙脚乱，手册根本没派上用场。

正解预案的价值在于“被演练过”，而不在于“被写过”。就像消防手册挂在墙上，不演习的话，火场里没人记得住步骤。每月至少做一次故障演练，用混沌工程随机注入故障，让团队在低压力环境下把SOP走成肌肉记忆，真出事才能按流程执行。

为何常见：写文档带来“已经准备好了”的错觉，人们容易把“制定计划”误当成“具备能力”。实际上从知道到做到之间，隔着反复练习。

误区我一看账单爆炸，第一反应是“把GPT-4换成便宜的小模型”。结果复杂问题回答质量明显下降，用户投诉增加，成本是降了，体验崩了。

正解成本优化是系统工程，模型选择只是其中一环，而且是最不该先动的一环。正确顺序是：先做成本构成分析，再用上下文缓存复用和prompt压缩减少token消耗，最后才考虑对不同难度请求做分级路由。就像省钱不能只靠买最便宜的食材，而是先看哪里浪费、哪里可以复用。

为何常见：“换便宜模型”是最直观、最省事的降本动作，人们容易忽略质量代价和更精细的优化手段。

误区我觉得评测集就是一次性资产，建好100条用例就能一直用。结果三个月后，明明评测分数很高，线上用户反馈却越来越差。

正解评测集需要持续更新，因为业务场景、用户表达、模型能力都在变化。旧用例会过拟合，新出现的边界case覆盖不到，评测分数就会失真。正确做法是把评测集当“活文档”：每次灰度失败、每次用户投诉，都把典型案例补充进评测集，让回归测试越来越贴近真实世界。

为何常见：构建评测集成本高，人们倾向于“建完就完”，忽略了评测集本身需要像产品一样迭代维护。

面试题

Q1. 关于告警分级，下列说法正确的是？

单选题 · mid

  • A.级别越高通知的人越少
  • B.严重告警直达值班负责人← 正确答案
  • C.所有告警统一按最高级发
  • D.告警级别与业务影响无关

答案：B。告警分级的本质是按业务影响分配响应资源，级别越高影响越大、响应越重。A错在方向反了，级别越高通知范围越大而非越小；C会引发告警疲劳；D完全否定了分级的意义。B正确，严重告警必须直接触达on-call值班人，就像油锅起火要直接喊值班大厨。

Q2. 告警疲劳（alert fatigue）的主要成因是？

单选题 · easy

  • A.告警通知的渠道太少
  • B.告警太多且多为无效噪音← 正确答案
  • C.值班人员轮换太频繁
  • D.告警内容描述过于详细

答案：B。告警疲劳是指大量无效告警让值班人对告警信号变得麻木。核心成因是告警数量过多、命中率低，就像后厨报警器天天误报。渠道少、轮换频繁、内容详细都不是疲劳的主因，反而内容详细是好事。

Q3. 下列哪些是治理告警疲劳的常见手段？

多选题 · mid

  • A.同类告警做聚合去重← 正确答案
  • B.设置冷却抑制的窗口← 正确答案
  • C.动态调整告警的阈值← 正确答案
  • D.直接关闭全部的告警

答案：ABC。聚合去重把同源告警合并为一条，冷却窗口让同类告警在静默期内不重复打扰，动态阈值让正常业务波动不误报，这三者都是正规治理手段。D“关闭全部告警”是极端逃避，会让系统裸奔，不是治理手段。

Q4. on-call值班中“响应SLO”指的是？

单选题 · easy

  • A.值班人员每天的工作时长
  • B.告警触发到处理的时限← 正确答案
  • C.系统每秒处理请求的数量
  • D.告警内包含字段的数量

答案：B。响应SLO是服务等级目标，指从告警触发到值班人开始处理的最大允许时间，比如“5分钟接警、15分钟处理”。它不是工作时长、吞吐量或字段数量，而是衡量值班响应速度的契约。

Q5. AI产品上线前，验证应急响应预案最有效的方式是？

单选题 · easy

  • A.不断修改预案的文档
  • B.定期进行故障的演练← 正确答案
  • C.增加更多的告警规则
  • D.减少值班的排班人数

答案：B。预案的价值在于被演练过。定期故障演练让团队在低压力下把SOP走成肌肉记忆，真出事时才能按流程执行。改文档、加告警、减人都是纸面功夫或反向操作，不能真正验证预案有效性。

Q6. 灰度发布时，评测驱动迭代的“通过判定”通常是？

单选题 · hard

  • A.准确率必须绝对高于旧版
  • B.不显著劣于旧版视为通过← 正确答案
  • C.只看新版的响应速度
  • D.无需评测直接全部上线

答案：B。灰度发布的通过标准是“新版关键指标不显著劣于旧版”，允许小容差，而非要求绝对更优。绝对更高过于严苛，会扼杀迭代节奏；只看速度太片面；不评测直接全量是赌博式操作。B符合统计显著性思维。

Q7. Token成本优化可以采用的策略包括？

多选题 · mid

  • A.使用上下文缓存的复用← 正确答案
  • B.简单问题路由到小模型← 正确答案
  • C.压缩 prompt 减少冗余← 正确答案
  • D.无限增大输出的上限

答案：ABC。上下文缓存复用让相同前缀只付一次费用，模型分级路由让简单任务用小模型省钱，prompt压缩减少输入token，三者都是成熟优化策略。D增大输出上限只会让账单更贵，方向完全相反。

Q8. 告警冷却抑制窗口的作用是？

单选题 · mid

  • A.延迟所有告警的发送
  • B.同一故障源窗口内只发一条← 正确答案
  • C.提高每个告警的发送速度
  • D.扩大告警通知的范围

答案：B。冷却窗口让同一故障源在设定时间内只发出第一条告警，后续重复状态不再打扰值班人，除非指标进一步恶化。它不是延迟所有告警、提速或扩范围，而是精准抑制重复噪音。

Q9. 故障复盘（postmortem）的核心目的是？

单选题 · hard

  • A.追责值班人员的责任
  • B.找到改进项形成行动项← 正确答案
  • C.记录故障时长用于绩效
  • D.删除故障相关的日志

答案：B。复盘是为了从故障中提取系统改进项并跟踪落地，让同样的故障不再发生。追责会让团队隐瞒问题；记录时长用于绩效会扭曲动机；删除日志是销毁证据，掩盖真相。B才是“改进导向”的正确复盘。

Q10. 反馈机制构建包括哪些环节？

多选题 · easy

  • A.收集用户的反馈信息← 正确答案
  • B.后端日志的埋点监控← 正确答案
  • C.业务指标的追踪分析← 正确答案
  • D.全量回滚到旧的版本

答案：ABC。反馈机制四层包括用户反馈收集、日志埋点监控、业务指标追踪和闭环流程。收集、埋点、指标分析都是反馈链路的组成部分。D“全量回滚”是应急手段，不是反馈机制环节，两者要区分开。