AI 原生时代的可观测性——房间里的大象：人工智能既然我们已经讲完了可观测性，接下来就需要看看 AI，以及为了将可观测性

既然我们已经讲完了可观测性，接下来就需要看看 AI，以及为了将可观测性与 AI 集成起来以实现 AIOps 所需的各个组成部分。虽然我们预期你已经对 AI 有一定了解，但我们仍然加入这一章，既作为总结，也为后续章节建立上下文。

在本章中，我们将涵盖以下几个主要主题：

为什么 AI 会成为一个如此热门的话题，以及它当下究竟擅长什么
什么是模型上下文协议（Model Context Protocol，MCP）
RAG 与 CAG 是什么，以及它们与 LLM 的关系
如何选择语言模型
可能出什么问题，以及你可以如何应对
为什么 AI 项目会失败，以及它们在哪些地方会成功

技术要求

在本章中，我们将回顾与本地 LLM 交互是什么样子的。推荐使用以下工具来跟着一起实践；不过，它们并不是绝对必需的。这些工具会在整本书中持续使用：

LLM：通过 Ollama 运行 DeepSeek
（ollama.com/download）

在 macOS 和 Linux 上运行 DeepSeek 模型：

ollama run deepseek-r1

我们还提前购买了一些 OpenAI 点数，这样我们就可以向 ChatGPT 提问，并在本书后续章节中将其与 HolmesGPT 一起使用：
robusta-dev.github.io/holmesgpt/

一旦你已经在本地运行起 LLM，我们就开始深入吧。

为什么 AI 会有这么大的热度？AI 擅长什么？

AI 其实并不是一个新术语，但随着大型语言模型（LLM）的出现，它进入了一个全新时代。像 ChatGPT、DeepSeek、Claude 和 Gemini 这样的系统，可以接收自然人类语言指令，并返回各种形式的输出。这个输出可以是图像、代码、音乐，或者文本。最重要的一点是：LLM 输出的内容可以被人类自然理解；它不需要再经过额外的翻译层才能有意义。

这种计算机与人类之间的自然接口令人兴奋。它降低了人与机器交互的门槛。这并不意味着你仍然不需要一定程度的技能——提示词工程（prompt engineering）就是一项关键技能，我们会在本章稍后进一步讨论——但对于很多简单任务来说，与机器交互所带来的认知负担确实变小了。

AI 与自动化

在 AI 出现之前，我们其实早已在使用软件自动化来处理各种任务。自动化，本质上是把人类知识转化为可以执行某种流程的软件。这种流程可以根据需要被设计得非常简单，也可以非常复杂，许多常见的自动化工具都能够处理依赖等待和竞争条件。要编写自动化，你必须知道如何成功地完成那些即将由自动化接管的任务。AI 的优势恰恰就出现在这里。当你向一个 AI agent 或 assistant 发出指令时，你不一定需要知道这个任务该怎么做。AI 会替你把这件事想出来。鉴于对人类专业知识要求的降低，人们可能很容易产生一种冲动：那就干脆直接上 AI，完全不要自动化了。但这未必是最明智的做法。在评估 AI 时，我们必须权衡：什么样的行为模式最能支撑我们的使用场景。可以考虑两个很实用的原型——AI agent 和 assistant：

Agent（Agentic AI）：

主动型：可以独立行动
可以比人类行动得更快
如果被赋予了糟糕的指令，或发生幻觉，可能会很危险

Assistant：

被动型：必须等待指令
可能无法直接采取行动（例如聊天机器人）
可能可以调用 agent（充当调度者）
可以比人类更快地解释数据
直接与人类交互
如果被赋予了糟糕的指令，或发生幻觉，可能会很危险

这两类系统各有其优势，但都不是银弹。AI 可能在某些场景下算不上太贵，但大多数自动化系统在计算层面上都微不足道，因此对于同样的任务来说，维护自动化的成本甚至可能高于直接用 AI。

假设我们负责一个云环境中的虚拟机（VM）集群。业务逻辑告诉我们：应该运行足够多的 VM 以快速处理工作负载，但又要足够少，以避免浪费金钱。与其雇佣一个庞大的运维团队——并且让他们因重复性任务而倦怠——标准做法通常是依赖自动化。在 Kubernetes 环境中，通过 Prometheus，或者在 AWS 环境中通过 CloudWatch，围绕系统容量配置告警是相对容易的。这些告警可能会表明需要扩容或缩容，但它们只会提示人类进行交互；它们并不能替代人类。由于人力成本相当昂贵，因此围绕系统容量（例如 CPU 和内存使用率）的告警或指标，通常会配合自动化一起使用，以对这些告警做出响应。在 Kubernetes 中，这可能涉及像 Cluster Autoscaler（kubernetes.io/docs/concep…）或 KEDA（keda.sh/）这样的工具，即 Kubernetes-based Event-Driven Autoscaler，它们会与 Amazon CloudWatch 或 Azure Monitor 这类云可观测性工具集成。对于非 Kubernetes 环境，也存在类似选择，例如 Azure Monitor 中的 Autoscale 功能。告警与自动扩缩容规则，就是非常典型的自动化示例，而且通常都比较简单。当达到预定义阈值时，就发送一个告警。当 CPU 和 RAM 利用率接近 100% 时，这匹配的是一种模式——它曾经用于预测老式独立服务器的崩溃。从这里开始，你的自动化规则可以是呼叫一个值班操作员，也可以是新增一台 VM。无论采取什么动作，它都在代码中被清晰地定义了，自动化永远不会偏离这个定义。它没有任何机会展现出代码中未被写明的“智能”。

相反，一个 AI agent 也可以完成同样的事情，而且无需严格定义，它就能自行判断如何行动，但运行成本会更高，而增加的价值却很有限。不过，如果某个系统的扩缩容需求要么呈现规则性模式，要么比基准测试预测的更频繁地发生，那么就可能需要进一步调查。

对于人工运维人员来说，手动调查自动化事件的成因，可能会相当枯燥且耗时。资源消耗很少会在某一刻瞬间全部发生，因此理解资源利用情况可能需要分析一段相当长时间内的数据。在这里，AI assistant 就能提供巨大的价值，因为它可以帮助运维人员获取、过滤、清洗、标注并总结信息。要求运维人员快速查看过去 5,000 个事件，或者迅速整合 10 个彼此分散的数据源，是不合理的；但这些事情对 assistant 来说却是轻而易举。借助 AI，还可以把运维的成熟度再向前推进一步——让 assistant 去调用 agent。随后，agent 就可以解读 assistant 提供的运维数据，并以“某个正在响应工单或告警的人”的角色来采取行动。

即便你把 AI 与自动化结合在一起，也依然合理地期待：自动化规则去触发值班告警，即使这些告警本身并不可直接操作。但同样合理的是，由 AI assistant 识别出某些模式，从而减少运维 Pager 在半夜响起的次数。不同于受限于程序逻辑的自动化，assistant 本质上可以扩展一个人类运维人员可用的资源，而这个人类可能缺乏经验，或者根本没有额外人手可用。

在 AI agent 与复杂自动化之间，它们的能力维恩图有很大重叠；不过，AI agent 的硬件需求更高。要运行一整套基于 LLM 的 AI 工具，你需要图形处理单元（GPU），这可能很昂贵，也未必容易获得。那么，为什么还要使用 AI agent，而不是构建并运行复杂自动化系统呢？区别归根结底在于：易用性与易变更性。AI agent 的易用性，直接对应了 AI 相对于自动化的独特价值。

AI 的独特价值主张是什么？

AI 能够做出看似直觉性的跳跃，并且具备无监督学习能力。它可以在用户并不理解其工作原理、也不一定理解或关心全部上下文的情况下，对提示作出响应。与早年那些为了通过图灵测试而设计的系统不同，这一代 AI 被要求对不断变化的输入和条件做出响应。这并不意味着它已经达到“天网”级别的智能（能够在实时环境下做出战术上极其高明、完全自主的决策），但它确实意味着：在一个会话内，AI assistant 可以根据用户需求进行调整，而 agentic AI 则可以开始识别模式，并基于它所收集的信息提出建议。

重要的是，用户的交互和输入会直接影响 AI agent 或 assistant 的输出与行为，因为它会根据用户在不同需求领域中的期望不断变化。让我们来看一个简单用例，它能说明我们给 AI 系统施加的需求有多广：rubberducking。在软件工程中，rubberducking 指的是字面意义上的“对着一只橡皮鸭（或者一小群）把问题讲出来”，以帮助你理清思路并解决问题。生成式 AI 已经超越了一只橡皮鸭、一个手偶、一本 runbook，甚至一张逐渐褪色的便签纸（上面还写着一个不那么温柔的提醒：去看手册）。它的视角未必新颖，也未必专家级，但即便如此也可能依然有用。GitHub 在给自己的 AI 助手命名为 Copilot 时，就完美地捕捉到了这一点。

有了 agentic AI，AI 系统会主动审查数据，并提出建议，甚至在完全没有人工干预的情况下，依据它认为需要的内容直接采取行动。这实际上等于给人类团队增加了一双额外的眼睛和耳朵，使他们能够把时间投入到那些 AI 目前还不一定能像人类一样处理得那么好的工作上，包括训练 AI 系统本身。

AI 现在擅长什么

LLM 以及我们今天所称的 AI 技术都相当新，就其可用性而言，它们几乎可以说是全新的。在第 3 章中，我们将深入探讨多个 AIOps 使用场景和实践示例；但在这里，我们也会先从高层次看几个用例，因为这些例子将为本章剩余理论内容提供非常有用的上下文。

正如前面讨论过的那样，一个连接到你的监控与告警栈的 agentic AI 系统，动作可以比人类更快。如果某个阈值被超过，或者某个告警被触发，AI 系统能够更快地收集并解析数据，把它们整理成人类可消费的信息，这可能包括建议动作，甚至在无人干预的情况下直接采取行动。就目前而言，大多数专家都不会建议你盲目信任 AI 的建议。就像对待任何一次人工干预一样，任何动作，尤其是写动作（write actions） ，都应由人类进行审查。

AI 系统还会非常迅速地识别并呈现模式。一个例子是：发现某种资源压力是规律性发生的。这可能来源于每周一次的备份任务、正常用户行为，甚至是某个软件缺陷。虽然正确识别根因未必已经落在 LLM 的能力范围之内，但识别模式并据此提出预测性扩缩容建议，却是可以做到的。这优于其他自动扩缩容技术，因为它是主动式的——也就是说，它会在资源争用真正发生之前完成扩缩容，而不是等到某个预定义压力阈值被击中之后才反应。

至于根因，AI 可以被用来快速收集数据、把那些根据你的要求看起来值得注意的东西浮现出来，并帮助你更快地识别根因，但它未必一定值得被信任去正确判断一个复杂问题的真正根因。

一个创造价值的抽象层

在可观测性和运维领域，不存在一个能解决所有问题并同时提供所有必要业务价值的单一工具。试图构建并维护这样一个工具，无异于西西弗斯式的任务。因此，大多数组织都会使用多个彼此相关的工具来获取完整的可观测性和运维数据。一旦所有这些数据都存在了，要把数据转化成信息仍然会极具挑战，并且需要投入大量专门工时。对于 AIOps 而言，这正是在技术栈中加入 AI assistant 或 agent 的真正力量所在。

在与作者们的一次交流中，行业专家 Premraj Varadharaj Singaravelu 是这样表述的：“ [借助 AI] 我们整合的是可观测性数据，而不是工具本身。数据应该是工具无关的。 ”

要求计算机同时从多个来源中做模式匹配并收集数据，这几十年来一直是系统管理员和其他运维专业人员的核心任务。一个简单的 Bash 脚本配合一些 sed 和 awk 命令，就可以比任何人手工处理更快地产出一份经过清洗的数据报告。而把 LLM 应用到同样的概念之上，则会更加强大。

想象一下，你有一个运行在云中的 Kubernetes 集群，承载着一个内部开发者平台（IDP）。运维数据可能来自多个来源，例如应用数据与指标、系统运行时与指标、网络栈、数据库等等。Prometheus 和 OpenTelemetry 这类工具能够帮助从运行时环境中收集实时指标，而且这些数据在采集后往往很快就会被查看，因为它们通常用于判断部署健康状态或调查事故。然而，所采集的数据通常也会被长期存储；超过某个时间阈值的数据，很可能会被迁移到冷存储以节省成本。从第二个位置取回这些数据，会需要额外的过程。此外，日志可能通过 Loki 这类系统被收集与存储，而 Loki 可能又会把它们放到第三个位置，例如对象存储。将多种数据类型和多个位置整合起来，对大多数可观测性系统及其工程师而言都是再正常不过的日常工作。一个优秀的平台可观测性技术栈应该是工具无关的，它应更多关注那些能够保证运维卓越的实践和模式。

再来看另一个场景：假设你在运营一个全球性的金融系统。当你的面向用户的软件覆盖面如此之广时，客户常常会跑到社交媒体上抱怨可用性和性能问题。传统的可观测性工具未必能够把这类数据带入运维团队，但一个 AI agent 却能够审查社交媒体标签，并将这些数据与系统数据一起汇总。加入 AI 工具之后，你就不再需要把工具本身做整合或做限制，因为 AI 会成为运维团队用来整合数据的那个接口。AI 的这种应用，也使我们前面所说的“工具无关性”成为可能。如果 LLM 成为接口，那么无论后端工具和数据源如何变化，用户在运维场景中的交互路径都可以保持一致。这就使得后端团队在构建和交付应用时，可以自由使用最能帮助他们在运维上取得成功的工具，而不会破坏整体平台层面的能力。

在这些复杂的活动部件以及围绕可观测性已经形成的实践之上，你如何把这些东西整合起来，从而获得超越单个 LLM 及其训练数据本身的收益？一个 AI agent 怎么会知道如何把日志、社交媒体和指标数据整合到一起？这正是 模型上下文协议服务器（MCP server） 发挥作用的地方。

模型上下文协议（Model Context Protocol）

在软件工程中，随着问题变得越来越复杂，通常会引入一个抽象层，或者说一个间接层，来把复杂性集中地解决在一个地方，而不是让它以难以重构的方式蔓延在整个代码库中。MCP 只是这一原则的另一个例子。MCP 制定了一种标准，使得 LLM 与其所依赖、或它可能需要采取动作的其他系统之间，能够拥有一个通用接口。MCP 可能通过 API 或其他方式提供这个接口，但这对 LLM 来说并不重要。该协议在每一个 MCP server 上都完全一致，从而使运维人员能够把任意数量的、针对特定用途构建的 server，无缝集成到自己的 AI 系统中。

MCP server 是为特定目的而构建的，也就是说，它所提供的抽象，是针对该 MCP 所独有功能的抽象。正因如此，一个 AI 系统通常很可能会同时使用多个 MCP server，从而使 LLM 能够整合来自多个来源的数据。

例如，在我们前面那个“计算资源迅速逼近 100% 利用率”的场景中，你可能会让一个 agentic AI 先检查云上是否还有配额可用于再创建一台 VM，同时也让它检查运行中的应用是否存在内存泄漏证据。这是两个非常基础的任务，但它们要求 AI agent 面对的是两套完全不同的接口；于是，每个任务都会分别使用一个 MCP server。

MCP server 是一个相对容易理解的软件组件，但它的能力非常强大。

其整体架构遵循客户端—服务器架构模型，而根据 modelcontextprotocol.io 的定义，一个完整 MCP 架构的组件列表如下：

MCP host：负责协调和管理一个或多个 MCP client 的 AI 应用
MCP client：维持与某个 MCP server 的连接，并从 MCP server 获取上下文，供 MCP host 使用的组件
MCP server：向 MCP client 提供上下文的程序

需要特别注意的是，这里的 server 并不是指“运行应用的那台机器”，而更像是“一段向另一段软件提供信息（此处是上下文）的软件”。MCP server 被设计成 AI agent 与数据源及其他基础原语之间的连接层。

官方文档继续给出了一个例子：Visual Studio Code 可以作为一个 MCP host。下面这张截图中，你可以看到多个 MCP server，它们可以通过 Visual Studio Code 连接：

图 2.1 —— Visual Studio Code 扩展市场中可用 MCP server 的截图

在 Visual Studio Code 的这个例子中，MCP client 来自 VS Code 运行时。客户端到服务器的连接是一对一的，因此一个 host 可以运行多个 client，但每个 client 只会连接一个 server。由于 MCP 是一项标准，因此所有组件与功能在每种实现中也都是标准化的。

MCP server 的组件与特性

MCP server 由两个被称为“层（layers）”的组件构成。第一层是数据层，第二层是传输层。它们在 MCP 官方文档中有详细说明：
modelcontextprotocol.io/docs/learn/…

由于官方文档始终会比一本书更接近“真相源（source of truth）”，因为它可以持续更新，所以这里我们不展开太多细节，而只给出文档中当前的高层定义：

数据层（Data layer） ：定义基于 JSON-RPC 的客户端—服务器通信协议，包括生命周期管理，以及工具、资源、提示和通知等核心原语
传输层（Transport layer） ：定义客户端与服务器之间进行数据交换的通信机制和通道，包括与传输相关的连接建立、消息封装与授权

除了 MCP server 的这两个层级之外，还有若干 原语（primitives） ，也就是其基础元素。MCP 中“原语”的概念，正是这个标准真正强大的地方。一个 MCP server 可以使用所有原语，也可以只使用其中一种。并且每个 server 都支持 Discovery（发现） ，也就是说，它能够按需列出自己支持哪些原语。这让 LLM 组件能够在无需任何额外编码的情况下，学习并利用新的 MCP server 能力。根据 MCP 官方文档中给出的定义（modelcontextprotocol.io/docs/learn/…），MCP server 的原语包括：

Tools（工具） ：AI 应用可以调用的可执行函数，用于执行动作（例如文件操作、API 调用和数据库查询）
Resources（资源） ：向 AI 应用提供上下文信息的数据源（例如文件内容、数据库记录和 API 响应）
Prompts（提示） ：帮助组织与语言模型交互的可复用模板（例如 system prompts 和 few-shot examples）
Sampling（采样） ：允许 server 向 client 的 AI 应用请求语言模型补全。这对于那些想要访问语言模型、但又希望保持与具体模型无关、并且不想在自己的 MCP server 中集成语言模型 SDK 的 server 开发者很有用。他们可以通过 sampling/complete 方法，向 client 的 AI 应用请求语言模型补全。
Elicitation（引导提问） ：允许 server 向用户请求额外信息。这对于那些希望从用户处获取更多信息，或请求用户确认某个动作的 server 开发者很有用。他们可以通过 elicitation/request 方法向用户请求额外信息。
Logging（日志） ：使 server 能够向 client 发送日志消息，以用于调试和监控
Tasks（任务） ：一种持久化执行包装器，支持对 MCP 请求进行延迟结果获取和状态跟踪（例如高成本计算、工作流自动化、批处理和多步骤操作）

在本书后续内容中，我们会使用 MCP server，并展示它们在 AI 系统中的实际样子。需要知道的是：MCP server 并不能替代通过其他行业方法来增强 AI 系统知识，例如微调（fine-tuning，我们会在第 9 章进一步介绍）。MCP server 只是增强 AI 系统能力的另一种方式。

RAG 与 CAG，以及它们与 LLM 的关系

如果没有额外组件，LLM 的能力会受限于它被训练时所使用的数据。不过，它的数据也可以通过另外两种自然语言处理方法来增强，而这两种方法本身也已经成为了业界标准。

检索增强生成（RAG） 和 缓存增强生成（CAG） 都属于自然语言处理方法。不过，它们生成输出的方式不同。

RAG 与 CAG

当一个 LLM 试图生成响应时，它会在其整个知识库中寻找依据。而 RAG 与 CAG 都会在一个更受限制的数据集上工作，以生成响应。不过，它们彼此在功能层面是不同的，并且会根据具体业务场景和数据特性提供不同优势。

RAG 是一种令人安心的方式，用于缓解“信息过时”问题。假设某人在 1982 年于巴尔的摩陷入昏迷，并在 1992 年突然醒来。如果此时问他：“美国现任总统是谁？”他可能会回答“罗纳德·里根”。这个答案当然是错的，因为他掌握的信息已经落后了 10 年。如果他能够像 RAG 那样处理这个问题，他会先搜索关于现任总统的外部来源，然后结合这些结果与问题来作答。就像 LLM 一样，这会让他即使在并不完全知道自己所处时代背景的情况下，也能给出正确回答。

从业务场景角度看，如果你的数据集范围非常广，和/或变化非常快，那么 RAG 就是首选的数据增强方式。

在可观测性场景中，如果你问：“今天系统健康状况如何？”一个具备 RAG 能力的 assistant 会先去检查实时指标和日志，然后再回答。这个答案不会是即时的，但会非常准确。

CAG 提供了另一种思路：先加载一批上下文，然后基于它进行回答。如果同样是那个醒来的人，先去收集当前世界状况的信息，那么接下来在被问问题时，他就可以不再依赖外部检索而作答。这也会让他回答得更快。在计算机领域，CAG 非常适合那些边界明确、更新不频繁的数据集，例如 runbook。

还是用同样的例子：你也可以附上一份日志文件，说：“请查看这些日志，然后告诉我，今天系统健康状况如何？”你得到的答案几乎会是即时的，而且基于这些日志它也会是正确的。但如果在你提取日志与开始这个 AI assistant 会话之间的那一分钟里，系统崩溃了，那么这个答案就可能已经过时。

不过，如果你有一个 AI agent 正在排查某个告警，而告警信息与 runbook 在一开始就被提供进去，那么 agent 就能非常快地返回 runbook 执行结果，因为使用这些额外上下文的过程已经预先存在了。

这两种方式都有利有弊。CAG 对可引用数据量存在限制，因为所有数据都必须预先放入缓存中；但这些数据可用得更快，因此任何依赖缓存数据的 prompt，返回结果都会比使用 RAG 更快。

RAG 的限制更少，因为虽然执行检索过程会增加额外时间，但数据可以是实时的，这对于通过解析可观测性指标来理解软件健康状况或应用当前状态非常有用。

虽然 RAG 与 CAG 系统本身也可以独立存在，但这是相当非典型的使用方式；它们更常见的用途，是作为 LLM 的增强手段，为模型提供训练数据之外的更新数据或外部数据。RAG 和 CAG 也都不同于 微调（fine-tuning） ，后者是一种将新数据添加进 LLM 训练知识中的特定方法。与 RAG 和 CAG 中“增强数据始终保持独立”不同，微调允许 AI 系统的使用者将系统知识扩展到某个特定专业领域，尤其是当这部分数据是专有数据时。

对于这三种生成方式（LLM、RAG 和 CAG）来说，所依赖的数据都可以被索引并赋予权重，以帮助 AI 系统给出更准确的响应。这是保证 AIOps 系统质量的一个重要方面，因为它能够作为防护措施，降低错误和失败发生的概率。

选择语言模型

你知道吗？从技术上讲，语言模型其实有两种“口味”。除了 LLM，还有 小语言模型（SLM） 。SLM 在架构上与 LLM 类似；但是，它们接受训练的数据量要小得多，因此通常更高效、运行成本更低，但这也会增加它们发生幻觉或错误的概率。这可以通过微调来缓解；微调本质上就是进一步训练你的语言模型。但如果某个 prompt 超出了模型训练数据所覆盖的范围，那么它给出的响应就极有可能不准确。SLM 也可能更容易出现偏差，因为它们的采样数据本身就可能更有偏差，这可能是有意的，也可能是无意的。这里的“偏差”并没有什么特别含义，它和人类中的偏见没有区别，只不过通过训练数据传递给了 AI。

相比之下，LLM 拥有更多数据，因此它是一个非常通用的工具；而一个经过恰当调优的 SLM，则是一个针对单一应用而打造的专用工具，它会在自己被训练的那个场景上表现得极其出色。但并不是所有 LLM 或 SLM 的规模都一样。

在本章中频繁出现的 DeepSeek，就有多个不同尺寸。尺寸越大，它拥有的知识就越多。LLM 的知识不仅体现在总数据量上，也体现在参数（parameters） 上。参数是对数据的表征方式。正如你应该给可观测性数据打标签一样，用于训练语言模型的训练数据也会有权重、偏置、注释以及其他特征。参数不仅会在训练中被使用，也会在微调中被使用。关于微调，请参见第 9 章。

不过，对于一个并不需要那么强推理能力的任务，直接把最大模型扔上去，未必会比使用一个较小、但能力已在特定领域被扩展过的模型带来更好的性能。

此外，DeepSeek、Claude、Gemma 以及其他 LLM，都还会有专门为特定用途设计的不同变体。例如，DeepSeek、Gemma 和 Claude 都有专门设计成编码助手的模型。尽管它们可能更小，但在各自指定用途上，这些模型会比更大的通用模型表现更好。

然而，在模型选择时，需要考虑的数据点并不只有模型大小和用途。除了模型规模，模型的上下文长度（context length） 也会影响准确性与性能。上下文长度以 token 为单位衡量，它表示该语言模型在每个会话中能够保留的总 token 数量。在你的电脑上，这部分会存储在模型所使用的随机存取内存（RAM）里。换句话说，模型的上下文就是它在会话中能够记住的内容，而长度则表示你大致能使用多少上下文。

一个 token 是一个数据块，通常大约相当于 4 个字符。上下文长度越大，就意味着更多的数据/token。当你输入一个 prompt 时，它会被切分为 token，而响应也是从 token 开始，由模型逐个拼接并输出。很多 AI 厂商会按 token 消耗收费，因此换句话说，当你为 AI 系统中的 token 付费时，你实际上是在为数据传输买单。我们会在第 9 章进一步讨论 token 与成本管理的关系；这里先继续关注 token 对准确性的意义。

在本章中，我们使用的是 DeepSeek-R1 模型，它的上下文长度为 128,000 个 token。如果你去问这个 DeepSeek 模型，它会告诉你，这大约相当于 64 页文本，或者 几小时的对话。随着你与 AI 系统的会话持续进行、token 数量不断增加，一旦超过上下文长度，你就会发现系统开始变得不那么准确。它可能会忘记某个关键信息，或者产生一个看起来合理、但实际上并不准确的幻觉性答案。

在选择模型时，理解训练数据的某些信息非常重要，包括：该模型是否被设计成在某个特定领域中表现突出、它有哪些限制（包括上下文长度）等等。一旦掌握这些信息，就把你的使用场景和系统设计选项映射到这些约束之上，以选择一个或多个模型。例如，代码审查可以选择一个 SLM，而运维数据解析则选择一个 LLM。同时，对自己拥有的数据量有一个概念也很重要，这样你才能确保模型满足需求。好消息是：在一个 AI 系统中，连接器、托管等通常是最难的部分；而把一个模型替换成另一个，往往可以非常容易。

如果你观察到错误率很高或准确性很差，你就可能选择替换模型。接下来，我们来看一看：你的 AI 系统中可能会出什么问题，以及你有哪些应对手段。

可能会出什么问题（以及你能做什么）

虽然 AI 是我们工具箱中一个强大的工具，但和其他软件一样，它也会受到错误、缺陷或其他问题的影响。下面是一个“半穷尽式”的列表，列出 AI 系统运维人员可能会注意到的问题类型。

用户预期不正确

在本章开头，我们提到过，AI 的一个好处在于它会让人感觉像魔法一样。但这也可能导致不准确的预期。任何已部署的 AI 系统的用户，都应该清楚了解该系统在合理范围内能够做什么、知道什么。否则，AI assistant 或 agent 可能会给出错误答案或错误建议，甚至采取危险动作。

AI 系统的用户和运维人员需要了解以下内容：

模型训练数据有多新
AIOps 系统具备什么能力
什么样的 prompt 才算是好的 prompt
已知限制

其中，“已知限制”是最大的总括项，因为一个 AIOps 实现本身就是一个面向特定目的构建的系统。既然它是为特定目的而建，那么它应该做什么、不应该做什么，就必须被非常清晰地定义出来。应当明确告知用户：哪些地方不应依赖该模型，以免他们尝试把模型拉伸到超出其预期用途的范围。此外，在一个新的实现中，你可能还没有足够多的系统数据可用于微调。如果训练数据或调优数据存在空白，就应当指出这些空白在哪些领域，以便用户意识到，在这些任务上，模型此时可能还缺乏准确性。这种数据缺口可能会导致与推理相关的错误——因为 LLM 没有足够信息来正确解释 prompt。LLM 中的推理过程本身相当复杂，但归根结底，它还是围绕 token 的输入与输出展开。LLM 会一边考虑 prompt，一边参考自己已经开始生成的内容，逐 token 地继续输出。如果没有足够的参数或相关数据来为 prompt 提供上下文，那么响应就更容易出错。这也是为什么：向新用户和运维人员明确说明 AIOps 系统“目前知道什么、还不知道什么”非常重要。虽然设定正确的用户预期并不能防止所有问题或错误，但让运维团队一开始就站在更容易成功的位置，是 AIOps 成功应用的关键因素之一。

幻觉与错误

LLM 中的“幻觉（hallucination）”指的是：AI 对某个 prompt 作出回应，但回应中的信息不仅是错误的，而且根本没有扎根于其数据集中任何实际存在的数据。LLM 经常会以两种形式发生幻觉：一是识别出其实并不存在的模式，二是编造出其引用来源中根本不存在的信息。

幻觉与简单错误不同，尽管两者都可能带来问题。

来看一个例子：让 Gemma 统计单词 Pneumonoultramicroscopicsilicovolcanoconiosis 中字母 i 出现的次数（正确答案是 6）：

图 2.2 —— Gemma 错误回答为 5

在这里，LLM 只是过早停止了计数；它并没有发明并不存在的数据或信息。它只是犯了一个错误，以为自己已经数完了。但当我们进一步要求它“再试一次，因为答案不正确”时，接下来的回答就显示出了幻觉的迹象，尽管它也仍然可能被归类为一种错误：

图 2.3 —— Gemma 数出了并不存在的 i

第二次，它没有正确数出 6 个字母 i，而是莫名其妙地认为这个词里有 9 个 i，而第一次它只数出了 5 个。虽然这带有一定幻觉特征，但由于 LLM 还没有凭空捏造出什么具体事物，所以把它归类为推理错误，可能依然更准确。

一个更典型的幻觉例子，是下面这个来自 DeepSeek 的输出。上下文是：LLM 被问到，“你会如何诊断 TCP socket exhaustion？”模型给出了一个很长的回答，其中一部分内容包括：

D. Examine Firewall Rules

Firewalls can impose limitations based on source IP addresses or port
usage patterns that might lead to socket exhaustion if they block
connections too aggressively or restrict ports.

由于我对防火墙略有了解，这段回答看起来很奇怪，所以我继续提示它扩展这一概念，问它：“How could a bad firewall rule cause TCP socket exhaustion?”

模型返回了一段很长、听起来很有说服力，但显然不准确的回答。随后最后一个 prompt 是：“Cite sources for your last answer.” 它确实给出了来源，如下图所示：

图 2.4 —— DeepSeek 关于 TCP socket exhaustion 的最终回答

然而，前两个来源所给出的网页 URL 实际上根本不存在，而且很可能从来就没有存在过。这些项目把文档维护在 GitHub 中，而它提到的那些文件在 GitHub 历史中完全不存在。另一个线索是：这两个项目的文档 URL 模式根本不是这样。第三个 URL 中，也根本没有提到模型所声称的内容。在这个例子中，LLM 的回答听起来很有说服力，但它并不准确，而且来源是彻底编造出来的。

ChatGPT 的表现稍好一些，这也符合预期，因为相较于本地运行的 DeepSeek，它是一个更新、更大的模型。它解释说，TCP socket exhaustion 可能与有状态防火墙有关，并给出了有效来源。

但这仍然是另一个错误示例。有状态防火墙可能会经历 socket exhaustion，但它们并不是造成该问题的原因。最终，在进一步提示之后，它用一个图示给出了更准确的解释，指出：有状态防火墙自身可能发生 TCP socket exhaustion，而无状态防火墙则可能对另一台主机上的 socket exhaustion 起到促成作用。

注意
本例中使用的 prompt 是故意设计得不够理想的，以确保这些错误能够发生。

推理错误和幻觉会令人非常沮丧，尤其是当一个 AI 系统听起来极具说服力，并且它访问的数据你又不容易验证时，你就很容易被误导。以下是一些降低此类错误概率的建议：

选择一个符合你预期的模型。更大的模型拥有更多参考数据，因此可能更准确。更小的模型在面对其训练数据覆盖范围内的问题时会很快且准确，但如果被要求回答超出训练领域的问题，就更容易发生幻觉或错误。
依赖成熟可靠的聚合工具，例如 OTel 和 Prometheus，然后让你的 AIOps 从这些工具之上进行解释。
用领域专有知识对模型进行微调。我们会在第 9 章进一步介绍如何微调。
考虑通过 RAG 或 CAG 系统来增强模型，以提高准确性。
连接到一个 MCP，把模型的功能扩展到你组织真正关心的专业领域。

数据投毒

所谓 数据投毒（data poisoning） ，是指一个 LLM 被要求解释的数据本身是故意不正确的。具有全球声誉的大型组织，可能会把社交媒体抓取纳入其整体可观测性战略的一部分。不幸的是，用户有时比自动化、甚至比 AI 更快察觉问题。然而，社交媒体或其他由人类生成输入的数据源，可能会遭受数据投毒。

IBM 的这篇博客（www.ibm.com/think/topic…）很好地概览了数据投毒的类型，并引用了业界中的具体例子。它们的例子主要聚焦于恶意的、故意为之的投毒；我们会在第 9 章中进一步讨论这一点以及更多安全相关主题。本章中我们想强调的是：在许多系统里，数据投毒即便并不是出于恶意，也完全可能带来负面后果。

例如，考虑一种 标签翻转攻击（label-flipping attack） 。给可观测性数据打标签是一种很常见的做法，它有助于创建语义正确的链路，并在分布式系统中聚合相关应用数据。然而，可观测性数据中的标签翻转，很容易因为人为失误而发生，也可能是因为某个应用团队改变了打标签方式，却没有通知运维团队。这会导致团队向 AI agent 请求的数据被错误地归类为“不存在”，或者让显示出来的数据与大家的理解和预期不一致。接下来，团队可能就会围绕 AI agent 展开漫长的调试，最后发现：AI agent 按预期工作了，只是数据本身已经被投毒了。

再看另一个数据投毒场景：假设一个 AI agent 会基于用户在 Slack 中的聊天或工单，向 Slack 发布潜在系统故障更新。许多拥有面向客户工单系统的运维团队，常常会收到用户提交的“服务坏了”的工单。一个有判断力的人类可以通过追问正确的问题，进一步识别到底是真的坏了什么，还是只是用户误操作。然而，AI agent 未必知道该问什么问题，或如何正确解释回答。因此，它可能无法正确识别用户错误或某个依赖项的问题，最后会在并不存在故障时，错误地宣布发生了故障。

灾难性遗忘

灾难性遗忘（catastrophic forgetting） 或 灾难性推理退化（catastrophic inference） ，大概是所有潜在问题中最容易望文生义的一个。这指的是：一个模型在接受新数据或新任务训练之后，反而忘记了原有知识。这可能是重新训练或微调的结果。我们假定你大概率不会从零开始自己训练完全定制化的模型，而更多是依赖 LLM 厂商提供的模型。至于如何预防和缓解灾难性遗忘，这已经深入到了 AI 和神经网络底层机制的细节，我们认为它超出了本书范围；但如果你对该主题有兴趣，我们推荐这篇来自康奈尔大学的白皮书：
arxiv.org/abs/2501.01…

对于正在搭建 AIOps 系统的工程师来说，重要的是知道如何识别灾难性遗忘的症状。灾难性遗忘可以通过测量那些依赖 AI agent 的系统的性能来识别。这正是“观测你的 AI”非常重要的地方：监控响应时间、整体系统健康状况，并识别例行 AI 任务是否突然比平时慢了很多。虽然延迟升高或 AI 错误并不一定都是灾难性遗忘造成的，但它们确实是其典型特征，因此应当通过自动化和其他传统可观测性实践去加以监测。

无限循环

所谓 无限循环（infinite loop） ，基本上就和字面意思完全一样。LLM 会卡在一组相同步骤上无限重复，最终必须由用户手动取消。

来看这个例子：DeepSeek 在处理这个 prompt 时陷入了循环——“How many times does the letter R appear in the word strawberry?”：

图 2.5 —— DeepSeek 陷入循环的截图

你可以看到，在这个过程被取消之前，DeepSeek 已经围绕同一逻辑迭代了好几次，而且看起来又要开始新一轮。那为什么它没有在第一轮遍历单词之后，直接回答 3 呢？

答案一部分在于 LLM 本身的局限，另一部分则在于 prompt 的写法本身。对于一个普通人来说，这个 prompt 非常容易理解；但其中其实隐含了一些 LLM 未必天然能够把握的上下文。例如，在英语中，当我们提及某个字母时，将它写成大写在语法上是正确的；但从数学上说，大写字母 R 与小写字母 r 是不同符号，这就让 AI assistant 难以判断这种区别是否重要。因此，必须记住：计算机是在用数学机制决定如何生成响应，所以你的 prompt 需要给出额外清晰度。

现在我们换一个版本的 prompt，并用同一个模型（期间清空会话，以防不必要的上下文干扰）再试一次。

这一次，我们考虑到了计算机会如何处理和评估输入，因此给出了一个更适合它的 prompt，结果返回就是正确的：

图 2.6 —— DeepSeek 成功回答图 2.5 中问题的截图

LLM 不会在不同会话之间保留上下文，因此如果你希望跨会话延续上下文，就必须在每个会话开头把上下文提供给它。某些 AI 平台可能会替你存储上下文，从而让你从上次中断的地方继续；或者你也可以动态提供上下文——例如在调用 LLM 的 API 时传进去，或者直接包含在 prompt 中。

这就催生出一种新的实践：提示词工程（prompt engineering） 。

提示词工程会有所帮助

提示词工程，从功能上讲，就是识别“如何向 LLM 系统发出最佳提问方式”，从而获得一致结果的过程。在 James Phoenix 和 Mike Taylor 所著的 Prompt Engineering for Generative AI 一书中，作者提出了一个好 prompt 的五项原则：

给出方向
指定格式
提供示例
评估质量
分工处理

这项实践，以及如何成功实施它的方法，对于任何希望构建并利用 AI 系统的团队来说，都是关键技能。回看前面关于无限循环的例子，我们会发现：虽然一开始 LLM 表现得很挣扎，但 prompt 一旦被改进，它就成功完成了任务。另一个不同的语言模型，也许能够在原始 prompt 下直接答对；但重要的是，你必须知道如何与自己日常所使用的模型成功交互。

你并不需要一直为 prompt 苦苦挣扎，也不必靠无穷无尽的试错来摸索。当你已经拥有一个 AI 模型时，关于“如何最好地使用它”，最好的专家其实已经在你触手可及的地方了。AI 知道如何更成功地使用 AI。即便你的团队经验不足，AI agent 本身却知道应该做什么、如何去做。

我们来实际练习一下：请 DeepSeek 帮助我们评估 prompt。在我的机器上，我通过 Ollama 启动了 DeepSeek，并给了它如下 prompt：

I am a new user of DeepSeek hoping to use it in Software Observability applications. Please help me evaluate this prompt: “On an OpenShift cluster, there is a Prometheus alert firing; the alert is that CPU usage exceeds 90% over the last five minutes for a control plane node. Troubleshoot this alert”. Imagine that you have a kubeconfig, as that would be included with the prompt if it were real.

思考模式被开启了，所以我能够看到：它也知道哪些最佳实践可以构成一个好 prompt。结果，它给出了非常扎实的反馈，指出了这个 prompt 的优点与缺点。

DeepSeek 的结论是：这个 prompt 是个不错的起点，但缺乏足够具体性。例如，“troubleshoot” 过于开放，没有给出清晰的成功标准。于是我要求 DeepSeek 根据这些反馈重写 prompt，它返回了一个明显更好的版本：

On an OpenShift cluster, Prometheus is alerting that CPU usage on node [node-name] has exceeded the [metric] by 90% for 5 minutes. Please analyze the potential causes and provide specific actions to mitigate and resolve this alert.

提示
告诉你的模型尽可能简洁，以保持字数，也就是 token 数量尽量低。我们会在第 9 章讨论 token 及其与成本的关系。

前面我们提到过：上下文不会跨会话持续存在。这意味着，如果你想在多个会话之间携带上下文，就需要在每个新会话开始时向 LLM 提供上下文。有些 AI 平台可能会为你保存上下文，从而让你从之前的位置重新开始。或者，你也可以动态提供上下文——无论是通过 LLM 的 API 调用传递，还是直接写入 prompt 中。

我们再练习一次：清空前一个会话，重新开始。这次，我先告诉模型我们上一个会话中做了什么：

Last session, we discussed how to make a prompt for OpenShift alert troubleshooting better. Here is the prompt you suggested. “On an OpenShift cluster, Prometheus is alerting that CPU usage on node [node-name] has exceeded the [metric] by 90% for 5 minutes. Please analyze the potential causes and provide specific actions to mitigate and resolve this alert.” How can we make this even better?

模型给出了一个进一步优化后的 prompt，并解释了为什么它更好。

下面是改进后的 prompt：

“On an OpenShift cluster, Prometheus is alerting that node [node-name] has exceeded its CPU limit (current usage: [metric], threshold: [threshold]). The alert has been active for [duration]. Please analyze potential causes from these perspectives:
Resource allocation (for example, pod limits, node allocatable resources).
Resource contention (for example, CPU vs. memory bottlenecks).
Runtime behavior (for example, pod restarts, unexpected spikes).
Cluster-level issues (for example, node pressure, resource reservations).
Provide:
A prioritized list of root causes (most to least likely).
Specific troubleshooting commands (for example, kubectl top, oc describe node, oc get pod -A --sort-by).
Immediate mitigation steps (for example, throttling pods, evicting non-critical pods).
Long-term fixes (for example, increasing limits, optimizing pod resource requests, autoscaling).
Include potential risks (for example, throttling impact on application performance).”

DeepSeek 解释它之所以更好，是因为以下几点：

它避免了歧义（例如，把 “exceeding by 90%” 改为基于阈值比较）
它符合 OpenShift 最佳实践（例如，使用 oc 命令）
它在深度（根因）和实用性（命令与步骤）之间取得了平衡

这个 prompt 看起来确实不错，但也确实非常长；如果我们正在使用受限的上下文窗口，或者面对大量数据，这就可能成为一个问题。那我们再问 AI 一次：这次要求它优先考虑低 token 数量，并解释为什么新的 prompt 更好。

下面是优化后的 prompt：

“On an OpenShift cluster, Prometheus alerts that node [node-name] has exceeded its CPU limit (current usage [metric], threshold [threshold]). The alert has persisted for 5 minutes. Analyze potential causes and provide:
A prioritized list of root causes
Immediate mitigation steps (for example, throttling pods)
Long-term fixes (for example, increasing limits)
Include risks of actions”

关键优化包括：

减少冗余：
删除了泛化表述（例如把 “CPU usage on node has exceeded... by 90%” 压缩为 “exceeded its CPU limit”）
简化了告警描述，只保留关键细节（节点、指标、阈值和持续时间）
结构化输出：
用列表替代开放式请求，从而使输出更可执行
显式要求说明风险，以契合安全意识
Token 效率：
缩短了短语（例如用 “exceeded its CPU limit” 替代 “has exceeded the metric by 90%”）
去掉了额外假设（例如不再明确列出“请从这些角度分析”，因为这已经隐含在输出要求中）

之所以更好，是因为：

它只用了原来约三分之一的 token，却保留了核心任务
它优先要求给出可执行结果（列表/步骤），从而引导故障排查
它更适合 LLM 产出简洁、角色明确的响应

这个最终 prompt 确实更短，同时保留了几乎全部收益。正如我们从第二次让 DeepSeek 迭代时看到的那样，这三个 prompt 对于给定场景来说，很可能都能成功工作。不过，对于更复杂的任务，你就需要在设计 prompt 时投入更多思考。我们建议你使用 AI assistant 帮助自己构建 prompt，而这些 prompt 最终会塑造你的 AIOps 实现。在这里，机器审查所发挥的力量，完全可以与人工审查一样强大。

为什么 AI 项目会失败？你又该如何成功？

AI 项目失败有很多原因，而这些原因并不完全是 AI 独有的：

范围不清晰或过大
成本
缺乏专业知识
ROI 不足或回报太慢
过多的定制化实现

为了帮助确保你的 AIOps 项目成功，我们最推荐的第一策略是：采用产品思维（product mindset） 。项目会结束，而产品会演化；如果你用产品思维来构建 AIOps 实现，你就可以通过里程碑、关键绩效指标（KPI）和其他成功基准，规划出一条通向成功产品的路径。

Purpose（目的） 就是愿景；它定义了你想达成什么。任何项目，如果没有清晰的目标、内容和成功标准，都几乎不可能成功。对于新兴且尚未被充分理解的技术来说，更是如此。一个快速但不一定无痛的目的检验方式，是找离你最近的人，然后把它讲给对方听：

你能在 30 秒内解释清楚这个项目是什么吗？
你能解释清楚你将如何知道它是否成功吗？

“用了 AI”并不是银弹。如果这两个问题中有任意一个答案是否定的，或者表述不清，那就要考虑：这个项目是不是定义得太松散了，或者试图做得太多。这里并不是说项目过于雄心勃勃，而是说范围需要更精炼。站在技术前沿的风险之一，就是很容易掉进“一个解决方案到处找问题”，或者“试图一次解决全世界所有问题”的陷阱。那样的项目注定会失败。所以，要尽早识别出你真正的问题是什么，以及你将如何判断它们是否被解决。

一个好的产品有清晰定义的目的、一套指导它的原则，并且从一个 最小可行产品（MVP） 开始。原则是你在追求目标过程中，用来评估各种决策的护栏；而 MVP 则是在仍能形成端到端可用产品的前提下，你所能实现的最小版本。

你的原则可能体现为技术限制、商业伦理、安全与合规要求，或者业务目标。它们应当作为你绝不能违背的“法律”，否则产品就不可能成功。

在项目管理中，原则既可以表现为需求，也可以表现为 KPI。KPI 并不是一次性成功指标，而是需要持续评估的。随着你向项目中增加功能与能力，KPI 所反映的成功状态也必须持续成立；否则，你就可能需要重新评估 KPI。一个 KPI 示例是：我们的数据库备份可以在 15 分钟内恢复。这就需要被定期验证（例如每季度、每月等），以判断它是否仍然达成。如果没达成——例如数据库规模与复杂度已经增长——那么要么调整 KPI，要么改进过程以满足它。

这些看起来和 OKR（Objectives and Key Results） 有点相似，它们也可以一起使用，或者彼此独立使用。不过 OKR 与 KPI 不同，因为它是一个有时间边界的目标。和 KPI 一样，OKR 也应该是可衡量的；目标本身可能不那么容易量化，但关键结果必须可以用数据轻松量化。关键结果，正是你为了实现该目标而打算采取的路径。

一个 OKR 示例是：

Objective： 用户因系统的可靠性而感到满意
Key result： 系统可用性达到 99.99%
Key result： 发布过程可被观测，并通过 DORA 框架衡量成功
Key result： 导致系统不稳定的发布可以被回滚
Key result： 用户满意度调查结果处于 {Parameters} 范围内

OKR 可以非常宏观，而 KPI 可以更聚焦，这完全没有问题。这些工具本来就是为业务与产品管理中的不同方面而设计的。只要你的 OKR 和 KPI 都能被客观衡量，你就做对了。

除了有助于塑造技术路线图，OKR 和 KPI 还是非常有用的沟通工具。CEO 怎么知道这个 AI 项目真的在产生价值？尤其是对于 AIOps 项目来说，它们大多面向内部，不像营收那样直观可见，因此更需要清晰设定并传达你所做事情的业务价值。KPI 的成功达成，以及 OKR 的推进情况，都是向高层领导展示项目进展、并用他们熟悉的方式界定产品意义的简单方法。它们也能帮助你展示投资回报率（ROI），即使这种“回报”并不容易直接折算成美元。请记住：节省下来的人类时间也是 ROI，而且只要你在过程中持续量化，它就是可以被证明的。

其他项目杀手，例如成本问题，我们将在第 9 章中详细讨论，因为成本管理是一个非常关键的挑战，而 AI 在成本方面也有一些传统软件项目所没有的独特之处。不过从总体上说，要管理成本，你就必须追踪并观测你的花费。而你已经熟悉的那些可观测性工具，正好可以帮你完成这件事。

缺乏专业知识也会是一个挑战，因为这些技术太新，而且演进极快。阅读像本书这样的内容，是一个非常好的开始；你还会在大多数章节末尾看到 Further reading 小节，帮助你继续前进。

通过把 AIOps 实现当成一个产品来对待，你就可以持续跟踪成本与收益。把工作组织成 user stories；如果多个团队正在围绕 AI 与可观测性做不同项目，那么就要把工作集中起来。一个集中化的推进方式，也能帮助你提前避免成本失控和难以维护的技术债务螺旋。

如果你想进一步了解如何以产品思维来推进这类计划，我们推荐另一本 Packt 的书：Platform Engineering for Architects，作者是 Max Körbächer、Andreas Grabner 和 Hilliary Lipsig。

总结

总而言之，按照我们今天的定义，AI 仍然是一个不断演化的领域，这项技术还在寻找一种像较老一代机器学习技术那样的稳定性。它有自身的优点与弱点，并且要想在任务上取得成功，就需要人类输入与数据调优。不过，只要有工程师在组织内部指导并定义 AI 的使用方式，并以产品思维来治理它，那么面向运维的 AI 项目就可以成为现代组织的强大工具。在下一章中，我们将更进一步，深入探讨 AIOps 今天就可以解决的使用场景。

AI 原生时代的可观测性——房间里的大象：人工智能