AIRegulation/aiops-docs
7
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add initial AIOps documentation set

Browse Source
This commit is contained in:
guangfei.zhao
2026-03-26 10:55:46 +08:00
commit 19e1e1e2cf
8 changed files with 1382 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
.gitignore vendored Normal file
View File

@@ -0,0 +1,10 @@
.DS_Store
Thumbs.db
desktop.ini
.idea/
.vscode/
*.tmp
*.temp
~$*

281
AIOps_Architecture_Diagram_Explanation.md Normal file
View File

@@ -0,0 +1,281 @@
# AIOps 架构图详解（实践落地路线）
本文是 `AIOps_Practical_Route_Architecture.png` 的配套说明，目标不是再讲一遍产品愿景，而是回答 3 个更实际的问题：
- 这张图是怎么推导出来的
- 图里的每一层到底在做什么
- 图中每个框和未来实现模块如何一一对应
![AIOps Practical Route Architecture](AIOps_Practical_Route_Architecture.png)
## 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 和优化指标，形成持续学习闭环。
如果要更简短，可以记一句话：
> 这张图讲的是“怎么把告警变成可控处置，再把处置经验变成下一次更快的处置能力”。

BIN
AIOps_Practical_Route_Architecture.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.6 MiB

874
AIOps_Product_Architecture_and_Commercialization.md Normal file
View File

@@ -0,0 +1,874 @@
# AIOps 智能运维平台：产品架构与商业化方案
## 1. 文档目标
本文档用于统一 AIOps 项目的技术架构、产品形态与商业化方向，作为：
- 研发设计与实施的基线文档
- 管理层立项评审与资源投入依据
- 面向客户的产品方案与售前材料母版
同时用于小团队条件下的范围控制与里程碑落地，确保先做成可用 MVP，再逐步扩展。
---
## 2. 产品定位与愿景
### 2.1 产品定位
面向中大型企业（金融、政务、制造、互联网）的 **企业级智能运维平台**，以“告警降噪 + 智能诊断 + 自动化自愈”为核心能力，帮助客户显著降低 MTTR、提升稳定性并实现运维能力沉淀。
### 2.2 产品愿景
构建“**感知 → 响应 → 决策 → 恢复 → 学习**”的智能闭环，形成可持续优化的运维中枢。
### 2.3 核心价值主张
- 从“人肉看告警”升级为“语义级事件治理”
- 从“专家经验驱动”升级为“知识库 + Agent 协同决策”
- 从“手工处置”升级为“可控自动化执行”
- 从“单点工具”升级为“私有化、可审计、可扩展的平台能力”
---
## 3. 目标客户与典型场景
## 3.1 目标客户画像
- 业务系统复杂：微服务/K8s/数据库/中间件并存
- 故障影响高：停机损失大、SLA 约束严
- 合规要求高：偏好私有化部署和全链路审计
- 运维团队压力大：告警量高、专家资源稀缺
### 3.2 典型应用场景
1. **夜间告警风暴治理**：分钟级完成去重、归并、关联。
2. **跨系统故障定位**：结合指标、日志、历史 SOP 自动生成 RCA。
3. **低风险故障自动自愈**：如 Pod 重启、HPA 扩容、服务摘流。
4. **运维知识沉淀**：将案例和处置过程沉淀为可检索 SOP。
---
## 4. 产品形态设计
### 4.1 产品形态（建议）
- **平台版（私有化）**：面向大型客户，支持本地部署与深度集成。
- **增强模块版**：在现有监控体系上增配“诊断与自愈模块”。
- **行业方案版**：金融版、政务版、制造版，提供行业预置 SOP 与策略模板。
### 4.2 角色与工作台
- **NOC/L1 运维**：告警收敛、工单联动、建议执行。
- **SRE/L2-L3**：RCA 验证、处置策略编排、规则优化。
- **运维负责人**：SLA、MTTR、团队效率与风险看板。
- **安全/审计**：审批、权限、操作留痕、审计报表。
### 4.3 产品功能包
| 功能域 | 核心能力 | 输出价值 |
| --- | --- | --- |
| 告警治理 | 去重、分组、抑制、路由、拓扑关联 | 降噪、聚焦关键事件 |
| 智能诊断 | 指标/日志联查、RAG 检索、RCA 生成 | 缩短定位时间 |
| 自愈执行 | 自动化脚本/Playbook、审批流、回滚 | 降低恢复时延 |
| 知识中枢 | SOP 管理、向量检索、案例复盘 | 经验资产化 |
| 治理与审计 | 权限分级、策略控制、全链路审计 | 可控合规 |
### 4.4 小团队 MVP 范围（6 个月）
**本期必须做（In Scope）**
- 事件中心：告警接入、去重分组、状态机流转
- Agent 诊断：基于 Dify 的诊断工作流与结构化 RCA 输出
- RAG 知识库：SOP 文档入库、检索、引用证据输出
- 自愈执行（低风险）：重启/扩容等白名单动作 + 审批闸门
- 平台看板：MTTR、告警处理时长、RCA 准确率、自动恢复率
**本期暂不做（Out of Scope）**
- 全量 APM 能力替代（Trace 全栈深度分析）
- 复杂多租户计费与全功能商业化后台
- 全行业模板一次性覆盖
- 全自动高风险故障处置（默认人工审批）
### 4.5 职责矩阵（RACI）
| 工作项 | 前端工程师 | 后端工程师 | AI 工程师 | 运维/平台工程师 | PM |
| --- | --- | --- | --- | --- | --- |
| 事件中心与详情页 | R | C | C | I | A |
| Incident API 与状态机 | C | R | I | C | A |
| Dify 工作流与 RAG | C | C | R | I | A |
| 工具层 Python 服务 | I | C | R | C | A |
| 执行网关与审批流 | C | R | C | C | A |
| 审计中心与报表 | C | R | I | C | A |
| 故障注入测试与验收 | C | C | C | R | A |
说明：R=Responsible（负责执行），A=Accountable（最终负责），C=Consulted（协作），I=Informed（知会）。
---
## 5. 总体技术架构（路线 A 详细版）
当前内部统一参考图为 `AIOps_Practical_Route_Architecture.png`。这张图是路线 A 的逻辑架构图，重点回答“事件如何进入平台、如何形成诊断、如何受控执行、如何回流学习”，而不是回答“每个服务最终部署在哪台机器上”。
![AIOps Practical Route Architecture](AIOps_Practical_Route_Architecture.png)
配套逐层说明文档见 `AIOps_Architecture_Diagram_Explanation.md`，可用于理解图中每一层为何存在、模块之间如何一一对应，以及这张图是如何从产品目标推导出来的。
路线 A 已从“增强版”升级为“可落地版”：
- 平台核心链路（事件流转、审批审计、执行控制）自研
- Dify 作为 Agent + RAG 中枢，通过 API 向平台开放能力
- 各层解耦，后续可平滑替换模型或 Agent 框架
- 图中展示的是逻辑能力分层，MVP 阶段允许多个模块合并实现
## 5.1 架构图阅读说明与分层（职责到模块级）
### 这张图是怎么来的
- 从 AIOps 的闭环目标倒推：采集、治理、编排、诊断、执行、学习。
- 只保留小团队 6 个月内必须落地的模块，把“概念能力”收敛成“可实现组件”。
- AI 能力放在 `Dify Platform + Agent Brain`，但执行仍必须经过审批、策略和审计约束。
- 因此形成 `Layer A -> Layer F` 六层逻辑：数据接入、上下文补齐、事件成案、AI 判断、受控执行、复盘学习。
### 架构图怎么读
- 自下而上看主链路：`NormalizedEvent -> IncidentContext -> Incident -> RCA Result -> Incident Closure & Execution Results -> Knowledge Update`
- 蓝色实线表示主控制流 / API 调用 / 执行 / 审计；红色虚线表示复盘反馈与知识优化闭环
- 左侧和中部偏事件主链路，顶部偏执行治理，右侧偏学习与持续优化
### 图中名称与实现模块映射
| 图中展示名 | 实现模块/建议 | 作用 |
| --- | --- | --- |
| `collector-adapter` / `alert-webhook` / `event-normalizer` | 保持一致 | 接收并标准化多源告警 |
| `context-enricher` / `topology-resolver` / `change-correlator` | 保持一致 | 做标签统一、拓扑与变更关联 |
| `Incident Service` | `incident-service` | 统一 Incident 生命周期 |
| `Deduplication & Correlation Engine` | `dedupe-group-engine` + 关联规则 | 告警去重、分组、归并 |
| `Custom Gateway` | `platform-dify-gateway` 或平台代理层 | 封装 Dify 调用、结果标准化、审计打点 |
| `Agent Brain (Dify)` | Dify 工作流 + RAG | 诊断、推理、检索、建议 |
| `Approval Gateway` / `Execution Control with Policy Gateway` | `approval-service` + `execution-gateway` + `policy-engine` | 审批、策略校验、执行控制 |
| `Knowledge Feedback` / `kpi-dashboard` | `postmortem-service` + `knowledge-feedback-worker` + `kpi-dashboard` | 复盘、知识更新、指标评估 |
### A. 感知层（Observability Ingestion）
- 数据源：Prometheus、Alertmanager、Loki/ELK、CMDB、K8s Event、变更系统。
- 核心模块：`collector-adapter`、`alert-webhook`、`event-normalizer`。
- 产出对象：统一事件 `NormalizedEvent`（含 source、severity、labels、fingerprint）。
### B. 数据治理层（Normalization & Context）
- 核心职责：统一标签、拓扑关联、变更关联、历史事件关联。
- 核心模块：`context-enricher`、`topology-resolver`、`change-correlator`。
- 产出对象：`IncidentContext`（服务、依赖、变更、近期同类故障）。
### C. 流转编排层（Event Orchestration）
- 核心职责：去重分组、关联归并、状态机流转、升级通知、时间线沉淀。
- 核心模块：`incident-service`、`dedupe-group-engine`（对应图中 `Deduplication & Correlation Engine`）、`escalation-engine`、`timeline-service`。
- 状态机：`new -> triaged -> diagnosing -> remediating -> resolved/closed`。
### D. 智能决策层（Agent Brain, Dify）
- 图中展示为 `Custom Gateway + Dify Platform + Agent Brain (Dify)`。
- Dify 负责：工作流编排、模型调用、RAG 检索、多轮对话。
- 平台负责：通过 `platform-dify-gateway` 或平台代理层封装 Dify 调用、结果标准化、审计留痕与兜底逻辑。
- 核心输出：`RCA Result`（结论、置信度、证据链、影响范围、建议动作）。
### E. 执行与控制层（Execution & Guardrail）
- 核心职责：动作执行、审批闸门、策略控制、权限分级、回滚与审计。
- 核心模块：`action-registry`、`approval-service`、`policy-engine`、`execution-gateway`、`audit-service`。
- 图中的 `Approval Gateway` + `Execution Control with Policy Gateway` 对应实现上的审批流、策略引擎与执行网关组合。
- 执行器：Ansible、K8s API、脚本引擎（统一封装在 `execution-gateway` 后）。
### F. 学习与评估层（Learning Loop）
- 核心职责：复盘反馈、知识更新、评估看板、持续优化。
- 核心模块：`postmortem-service`、`knowledge-feedback-worker`、`kpi-dashboard`。
- 关键指标：MTTR、RCA 准确率、自动恢复率、人工驳回率。
- 关键输出：Runbook Update、Prompt / Workflow Optimization、Knowledge Base Curation。
## 5.2 部署拓扑（小团队可运维）
- 控制平面：`frontend` + `backend-api` + `incident-service` + `approval-service`
- AI 平面：`dify-api` + `dify-worker` + `vector-db`
- 数据平面：`postgres`（业务数据）+ `redis`（缓存与去重窗口）+ `kafka/nats`（事件总线）
- 可观测性平面：`prometheus` + `grafana` + `loki`
建议先单集群部署，按命名空间隔离：`aiops-core`、`aiops-ai`、`aiops-observability`。
## 5.3 路线 A 关键数据流（闭环）
1. 告警进入 `event-normalizer`，生成标准事件。
2. `dedupe-group-engine`（图中 `Deduplication & Correlation Engine`）聚合后生成或更新 Incident。
3. 状态进入 `diagnosing`，平台通过 `Custom Gateway` 调用 `Agent Brain (Dify)` 诊断工作流。
4. Dify 调用平台 Tools（metrics/logs/k8s/change）收集证据。
5. 返回结构化 `RCA Result` 与动作建议，平台按风险策略路由执行。
6. 低风险动作进入执行控制，高风险动作进入审批；结果写入时间线与审计。
7. 事件关闭后自动触发 `postmortem-service` 与 `knowledge-feedback-worker`，更新知识库与 KPI。
## 5.4 路线 A（小团队）技术实现细化
### 核心原则
- 核心事件链路自研（可控）：状态机、升级策略、审批与审计。
- AI 能力通过 Dify 承载（提效）：诊断、RAG、工具编排。
- 平台与 Dify 通过 API 解耦（可替换）：避免绑定单一实现。
### Dify 在本架构中的边界
- Dify 负责：`诊断`、`建议`、`知识检索`、`多轮追问`。
- 平台负责：`状态变更`、`执行授权`、`审计归档`、`SLA 统计`。
- 禁止 Dify 直接改生产资源；所有执行请求必须经 `execution-gateway` 和 `policy-engine`。
### 建议组件分工
- 平台层（前后端自研，对应图中 Layer C / Layer E / 部分 Layer F）：Incident API、状态机、执行控制台、审计中心。
- Dify 层（对应图中 Layer D 的 Dify Platform）：诊断 Agent、RAG 管理、工具调用编排。
- 工具层（Python 服务，对应查询工具与执行器适配层）：metrics/logs/k8s/change 查询与执行器网关。
### 三层项目详细设计
#### 1) 平台层（前后端自研）
**项目目标**
- 建立可控的 Incident 主流程，确保状态流转、审批执行、审计留痕可追踪。
**核心子系统**
- Incident API：事件创建、合并、分派、关闭。
- 状态机引擎：`new -> triaged -> diagnosing -> remediating -> resolved/closed`。
- 执行控制台：动作确认、审批流、执行结果可视化。
- 审计中心：操作日志、状态变更日志、执行审计日志。
**前端功能（你负责重点）**
- 事件列表页：筛选、分组、优先级、责任人。
- 事件详情页：时间线、RCA 卡片、证据引用、影响范围。
- 执行面板：建议动作、风险等级、审批与执行入口。
- 审计查询页：按 incident/operator/action 检索与导出。
**推进计划（建议）**
- Sprint 1：Incident API + 状态机 + 事件列表/详情基础页。
- Sprint 2：执行控制台 + 审批流 + 时间线完整回放。
- Sprint 3：审计中心 + KPI 看板 + 异常处理与告警。
#### 2) Dify 层（Agent 与 RAG 中枢）
**项目目标**
- 提供可解释、可追踪的诊断能力，输出结构化 RCA 与动作建议。
**核心子系统**
- 诊断 Agent 工作流：`incident_diagnosis`。
- 动作规划工作流：`action_planning`。
- 复盘工作流：`postmortem_summary`。
- RAG 管理：SOP 入库、分块、索引、召回与重排。
**必须输出能力**
- 结论（conclusion）
- 置信度（confidence）
- 证据链（evidence）
- 影响范围（impact_scope）
- 动作建议（actions: risk + mode）
**推进计划（建议）**
- Sprint 1：打通诊断工作流，接入 2-3 个基础工具（metrics/logs/k8s）。
- Sprint 2：完善 RAG（标签、重排、引用），稳定结构化输出。
- Sprint 3：加入低置信度降级策略与评测集回归（RCA 准确率、幻觉率）。
#### 3) 工具层（Python 服务）
**项目目标**
- 作为 Dify 与生产系统之间的安全网关，提供标准化查询与受控执行。
**核心子系统**
- 查询工具：`query_metrics`、`query_logs`、`query_k8s`、`query_changes`。
- 执行网关：`execute_action`（统一鉴权、审批校验、回滚控制）。
- 安全治理：限流、超时、重试、幂等键、审计打点。
**推进计划（建议）**
- Sprint 1：完成查询类工具 API，先满足诊断证据采集。
- Sprint 2：完成执行网关，接入 Ansible/K8s API 低风险动作。
- Sprint 3：完善可靠性策略（超时重试/幂等/回滚）与审计标准。
#### 三层协同联调顺序（必须按顺序）
1. 平台层先完成 Incident 状态机与诊断触发入口。
2. Dify 层返回结构化 RCA（先不接自动执行）。
3. 工具层完成查询工具后，补齐证据链。
4. 最后接执行网关与审批流，放开低风险自动动作。
### 平台调用 Dify 的 API 约定（建议）
1. `POST /api/ai/diagnose`：触发诊断工作流，输入 Incident 上下文。
2. `POST /api/ai/chat`：人工追问与补充诊断。
3. `POST /api/ai/tools/{toolName}`：受控工具调用（平台代理）。
4. `GET /api/ai/tasks/{taskId}`：查询异步任务状态与结果。
### 平台核心数据模型（建议）
- `incident`：id、status、severity、service、owner、start_at、end_at
- `incident_timeline`：incident_id、event_type、payload、operator、created_at
- `ai_rca_result`：incident_id、conclusion、confidence、impact_scope、evidence
- `remediation_action`：incident_id、action_name、risk、mode、approval_status、result
- `audit_log`：trace_id、actor、resource、operation、before、after、created_at
### API 契约与版本策略（建议）
- 统一前缀：`/api/v1`
- 版本升级原则：新增字段向后兼容；破坏性变更进入 `v2`
- 字段规范：时间统一 ISO8601，枚举统一小写下划线
- 错误规范：`{ code, message, request_id, detail }`
**核心接口最小集合（MVP）**
- `POST /api/v1/incidents`
- `GET /api/v1/incidents/{incident_id}`
- `PATCH /api/v1/incidents/{incident_id}/status`
- `POST /api/v1/incidents/{incident_id}/diagnose`
- `POST /api/v1/incidents/{incident_id}/actions/{action_id}/approve`
- `POST /api/v1/incidents/{incident_id}/actions/{action_id}/execute`
- `GET /api/v1/incidents/{incident_id}/timeline`
- `GET /api/v1/audit/logs`
### 后端 & AI 联调契约表（JSON 字段级）
#### A. 诊断触发：`POST /api/v1/incidents/{incident_id}/diagnose`
**Request JSON**
```json
{
"request_id": "req-20260325-0001",
"incident": {
"incident_id": "INC-2026-0001",
"title": "api latency high",
"status": "diagnosing",
"severity": "p1",
"service": "order-service",
"env": "prod",
"cluster": "cn-hz-prod-01",
"fingerprint": "svc:order|alert:latency_p95|env:prod",
"labels": {
"team": "sre",
"region": "cn-hz"
},
"started_at": "2026-03-25T09:10:11Z"
},
"time_window": {
"start": "2026-03-25T08:55:00Z",
"end": "2026-03-25T09:10:00Z"
},
"context": {
"recent_changes": [
{
"change_id": "chg-1189",
"type": "config",
"summary": "update db pool max",
"changed_at": "2026-03-25T08:58:00Z"
}
],
"related_incidents": ["INC-2026-0007"],
"topology": ["api-gateway", "order-service", "mysql-primary"]
},
"policy": {
"auto_execute_allowed": true,
"max_actions": 3,
"confidence_threshold": 0.7
}
}
```
**Response JSON**
```json
{
"request_id": "req-20260325-0001",
"task_id": "task-diag-00091",
"incident_id": "INC-2026-0001",
"status": "queued",
"queued_at": "2026-03-25T09:10:13Z"
}
```
#### B. 任务结果查询：`GET /api/v1/ai/tasks/{task_id}`
**Response JSON（running）**
```json
{
"task_id": "task-diag-00091",
"incident_id": "INC-2026-0001",
"status": "running",
"progress": 65,
"steps": [
{"name": "query_metrics", "status": "done"},
{"name": "query_logs", "status": "running"}
]
}
```
**Response JSON（succeeded）**
```json
{
"task_id": "task-diag-00091",
"incident_id": "INC-2026-0001",
"status": "succeeded",
"result": {
"summary": "数据库连接池耗尽导致 API 延迟升高",
"rca": {
"conclusion": "连接池参数与突发流量不匹配",
"confidence": 0.86,
"impact_scope": ["api-gateway", "order-service"],
"evidence": [
{"type": "metric", "ref": "promql://latency_p95"},
{"type": "log", "ref": "loki://timeout_errors"},
{"type": "sop", "ref": "kb://sop/db/pool-tuning"}
]
},
"actions": [
{
"action_id": "act-001",
"name": "临时扩容 order-service",
"risk": "low",
"mode": "auto",
"rollback": "scale down deployment/order-service"
},
{
"action_id": "act-002",
"name": "调整数据库连接池配置",
"risk": "medium",
"mode": "approval",
"rollback": "restore configmap db-pool-v2"
}
],
"model_usage": {
"model": "qwen2.5-32b",
"input_tokens": 4821,
"output_tokens": 691,
"cost_usd": 0.092
}
},
"finished_at": "2026-03-25T09:11:20Z"
}
```
#### C. 追问会话：`POST /api/v1/ai/chat`
**Request JSON**
```json
{
"incident_id": "INC-2026-0001",
"task_id": "task-diag-00091",
"question": "为什么判断是连接池问题而不是下游网络抖动？",
"conversation_id": "conv-9001",
"response_mode": "stream"
}
```
**Response JSON（non-stream）**
```json
{
"conversation_id": "conv-9001",
"answer": "过去15分钟连接超时错误与连接池使用率峰值高度相关，且网络丢包指标正常。",
"citations": [
{"type": "metric", "ref": "promql://db_pool_usage"},
{"type": "metric", "ref": "promql://packet_loss"}
]
}
```
#### D. 工具调用代理：`POST /api/v1/ai/tools/{tool_name}`
**Request JSON（以 `query_metrics` 为例）**
```json
{
"incident_id": "INC-2026-0001",
"task_id": "task-diag-00091",
"arguments": {
"query": "histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{service='order-service'}[5m])) by (le))",
"start": "2026-03-25T08:55:00Z",
"end": "2026-03-25T09:10:00Z",
"step": "30s"
}
}
```
**Response JSON**
```json
{
"tool_name": "query_metrics",
"status": "ok",
"data": {
"series": 1,
"points": 30,
"summary": "p95 latency 从 220ms 升至 2.1s"
},
"duration_ms": 328
}
```
#### E. 枚举与必填字段约束
- `incident.status`：`new | triaged | diagnosing | remediating | resolved | closed`
- `incident.severity`：`p1 | p2 | p3 | p4`
- `actions.risk`：`low | medium | high`
- `actions.mode`：`auto | approval | suggest_only`
- `task.status`：`queued | running | succeeded | failed | timeout`
**必填字段（后端 -> AI）**
- `incident_id`、`status`、`severity`、`service`、`env`、`fingerprint`、`time_window`
**必填字段（AI -> 后端）**
- `task_id`、`incident_id`、`status`
- 成功时必须包含 `rca.conclusion`、`rca.confidence`、`rca.evidence[]`
- `confidence < 0.70` 时 `actions.mode` 只能为 `suggest_only | approval`
#### F. 错误码约定（联调最小集）
| code | 含义 | 处理建议 |
| --- | --- | --- |
| `AI_TIMEOUT` | AI 任务超时 | 进入人工接管，保留建议模式 |
| `TOOL_UNAVAILABLE` | 工具层不可用 | 降级检索，禁止自动执行 |
| `INVALID_STATE` | 状态机非法跳转 | 拒绝请求并记录审计 |
| `APPROVAL_REQUIRED` | 缺少审批 | 拒绝执行并提示审批人 |
| `SCHEMA_INVALID` | AI 返回结构不合法 | 触发重试/兜底模板 |
### 统一响应结构（建议）
```json
{
"incident_id": "INC-2026-0001",
"summary": "数据库连接池耗尽导致 API 延迟升高",
"rca": {
"conclusion": "连接池配置与突发流量不匹配",
"confidence": 0.86,
"impact_scope": ["api-gateway", "order-service"],
"evidence": [
{"type": "metric", "ref": "promql://..."},
{"type": "log", "ref": "loki://..."},
{"type": "sop", "ref": "kb://sop/db/pool-tuning"}
]
},
"actions": [
{"name": "临时扩容 API", "risk": "low", "mode": "auto"},
{"name": "调整连接池参数", "risk": "medium", "mode": "approval"}
]
}
```
### 失败与降级策略（必须实现）
- Dify 超时：返回最近一次可用建议 + 人工接管提示。
- Tool 调用失败：标记证据缺失，降低置信度并阻断自动执行。
- 执行失败：自动回滚并创建高优 Incident 子任务。
- 向量检索异常：降级到关键词检索 + 近期案例兜底。
## 5.5 调度精度保障（SLO + 规则）
### 调度与响应精度机制
- 状态机强约束：非法状态跳转直接拒绝并记录审计。
- 证据门槛：无证据链 RCA 不允许进入自动执行。
- 置信度门槛：`confidence < 0.70` 时强制降级为建议模式。
- 风险门槛：`risk=high` 必须审批且双人复核。
- 执行前校验：变更窗口、白名单、目标资源健康度。
### 精度验收指标（建议）
- RCA Top1 准确率 >= 80%
- 自动动作误触发率 <= 1%
- 高风险动作审批覆盖率 = 100%
- 事件处理延迟 P95 <= 5 秒
## 5.6 AI 调用成本治理（FinOps）
### 成本控制策略
- 模型分级路由：小模型用于分类/摘要，中模型用于常规诊断，大模型仅复杂故障触发。
- Token 预算：按任务类型设置输入输出上限，超限自动裁剪上下文。
- 缓存复用：同 fingerprint 故障复用历史 RCA 与动作模板。
- 异步化：复盘类任务离线执行，避免占用实时预算。
- 本地优先：可本地推理任务不走外部高价 API。
### 成本指标（建议）
- `cost_per_incident`
- `cost_per_resolved_incident`
- `token_per_incident`
- `mttr_improvement_per_dollar`
## 5.7 测试与验收计划（故障注入）
### 场景清单（MVP 建议 12 个）
- API 延迟飙升
- 数据库连接池耗尽
- K8s Pod OOM
- 节点不可达
- 依赖服务超时
- 配置变更回归故障
### 测试分层
- 单元测试：状态机规则、风险策略、工具适配器
- 集成测试：平台 -> Dify -> 工具层 -> 执行网关全链路
- 压力测试：高并发告警风暴场景
- 演练测试：回滚、审批超时、Dify 超时降级
### 验收标准
- Month 3：10+ 场景联调通过，MTTR 改善 > 50%
- Month 6：低风险自愈率 > 60%，关键 KPI 达标
## 5.8 安全与合规细化
- 密钥管理：统一 KMS/Secret 管理，禁止硬编码
- 权限管理：RBAC 最小权限 + 操作双人复核
- 数据治理：敏感字段脱敏，审计日志保留 >= 180 天
- 网络安全：服务间 mTLS，关键接口 IP 白名单
## 5.9 发布与回滚 Runbook
### 发布策略
- 灰度发布：10% -> 30% -> 100%
- 观测窗口：每阶段观测 30-60 分钟
- 门禁条件：错误率、延迟、误触发率不劣化
### 回滚触发条件
- 自动动作失败率连续 5 分钟超阈值
- Dify 调用超时率超过阈值并影响响应 SLA
- 关键服务错误率超过基线阈值
### 回滚步骤
1. 切换到上一个稳定版本
2. 暂停自动执行，仅保留建议模式
3. 触发应急群通知并生成复盘任务
---
## 6. 非功能与治理要求
### 6.1 平台级 SLO
- 告警处理延迟 P95 < 5 秒
- 诊断建议生成时延 P95 < 60 秒
- 平台可用性 > 99.9%
- 审计日志完整率 100%
### 6.2 安全与合规
- 全链路 RBAC、最小权限原则
- 高风险动作强制审批与双人复核
- 敏感数据脱敏与传输加密
- 全量操作可追踪、可回放、可审计
### 6.3 可靠性设计
- 关键组件高可用（多副本 + 失败转移）
- 执行器幂等与超时控制
- 自愈操作默认可回滚
- 平台自身监控与告警闭环
---
## 7. 行业成功案例与可借鉴能力
本节聚焦可公开验证的产品能力与落地方法，给出“案例细节 + 可复制做法 + 本项目映射”。
### 7.1 PagerDuty：事件响应与值班协同的标杆实践
**产品定位**
- 核心是 Incident Response 平台，不替代监控系统，而是承接监控告警并驱动处置流程。
**能力拆解**
- On-call 与 Escalation Policy：告警按排班与升级链自动触达，避免“没人接警”。
- Event Intelligence：告警去重、聚合、抑制，降低重复告警噪声。
- Incident Timeline：自动记录事件时间线，沉淀复盘证据。
- 协同联动：和 IM、工单、电话短信等系统联动，缩短协作路径。
**典型处置链路（可直接借鉴）**
1. 监控触发告警并推送至事件平台。
2. 平台完成去重与聚合，生成 Incident。
3. 根据值班策略通知责任人；超时未响应自动升级。
4. 故障处理期间持续写入时间线与操作记录。
5. 事件关闭后自动进入复盘，产出改进项。
**对本项目的设计启示**
- 流转层应优先实现：事件状态机、升级规则、值班联动、时间线中心。
- 以“先把流程跑通，再叠加智能诊断”为原则，避免一开始过度依赖模型能力。
### 7.2 Datadog：统一可观测性驱动的关联诊断
**产品定位**
- 统一可观测性平台，强调 Metrics / Logs / Traces / Events 的联动分析。
**能力拆解**
- 跨数据源检索：同一故障上下文中同时查看指标、日志、链路。
- 服务拓扑视图：用依赖关系缩小故障定位范围。
- 异常检测与动态阈值：减少静态阈值带来的误报与漏报。
**典型处置链路（可直接借鉴）**
1. 告警触发后自动关联同时间窗口日志与 Trace。
2. 按服务拓扑定位“上游异常”和“下游受影响面”。
3. 生成诊断候选清单，输出最可能根因路径。
**对本项目的设计启示**
- 数据治理层必须建立统一标签标准（service/env/region/owner）。
- 大脑层工具链应支持多源联查，避免只依据单一指标给结论。
### 7.3 Dynatrace / New Relic：AIOps 根因分析能力建设
**产品定位**
- 强调“自动检测 + 智能诊断 + 影响分析”的连续闭环。
**能力拆解**
- 异常模式识别：识别偏离基线的行为并触发分析。
- 根因候选推理：基于依赖、时序和上下文给出候选原因。
- 影响域评估：输出受影响服务、租户或业务线范围。
**典型处置链路（可直接借鉴）**
1. 监控发现异常并触发自动诊断。
2. 系统聚合证据并排序根因候选。
3. 输出诊断结论、置信度与影响范围，支持人工确认。
**对本项目的设计启示**
- RCA 输出必须包含：结论、证据链、置信度、影响范围、建议动作。
- 建议在模型层增加“低置信度降级策略”（仅建议，不自动执行）。
### 7.4 Splunk SOAR / IBM SOAR：自动化与治理并重
**产品定位**
- 重点在 Playbook 编排、权限管控和审计闭环，适合高合规场景。
**能力拆解**
- 自动化编排：将多步骤处置动作标准化为可复用流程。
- 审批与权限：高风险动作执行前置审批，细粒度授权。
- 审计追踪：保留操作记录、执行结果和责任主体。
**典型处置链路（可直接借鉴）**
1. 命中自动化策略后生成执行计划。
2. 高风险动作进入审批流，低风险动作自动执行。
3. 执行完成后自动记录证据并归档审计。
**对本项目的设计启示**
- 执行层要内置策略闸门：白名单、审批、回滚点、双人复核。
- 任何自动操作都必须可追踪、可回滚、可审计。
### 7.5 开源组合实践：可控、可扩展、可私有化
**推荐基线组合**
- 监控：Prometheus + Alertmanager + Grafana
- 日志：OpenSearch/ELK
- 编排与执行：Argo Workflows / Ansible / K8s API
- 数据采集标准：OpenTelemetry
**实践价值**
- 降低厂商锁定风险，便于私有化与国产化替代。
- 组件化扩展灵活，适合分阶段建设。
- 与现有运维体系兼容度高，迁移成本可控。
**对本项目的设计启示**
- 坚持“开源底座 + 智能中枢”路径，智能层通过连接器与适配层解耦。
- 先做高价值连接器（Prometheus、K8s、工单、IM），再扩展其他生态。
### 7.6 本项目能力映射（Benchmark Mapping）
| 参考产品/方向 | 关键可借鉴能力 | 本项目落地动作 | 近期优先级 |
| --- | --- | --- | --- |
| PagerDuty | 值班升级、事件时间线、响应流程标准化 | 事件状态机 + 升级策略 + 时间线中心 | P0 |
| Datadog | 指标/日志/Trace 联动分析 | 统一标签标准 + 多源联查工具链 | P0 |
| Dynatrace/New Relic | 根因候选、影响范围、置信度输出 | RCA 证据链模板 + 置信度阈值 | P1 |
| Splunk SOAR/IBM SOAR | Playbook、审批治理、审计留痕 | 策略闸门 + 回滚机制 + 审计中心 | P0 |
| 开源生态组合 | 私有化可控、组件化扩展 | 连接器优先级建设 + 模块化部署 | P1 |
### 7.7 里程碑化落地建议（结合本项目 6 个月计划）
- Month 1-2：优先交付 PagerDuty 类能力（事件收敛、升级策略、时间线）。
- Month 2-4：补齐 Datadog 类能力（多源联查、统一标签、拓扑关联）。
- Month 4-5：引入 Dynatrace 类能力（RCA 证据链与置信度输出）。
- Month 5-6：落地 SOAR 类能力（审批、回滚、审计）并完成验收。
---
## 8. 分阶段实施路径（与产品化联动）
### Phase 1（0-3 个月）：MVP 可用
- 打通感知-编排-诊断主链路（平台 + Dify Platform + Custom Gateway）
- 完成 10+ 典型场景故障注入测试
- 输出首版 KPI 看板和实施手册
### Phase 2（4-6 个月）：生产就绪
- 完成执行层与安全闸门
- 实现低风险故障自动自愈
- 完成平台化运维流程（审计、审批、复盘）
### Phase 3（6-12 个月）：规模复制
- 行业模板化交付
- 完善多租户与插件生态
- 按资源情况逐步扩展商业化能力
---
## 9. 主要风险与控制点
| 风险 | 影响 | 控制措施 |
| --- | --- | --- |
| LLM 幻觉或误判 | 错误决策 | 置信度阈值 + 人工审批 + 证据链输出 |
| 知识库质量不稳定 | 诊断命中率下降 | 知识治理流程 + 评分淘汰机制 |
| 自动化误操作 | 业务中断 | 白名单 + 回滚点 + 双人复核 |
| 集成复杂度高 | 项目延期 | 标准连接器 + 适配层抽象 |
---
## 10. 附录：参考案例追踪清单（建议）
为保证方案持续更新，建议在项目推进中维护如下案例追踪清单：
- PagerDuty：事件编排、值班升级、事件复盘能力更新
- Datadog：可观测性联动分析、AIOps 功能演进
- Dynatrace / New Relic：RCA 自动化与影响分析能力
- Splunk SOAR / IBM：自动化编排、安全审批与审计实践
- CNCF 生态：OpenTelemetry、Prometheus、Argo 等开源能力演进

195
AIOps_Project_Proposal.md Normal file
View File

@@ -0,0 +1,195 @@
# 项目立项报告 · 2026年Q1
## AIOps 智能运维平台项目立项
基于 Prometheus + Agent 协同的“感知 → 响应 → 决策 → 恢复”智能闭环。
## 行业背景与市场机遇
企业运维正面临前所未有的复杂性挑战。
1. **告警风暴问题严峻**
企业平均每天产生数千条监控告警，运维团队 70% 以上时间耗费在告警分类与噪音过滤上，真正有效处理时间严重不足。
2. **MTTR 居高不下**
行业调查显示，企业关键系统故障平均恢复时间超过 4 小时，每小时宕机损失可达数十万至数百万元。
3. **商业价值验证与自主可控**
市场领导者 PagerDuty 的成功案例证明了事件管理平台在提升运维效率方面的巨大潜力，本项目旨在打造自主可控的同类解决方案。
4. **国产化替代需求迫切**
在数据安全合规与降本增效双重压力下，企业对自主可控的 AIOps 解决方案需求强烈。
## 项目研究方向
构建“感知 → 响应 → 决策 → 恢复”AIOps 智能闭环。
### 研究方向、核心技术与预期突破
| 研究方向 | 核心技术 | 对标商业产品 | 预期突破 |
| --- | --- | --- | --- |
| 智能感知层 | Prometheus + Alertmanager | Datadog APM | 多维指标实时采集与异常检测 |
| 事件编排层 | Agent 协同工作模式 | 自主智能事件管理 | 告警去重、分组与上下文关联 |
| 智能诊断层 | Agent LLM + RAG 知识库 | PagerDuty AIOps | 根因分析（RCA）自动生成 |
| 自愈执行层 | Ansible / K8s API | 市场领先产品 | 故障自动修复与弹性扩容 |
### 研究核心问题
- 如何利用 Agent 将非结构化告警信息转化为可执行的故障处置方案？
- 如何构建高质量的运维知识库（SOP）以支撑 RAG 精准检索？
- 如何在保障安全边界的前提下实现故障自愈的自动化执行？
## 项目整体架构
四层技术栈协同驱动智能运维闭环。
### 感知层（PROMETHEUS / ALERTMANAGER）
- 实时监控 K8s、数据库及应用核心指标。
- 触发阈值时执行告警路由与抑制规则。
- 向下游推送结构化告警数据。
### 流转层（AGENT 协同 / 事件管理）
- 执行告警去重、智能分组与抑制。
- 记录完整事件上下文与生命周期时间线。
- Agent 协同处理告警并触发诊断流程。
### 大脑层（AGENT 智能体 / RAG 知识库）
- Agent 调用 Tools 查询实时指标与日志。
- Agent 检索 RAG 知识库，对比历史 SOP。
- Agent 生成根因分析报告（RCA）与建议。
### 执行层（ANSIBLE / K8S API）
- 将分析结果推送至即时通讯工具。
- 调用 Ansible 或 K8s API 执行自愈操作。
- 实现重启、扩容、流量切换等闭环响应。
## 核心商业价值
对标 PagerDuty，打造企业级 AIOps 核心竞争力。
| 能力维度 | 传统运维模式 | PagerDuty（市场标杆） | 本项目目标 |
| --- | --- | --- | --- |
| 告警降噪 | 人工筛选，效率低 | AI 自动去重分组 | LLM 语义级降噪 |
| 故障诊断 | 依赖专家经验 | 事件时间线 + 上下文 | RAG + LLM 自动 RCA |
| 响应速度 | MTTR > 4 小时 | MTTR 降低 60% | 目标 MTTR < 30 分钟 |
| 知识沉淀 | Wiki 文档，难检索 | Runbook 自动化 | 向量知识库，RAG 精准召回 |
| 自愈能力 | 手动执行脚本 | 市场领先产品 | K8s/Ansible 自动执行 |
| 数据主权 | 数据上传第三方 | SaaS 托管 | 完全私有化部署 |
### 效率提升
显著减少 L1/L2 运维人力投入，MTTR 从小时级压缩至分钟级，系统可用性目标 99.9%+。
### 安全合规
完全私有化部署，满足金融、政务等行业数据安全要求，核心技术自主可控。
### 可扩展性
模块化架构支持持续演进，支持接入更多数据源与执行引擎，适配多种云环境。
## 项目团队与人员分工
精简核心团队，确保高效交付。
| 角色 | 成员 | 核心职责 | 技术要求 |
| --- | --- | --- | --- |
| 项目负责人（PM） | 党泽荣 | 项目整体规划、进度把控、跨团队协调 | 运维/研发背景，5年以上项目管理经验 |
| AIOps 平台工程师 | 王伟、赵光飞 | 监控体系部署、后端 API 开发、Webhook 集成、自动化执行模块开发 | K8s、Prometheus、Python/Go、Ansible、API 开发 |
| AI Agent 工程师 | 毛越民 | Agent 编排、RAG 知识库构建、Prompt 工程优化 | LangChain/Agent 框架、向量数据库、RAG 技术 |
| 运维领域专家 | 罗辉 | SOP 知识库整理、故障案例沉淀、RCA 模板设计、测试验证 | 丰富的运维故障处理经验、测试技能 |
- 总团队规模：5人
- 核心成员：党泽荣、王伟、赵光飞、毛越民、罗辉
## 第一阶段规划（Month 1-3）
夯实基础，打通核心链路。
### Month 1：基础设施搭建
- 部署 Prometheus + Alertmanager 监控体系
- 完成 Grafana 可视化仪表盘搭建，建立基线告警规则
- 搭建 Agent 协同事件管理模块，打通监控 → Agent 链路
### Month 2：Agent 智能体基础版
- 部署 Agent 框架，完成基础 LLM 接入
- 设计并实现第一版告警诊断 Agent
- 构建初始运维知识库，完成 RAG 基础检索验证
### Month 3：集成联调与验证
- 完成四层架构端到端集成联调
- 设计 10+ 个典型故障场景，执行故障注入测试
- 验证 RCA 报告生成质量，与人工诊断结果对比
**第一阶段交付物：** 可运行的 MVP 系统 + 测试报告 + 优化路线图
## 第二阶段规划（Month 4-6）
深化智能，实现自愈闭环。
### Month 4：Agent 智能诊断能力增强
- 优化 Agent 诊断逻辑，引入多轮对话诊断
- 扩充运维知识库，提升 RAG 召回精度
- 接入 ELK 日志查询，实现联合诊断
### Month 5：自愈执行层开发
- 开发自动化执行引擎，基于 Agent 决策触发
- 实现 K8s 层面自愈操作：Pod 重启、HPA 扩容
- 建立执行安全边界，实现关键操作人工审批
### Month 6：生产就绪与规模化准备（不含完整商业化后台）
- 完成生产环境压力测试与安全审计
- 编写完整部署文档、运维手册与用户指南
- 制作产品 Demo 视频，准备对内评审与试点推广材料
**第二阶段交付物：** 生产级 AIOps 平台 + 完整文档 + 试点推广材料
## 技术风险与应对策略
主动识别风险，制定预案确保项目成功。
| 风险类型 | 具体风险 | 影响 | 概率 | 应对策略 |
| --- | --- | --- | --- | --- |
| 技术风险 | LLM 幻觉导致错误诊断 | 高 | 中 | 引入人工审核机制，高风险操作强制人工确认 |
| 技术风险 | RAG 召回精度不足 | 中 | 中 | 持续优化 Embedding 模型，建立知识库评估体系 |
| 数据风险 | 运维 SOP 文档缺失/质量差 | 高 | 高 | 第一阶段专项投入知识库建设，引入专家审核 |
| 集成风险 | 第三方系统 API 变更 | 中 | 低 | 抽象适配层设计，降低与具体产品的耦合度 |
| 安全风险 | 自动化执行误操作 | 高 | 低 | 严格的执行权限分级，关键操作双人审批 |
| 组织风险 | 运维团队对 AI 决策信任度低 | 中 | 中 | 渐进式推广，先建议后自动化，用数据建立信任 |
> 总体风险评级：中等可控，通过分阶段交付和充分测试可有效降低风险。
## 成功标准与关键指标
用数据衡量项目成果，确保目标可量化。
| 指标类别 | 关键指标（KSI） | 当前基准（BASELINE） | 目标值（TARGET） |
| --- | --- | --- | --- |
| 效率指标 | MTTR（平均恢复时间） | > 240 分钟 | < 30 分钟 |
| 效率指标 | 告警处理时间（人均/天） | 4 小时 | < 1 小时 |
| 质量指标 | 告警误报率 | > 40% | < 15% |
| 质量指标 | RCA 报告准确率 | N/A（人工） | > 80% |
| 自动化 | 故障自动恢复率 | 0% | > 60% |
| 知识库 | RAG 检索召回准确率 | N/A | > 85% |
| 可用性 | 系统自身可用性 | N/A | > 99.9% |
### 验收节点
- Month 3 验收节点：MVP 系统上线；完成 10+ 典型故障场景验证，MTTR 改善幅度 > 50%
- Month 6 验收节点：生产系统正式上线；低风险故障自愈率 > 60%，全部 KPI 指标达标（不包含商业化计费与运营后台）
## 总结与下一步行动
项目价值清晰，建议快速推进立项决策。
### 核心结论
- **技术先进性：** 融合 Agent + RAG + 自动化执行，代表 AIOps 技术前沿方向。
- **商业可行性：** 对标 PagerDuty 验证的成熟商业模式，具备显著的降本增效潜力。
- **战略意义：** 构建企业自主可控的智能运维核心能力，支撑数字化转型。
- **可扩展性：** 模块化架构支持持续演进，可扩展至安全运营等更多场景。
### 立即需要的决策
1. **批准立项：** 正式启动项目，完成团队组建（目标：本月内）。
2. **指定负责人：** 确认项目 PM 及核心技术负责人。
3. **环境准备：** 协调 K8s 测试集群与 LLM API 资源。

BIN
AIOps_智能运维平台项目立项书.pdf Normal file
View File

Binary file not shown.

BIN
Implementable_AIOps_Platform_Route_A_Architecture.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.3 MiB

22
README.md Normal file
View File

@@ -0,0 +1,22 @@
# AIOps Docs
这个仓库用于沉淀 AIOps 项目的产品方案、架构设计、实施路线和配套架构图，作为内部讨论、方案迭代和后续产品化的统一文档入口。
## 当前文档
- `AIOps_Product_Architecture_and_Commercialization.md`：产品架构与商业化主文档
- `AIOps_Architecture_Diagram_Explanation.md`：当前架构图逐层详解与推导说明
- `AIOps_Project_Proposal.md`：项目提案文档
- `AIOps_Practical_Route_Architecture.png`：当前统一参考架构图
## 使用建议
- 统一围绕 `AIOps_Practical_Route_Architecture.png` 讨论和更新文档
- 架构图有较大调整时，同步更新 `AIOps_Architecture_Diagram_Explanation.md`
- 产品定位、范围、实施路径变化时，同步更新主文档
## 仓库定位
- 这是一个文档仓库，不是代码仓库
- 图中的模块首先表达逻辑职责，不强制等于最终微服务拆分
- MVP 阶段允许多个模块在实现上合并