AI On-Call 心理学：为非确定性告警重建运维直觉

当一名 on-call 工程师第一次以“模型刚才又表现得有点怪”为由关闭告警页面时，团队就已经悄然越界了。这句话同时表达了三层意思：它宣告了问题不可调查，它将未来类似的告警归类为噪音，并免除了轮值人员记录事件经过的责任。一周后，同样的特征再次触发告警，另一个人看到“之前已经关闭过一次”，于是真正的回归（regression）便会一直潜伏在生产环境中，直到有客户在 Twitter 上发帖投诉。

这种模式并不是因为懒惰。它是将标准的 SRE 直觉运行在一个不再表现出确定性的系统上所产生的必然结果。经典的 on-call 培训教导工程师将“输入相同但输出不同”的情况视为可观测性堆栈中的 Bug——这不可能是系统本身的 Bug，因为系统不会那样运作。但基于大语言模型（LLM）的系统正是在每一次请求中都以这种方式运作，这是其设计使然。如果建立 on-call 轮值机制时没有内化这一点，系统就会滑向两个极端：要么是瘫痪（每一个随机波动都是 P2 级事故），要么是虚无主义（模型总是很奇怪，别再给我发告警了）。

我所见过的处理得比较好的团队，会将 AI on-call 视为一门与传统可靠性工作截然不同的学科。他们重新设计了告警分类体系，重建了轮值激励机制，并投入精力进行培训，明确要求参与者抛弃一些根深蒂固的 SRE 本能。以下是这些实践经验的总结。

“模型当时想这么做”并不是根本原因

传统 SRE 的运维前提是：通过严密的调查，每个事件都能找到其根本原因——错误的配置推送、竞态条件或是依赖项性能下降。围绕这一前提建立的复盘文化（五个为什么、因果链、无责备复盘）只有在树的最底层确实存在一个“为什么”时才有效。

随机系统（Stochastic systems）从底层打破了这一前提。在第一次 logit 计算中，仅仅一个比特位的差异就可能改变 token 的选择，而一旦轨迹发生偏移，模型可能在这一分钟给出准确答案，下一分钟就产生言之凿凿的幻觉，而输入完全没有变化。当批处理、缓存和请求调度与浮点非确定性相互作用时，即使在相同模型上以相同的 temperature 重放相同的 prompt，也可能产生不同的输出。树底层的“为什么”往往只是采样过程的联合熵（joint entropy）。

危险的做法是将这一事实引入 on-call 行为，将其作为停止调查的通行证。如果“模型当时想这么做”变成了事故树中被接受的终端节点，那么你已经把 AI 路径上的每一个生产环境 Bug 都定义为了不可分析。抵制这种倾向的团队会采取一种微妙的做法：他们将“随机性”视为分类体系中的一个类别，而不是逃避的借口。“在当前 N=1 的情况下无法与采样噪声区分”是一个结论，但它会触发不同的工作流——通常是自动请求以更高的 N 值重放追踪（trace）、运行针对性的评估切片（eval slice），或者在特征持续出现时升级处理。轮值产生的结果要么是真正的根本原因，要么是足以说明故障处于预期噪声范围内的统计证据。它永远不会产生一个“耸耸肩表示无奈”的结果。

为非确定性系统构建的告警分类体系

大多数 AI 可观测性堆栈只是将 LLM 指标硬塞进现有的告警基础设施中，这产生了根本性的信号混乱。一名工程师被叫醒，打开仪表盘，看到“质量分数下降了 8%”与“p99 延迟增加了 40ms”以及“错误率 0.3%”并列在一起——这三个指标有着三种完全不同的可复现性保证，却通过同一个寻呼机（pager）路由。

一个能够在生产环境中经受考验的分类体系至少将告警分为四个不同的族群，每个族群都有自己的响应协议。

第一种是确定性基础设施：常见的超时、5xx 错误率、依赖项健康状况、队列深度。沿用你之前的直觉即可。如果 GPU 主机卡死了，那就是卡死了；经典的调试方法依然适用。

第二种是策略和契约违反：安全分类器触发、JSON Schema 校验失败、拒绝工具调用、提示词注入检测。在固定的 trace 下，这些是确定性的，尽管它们发生在随机系统内部。单次复现就具有重要意义；它们属于高优先级的告警。

第三种是具有统计信号的质量回归：诚实度（faithfulness）分数持续下降、输出长度分布发生偏移、数千个请求中的工具调用成功率出现漂移。这些是真实存在的问题，但需要群体层面的分析，而不是单条请求级别的调试。它们绝不应该叫醒正在睡觉的人——它们应该被创建为一张明早处理的任务单，并预先附上评估切片。这类告警最容易让人产生习得性无助。

第四种是随机噪声：在低访问量的代码路径中出现一次奇怪的输出。这些根本不应该成为告警。如果它们漏进来了，正确的 on-call 操作是将该 trace 记录到重放语料库中并关闭页面。训练工程师毫无愧疚感地执行此操作比听起来要难，因为 trace 往往看起来是可调查的——模型确实给出了错误答案，而通常的直觉是错误答案必须被修复。

这里的纪律在于，将“修复”保留给在聚合层面可见的回归。单个随机失效是数据点，而不是 Bug。混淆这两者的团队要么每周二根据单个案例重写 prompt（由于对最新的噪点样本过拟合而导致 prompt 漂移），要么得出“任何事情都没有可行性”的结论并停止响应。

抵抗“推诿模式”的轮值设计

“AI 又出毛病了”这种推诿不仅是一种认知结构，更是一种社会结构。当一名工程师在凌晨 3 点的值班中耸耸肩，这种行为就会成为下一名工程师在下次值班时的先例。要打破这种模式，需要构建一种旨在传播调查而非推诿的轮值机制。

以下三种设计选择会有所帮助。

对模糊推诿进行强制二次审查。 当首要值班人员将告警归类为“随机噪声，无需采取行动”时，系统会记录该分类及追踪 ID（trace ID），并要求次要值班人员在下一班次中随机抽查一部分。这并不是对抗性审查，而是保持分类边界校准的一种方式。如果次要人员经常持不同意见，说明首要人员的阈值发生了偏移。如果他们很少有分歧，说明分类体系运作良好。无论哪种情况，团队看到的是信号，而不是每个工程师私下积累的个人偏见。

轮值交接应包含开放的行为线索，而不只是故障事件。 传统的轮值交接涵盖活动中的故障和已知的脆弱系统。具备 AI 意识的交接增加了第三个维度：低于告警阈值但呈现某种趋势的行为观察。“工具 X 生成幻觉参数的频率大约是上周的两倍，我开启了一个评测切片。”通过这些线索，你可以捕捉到那些单独看起来像噪声、但汇聚起来却是真正问题的质量退化。如果没有明确的交接，每个班次都会从头开始重新发现它们，并逐个将其忽略。

轮换评测负责人。 在标准的告警轮值之外，每个周期指定一名工程师负责审查从已忽略告警中提取的回放数据集，并提升那些重复出现的告警。这个角色修复了结构性不对称：忽略告警总是比调查告警快。如果忽略行为没有后续读者，那么阻力最小的路径就是忽略一切。如果你的同事明天会阅读你的忽略记录，门槛自然会提高。

缺乏这类控制机制的团队最终会趋向于一种双峰模式的轮值：新工程师过度调查每一个随机波动并最终精疲力竭，而资深工程师则忽略一切并错失真正的回归。从个体角度看，这两组人都没有错；错在系统缺少能让他们进行校准的反馈闭环。

课程大纲：值班培训必须“去学习”的内容

传统的 SRE 入职清单假设了一套直觉：重现问题、缩小变量、找到单一变更、修复、通过重新重现进行确认、关闭。当系统在负载下具有概率性时，该清单的每一步要么部分失效，要么需要不同的实现方式。

以下四项“去学习”（纠正旧习）的练习至关重要。

重现是统计学的，而非二元的。 “我运行了一下，成功了”并不能证明 Bug 已经消失——这只是分布中的一个样本。新的值班工程师在下结论前，应练习以 N=20 或 N=100 的规模回放追踪，并学会阅读比率的置信区间，而不是将单次重现视为诊断结果。这起初会让人感到不适，因为之前的所有本能都在告诉你，曾经失败的测试现在通过了，就意味着修复成功。

根本原因通常存在于模型调用之外。 随机系统诱导工程师将责任归咎于模型，因为模型是可见的方差来源。在实践中，大多数生产环境中的 AI 事故仍是由检索、工具模式 (schemas)、提示词版本控制或上游数据更改引起的——即流水线中的确定性部分。模型通常只是在面对退化的输入时表现正常。培训必须反复强调这一点：在归咎于采样噪声之前，先对比模型实际看到的输入与昨天的输入。

指标存在底噪，你必须凭感觉学习。 每个评测指标都有一个由样本量和任务本质决定的固有方差水平。培训新的值班工程师识别每个生产指标的底噪——“这个分数每天无论我们发布什么都会波动 2 分，下降 8 分才是有意义的”——这无法记录在运维手册中，只能通过刻意接触带有事后标签的历史告警流来习得。

修复是分布的偏移，而非单纯的更改。 当传统的 Bug 被修复时，该路径的失败率会降至零。当 AI 的失效被缓解时，失败率从某个百分比降低到更低的百分比。“生产环境零 Bug”的心智模型在这里会严重损害值班判断。更好的框架是：每种线上的失效模式都有一个概率，你的工作是了解哪些概率在变动，以及变动的方向。

适配概率系统的故障复盘形式

Google 风格的故障复盘组织方式围绕“哪里坏了、根本原因是什么、如何防止再次发生”展开，其形式假设了 Bug 存在于代码或配置中的某个地方。对于 AI 事故，更有效的形式应以版本化的状态和分布证据为中心。

值得保留的字段包括：事故发生时准确的模型、提示词、检索索引、工具模式和策略版本；指向受影响追踪的链接，并附带 N=多次的回放记录；受影响群体的聚合指标变动，而非仅是触发告警的那次请求；以及明确说明缓解措施是针对根本原因、降低发生率，还是提高检测门槛。如果复盘报告混淆了这三类缓解措施（修复、缓解和检测改进），往往会导致过度承诺，并使下一次事故看起来像是重复发生，而实际上它是以相似概率发生的另一种失效。

另一个有用的字段是随机性判定。一句话总结：“在相同版本下可重现”、“仅在相似提示词下可重现”或“属于当前 N 规模下的采样噪声”。这个单一字段能让团队对事故提供的信息保持诚实，防止归档文件变成一堆在六个月后被脱离上下文引用的模糊轶事。

一场静默的文化转变

未来几年能够出色运行 AI 系统的团队正在经历一场静默的文化转变，而 On-call 正是这种转变最先显现的地方。传统的 SRE 身份认同——那个寻找单一根本原因的人，那个只要有足够的毅力就能复现任何问题的人，那个绝不接受“它很不稳定”这种说法的人——正面临着这样一个系统：在这里，复现是概率性的，根本原因表现为分布，而“它很不稳定”有时反而是正确的科学答案。

解决之道并非降低标准，而是升级工具链：用统计学复现取代二进制式的复现，用分布偏移取代单纯的变更，建立起奖励“经过校准的告警关闭”而非奖励“漫不经心”的值班激励机制。在这些方面投入的团队不再让他们的资深工程师在噪声中耗尽精力，也不会在被忽略的告警堆中漏掉真正的性能回退。而那些不愿投入的团队则会陷入两难的境地：值班时既会忽略真正的问题，又会过度关注采样噪声，最终没有人能确定哪些告警才是真正重要的。

“模型又在表现异常了”只是一种表象。我们的工作是构建一种文化，让这句话永远不再是终结性的回答——而是一个总是能触发下一步测量工作的假设。