3. 异常知识库的总体架构
异常知识库不是“把异常日志存进数据库”这么简单。它要同时回答四类问题：异常长什么样（数据模型）、异常存在哪里（存储选型）、外部系统怎么读写（服务接口）、以及它如何嵌入现有研发链路（集成方式）。这四类问题分别对应架构中的分层、模型、存储、接口与集成五个视角。下面按“分层—模型—存储—接口—集成”的顺序展开，并在关键处给出可直接参考的示例参数。
一、知识库分层：从原始信号到可复用知识
推荐把异常知识库划分为五层，每层职责单一、边界清晰，避免把采集、清洗、检索、推理混在一个服务里。
- 采集接入层：对接日志、APM、告警、工单、CI/CD 等来源，负责协议适配与幂等去重。典型输入是异常事件流，输出是标准化事件。
- 标准化层：把不同来源的异常归一为统一字段，包括异常类型、堆栈指纹、服务名、版本、环境、发生时间、影响面。核心产物是“异常事件”实体。
- 知识建模层：在事件之上建立异常模式、根因、处置方案、验证结论之间的关联，形成“异常—根因—方案—验证”的知识图谱。
- 存储检索层：按访问模式选择存储，支持精确匹配、相似检索、全文检索和图关系查询。
- 服务接口层：对外提供写入、查询、相似推荐、方案复用等 API，并承担鉴权、限流、审计。
分层的价值在于：采集层可以频繁变更而不影响知识模型；存储层可以替换引擎而不影响接口契约。实践中常见错误是把“异常指纹计算”写在采集层，导致指纹规则升级时必须回刷全部历史数据。
二、数据模型：异常知识的最小完备集合
数据模型决定知识库能否被复用。建议至少定义五个核心实体：异常事件（Incident）、异常模式（Pattern）、根因（RootCause）、处置方案（Playbook）、验证记录（Verification）。它们之间的关系是：一个模式可聚合多个事件；一个模式可关联多个候选根因；一个根因对应若干处置方案；每个方案执行后产生验证记录，验证结论反过来修正模式的置信度。
异常事件的关键字段示例：
incident_id: INC-20240612-0031
service: order-service
version: 2.7.3
env: prod
exception_type: java.lang.NullPointerException
stack_fingerprint: 9f2c1a...（对异常类名+关键栈帧做哈希）
first_seen: 2024-06-12T10:21:33+08:00
impact: 订单创建失败率 3.2%
source: sentry
其中 stack_fingerprint 是相似检索的锚点。计算时通常保留异常类名、最内层业务栈帧、以及被调用方方法名，剔除行号、线程名、时间戳等易变字段，否则同一缺陷会因行号变化被拆成多个模式。
三、存储选型：按访问模式分工
异常知识库的查询形态差异很大，单一存储很难兼顾。推荐组合使用：
| 存储 | 承载数据 | 典型查询 | 选型理由 |
|---|---|---|---|
| 关系型数据库（PostgreSQL） | 事件、模式、方案元数据 | 按服务/时间/状态精确过滤 | 事务、约束、成熟运维 |
| 搜索引擎（Elasticsearch） | 异常文本、堆栈、日志片段 | 全文检索、聚合统计 | 倒排索引、分词、聚合快 |
| 向量库（Milvus/pgvector） | 异常描述与堆栈的嵌入向量 | 相似异常 Top-K 召回 | 语义相似，跨语言/跨写法 |
| 图数据库（Neo4j） | 异常—根因—方案关系 | 多跳关联、路径查询 | 关系遍历天然高效 |
| 对象存储（S3/MinIO） | 原始日志包、堆栈快照 | 按 ID 取原始证据 | 低成本、大容量 |
一个可落地的折中方案是：PostgreSQL 存主数据，pgvector 扩展承担向量检索，Elasticsearch 承担全文与聚合，图关系先用关系表加递归查询实现，规模上来后再迁移到图数据库。这样初期只维护两套存储，降低运维成本。
四、服务接口：契约先于实现
接口层建议提供四组能力：写入、查询、相似推荐、方案复用。写入接口要支持批量与幂等；查询接口要支持按指纹、服务、时间窗组合过滤；相似推荐接口输入异常描述或堆栈，返回相似模式及历史处置；方案复用接口返回某模式下的方案列表及成功率。
POST /api/v1/incidents # 写入异常事件，幂等键 incident_id
GET /api/v1/patterns?service=&from=&to=
GET /api/v1/patterns/{id}/similar?topK=5
GET /api/v1/patterns/{id}/playbooks
POST /api/v1/verifications # 回写方案执行结果
接口设计要点：相似推荐返回结果必须带 score 与 matched_fields，便于调用方判断可信度；方案复用返回 success_rate 与 sample_size，避免小样本误导。所有写接口需记录操作者与来源系统，满足审计要求。
五、与现有系统的集成方式
集成应遵循“旁路优先、逐步深入”的原则，避免一开始就阻塞主流程。常见集成点包括：
- 告警平台：告警触发时调用写入接口，把告警上下文转为异常事件；知识库返回相似历史与推荐方案，展示在告警详情页。
- 工单系统：工单创建时关联异常事件 ID，工单关闭时回写验证记录，形成闭环。
- CI/CD：发布后若异常率上升，自动关联本次发布版本，辅助判断是否回滚。
- 值班助手/IM：通过机器人查询相似异常与处置方案，降低检索门槛。
集成方式上，优先采用异步消息（如 Kafka）解耦写入，避免告警风暴打垮知识库；查询走同步 HTTP，并设置超时与降级，知识库不可用时不影响告警本身。下面这张图概括了分层、模型、存储、接口与集成之间的整体关系。
六、落地时的三个判断点
第一，指纹规则是否稳定。如果指纹频繁变化，相似检索会失效，应先用一周真实数据验证指纹聚合效果，再决定是否上线。第二，存储是否过度设计。初期事件量低于百万级时，PostgreSQL 加 pgvector 足以支撑，不必同时引入四套存储。第三，集成是否阻塞主流程。知识库写入必须异步、可降级，查询必须设超时，确保告警和工单本身不受影响。
总体架构的价值不在于组件多，而在于每一层都能独立演进：采集规则变了不影响模型，模型扩展了不影响接口契约，存储替换了不影响调用方。按这个原则落地，异常知识库才能从“日志仓库”真正变成“可复用的知识资产”。