---

在错综复杂的IT运维环境中，快速精准定位并高效解决故障是保障业务稳定运行的关键，每当故障发生，运维人员常陷入如下困境：

"这个告警好像上个月处理过..." 

"当时是怎么定位的来着？"  

"要是系统能自动调出类似案例就好了"

事实上，不少企业的运维团队积累了大量故障处置记录，但每次告警响起，还是靠运维人员回忆、翻工单，历史经验就像散落的珍珠，缺少一根线把它们串起来。

擎创科技在智能运维领域深耕多年，我们探索出一种简单有效的方案：用LLM理解故障特征，用Jaccard计算相似度，让历史案例能够更有效地为当前故障处理提供参考，真正‘活’起来” 。

一、核心思路：LLM管"理解"，Jaccard管"计算"

1.为什么需要LLM？

要是仅仅依靠服务名来进行故障案例匹配，那效果往往不尽如人意，毕竟一个大型系统可能包含成百上千个服务，两次故障涉及完全相同服务的概率微乎其微，而LLM就像一位超级智能的“理解大师”，它能够从服务名称、最近告警信息以及服务描述中，精准地抽象出关键特征，为后续的相似度计算奠定基础。

2.为什么需要Jaccard？

Jaccard算法以其简洁、高效和出色的可解释性而闻名，它通过计算两个集合的交集与并集之比，得出相似度数值，结果直观易懂。打个比方，如果说“这两个故障有80%的特征重叠”，相信大家都能轻松理解其中的含义。

3. Jaccard相似度：简单背后的强大逻辑

Jaccard相似度，用一句话就能解释清楚：两个集合的交集除以并集，举个例子：

集合 A = {苹果, 香蕉, 橙子}

集合 B = {苹果, 香蕉, 葡萄}

交集 = {苹果, 香蕉} = 2 个

并集 = {苹果, 香蕉, 橙子, 葡萄} = 4 个

Jaccard相似度 = 2 ÷ 4 = 0.5

二、关键一步：LLM特征抽象，挖掘故障本质

1.让我们来看看下面这两个故障实际案例

如果直接用服务名来计算Jaccard相似度，结果会是0（因为它们没有交集），但实际上，这两个故障的本质是一样的，都是“数据库问题影响了应用层”，这时候，把角色和告警类型绑定成特征

此时，Jaccard相似度=1.0（完全匹配！）

2.用LLM做角色推断

擎创科技总结了8种服务角色，通过LLM对服务进行角色推断，能够输出角色名称、置信度以及判断依据。

3.LLM推断Prompt设计

请根据以下信息判断服务的角色类型

服务信息：

-服务名称：{service_name}

-最近告警：{recent_alerts}

-服务描述：{service_description}

可选角色：

1. Gateway-流量入口（网关、负载均衡）

2. Application-业务应用服务

3. Database-数据库（MySQL、MongoDB等）

4. Cache-缓存（Redis、Memcached等）

5. MessageQueue-消息队列（Kafka、RabbitMQ等）

6. Middleware-中间件（ES、ZK、Nacos等）

7. Storage-存储服务

8. Infra-基础设施组件

请输出：

{

  "role": "角色名称",

  "confidence": 0.0-1.0 之间的置信度,

  "reason": "判断依据"

}

示例：

输入：

• 服务名称：order-mysql-master

• 服务描述：MySQL数据库集群(主)

• 最近告警：slow_query_time > 1s, connection_count > 80%

输出：

{

  "role": "Database",

  "confidence": 0.95,

  "reason": "服务名包含mysql，告警为数据库典型告警（慢查询、连接数），拓扑位置为叶子节点且被多服务调用"

}

4.告警类型分类

同样用LLM将告警抽象为 5 种类型：

三、匹配流程与计算示例：精准定位相似案例

1.完整流程

Step 1：LLM特征抽象

• 服务 → 角色（如：Application, Database）

• 告警 → 类型（如：Resource, Latency）

• 绑定生成特征集合：{Database.Latency, Application.Error, ...}

Step 2：Jaccard相似度计算

• 遍历历史案例

• 直接计算特征集合的Jaccard相似度

Step 3：返回Top-N相似案例

特征集合：{Database.Latency, Application.Latency, Application.Error}

• 输出：历史根因+处置方案

  2.计算示例

  当前故障：

• mysql-master慢查询→ Database.Latency

• order-service超时→ Application.Latency

• order-service 5xx报错→ Application.Error

历史案例 A：

pg-master慢查询→ Database.Latency

payment-service超时 → Application.Latency

特征集合：{Database.Latency, Application.Latency, Application.Error}

• • payment-service报错 → Application.Error

计算：

交集= {Database.Latency, Application.Latency, Application.Error} = 3

并集= {Database.Latency, Application.Latency, Application.Error} = 3

Jaccard相似度 = 3/3 = 1.0

完全匹配！ 虽然服务名完全不同（mysql vs pg，order vs payment），但故障模式一致，历史案例的处置方案可以直接参考。

用LLM把"具体"变成"抽象"，用Jaccard把"抽象"变成"相似度"，这个方案巧妙地结合了LLM的理解能力和Jaccard的计算效率——LLM擅长语义理解但计算慢，Jaccard计算快但不懂语义，两者相互配合、相得益彰。

核心价值：

• 告别人工回忆：历史经验不再依赖运维人员苦苦回忆，秒级定位相似案例，大幅缩短故障处理时间

• 助力新人成长：新人也能借助历史经验快速上手，提升整个团队的运维效率、

擎创科技深耕智能运维领域多年，后续也将持续探索AI与运维场景的深度融合。

---