你可能已经习惯了用 dashboard 看系统、用 alert 发现问题，但问题是，当一个系统有成百上千个服务、每天产生海量数据时，你真的还能看见它吗？
作为领先的 observability（可观测性）平台，New Relic 几乎见证了整个现代软件运维的发展历程。如今，他们正尝试把 AI 引入 observability，从“让你看见问题”，走向“直接告诉你该关注什么”，甚至在问题发生前自动采取行动。与此同时，一个新的难题也浮现出来：当 AI 本身成为系统的一部分，我们又该如何监控这些不确定、会“胡说”的模型？
近日，在播客节目中，New Relic 的 Chief Technology Strategist（首席技术战略官）Nic Benders 与主持人 Lee Atchison 一起讨论了 observability 如何从 dashboards 和 alerts 演进到 AI 驱动的智能系统，LLM 如何与统计方法协同从海量数据中提取信号，以及 AI 对软件工程职业未来的影响。本文基于该播客视频整理，经 InfoQ 编辑。
核心观点如下：
observability 系统，其实更应该叫“understandability 系统”，因为没人真的想“观察”，大家要的是“理解”。
增加 alert 并不会提升响应能力。它会训练人产生一种反应：“先等一下，看看它会不会自己恢复。”结果响应时间反而被拉长了。噪音越多，响应越慢，但团队却误以为 alert 越多越安全。
当 AI 让每个人有能力去完成更多事情，结果不是“少工作”，而是“多产出”，历史上从来没有哪次技术进步让人类真的减少工作量。
真正的“source of truth”始终是业务本身：如果你是电商，那就是有没有成交；如果是社交产品，那就是用户有没有互动；不管是什么产品，你之所以写这些软件，就是为了实现那个目标。
从“看得见”到“看不过来”
Lee：这些年你都在 New Relic 忙什么？作为首席技术战略官，你的日常职责到底是什么？
Nic：New Relic 的发展路径某种程度上也就是整个行业的发展路径。
最早我们处在一个“instrumentation（代码插桩）时代”。那时候我们每天思考的问题很简单：怎么才能给更多关键系统做插桩？最开始是 Ruby，接着是 Java、.NET、Python，还得研究怎么进驻浏览器、移动端 App。但很快，我们插桩的东西太多了，数据量大到根本处理不过来。
于是行业进入了“data platform（数据平台）时代”。对 New Relic 来说，这个转变大概发生在 2013、2014 年，我们推出了 NRDB（New Relic 数据库）。NRDB 的核心价值在于：你可以问那些你原本不知道该问的问题。数据先全部收进来，之后再探索。比如你会突然问：“我的慢查询从哪儿来？”结果发现大部分来自测试系统，那就排除掉测试环境，再继续分析，甚至按国家拆分。这种“交互式提问”的能力，支撑了 dashboards、data explorer、alerts 等一整套能力。
但十年后的今天，仅仅“能问问题”已经不够了。因为数据太多，多到你甚至不知道该问什么。于是我们进入了“intelligence（智能）时代”。重点不再是“你能问什么”，而是系统告诉你“你应该问什么”、“你该看什么”。
说到 intelligence，大家立刻会想到 AI。AI 是其中一部分，但不只是 AI。它还包括产品设计、交互方式、内置判断逻辑。因为用户打开工具，不是为了写 query，也不是为了搭 dashboard，他们要的是答案。他们想知道：我的系统现在到底发生了什么。
这就是我们现在所处的阶段，而且这种演进不会停止，我们可能正迈向 Action 时代，让系统不仅能看，还能直接动手解决问题。
至于首席技术战略官这个角色，本质上就是在思考这个问题：我们现在在哪里？接下来要去哪里？我在 New Relic 已经 16 年了，从当年 monitoring 还只是 ping 的时代开始，也用了 30 年的 observability 工具。所以我的工作，其实更偏向“未来导向”。
Lee：听起来核心使命经历了两次大跳跃：从 instrumentation 到 data platform，再到 intelligence。
Nic：十年前的核心认知是：你必须有一个强大的 data platform，而且要支持“任意规模、任意查询”。但这几年我们意识到一个更深的问题：我们构建的这整套 observability 体系，本质上并没有那么大的变化。
现在的 dashboards 更漂亮、更好用、数据更多，但本质上和我 90 年代做的没什么区别。那时候我也会想：要监控什么？CPU、内存、网络……当时用的是 Tcl/Tk ，现在用 NRQL（New Relic 查询语言），本质一样。
Lee：区别只是从 3 个图变成了 300 个图。
Nic：对，大家疯狂加图表。但问题是，没有任何一个 dashboard 小到可以让你“看见一切”。当我们意识到这一点时，就明白了：以 dashboards 和 alerts 为核心的 observability，已经走到尽头了。
你不可能靠“更复杂的 dashboard”或“更多 alert”解决问题，没人真的想写 alert，也没人真的想做 dashboard。大家只想知道：系统到底怎么了？
dashboard 和 alert 只是工具，而不是目标。这是这几年我们最大的认知转变，而且我认为整个行业都会走向这个方向，尤其是在 AI 的推动下。
Lee：记得我们在 NRDB 时代，经常讲 machine learning。比如用一些“神奇算法”自动生成 alerts，说“这个模式异常了”。但当时很强调：这不是 AI，只是 machine learning。那么，现在真正的 AI 智能和当时的 machine learning 到底有什么本质区别？
Nic：我会把这些技术分成三类。
第一类，其实根本不是 AI，就是数学和统计。比如做 signal analysis、baseline deviation，本质就是公式计算。再复杂，也是数学。
第二类是 machine learning。你不再手动设参数，而是定义 hyperparameters，让算法自动调整告警基准，比如保证一段时间内只发一个 alert。这撑起了前几年大家认知的 MLOps。
但这两三年，一切都被 neural networks 改写了。这不是新东西，60 年代就有，但直到 transformer 架构出现，加上巨量资金投入，它才真正“好用”。现在大家说的 AI，本质上就是这些 neural networks 系统。
所以你可以这样理解：统计方法 → machine learning → neural networks（现在的 AI）。一个好的产品，应该三者都有。
如果你的 AI 策略只是把所有东西塞给 OpenAI 等着拿答案，那当然也有价值，但不是万能解法。很多场景下，传统 machine learning 或统计方法更合适。
目前的趋势是：neural networks（比如调用 OpenAI、Gemini、Anthropic）成为“决策层”，但它背后调用的工具，应该包括各种 machine learning 和统计能力。
Lee：以前针对单个指标，比如内存到 80% 就告警，结果一小时收到 50 条噪音。机器学习把它优化到了 86.2% 这种动态值，减少了噪音，而现在的 LLM 是在尝试理解模式。
Observability 的核心是让复杂系统变得可理解。AI 最擅长的就是总结和解释庞大系统里到底发生了什么，而不是让工程师在那儿一点点啃数据。虽然现在还没完全普及，但我预感这快了。你怎么看 LLM 在大规模系统理解中的角色？
Nic：我完全同意，这是迈向 insight（见解）时代的关键。。现在的 Kubernetes 集群有数百个节点、数千个 Pods，数据量呈爆炸式增长，人根本看不过来。你也不可能预先写好涵盖所有故障的 alert 规则。真正重要的信号，可能是你从未关注过的一个指标，但它和用户问题高度相关。
这里就需要结合统计方法和 LLM：你不能直接把 petabyte 级数据喂给 LLM，成本会高到离谱。但你可以先用统计方法找 anomaly，再把这些“可疑片段”交给 LLM，让它判断哪些有意义。
要实现这一点，我们需要三样东西：海量数据输入、结构化数据（明白什么指标对应什么系统），以及空间和时间上的关联。比如，用户在这个浏览器操作，调用了这个服务，这个服务又依赖那些基础设施。这种图谱关系在做故障根因分析时至关重要。
LLM 是总结天才。虽然现在的上下文窗口已经到了 10 万甚至 100 万 Tokens，但这在海量数据面前还是太小了。我们的数据规模是 10 亿级的，必须通过工具先把数据量从 10 亿级降到万级，AI 才能真正起作用。
告警疲劳的尽头
Lee：你刚刚描述的这个过程，让我想起早期 monitoring 的一个老问题——alert fatigue（告警疲劳）。那时候我们能收到各种 alerts，各种异常通知，但数量多到最后大家直接忽略。
现在你说的这一套，其实有点像是：系统可以接收所有这些 alerts，但它不会“疲劳”，还能从中找出真正的模式和问题。可以这么简单理解吗？还是说事情远比这复杂？
Nic：它发生在两个层面上。你说“老问题”，但说实话，这到现在还是头号问题。我跟任何客户和团队聊，都会听到同一件事：一旦出问题，大家做 retro，最后的结论几乎永远一样——“我们需要为 xxx 加更多 alert，下次才能更早发现。”
如果你把这个逻辑持续几年，最后的结果就是：整个宇宙里的每件事都有 alert。
我记得我们以前的同事 Aaron Bento 有一次分享特别精彩，他说：增加 alert 并不会提升响应能力。它会训练人产生一种反应：“先等一下，看看它会不会自己恢复。”结果响应时间反而被拉长了。噪音越多，响应越慢，但团队却误以为 alert 越多越安全。
所以第一层，我们可以用 intelligence 去“过滤 alert”。在通知人之前，先判断它是不是严重。这其实很接近 on-call 工程师的直觉：如果只是一个小波动，你会觉得“有点奇怪，但先看看”；但如果六个系统同时报警，你会立刻冲向键盘。AI 可以做这件事，machine learning 也可以，这不是什么高深技术。
第二层，我们可以反过来优化 alert 本身。比如：哪些 alert 总是一起触发？哪些 alert 从来不可操作？哪些只是闪一下就消失？从全局去分析，然后把这些无用的 alert 调低甚至去掉。但说到底，这些都是“事后优化”。真正的问题是：我们为什么一开始要有这么多 alert？
我们之所以创建 alert，是因为我们害怕系统出问题却不知道。那有没有可能从根本上解决？比如：当系统检测到 anomaly 时，它可以先自己判断：这个问题是否“有趣”？是否可以自动处理？比如直接 rollback 并通知用户？是否需要人类介入？还是说现在还不到阈值，那就先放进“信号池”，等更多信息再判断？
observability 系统，其实更应该叫“understandability 系统”，因为没人真的想“观察”，大家要的是“理解”。
我相信在不久的将来，当你搭建 observability 系统时，不需要再配置一堆 alert，你只需要说：“这些是最重要的信号，这些代表用户体验的真实状态。你帮我盯着，在问题发生之前告诉我。”
听起来有点像科幻，比如《2001 太空漫游》里的 HAL 9000 提前告诉你设备会坏。但其实很多逻辑很简单，本质就是我们现在人类已经在做的事：设定 CPU、内存的安全阈值。区别只是现在是人类在“慢速响应”，未来是机器在“毫秒级响应”。
当检测、响应、修复都发生在机器尺度上，on-call 这个概念就会慢慢消失，系统会变得像其他“无聊到几乎不被当作技术”的东西一样自动化。比如程序崩溃自动重启，这在 90 年代就有了；Kubernetes 发现 node 挂了就自动拉起 pod，这就是 self-healing。我们现在甚至都不觉得这是“技术能力”，只觉得“理所当然”。
未来大部分系统都应该这样。很多今天需要 runbook 的事情，最终都会变成“顺带发生”的事情。比如：节点挂了、pod 被重调度——没人会被 page，甚至不会发邮件，可能只是 log 里一行记录：“刚刚发生了点事，我们处理完了。”很多今天被当作“incident”的问题，其实都应该属于这一类。
Lee：听起来就像老式客服的经典问题：“你试过重启吗？”本质上，我们就是在把 runbook 自动化：关掉这个、重启那个、再试一次……云计算帮我们做了一部分，Kubernetes 又做了一部分，两者结合才真正推动了这个变化。现在我们的基础设施其实已经是这样运作的了。甚至网络出问题，也可以重启网络。
你的意思是，这一切都可以进一步自动化，让它“自然发生”，而 AI 会成为核心驱动力。
Nic：对。云计算就是一个很好的例子，尤其是 Kubernetes 这类 container orchestrator，让很多问题变得“可定义”。我们可以明确地说：如果发生 A，就执行 B；如果发生 C，就执行 D。
但剩下的那些问题呢？就是 SRE 还得盯着的那些，比如 IP 用完了、证书出问题了、上游依赖异常了……这些都比较“模糊”，很难写成 runbook。如果你试图把所有可能情况写成代码，那你一辈子都写不完，而且只能覆盖极小一部分。
但如果你有一个“推理系统”（reasoning system），它可以在结构化数据和模糊判断之间架桥，这正是 LLM 和 neural networks 擅长的，它可以说：“这个问题看起来和之前那个很像。”
于是我们可以把问题归类：哪些是我们知道怎么修的 → 自动处理；哪些还不紧急 → 建 ticket 给人；哪些是紧急但不确定 → 才去 page 人。
这样一来，很多今天被认为“必须人工处理”的工作，其实都可以归类为 automatable toil（可自动化的重复劳动）。我们正在重新定义“toil”，并把它不断推进自动化。
Lee：这意味着维护系统所需的人力 toil 会减少。但另一方面，系统本身越来越复杂。所以最终结果可能是：总工作量并没有减少，甚至还在增加，只是我们在做更复杂的事情。换句话说，AI 让事情更容易，但也让我们去做更难的事情。
Nic：我记得有一次和工程师聊，我们已经做了大量平台优化，部署方式都已经完全不一样了，一切都更高效。但问题是，为什么大家还是这么忙？答案很简单，因为我们做得更多了。
人类的瓶颈始终是“带宽”。当 AI 让每个人有能力去完成更多事情，结果不是“少工作”，而是“多产出”，历史上从来没有哪次技术进步让人类真的减少工作量。
Lee：我真希望媒体能用这种方式讲 AI 和就业问题，AI 不是减少工作，而是让每个人产出更多，从而整个社会做更多事情。
Nic：是的，AI 确实会改变工作形态。它不一定“消灭工作”，但会“转移工作”。
这让我想到 200 年前的工业革命。整体来看，它极大提升了经济规模，也创造了大量新工作。但对那些原本从事旧工作的个体来说，转变是非常痛苦的。所以我们还是要保持一点警惕。
回到软件工程师本身，虽然我现在已经不写生产代码了，但我一直在用 AI 工具。我最大的感受是：它改变了你的“思考层级”，这其实也不意外。过去几十年，我们一直在向更高抽象层演进：更高级语言、虚拟机、云计算……现在我几乎不需要关心底层基础设施。我甚至不记得上一次看 assembly 是什么时候了，而刚入行时，那是日常操作。
Lee：在你的 TRS-80 Model I 上吗？
Nic：不，我是 TI-99/4A 阵营的（笑），买不起 TRS-80。
Lee：我当年在 RadioShack 打工，可以直接用店里的电脑。
Nic：你肯定还记得，有很长一段时间，我们写完代码丢给编译器，如果结果不对，就得打开 hex editor，一行一行去看：“你到底生成了什么鬼东西？”甚至还会直接单步调试生成的代码。但现在我们已经不这么干了。
你上一次怀疑是编译器 bug 是什么时候？这几乎不会发生了。这其实是件好事，它解放了我们。那些原本用来纠结底层细节的脑力，现在被腾出来去思考更高层的问题：系统架构、数据结构怎么设计、数据如何在大规模系统中流动、如何处理 petabyte 级数据……我觉得，这就是我们必须适应的转变。
再看 New Relic，我们的使命一直是让开发者和运维人员的工作更轻松。但随着他们的工作在变化，我们不仅要改变“做什么产品”，还要重新理解“我们服务的是谁，他们遇到的问题是什么”。
如果现在写软件变得更容易了，那问题来了：运行这些软件是不是也同样变容易了？
如果现在大家都能用 AI 轻松 Vibe coding，那谁来负责这些代码的运维？毕竟 AI 生成的代码运行起来照样会崩溃，而且你甚至没法问作者这代码啥意思，因为作者可能不是人。
Observability 的新对象
Lee：开发者会越来越向 software architect 这个方向演进，因为工具变强了，你自然要往更高价值的位置走。现在有很多人说 AI 会直接取代开发者，我一直觉得这说法不对。人类肯定还会参与软件开发，只是方式会发生巨大变化。
说回 AI 和 observability，我觉得其实有两个方向。我们刚刚聊的是第一个：用 AI 提升对系统的可观测性。但反过来，还有一个问题：AI 本身也是一个需要被“观测”的系统。那我们到底该怎么监控 AI 系统？
Nic：一个是 AI for observability，用 AI 做更好的 observability 产品。这很重要，因为系统越来越复杂，开发者和运维的压力每年都在增加，AI 可以帮我们“对冲”一部分复杂度。
另一个是 observability for AI。现在很多人在构建 AI 系统，这些系统是非确定性的（non-deterministic），且特性特殊，通常需通过 API 调用一整套新工具链。我们要思考的是：如何帮助他们？
其实从历史上看，这种模式并不陌生。虽然这次 AI 的速度和规模前所未有，但模式很像过去的几次技术变革：web、cloud、NoSQL……每一次都会改变“什么才是重要信号”。所以问题变成：AI 系统的 golden signals 是什么？
它们一定和传统 web 系统不同，就像 Kubernetes 出现后，我们重新定义了 deployment 和 monitoring 的方式一样。
我们现在就在探索这些 AI 的 golden signals，同时也在和 OpenTelemetry 社区一起推动标准化。因为现在很多 AI 能力都是“API 外包”的，你甚至不运行这些系统，只是依赖它们。
OpenTelemetry 的价值在于：让所有新框架从一开始就是“可观测的”，无论是 New Relic、开源方案，还是其他厂商。
我们最初的 AI monitoring 是基于自己的 agent（开源但偏向 New Relic），现在正在往 OpenTelemetry + generative AI 的方向演进。
Lee：监控 AI 到底只是触发器（Triggers）变了，还是整个可观测性的模型都得推倒重来？
Nic： 我认为模型是一样的，只是触发器不同。
AI 系统和 web 系统的关系，其实就像数据库和 web 系统一样，它只是多了一套“自己的语言”。比如我们现在要关注：token 使用量、成本、response 质量、用户情绪（sentiment），甚至要评估“答案是否正确”。
很多新手团队第一次做 AI，他们不知道该看什么，也会担心：系统会不会乱说话？会不会烧钱？会不会惹怒用户？
这时候，工具厂商必须提供“默认判断”（opinionated guidance）。不能只是说：“你想监控什么都可以。”这对第一次上线 AI 的团队来说毫无帮助。你必须告诉他们：哪些信号最重要、合理范围在哪里、该关注什么风险、应该如何结构化数据。不仅是提供数据，还要帮助他们“理解该担心什么”。
Lee：当我构建一个 AI 驱动的系统时，我其实默认接受了一点：它是 non-deterministic 的。这既是优点，也是问题。它可以产生创新，也可能产生幻觉。
那 observability 在这里的作用是什么？比如：今天幻觉变多了，这算不算问题？或者输入数据导致输出波动更大，这些算不算信号？
Nic：是，这是一个核心信号。比如我把问题发给一个便宜的第三方 API，但我可能每隔一千个请求就抽样一个，发给另一个更贵、更强的模型去做对比评判：“这个回答得好吗？”
你实际上是创建了一个由一群不太靠谱的员工组成的“虚拟呼叫中心”。你需要一个“主管”，在走廊里来回巡视，确保这些 AI Agents 没在胡说八道。评估答案的质量，就是 AI 时代不同于数据库或云基础设施的新信号。
和传统系统不同，你不仅要看性能指标，还要评估“答案质量”。某种程度上，它就像 response time 或 error rate，只是换成了“语义质量”。过去你可能需要人工判断答案好不好，但在大规模系统中，这必须也交给 AI 来做。
Lee：那像 New Relic 这样的公司，会不会直接做这种“质量评估”？还是只负责提供数据和工具？
Nic：这个问题现在还在动态变化。目前我们的思路是：提供结构和工具，引导用户去做这些评估，比如 sampling、judging，然后把结果纳入系统。我们还没有直接替用户做这件事，一方面是行业变化太快，另一方面也涉及数据隐私，试想，你愿意把多少数据发给外部？
不过我认为未来必须往这个方向发展。因为用户需要的是“5 分钟就能上手并获得价值”。比如你刚上线系统，就能看到：“从 Sonnet 4.5 升级到 4.6 后，你在某个购买流程里的回答开始变奇怪了。”这对你来说是极其关键的信息，你可以立刻去检查 prompt 或 fine-tuning。否则，你可能只能等用户投诉才发现问题。
而 observability 的核心目标始终是：在用户抱怨之前，你就已经理解系统发生了什么。这一点不仅适用于 CPU、页面性能，也同样适用于 AI 输出质量。
Lee：这种思路其实可以延伸到 AI 之外。比如客户在页面上关注什么？为什么从 A 点跳到了 B 点？一旦你开始关注“应用如何与客户交互”，可观测性就进入了一个全新的领域。
Nic： 没错，可观测性本来就该涵盖这一切。
回想我 2000 年初在一家创业公司时，当时我们有各种 alerts，用来告诉我们系统哪里出问题了。但办公室角落里有一台电视，只显示一个图：每分钟的销售额。
我们都知道，如果系统出了问题，这个数字一定会掉。这个图不会告诉你“哪里坏了”，那是 CPU、内存、数据库这些 alerts 的工作。这个图回答的是更重要的问题：你的业务目标有没有达成？直到今天，这依然是最核心的问题，比 AI、cloud、data 这些都重要。
你有没有在实现你的业务目标？为什么？你是否真正理解用户在做什么？他们有没有成功完成他们想做的事情？如果你能回答这些，那其他一切都只是“诊断工具”，只是帮助你优化或定位问题。
真正的“source of truth”始终是业务本身：如果你是电商，那就是有没有成交；如果是社交产品，那就是用户有没有互动；不管是什么产品，你之所以写这些软件，就是为了实现那个目标。
Lee：对于刚毕业、刚准备进入行业的开发者，大家都在担心 AI 会不会抢走工作，你最想对他们说的一句话是什么？
Nic：如果只能说一件事，我会先说：我真的很理解他们。
我有很多朋友刚刚进入这个行业，现在其实是个非常艰难的起点。整个环境充满不确定性，宏观经济、全球贸易、AI 本身，这些因素叠加在一起，让公司变得非常保守。他们不愿意冒险招聘新人，因为害怕很快又不得不裁掉，现在几乎所有公司都在放慢招聘节奏。这和大家以前听到的“科技行业机会无限”完全不一样，落差会非常大，也很打击人。
但是，工作一定会有的。只是你可能需要更“传统”的方式去找，比如多投简历、主动联系、拓展人脉，就像 30 年前科技行业还没那么火的时候那样。
至于技能方面，我的建议是：一定要花时间去用这些新工具，比如 Claude Code，用它们来真正构建软件。关键是不要把它们当成“自动生成代码的黑盒”，应该把它们当成一个“可以解释的老师”，让它告诉你：它为什么这么做、它是怎么实现的。
写作时，不要让 AI 帮你写内容，没人想读 AI 写的东西。但你可以让 AI 帮你“读”你的文章，问它：“作为读者，你觉得哪里没讲清楚？”用它来打磨自己，而不是替代自己。
你们这一代开发者，很可能不会再从我们当年那种“底层起步”的路径成长起来，我也不认为你们需要这样。你们会从更高的起点出发，去到我们甚至想象不到的地方。只是现在这个起点，确实有点颠簸。
访谈原链接：https://softwareengineeringdaily.com/2026/04/14/new-relic-and-agentic-devops-with-nic-benders/
