1 为什么要引入 DeepSeek 故障定位

在讨论这个话题之前，需要先聊一聊传统的基于专家经验的故障定位的思路

●     数据源：提供可观测中 Tracing、Metric、Log、Event、Profiling 等各种数据

●     算法：对上述数据进行异常检测或者下钻分析

●     定位模型：作为大脑，掌控整个定位流程

○     编写各种场景的定位逻辑

○     在每个场景定位逻辑中

■     获取该场景下的数据

■     使用算法对数据进行异常检测

■     综合分析后跳转到下个场景继续定位

这里存在的难点有如下 2 个：

●     难点 1：每种场景都需要一定的专家经验才能编写出合理的定位逻辑：目前并没有太好的解决方案，还是靠定位专家来编写

●     难点 2：对各种各样的数据的都能进行自适应的异常检测：目前是采用智能的异常检测算法来应对

在各种大模型比如 DeepSeek 的智能推理出现后，上述 2 个难点问题就迎来了新的转机

●     针对难点 1：DeepSeek 已经具备了非常丰富的各种场景运维经验

●     针对难点 2：自适应的异常检测这种智能化的东西更是 DeepSeek 的强项

所以是时候重新需要思考下：在大模型的加持下，故障定位到底该如何改进了

2 引入 DeepSeek 的方案探讨

引入 DeepSeek 后最初步的设想是：大模型承担更多智能化工作，我们只需要提供数据源即可

整体定位架构就变得非常简单，如下所示：

●     大模型替代了 2 大模块：定位模型+算法

○     大模型作为大脑，掌控整个分析定位流程

○     大模型作为算法提供者，可以自主分析各种数据

●     我们需要将数据体系投喂给大模型：大模型根据数据体系来决策分析思路

●     数据源：向大模型提供定位时需要的数据

就是把智能化的工作交给大模型去处理，我们的重点就在于将我们的数据体系向大模型描述清楚，举个例子：

比如从 Trace 中抽取出了 http 接口的指标信息，如下所示：

●     metric：service.http

●     tags：clientService、clientIp、serverService、serverIp、httpUrl、httpCode、httpMethod

●     fields：cnt、error、duration、requestPayload、responsePayload

这里就是我们需要把我们的指标体系提供给大模型，让大模型理解这个指标是干什么的，有哪些 tags 和 fields，同理 Tracing 等其他数据也是类似

思路的本质：我们是需要将故障定位这个问题向大模型描述清楚，同时并不限制大模型的分析思路。因为一旦限制大模型的分析思路，那么我们的限制将成为定位的瓶颈，大模型也失去了智能化的意义，变成了一个执行器而已

这看起来才是一个智能化的架构，不过是一个非常理想的架构，存在哪些痛点呢？

以上述 service.http 指标为例，各种维度组合下，最近 10 分钟的 Metric，这个数据都可能有几 M 的大小

●     大模型 token 还无法支撑

●     token 过大时分析速度会很慢

基于以上痛点，业内也有基于 DeepSeek 的故障定位业的实践者，他们的主要思路如下

●     针对每个服务的每个指标进行异常检测

●     将下面 3 个元素发给大模型

○     服务拓扑

○     每个服务的异常检测结果

○     定位思路

●     大模型按照给定的定位思路进行解释执行

那在这种方案下，大模型接手的是处理过后大数据，数据量大大减少，确实解决了这个痛点，但是也会有副作用，大模型演变成了一个工作流执行器，失去了智能化的威力

有没有更好的方案：既能解决 token 的限制，也能充分发挥大模型的智能化呢？

●     我们提供数据体系投喂给大模型

●     大模型根据数据体系来决策整个分析流程：向 Agent 智能体下发分析命令

●     Agent 作为执行体，负责执行大模型下发的分析命令

○     命令中包含要分析的数据：Agent 需要从数据源中获取这部分数据

○     Agent 使用异常检测算法对数据进行初步的分析

○     Agent 将初步的分析结果发给大模型，让大模型进行下一步的决策

●     大模型根据 Agent 的响应，综合性的决策出下一步的分析步骤

该方案的本质：将基础数据分析这种脏活累活交给 Agent，不仅大大降低了大模型的 token 数，还加快了分析速度，同时又能充分发挥大模型的智力

3 落地方案

落地方案如下所示：

1.       Agent 向大模型提供数据体系，解释各种数据作用

2.       大模型根据数据体系形成分析决策，给出分析命令

3.       Agent 接收到分析命令后，获取相应数据，根据算法对数据进行初步分析，并将分析结果发送给大模型

4.       大模型根据分析结果，继续优化分析决策，并给出下一步的分析命令

5.       Agent 重复上述步骤

6.       直到大模型决策出找到根因，无需再分析则结束

4 实际效果

提前告诉大模型对应的数据体系，以及数据体系中的数据关联和约束。

然后当出现告警时，让大模型给出下一步的分析命令。

上述大模型给出了要分析的数据，Agent 能够从数据源中获取该数据进行初步分析，然后将分析结果发给大模型。

大模型针对 Agent 的响应，综合性分析给出下一步的分析指令。

就这样如此往复，最终大模型会给出结束指令。

然后让大模型综合分析结论，给出故障树。

5 后续展望

这个方案有 3 个核心关键点：

1.  向大模型解释数据体系：解释最基本的数据。

2.  大模型对数据体系的理解能力：尽量自动理解数据之间的关联，不需要人为一个个明确解释。

3.  大模型的推理能力：结合场景和数据进行严谨的推理。

第 1 个关键点是我们需要努力的，合理并且简单的数据体系更容易被理解。

第 2、3 个关键点是大模型需要进一步优化的。目前的大模型还是存在幻觉和推理不严谨的问题，还需要加一些约束机制，以及在数据体系上花费大功夫来解释到位。

不过大模型还在飞速进步，这些工作也会逐步废弃。