构建基于向量检索与LLM的智能On-Call系统：从告警到知识沉淀

1. 项目概述：一个永不遗忘的On-Call智能体

在运维和SRE的世界里，最让人头疼的场景之一，莫过于凌晨三点被刺耳的告警电话叫醒，面对一个似曾相识的系统故障，却怎么也想不起上次是怎么解决的。你隐约记得几个月前处理过类似的问题，但当时的处理步骤、根因分析、临时缓解措施，都散落在不同的聊天记录、工单系统或某个早已遗忘的文档里。这种“似曾相识却又束手无策”的无力感，不仅消耗工程师的精力和信心，更直接拉长了MTTR（平均恢复时间），影响业务稳定性和用户体验。

我构建的这个“永不遗忘的On-Call智能体”，就是为了彻底解决这个问题。它的核心目标不是替代人类工程师做决策，而是充当一个拥有“完美记忆”的超级助理。它能自动关联当前告警与历史上的所有相似事件，在工程师介入前，就将相关的处理记录、根因报告、甚至当时有效的命令行“魔法”直接推送到你面前。想象一下，当告警响起时，你收到的不仅仅是“数据库连接池耗尽”这条冰冷的信息，还有一条附注：“过去12个月内发生过3次类似事件，最近一次发生在45天前，由张三处理。根本原因为某中间件配置参数max_connections设置过低，临时解决方案是执行./scale_conn_pool.sh --factor 2，长期修复方案已合并至配置库repo/configs的v1.2.3版本。”

这个智能体本质上是一个事件驱动的、具备长期记忆和语义检索能力的自动化工作流。它连接了你的监控系统（如Prometheus、Datadog）、告警平台（如PagerDuty、Opsgenie）、事件管理工具（如Jira Service Management、Freshservice）以及内部的知识库（如Confluence、Wiki），通过大语言模型（LLM）的理解和推理能力，在纷繁复杂的数据中建立关联，让每一次痛苦的排障经历都转化为团队可复用的资产。

2. 核心设计思路：从“响应”到“认知”的范式转变

传统的On-Call流程是一个线性的“响应-处理-关闭”循环。智能体的引入，将这个循环升级为一个带有“记忆”和“学习”能力的增强回路。其设计核心可以概括为：事件向量化、记忆持久化、关联实时化、知识可操作化。

2.1 为什么是“向量化”而非“关键词匹配”？

早期我们尝试过基于告警标题、服务名等关键词进行匹配。效果很差，因为真实的故障描述千变万化。“API响应延迟高”和“用户请求卡顿”可能指向同一个后端服务队列满的问题，但字面上毫无重合。向量化嵌入（Embedding）技术是破局关键。

我们将每一条历史事件（包括告警描述、工程师处理过程中的聊天摘要、最终的事后分析报告）通过一个嵌入模型（如OpenAI的text-embedding-3-small，或开源的BGE-M3）转换为一个高维空间中的向量（一组数字）。这个向量捕获了文本的语义信息。当新告警产生时，我们同样将其向量化，然后在向量数据库中进行相似度搜索（通常使用余弦相似度）。这意味着，即使新老事件的措辞完全不同，只要语义相近，就能被关联起来。

注意：嵌入模型的选择至关重要。通用模型（如OpenAI的Ada）在技术领域表现尚可，但针对运维领域特有的术语（如K8s pod OOM、数据库死锁），使用在运维文档上微调过的模型或加入领域术语词典，能显著提升相关性。

2.2 记忆的层次：短期上下文与长期知识库

智能体的“记忆”分为两层：

1. 短期上下文：处理当前事件时，LLM（如GPT-4、Claude 3或本地部署的Llama 3）的对话上下文。这决定了智能体在当前会话中的连贯性。
2. 长期知识库：存储在向量数据库（如Pinecone、Weaviate、Qdrant或开源的Chroma）中的所有历史事件向量及其关联的原始文本（元数据）。这是智能体“永不遗忘”能力的基石。

设计时需要决定什么信息该存入长期记忆。并非所有聊天记录都值得存储。我们的策略是，当一个事件工单被标记为“已解决”时，触发一个记忆固化流程：

• 提取核心摘要：使用LLM自动生成一份结构化摘要，包括：根本原因（Root Cause）、影响面（Impact）、临时措施（Workaround）、永久修复（Fix）、相关服务与负责人。
• 向量化存储：将这份摘要和关键的处理步骤（如执行的命令、修改的配置项）一起向量化后存入数据库。
• 索引元数据：同时存储事件ID、发生时间、相关服务、负责人等结构化字段，便于后续混合检索（结合向量相似度和属性过滤）。

2.3 关联的触发：在正确的时间提供正确的信息

智能体不能是“马后炮”，也不能信息轰炸。我们设计了三种触发关联的模式：

• 告警触发式：当新告警产生并创建事件工单时，自动在知识库中搜索Top K个相似历史事件，将摘要信息作为“推荐上下文”附加到工单描述中。
• 交互查询式：工程师在处理过程中，可以向智能体自然语言提问：“我们以前遇到过类似的问题吗？”或“上次张三是怎么修复这个服务的？”智能体实时检索并回答。
• 复盘辅助式：在撰写事后分析报告时，智能体可以自动提供历史上所有相关事件的链接和共性分析，帮助发现系统性风险。

3. 系统架构与核心组件实现

整个系统的架构可以看作一个事件驱动的微服务集合，下图勾勒了其核心数据流与组件交互：

flowchart TD A[新告警/事件产生] --> B[事件摄取与标准化服务] B --> C[向量化引擎<br>（Embedding Model）] C --> D[向量数据库<br>（Pinecone/Qdrant）] D --> E[语义检索与关联] F[历史事件知识库<br>（Confluence/Jira）] -- 定期同步/事件关闭时触发 --> G[知识固化管道] G --> C E --> H[LLM推理引擎<br>（GPT-4/Claude/Llama）] I[工程师交互界面<br>（Slack/Teams/Web）] <--> H H --> J[生成建议/摘要/回答] J --> K[推送至告警工单或聊天频道]

下面我们拆解几个关键组件的实现要点。

3.1 事件摄取与标准化层

监控和告警源五花八门，格式各异。第一步是建立一个适配器层，将不同来源的事件归一化为统一的内部数据模型。

# 示例：统一事件模型 (Python Pydantic) from pydantic import BaseModel from datetime import datetime from typing import Optional, List, Dict class UnifiedAlert(BaseModel): source: str # e.g., "prometheus", "datadog", "custom" alert_id: str title: str description: str severity: str # "critical", "warning", "info" service: str environment: str # "prod", "staging" generated_at: datetime raw_data: Dict # 保留原始数据，供后续可能使用

对于每个告警源（如Prometheus webhook），编写一个解析器函数，将原始告警映射到UnifiedAlert模型。这一步看似繁琐，但为后续所有处理提供了稳定的数据基础。

实操心得：在description字段中，尽量保留有信息量的文本。很多监控模板的告警描述是“Instance {{$labels.instance}} is down”，这几乎没有语义价值。我们修改了告警规则，在描述中加入了指标名、阈值和可能的影响，例如：“主机web-01的CPU使用率持续5分钟超过90%（当前值：95%），可能导致Web服务响应延迟。”

3.2 向量化引擎与存储选型

我们选择了text-embedding-3-small作为嵌入模型，因其在性价比和效果上取得了很好的平衡。对于完全内网或成本敏感的场景，BGE-M3或Snowflake Arctic Embed是优秀的开源替代品。

向量数据库我们选用了Qdrant，原因如下：

• 性能：纯Rust编写，性能极高，尤其擅长高维向量的相似度搜索。
• 过滤：支持在向量搜索的同时，对元数据（如service,environment,time）进行高效的硬过滤。这对于检索“生产环境”、“最近半年”、“A服务相关”的事件至关重要。
• 云原生：易于用Docker部署，且提供云托管服务。

存储时，我们不仅存储向量和文本摘要，还包括了指向原始事件详情的链接（如Jira ticket URL），方便工程师一键跳转查看全貌。

# 示例：向量化与存储代码片段 from qdrant_client import QdrantClient from qdrant_client.models import PointStruct, Distance, VectorParams import openai client = QdrantClient(host="localhost", port=6333) openai.api_key = "your-key" def create_embedding(text: str) -> List[float]: response = openai.embeddings.create(model="text-embedding-3-small", input=text) return response.data[0].embedding def store_incident(incident_summary: str, metadata: dict): vector = create_embedding(incident_summary) point = PointStruct( id=metadata["incident_id"], # 使用事件ID作为向量点ID vector=vector, payload={ "text": incident_summary, "source_link": metadata["link"], "service": metadata["service"], "resolved_at": metadata["resolved_at"], ... # 其他元数据 } ) client.upsert(collection_name="incident_memory", points=[point])

3.3 LLM推理引擎的提示词工程

这是智能体的“大脑”。我们并不让LLM直接操作生产系统，而是让它扮演一个“信息整合与建议者”的角色。精心设计的提示词（Prompt）是关键。

# 示例：生成事件关联建议的提示词 INCIDENT_ASSISTANT_PROMPT = """ 你是一个资深的SRE工程师助理。你的任务是帮助当值工程师快速理解当前告警，并参考历史经验。 当前告警信息： 标题：{current_alert_title} 描述：{current_alert_description} 服务：{current_service} 环境：{current_environment} 以下是检索到的{top_k}个相似历史事件摘要： {historical_summaries} 请根据以上信息，生成一份简洁的协助报告，包含以下部分： 1. **核心问题推测**：用一句话概括当前告警最可能指向的问题。 2. **历史参考**：列出最相关的1-2个历史事件，每个事件包括： - 简述当时的问题与解决方案。 - 标注该解决方案是否可能适用于当前情况（是/可能/否），并说明理由。 3. **初步行动建议**：提供1-3条可立即检查或执行的命令或步骤（如果历史经验明确）。 4. **需澄清信息**：列出还需要从监控系统或日志中获取哪些关键信息，才能进一步确认问题。 注意：保持专业、简洁、客观。如果历史经验不相关或不足，请明确说明“未找到可直接适用的历史解决方案”。 """

我们将当前告警信息和检索到的历史摘要填充进提示词，发送给LLM，得到结构化的建议报告，然后自动发布到对应的Slack频道或事件工单的评论中。

避坑技巧：LLM有时会“过度联想”或生成不安全的命令。我们在提示词中明确限定了其角色，并在输出层添加了一个简单的校验：如果生成的“初步行动建议”中包含rm -rf、chmod 777或DROP DATABASE等高风险模式，系统会自动标记该条建议为“需人工复核”，并通知工程师。

4. 实操部署与集成流程

4.1 数据初始化：灌入历史知识

在系统上线前，需要将历史事件数据导入向量库。我们编写了一个脚本，从Jira、Confluence等系统导出过去1-2年内已解决的事件，通过上述的“记忆固化流程”（提取摘要->向量化）批量处理。

# 示例：批量处理历史事件的脚本概览 python3 backfill_history.py \ --source jira \ --query 'project = OPS AND status = Resolved AND created >= -365d' \ --batch-size 50 \ --output-dir ./processed_incidents

这个过程可能耗时较长，建议分项目、分批次进行，并做好日志记录和错误重试。

4.2 实时处理流水线搭建

我们使用Apache Kafka作为事件总线，构建了一个松耦合的流水线：

1. 告警接收器：订阅各监控系统的Webhook，将告警转换为统一格式后发布到alerts主题。
2. 事件丰富器：消费alerts主题，调用向量数据库进行相似度检索，获取相关历史事件摘要。
3. 智能体处理器：消费丰富后的事件，调用LLM生成协助报告。
4. 行动分发器：将生成的报告推送到目标系统（Slack、Teams、Jira评论）。

使用Kafka保证了系统的可扩展性和可靠性，任何一个组件故障都不会导致数据丢失。

4.3 与现有On-Call工具链集成

• 与PagerDuty/Opsgenie集成：通过其API或Webhook，在告警触发时，不仅呼叫人员，同时将告警信息发送给我们的智能体流水线。智能体生成报告后，再通过API写回告警的“备注”字段。
• 与Slack/Microsoft Teams集成：为每个服务创建一个专属频道。当该服务的告警触发时，智能体将报告直接发布到频道，并@当值工程师。工程师也可以在频道中直接向智能体提问。
• 与Jira/ServiceNow集成：在创建事件工单时自动附加历史参考信息。在工单解决关闭时，触发“记忆固化”流程，将本次解决经验存入知识库。

5. 效果评估与持续优化

系统上线后，我们建立了几个关键指标来衡量其效果：

• MTTR（平均恢复时间）：对比智能体启用前后，同类告警的解决时间是否有显著下降。
• 工程师查询率：工程师主动向智能体提问的频率。
• 建议采纳率：智能体提供的“初步行动建议”被工程师实际执行的比例。
• 知识库增长与命中率：每周新增的记忆条目数，以及新告警能成功关联到历史事件的比例。

我们发现在上线初期，由于历史数据不足，命中率较低。但随着系统运行，每一次解决事件都在丰富知识库，形成了一个强大的正向循环。大约三个月后，对于核心服务的常见故障模式，关联命中率达到了70%以上，MTTR平均缩短了约40%。

5.1 遇到的典型问题与解决方案

1. 问题：检索结果不相关

   • 现象：告警是“磁盘空间不足”，但返回的历史事件却是“内存溢出”。
   • 排查：检查嵌入模型是否适合运维领域文本。发现通用模型对“disk I/O high”和“slow query”这类专业组合词理解不佳。
   • 解决：切换为在StackOverflow、运维论坛文本上微调过的嵌入模型，并在预处理时，对告警文本中的专业术语（如服务名、错误码）进行标准化处理（例如，将“MySQL error 1205”统一替换为“MySQL_lock_timeout”）。

2. 问题：LLM生成的建议过于笼统

   • 现象：建议总是“检查日志”、“重启服务”，缺乏针对性。
   • 排查：发现提供给LLM的历史摘要信息不够具体，缺少可操作的命令或配置项。
   • 解决：优化“记忆固化”流程，强制要求摘要中必须包含“已验证有效的具体操作步骤”字段。同时，在提示词中强调“提供可执行的具体命令或检查路径”。

3. 问题：信息过载

   • 现象：每次告警都推送大量历史信息，干扰工程师判断。
   • 排查：相似度阈值设置过低，返回了太多相关性不高的结果。
   • 解决：引入动态阈值。对于严重（Critical）告警，返回Top 3相似事件；对于警告（Warning）告警，只返回最相关的1个。同时，在UI上对信息进行折叠，默认只显示“最相关”的一条，其余需要点击展开。

6. 安全、成本与隐私考量

构建这样一个系统，必须严肃对待以下几点：

• 安全：智能体只有“读”权限，绝不能拥有直接执行命令或修改配置的“写”权限。所有建议都需经人工确认。访问LLM API和向量数据库的凭证需妥善管理。
• 成本：LLM API调用和向量数据库存储是主要成本。我们通过以下方式控制：
  • 对历史摘要文本进行压缩，去除冗余。
  • 设置缓存层，对相同或高度相似的告警，直接返回缓存结果，避免重复调用LLM。
  • 为不同严重等级的告警设置不同的处理管道（如Critical告警用高性能LLM，Warning告警用轻量级或缓存）。
• 隐私：事件描述和聊天记录中可能包含内部IP、主机名、错误信息等。在存储到向量库前，我们使用一个简单的正则过滤和替换层，对敏感信息进行匿名化处理（如将10.0.1.5替换为[IP]）。

构建这个“永不遗忘的On-Call智能体”并非一蹴而就，它是一个需要持续迭代和喂养的系统。但投入是值得的。它最大的价值不在于处理了多少告警，而在于它将团队从重复性的、依赖模糊记忆的救火工作中解放出来，让每一次深夜的奋战都能沉淀下来，成为守护系统稳定性的砖瓦。现在，当告警电话再次响起时，我们心中多了一份底气，因为知道有一位拥有“完美记忆”的伙伴，已经为我们点亮了前路。