299 篇博文 含有标签「observability」

2025 年 4 月，全球使用最广泛的 AI 产品之一更新了系统提示词。错误率保持平稳。延迟表现正常。部署仪表盘显示一切正常。然而在三天内，数百万用户发现了一些严重的问题：模型变得异常谄媚，附和错误的想法，验证糟糕的推理，并对用户说的任何话都表现出虚假的热情。回滚公告发布时，该事件已经席卷社交媒体，用户纷纷晒出截图作为证据。在一段时间内，Twitter 成了生产告警系统。

当你把提示词和模型的变更当作配置更新，而不是行为部署时，就会发生这种情况。那些在代码金丝雀基础设施上投入多年的团队，却仍在以单一原子级切换的方式发布 AI 变更——瞬间全球化、瞬间不可逆，没有分级发布，除了用户投诉外也没有自动回滚信号。

LLM 行为的金丝雀部署并非可有可无。它是缺失的基础设施层，区分了那些能在内部捕捉退化的团队，和那些只能通过支持工单发现问题的团队。

在生产环境中运行一百个 agent 感觉还可以管理。你有追踪数据，有仪表盘，知道什么时候出问题。但运行一千个并发 agent 完全是另一个问题——不是因为 agent 更复杂，而是因为你为十个 agent 建立的监控模型在你注意到之前就已经悄然失效了。

失败模式很微妙。一切看起来都很正常。你的 span 树都在。错误率很低。然后，一个导致 40% 会话输出质量下降长达六小时的提示词回归，只因为客户投诉才浮出水面——而不是被你的可观测性系统捕获。

这就是仪表盘盲区问题：单 agent 追踪在小规模下运行良好，在集群规模下则会悄然失效。以下是它发生的原因及应对之道。

你的链路追踪仪表盘显示 Agent 为了响应用户请求发起了 8 次调用。但实际上，它发起了 47 次。你的头部采样器（Head-based sampler）静默地丢弃了其中的大部分。你保留下来的那些调用在技术上是正确的，但在因果关系上毫无用处——它们是从被父级采样器丢弃的根节点中孤立出来的子 Span。

这并不是可视化层面的 Bug。它是将专为 10 个 Span 的 HTTP 扇出设计的分布式链路追踪基础设施，强行套用到每轮对话生成数百个 Span 的系统上的必然结果。默认的 OpenTelemetry 配置系统性地低估了 Agent 的工作量，而运行这些 Agent 的团队通常直到客户抱怨链路追踪视图中显示“不存在”的延迟时，才会察觉到问题。

AIOps 供应商圈子里没人愿意宣传的悖论是：投入超过 100 万美元用于故障响应 AI 工具的组织，其运维负担占工程工时的比例反而从 25% 上升到了 30%——这是五年来的首次增长。团队本以为自动化能替代手工劳动，结果却多出了一项新工作：在执行 AI 建议之前先验证它说的是否正确。旧的任务没有消失，反而在上面又叠加了一层验证层。

这并不是反对在故障响应中使用 AI 的论点。同样的数据显示，当 AI 被妥善整合时，平均故障解决时间（MTTR）可降低 40%，部分团队报告将排查时间从两小时缩短到了三十分钟以内。这里要表达的论点更为精准：AI 副驾驶的故障模式在性质上与传统 SRE 工具的故障模式截然不同，而大多数团队还没有做好识别这些故障的准备。

这里有一个令人不安的模式：你的团队计划在下个季度推出的 AI 功能，其实早在两年前就在公司里“死”过一次了。它当时以不同的名称发布，带着不同的提示词（prompt），解决一个略有不同的问题，并在经历了六个月的增长停滞后被悄然关停。没有人记录它，没有人把这些点串联起来。本可以拯救这个周期的领先指标，一直躺在那些随功能一起被归档的数据看板里。

大多数工程组织都是为了记住成功而设计的精妙机器。发布会有复盘、博客文章和内部庆祝。但那些被砍掉的功能——尽管有精美的演示，但周活跃用户仅为 12% 的功能；当 Token 成本在超预期的工具链中叠加时导致单位经济效益倒挂的功能；那些用户先是学会信任、随后失去信心、最后完全绕开的功能——几乎没有留下任何组织记忆。而这些“死亡”中蕴含的失败模式，恰恰是你的规划流程无法预估并纳入成本的。

一个法律团队的 AI 研究助手伪造了三个案例引用，并将它们混入了法庭文件中。这些引用看起来非常可信 —— 真实的法院、听起来很真实的案例名称、连贯的判决理由。在提交摘要之前，没有人发现它们。这一事件导致律所面临紧急听证会、公开道歉以及律师协会的调查。

那是 Sev-0 还是 Sev-2？答案取决于你使用的框架 —— 而传统的严重程度模型几乎每次都会给你错误的答案。

软件事故严重程度分类是为确定性系统构建的。服务要么有响应，要么没有。数据库查询要么成功，要么抛出错误。失败模式是二进制的，责任可以追溯到某个 commit，而修复方案则是回滚或补丁。AI 系统同时打破了这三个假设，如果组织将传统的严重程度框架应用于 LLM 故障，最终要么是对噪声感到恐慌，要么是将结构性故障视为偶然的异常。

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

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

你的 AI 功能满意度评分是 4.2/5，用户点赞率高达 68%，A/B 测试显示任务完成率提升了 12%。团队决定上线。六周后，用户已悄然绕开它，遇到真正重要的事情时不再使用。

这就是指标表演。你优化的是看起来像成功的信号，而不是真正的成功。你收集到的反馈来自那 8% 愿意评分的用户——偏向极度满意和极度不满的两端，对那沉默的大多数一无所知——他们发现该功能时不时不可靠，于是悄悄停止信任它了。

构建 AI 功能需要一套与传统软件不同的度量哲学。你从第一天起就埋下的信号，决定了你是否能足够快地学习并改进，还是花六个月追着一个纹丝不动的满意度分数跑。

你正在值班，凌晨三点，告警触发：过去一小时内 AI 聊天功能的用户满意度下降了 18%。你打开日志，却看到……什么都没有。每个请求都返回了 HTTP 200，延迟正常，没有任何报错。

这就是 AI 事故的体验。传统值班的肌肉记忆——grep 堆栈跟踪、找到异常、部署修复——在这里完全失效。系统并没有崩溃，它做的正是它被设计来做的事。只是输出结果是错的。

我去年合作过的一个团队拥有一套包含 847 个测试用例的评估套件，仪表盘一片绿色，发布节奏从外部看非常有纪律。然而，他们的旗舰摘要功能开始为大约二十分之一的客户支持线程生成言之凿凿的错误摘要。该能力的评估得分在连续六个月里一直保持在 94%。当我们对这套套件进行审计时，发现问题并不在于评估在撒谎。问题在于这些评估已经悄然腐化，测量了错误的东西，惩罚了正确的模型行为，并与它们正在评估的模型共享盲点。这套套件并不是像传统测试那样以一种响亮的方式崩溃，而是像温度计一样坏掉了——无论你把它放在哪里，它都显示室温。

测试异味（Test smells）在传统软件领域已经被研究了二十年。Van Deursen 的目录、xUnit 模式分类以及更近期的工作都记录了那些看起来正常的测试如何能积极地损害代码库——通过编码错误的规范、使重构变得昂贵、以及制造让真正的 bug 隐藏得更深的虚假信心。LLM 评估是一个非常新的领域，以至于同类的文献几乎不存在，但同样的动态已经发生在我交流过的每个 AI 团队中。不同之处在于，LLM 评估异味具有传统测试所不具备的机制：训练数据重叠、随机输出、评委模型反馈循环、能力漂移。你不能只是简单地移植旧的分类体系，你需要一个新的。

你的 LLM 供应商 SLA 涵盖了 HTTP 正常运行时间和首个 Token 到达时间。但它对于模型下个月是否仍会遵从你的格式化指令、是否会拒绝上周还能接受的请求、或者在你未测试的边缘条件下能否返回有效 JSON，只字未提。大多数工程团队是通过生产环境事故才发现这一点的——而非通过更新日志。

这就是隐性 API 契约问题。传统 API 承诺稳定、有据可查的行为；LLM 供应商只承诺一条连接。从请求发出到应用处理响应之间发生的一切，都由你自己负责。

你的 AI 功能在上线时通过了所有评估。六周后，与其交流最频繁的用户群体的流失率翻了一倍，而你的 CSAT 仪表板却显示出一条无人能解释的平线。提示词（Prompts）没有变，模型没有更换，检索索引增长了，但没人觉得它坏了。上线时的表现第一轮（turn one）很好。真正变质的是在第 400 轮、第 17 次会话、注册三周后发生的事情。

大多数团队的评估套件无法察觉到这种失败。他们测试的是固定数据集上的单轮准确性，如果有追求的话，可能会测试单次会话中的多轮对话，然后就宣布该功能可以上线。真正重要的失败模式——即随着系统积累用户状态而质量下降——存在于评估工具从未设计去覆盖的时间维度中。在记忆研究文献中，研究人员称之为“自我退化”（self-degradation）：在初始阶段之后，受记忆膨胀（memory inflation）和错误记忆累积的驱动，性能出现明显且持续的下降。生产工程师则将其称为留存用户群无声流失的原因。