282 lines
10 KiB
Markdown
282 lines
10 KiB
Markdown
# AIOps 架构图详解（实践落地路线）
|
||
|
||
本文是 `AIOps_Practical_Route_Architecture.png` 的配套说明，目标不是再讲一遍产品愿景，而是回答 3 个更实际的问题：
|
||
|
||
- 这张图是怎么推导出来的
|
||
- 图里的每一层到底在做什么
|
||
- 图中每个框和未来实现模块如何一一对应
|
||
|
||
|
||
|
||
## 1. 这张图是怎么来的
|
||
|
||
这张图不是从技术栈出发画出来的，而是从 AIOps 要解决的实际链路倒推出来的。
|
||
|
||
### 1.1 从业务问题倒推
|
||
|
||
一个典型故障场景里，平台至少要回答下面几个问题：
|
||
|
||
1. 告警和事件从哪里进来，格式怎么统一。
|
||
2. 除了告警本身，还需要哪些上下文才能判断问题。
|
||
3. 多条重复或相关告警，怎么合并成一个可处理的 Incident。
|
||
4. 谁来做诊断、给出 RCA 和动作建议。
|
||
5. 建议出来以后，怎样保证执行是安全、可控、可审计的。
|
||
6. 处理完以后，经验如何沉淀，而不是下次还从头来一遍。
|
||
|
||
把这 6 个问题按顺序展开，就自然会得到 6 层：
|
||
|
||
- `Layer A`：先接数据
|
||
- `Layer B`：再补上下文
|
||
- `Layer C`：把事件变成 Incident 并推动流转
|
||
- `Layer D`：让 Agent 做诊断和建议
|
||
- `Layer E`：把动作放到可控执行框架里
|
||
- `Layer F`：做复盘、评估和知识更新
|
||
|
||
所以，这张图本质上是一个“从故障进入平台到经验回流平台”的闭环图，而不是单纯的服务清单图。
|
||
|
||
## 2. 读这张图的正确方式
|
||
|
||
### 2.1 先看主链路
|
||
|
||
最推荐的阅读顺序是自下而上：
|
||
|
||
`Observability Data` -> `NormalizedEvent` -> `IncidentContext` -> `Incident` -> `RCA Result` -> `Execution Results` -> `Knowledge Update`
|
||
|
||
这条链路对应的是“问题进入平台并被处理掉”的全过程。
|
||
|
||
### 2.2 再看两种流
|
||
|
||
- 蓝色实线：主控制流 / API 调用 / 执行 / 审计
|
||
- 红色虚线：反馈流，表示复盘之后对知识库、Prompt、工作流和指标的持续优化
|
||
|
||
### 2.3 最后看左右分工
|
||
|
||
- 左侧和中间：偏主处理链路，解决“当前这个故障怎么处理”
|
||
- 右侧：偏复盘和优化，解决“以后类似问题怎么更快处理”
|
||
- 顶部：偏执行治理，解决“能不能安全执行”
|
||
|
||
## 3. 一一对应说明
|
||
|
||
### 3.1 外部输入
|
||
|
||
### Prometheus / Loki-ELK / CMDB / Changes
|
||
|
||
- 这些不是平台内部模块，而是平台要接入的数据源。
|
||
- 它们共同回答一个问题：平台拿什么来感知故障。
|
||
- 在 MVP 阶段，不必一次性接全，优先级通常是 `Prometheus -> Logs -> CMDB -> Changes`。
|
||
|
||
### 3.2 Layer A: Perception
|
||
|
||
### 这一层解决什么问题
|
||
|
||
- 把不同来源的告警、事件、变更信号接进来。
|
||
- 把不同格式的数据统一成平台内部可消费的标准事件。
|
||
|
||
### 图中模块
|
||
|
||
- `collector-adapter`
|
||
- `alert-webhook`
|
||
- `event-normalizer`
|
||
|
||
### 输入 / 输出
|
||
|
||
- 输入：监控告警、日志事件、CMDB 信息、变更记录
|
||
- 输出：`NormalizedEvent`
|
||
|
||
### 为什么必须有这一层
|
||
|
||
- 如果没有统一事件格式，后面的去重、关联、AI 诊断都会高度依赖每个数据源自己的字段，系统很难扩展。
|
||
|
||
### 3.3 Layer B: Data Governance
|
||
|
||
### 这一层解决什么问题
|
||
|
||
- 只看告警标题通常不够，需要补齐服务归属、依赖关系、变更记录和历史相似事件。
|
||
- 这层的目标是把“告警”变成“带上下文的事件”。
|
||
|
||
### 图中模块
|
||
|
||
- `context-enricher`
|
||
- `topology-resolver`
|
||
- `change-correlator`
|
||
|
||
### 输入 / 输出
|
||
|
||
- 输入：`NormalizedEvent`
|
||
- 输出：`IncidentContext`
|
||
|
||
### 为什么必须有这一层
|
||
|
||
- AI 诊断不是只靠一句告警文案，而是要看时间窗口、依赖拓扑、近期变更和历史案例。
|
||
- 这一层是后面 RCA 质量的基础。
|
||
|
||
### 3.4 Layer C: Event Orchestration
|
||
|
||
### 这一层解决什么问题
|
||
|
||
- 多条重复告警不能让人逐条处理，需要合并成一个 Incident。
|
||
- Incident 形成后，还要有状态流转、升级通知和时间线记录。
|
||
|
||
### 图中模块
|
||
|
||
- `Incident Service`
|
||
- `Deduplication & Correlation Engine`
|
||
- `Escalation Engine`
|
||
- `Timeline Service`
|
||
|
||
### 实现映射
|
||
|
||
- `Incident Service` 对应 `incident-service`
|
||
- `Deduplication & Correlation Engine` 可以落成 `dedupe-group-engine` + 关联规则
|
||
- `Escalation Engine` 对应 `escalation-engine`
|
||
- `Timeline Service` 对应 `timeline-service`
|
||
|
||
### 输入 / 输出
|
||
|
||
- 输入：`IncidentContext`
|
||
- 输出：处于不同状态的 `Incident`
|
||
|
||
### 状态机为什么重要
|
||
|
||
- 图里的 `new -> triaged -> diagnosing -> remediating -> resolved/closed` 不是装饰，而是平台主流程。
|
||
- 没有状态机，就很难做 SLA、升级、审批和复盘闭环。
|
||
|
||
### 3.5 Layer D: Intelligent Decision
|
||
|
||
### 这一层解决什么问题
|
||
|
||
- 当 Incident 进入 `diagnosing` 状态后，需要 Agent 去做证据收集、RAG 检索、诊断判断和动作建议。
|
||
|
||
### 图中模块
|
||
|
||
- `Custom Gateway`
|
||
- `Dify Platform`
|
||
- `Agent Brain (Dify)`
|
||
|
||
### 为什么同时有 Custom Gateway 和 Dify
|
||
|
||
- `Dify Platform` 负责工作流编排、模型调用、RAG 检索和多轮对话。
|
||
- `Custom Gateway` 负责把平台和 Dify 解耦，承担结果标准化、策略封装、审计打点和兜底逻辑。
|
||
- 换句话说，Dify 负责“智能”，Custom Gateway 负责“平台接入与控制”。
|
||
|
||
### 输入 / 输出
|
||
|
||
- 输入：`Incident` + `IncidentContext`
|
||
- 输出：`RCA Result`
|
||
|
||
### RCA Result 至少要包含什么
|
||
|
||
- 结论
|
||
- 置信度
|
||
- 证据链
|
||
- 影响范围
|
||
- 建议动作
|
||
|
||
### 3.6 Layer E: Action Execution with Guardrails
|
||
|
||
### 这一层解决什么问题
|
||
|
||
- AI 给出建议不等于可以直接执行。
|
||
- 执行必须经过审批、策略校验、风险控制和审计留痕。
|
||
|
||
### 图中模块
|
||
|
||
- `action-registry`
|
||
- `approval-service`
|
||
- `Policy Engine`
|
||
- `audit-service`
|
||
- `Approval Gateway`
|
||
- `Execution Control with Policy Gateway`
|
||
- `Executors`
|
||
|
||
### 实现映射
|
||
|
||
- `Approval Gateway` 可以落成 `approval-service`
|
||
- `Execution Control with Policy Gateway` 可以落成 `execution-gateway` + `policy-engine`
|
||
- `Executors` 对接 Ansible、K8s API、脚本引擎等真实执行器
|
||
|
||
### 为什么必须单独画一层
|
||
|
||
- 因为“诊断正确”和“可以安全执行”是两个问题。
|
||
- 这一层存在的意义，就是避免 Agent 直接碰生产资源。
|
||
|
||
### 3.7 Layer F: Learning Loop
|
||
|
||
### 这一层解决什么问题
|
||
|
||
- 事件处理结束后，要把经验沉淀下来，变成下次更快的处理能力。
|
||
|
||
### 图中模块
|
||
|
||
- `postmortem-service`
|
||
- `Knowledge Feedback`
|
||
- `kpi-dashboard`
|
||
- `Assessment Metrics`
|
||
- `Optimization Outputs`
|
||
|
||
### 实现映射
|
||
|
||
- `Knowledge Feedback` 可以落成 `knowledge-feedback-worker`
|
||
- `Assessment Metrics` 由 `kpi-dashboard` 统计输出
|
||
- `Optimization Outputs` 体现为 Runbook 更新、Prompt/Workflow 优化、知识库整理
|
||
|
||
### 为什么不把它并到前面
|
||
|
||
- 前面几层解决的是“这次故障怎么处理”。
|
||
- 这一层解决的是“以后类似故障怎么处理得更快、更准、更稳”。
|
||
- 所以它是学习闭环，不是主处理链路的一部分。
|
||
|
||
## 4. 图中几个最容易困惑的点
|
||
|
||
### 4.1 为什么 Layer B 和 Layer C 都有“关联”含义
|
||
|
||
- `Layer B` 的关联更偏上下文补齐，比如拓扑、变更、历史事件。
|
||
- `Layer C` 的关联更偏事件处理，比如去重、分组、归并、Incident 归属。
|
||
- 一个是“看懂事件背景”，一个是“把事件组织成可处理对象”。
|
||
|
||
### 4.2 为什么 Dify 不直接调用执行器
|
||
|
||
- 因为这样会让 AI 和生产执行强耦合，风险很高。
|
||
- 正确做法是：Dify 只输出建议，平台统一做审批、策略和执行控制。
|
||
|
||
### 4.3 为什么学习闭环在最右侧
|
||
|
||
- 因为它不是每一步主链路都必经的同步流程，而是事件关闭后的回流与优化过程。
|
||
- 右侧单独成区，视觉上更容易看出“处理”和“学习”是两个阶段。
|
||
|
||
## 5. 用一个例子把图串起来
|
||
|
||
假设 `order-service` 延迟突然升高，这张图里的处理过程可以理解成：
|
||
|
||
1. Prometheus 触发高延迟告警，进入 `Layer A`。
|
||
2. `event-normalizer` 把告警转成统一 `NormalizedEvent`。
|
||
3. `Layer B` 补齐服务归属、依赖拓扑、最近变更和历史相似事件，形成 `IncidentContext`。
|
||
4. `Layer C` 发现同类告警很多，先去重归并，再生成一个 Incident，并把状态推进到 `diagnosing`。
|
||
5. `Layer D` 通过 `Custom Gateway` 调用 `Agent Brain (Dify)`，综合 metrics、logs、changes 和 SOP 输出 `RCA Result`。
|
||
6. 如果建议动作是低风险扩容，就进入 `Layer E` 的策略和执行控制；高风险动作则进入审批流。
|
||
7. 执行结果和关键操作写入时间线与审计。
|
||
8. Incident 关闭后，`Layer F` 做 postmortem，更新知识库，统计是否真的缩短了 MTTR、RCA 是否准确。
|
||
|
||
如果你按这个例子回头看图，基本就能理解每条箭头为什么存在。
|
||
|
||
## 6. 这张图不是部署图，而是逻辑图
|
||
|
||
这个点很重要。
|
||
|
||
- 图里的一个框，不一定等于一个独立服务。
|
||
- MVP 阶段，多个模块可以合并在一个后端服务里实现。
|
||
- 例如 `Incident Service`、`Timeline Service`、`Escalation Engine` 可以先合并。
|
||
- `Custom Gateway`、工具代理和执行网关，也可以先做成一个平台后端中的独立模块。
|
||
|
||
所以，读这张图时要把它理解成“职责分层图 + 关键能力图”，而不是“最终微服务拆分图”。
|
||
|
||
## 7. 你可以怎么对别人解释这张图
|
||
|
||
如果只用 1 分钟介绍，可以直接这么说：
|
||
|
||
> 这是一张 AIOps 实践路线的闭环架构图。底层先把 Prometheus、日志、CMDB 和变更系统的信号统一成标准事件；中间层补齐上下文并把多条告警收敛成 Incident；然后通过 Dify 做诊断、RAG 检索和 RCA 输出；再通过审批、策略和执行网关把建议动作变成受控执行；最后把复盘结果沉淀为知识库、Runbook 和优化指标，形成持续学习闭环。
|
||
|
||
如果要更简短，可以记一句话：
|
||
|
||
> 这张图讲的是“怎么把告警变成可控处置，再把处置经验变成下一次更快的处置能力”。
|