p10b-aiops-case

---
name: p10b-aiops-case
description: 'AI Native 产品方法论——AIOps 行业案例模板 Skill。

  用户提供 AIOps 场景和业务背景，Skill 自动执行全链路方法论：

  方向定界 → 试验展开 → 系统构建 → 审计放行 → 生产运行，输出完整案例方案。

  基于《AI Native 产品方法论》第19章 AIOps 案例，适用于高风险、强约束、重责任场景。

  '
tags:
- ai-product
- methodology
- aiops
- case-study
- high-risk
- book-skill
author: Max
source_book: AI Native 产品方法论
source_chapter: 第19章 AIOps 案例
version: 1.0
stage: p10b
homepage: https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p10b-aiops-case
---

# AIOps 案例模板 Skill

## 使用场景

- 运维团队希望引入 AI 能力，需要系统性方法论指导
- 需要为 AIOps 产品设计从方向到生产的完整路径
- 关注高风险、强约束、重责任场景的 AI 化方法

## AIOps 特征与适配性

| AIOps 特征 | 对方法论的影响 |
|------------|--------------|
| 高风险：错误建议直接导致故障扩大 | 必须有强审计放行和人在回路机制 |
| 知识密集：依赖专家经验 | 需要知识沉淀和检索增强 |
| 实时性强：响应时间要求高 | 模型延迟必须纳入评估 |
| 可解释性：决策必须可追溯 | 上下文工程和日志是基础设施 |
| 责任边界清晰：谁决策谁负责 | Agent 边界设计是核心 |

## AIOps 方法论路径

```
@ai-native-direction-framing
  → 选择最值得先 AI 化的运维节点
  → 输出：Direction Brief

@p2a-experiment-overview + @p2b-experiment-engine
  → 验证日志解释、告警聚类、案例召回能力
  → 输出：实验结论报告

@p2c-process-redesign
  → 值班升级链设计
  → 输出：人机协作矩阵

@p2e-shadow-validation
  → 影子系统并行验证
  → 输出：影子验证报告

@ai-native-audit-release
  → 高风险场景审计放行
  → 输出：放行决策

@ai-native-production-ops
  → 值班面板和生产观测
  → 输出：生产运行方案

@p10a-value-discovery-loop
  → 价值信号识别与反馈
  → 输出：价值发现方案
```

## 典型 AIOps 能力分层

### 第一层：值班辅助（低风险）
- 日志解释与摘要
- 告警聚类与去重
- 案例召回与相似故障推荐
- → 适合：自动 + 人在回路中

### 第二层：分诊辅助（中风险）
- 故障影响范围判断
- 根因概率排序
- 处置建议推荐
- → 适合：Copilot + 人在回路中

### 第三层：自动处置（高风险）
- 自动扩缩容
- 自动切流
- 自动补丁
- → 适合：人在监督中，且需强审计

## AIOps 案例 Skill 输出模板

\`\`\`yaml
# AIOps 案例方案

方向定界:
  核心问题: [选择最值得先 AI 化的运维节点]
  目标场景: [故障分诊 / 告警处理 / 日志分析 / 容量规划]
  约束条件: [响应时间要求 / 风险边界 / 可解释性要求]
  Direction Brief: [输出]

试验展开:
  能力实验:
    - 日志解释: [模型/准确率/结论]
    - 告警聚类: [模型/准确率/结论]
    - 案例召回: [模型/准确率/结论]
  产品实验:
    - 值班面板原型
    - 采纳率/满意度
  商业实验:
    - MTTR 缩短目标
    - ROI 测算

系统构建:
  Agent 设计:
    - 值班 Agent
    - 分诊 Agent
    - 知识库 Agent
  Memory: [会话状态 / 故障上下文 / 历史案例]
  Context: [告警上下文 / 服务拓扑 / 业务影响]
  RAG: [运维知识库 / SOP / 历史故障库]
  审计规则: [风险等级 / 升级条件 / 人工接管点]

审计放行:
  RAX 评估: [风险/接受度/体验评分]
  放行条件: [通过/附条件/拒绝]
  约束: [高风险动作必须人工确认]

生产运行:
  可观测性: [五层观测设计]
  反馈回灌: [故障案例 → 知识库更新]
  循环优化: [月度复盘 + 季度能力沉淀]
\`\`\`

## 与其他 Skill 的关系

- **核心协同**：@ai-native-direction-framing, @p2a-experiment-overview, @ai-native-audit-release, @ai-native-production-ops
- **配套**：@ai-native-memory-system（会话状态管理），@ai-native-knowledge-rag（运维知识沉淀），@p10a-value-discovery-loop（价值发现）
- **案例 Skill**：@p10c-customer-service-case（客服场景），@p10d-saas-case（数据分析场景）

## 适用边界

- ✅ 故障分诊、告警处理、日志分析、容量预测等场景
- ✅ 高风险、强约束、重责任的运维环境
- ❌ 需要直接自动执行高危操作（建议用人在监督中 + 强审计）
- ❌ 实时性要求极高的交易系统（延迟和准确率难以兼顾）

## 核心概念

### 1. 故障分诊优先于自动处置

AIOps 最值得先改写的不是"最终执行动作"，而是"高频、重复、信息密集的故障分诊与判断链"。故障分诊同时满足四个条件：高频、重复、可比较、价值直接。系统能更快做出初步判断，值班工程师就能缩短定位时间、减少无效升级，并把注意力放到真正高风险的信号上。

### 2. 能力分层递进

AIOps 系统应按风险等级分三层递进建设：
- **值班辅助层**（低风险）：日志解释、告警聚类、案例召回——适合自动 + 人在回路中
- **分诊辅助层**（中风险）：故障影响判断、根因排序、处置建议——适合 Copilot + 人在回路中
- **自动处置层**（高风险）：自动扩缩容、切流、补丁——适合人在监督中 + 强审计

### 3. 证据链驱动的可解释性

AIOps 输出的不应该只是一个"可能原因"，还应该包含：基于什么证据、建议优先看哪些线索、是否命中历史故障模式、以及什么情况下必须升级人工。没有证据链的 AIOps 充其量只是一个生成式分析器。

### 4. 经验复利与组织沉淀

过去分散在群聊、个人习惯和少数专家脑中的判断逻辑，应被写进案例库、规则系统和反馈回路里。每一次新故障、每一次人工修正、每一次升级路径变化，都会反过来让系统更懂本组织真实的运行环境。AIOps 的长期价值不只是"帮人快一点看日志"，而是把值班体系从依赖少数人，逐步推进到依赖组织能力。

### 5. 边界先于自动化

AIOps 场景最大的特点，是错误代价往往远高于一般信息类产品。一次错误归因可能让工程师沿错误方向排查半小时；一次错误建议可能触发错误扩容或重启；一次边界失守可能把局部问题放大成跨服务事故。因此，审计放行不是附加动作，而是产品成立的一部分。

## 分步执行

### 步骤 1：方向定界——选择最值得先 AI 化的运维节点

**输入**：运维团队现状、历史故障工单、监控体系、值班流程

**执行要点**：
- 判断基础条件：历史故障工单是否充足？日志样本是否可得？监控信号是否覆盖？处理手册和复盘材料是否具备？
- 选择第一批高频且可比较的故障模式，例如：告警去噪、故障摘要、相似案例召回、初步归因和升级建议
- 输出 Direction Brief：明确目标场景、约束条件和成功标准

**输出**：Direction Brief（含目标场景、风险边界、响应时间要求、可解释性要求）

### 步骤 2：试验展开——验证三层能力是否稳定

**输入**：Direction Brief、历史样本、评估标准

**执行要点**：
- **理解能力验证**：系统能否解释单条日志和单个告警？
- **关联能力验证**：系统能否把多源信号拼起来看出异常模式？
- **经验调用验证**：系统能否从历史案例中召回相似处置路径？
- 重点识别：哪些故障模式已进入稳定区？哪些仍依赖专家直觉？哪些看上去有效但真实环境会失真？

**输出**：能力实验报告（含各故障模式的准确率、召回率和置信度分析）

### 步骤 3：系统构建——把值班经验写进系统

**输入**：试验结论、可用数据源、系统架构约束

**执行要点**：
- 拆分能力单元：日志解释 Skill、故障摘要 Skill、相似案例召回 Skill、风险提示 Skill、升级建议 Skill
- 构建 Agent 编排：值班 Agent（理解告警 → 选择 Skill → 组织结果）、分诊 Agent、知识库 Agent
- 设计 Memory：会话状态、故障上下文、历史案例
- 设计 Context：告警上下文、服务拓扑、业务影响范围
- 设计 RAG：运维知识库、SOP、历史故障库
- 设计升级链：值班工程师 → 领域专家 → 服务负责人 → 跨团队协作

**输出**：系统架构方案（含 Agent 设计、Skill 清单、Tool 映射、升级路径）

### 步骤 4：审计放行——明确建议边界和人工接管条件

**输入**：系统架构方案、风险评估标准

**执行要点**：
- 定义 RAX 评估：风险（Risk）、接受度（Acceptance）、体验（eXperience）
- 设置边界规则：哪些输出只能作为建议？哪些动作需要双人确认？哪些生产环境永远不能让 AI 直接下指令？
- 设计回退机制：异常一旦出现必须强制回退到人工
- 设计证据展示：每个建议必须附带证据链和置信度

**输出**：放行决策（通过 / 附条件 / 拒绝）+ 审计规则清单

### 步骤 5：生产运行——让新故障和人工修正变成组织资产

**输入**：放行决策、生产环境配置

**执行要点**：
- 设计五层可观测性：基础设施层、模型性能层、业务效果层、用户行为层、价值发现层
- 建立反馈回灌机制：故障案例 → 知识库更新 → 模型优化
- 持续观测信号：故障分诊时间是否缩短？哪些建议最常被采纳？哪些故障模式最容易误判？哪些场景始终需要专家主导？
- 建立循环优化节奏：月度复盘 + 季度能力沉淀

**输出**：生产运行方案（含监控面板、反馈流程、优化节奏）

### 步骤 6：价值发现——识别和放大效率、组织与治理价值

**输入**：生产运行数据、业务目标

**执行要点**：
- 效率层价值：故障分诊、定位和交接速度提升
- 组织层价值：专家经验不再只留在少数人手里，新人也能借助系统完成高质量初步判断
- 治理层价值：团队开始更清楚地知道哪些场景可以自动辅助，哪些场景必须保留人工裁决
- 建立价值信号识别机制：MTTR 缩短、升级率下降、新人上手速度提升

**输出**：价值发现方案

## 示例 1：电商平台 AIOps 故障分诊系统

### 背景

某电商平台运维团队有 15 人，日均告警 200+ 条，大促期间峰值 1000+ 条。当前痛点：
- 值班工程师每天花 60% 时间在告警筛选和初步分诊上
- 高峰期告警风暴导致关键告警被淹没
- 故障定位平均耗时 45 分钟，其中 30 分钟在理解局面
- 专家经验只存在于 3 个资深工程师脑中

### Skill 执行输出

```yaml
# AIOps 案例方案：电商故障分诊

方向定界:
  核心问题: 告警风暴中的故障分诊是最高频、最重复、最值得先 AI 化的节点
  目标场景: 告警聚类 + 故障分诊 + 案例召回
  约束条件:
    - 响应时间: 分诊建议必须在 30 秒内返回
    - 风险边界: 所有建议仅供参考，禁止直接执行任何生产操作
    - 可解释性: 每个建议必须附带证据链
  Direction Brief: 优先将告警聚类和故障分诊 AI 化，目标 MTTR 缩短 40%

试验展开:
  能力实验:
    告警聚类:
      模型: 基于服务拓扑 + 时间窗口的聚类算法
      准确率: 92%（同类告警正确聚合）
      结论: 稳定可用
    日志解释:
      模型: LLM + 日志模板匹配
      准确率: 78%（关键字段正确提取）
      结论: 可用于辅助，需人工确认
    案例召回:
      模型: 向量检索 + 相似度排序
      准确率: 85%（Top3 命中历史案例）
      结论: 稳定可用，长尾案例需补充
  产品实验:
    值班面板原型: 告警聚合视图 + 分诊建议 + 案例推荐
    采纳率: 72%（值班工程师采纳分诊建议的比例）
  商业实验:
    MTTR 目标: 从 45 分钟缩短到 25 分钟
    ROI: 每次故障减少损失约 5 万元，月均 20 次故障 → 月节省 100 万元

系统构建:
  Agent 设计:
    值班 Agent: 接收告警 → 聚类分析 → 选择分诊 Skill → 组织建议
    分诊 Agent: 分析根因概率 → 推荐处置优先级
    知识库 Agent: 检索历史案例 → 推荐处置路径
  Memory:
    - 会话状态: 当前值班上下文
    - 故障上下文: 当前活跃故障链
    - 历史案例: 近 6 个月故障库（2000+ 条）
  Context:
    - 告警上下文: 服务名、时间窗口、告警级别
    - 服务拓扑: 上下游依赖关系（CMDB）
    - 业务影响: 订单量、支付成功率、页面 PV
  RAG:
    - 运维知识库: SOP 文档 50+ 篇
    - 历史故障库: 复盘报告 200+ 篇
    - 值班手册: 标准操作流程
  审计规则:
    - 低风险（自动辅助）: 告警聚类、日志摘要、案例推荐
    - 中风险（人工确认）: 根因建议、处置路径推荐
    - 高风险（禁止执行）: 任何直接操作生产的动作

审计放行:
  RAX 评估:
    风险: 中（错误建议可能导致排查方向偏移）
    接受度: 高（值班工程师反馈积极）
    体验: 中（需优化证据展示）
  放行条件: 附条件通过
  约束:
    - 所有分诊建议标注"仅供参考"
    - 置信度 < 70% 时必须标注"不确定，需人工确认"
    - 禁止任何直接操作生产的动作

生产运行:
  可观测性:
    - 基础设施: 推理延迟 < 5s，可用性 > 99.5%
    - 模型性能: 告警聚类准确率、分诊建议采纳率
    - 业务效果: MTTR、误判率、升级率
    - 用户行为: 建议查看率、采纳率、修改率
    - 价值发现: 故障处理效率趋势
  反馈回灌:
    - 每次人工修正 → 更新分诊规则
    - 每次新故障 → 沉淀到案例库
    - 每次误判 → 分析原因并优化模型
  循环优化:
    - 月度: 复盘误判案例，更新知识库
    - 季度: 评估能力分层，决定是否进入下一层
```

### 关键决策点

| 决策点 | 选择 | 理由 |
|--------|------|------|
| 第一批能力 | 告警聚类 + 故障分诊 | 高频、可比较、价值直接 |
| 自动处置时机 | 暂不进入 | 边界和回退机制尚未验证 |
| 人工接管设计 | 所有建议仅供参考 | 高风险场景，边界先于自动化 |
| 知识沉淀方式 | 案例库 + 规则库 + 反馈回灌 | 形成组织级能力资产 |

---

## 示例 2：金融行业 AIOps 运维知识系统

### 背景

某银行核心系统运维团队有 30 人，管理 500+ 微服务。当前痛点：
- 核心交易系统故障响应要求 5 分钟内定位
- 运维知识分散在 wiki、群聊、个人笔记中
- 新人培养周期 6 个月以上
- 专家经验难以传承，人员流动风险高

### Skill 执行输出

```yaml
# AIOps 案例方案：金融运维知识系统

方向定界:
  核心问题: 运维知识碎片化导致故障响应速度依赖个人经验
  目标场景: 运维知识沉淀 + 智能检索 + 分诊辅助
  约束条件:
    - 合规要求: 所有操作必须可审计
    - 安全要求: 数据不出生产网络
    - 响应要求: 核心系统故障 5 分钟内给出初步判断
  Direction Brief: 构建运维知识系统，将专家经验转化为可检索、可复用的组织能力

试验展开:
  能力实验:
    知识抽取:
      模型: LLM + 结构化模板
      准确率: 82%（从复盘报告中提取故障模式）
      结论: 可用，需人工审核
    智能检索:
      模型: 向量检索 + 关键词混合
      命中率: 88%（Top5 命中相关知识）
      结论: 稳定可用
    分诊建议:
      模型: 规则引擎 + LLM
      准确率: 75%（初步归因正确率）
      结论: 需配合专家确认
  产品实验:
    知识工作台: 故障模式库 + 检索 + 分诊建议
    使用率: 日均查询 50+ 次
  商业实验:
    新人培养周期: 从 6 个月缩短到 3 个月
    故障响应时间: 从 15 分钟缩短到 5 分钟

系统构建:
  Agent 设计:
    知识 Agent: 从复盘报告、SOP、群聊中抽取结构化知识
    检索 Agent: 理解运维问题 → 检索相关知识 → 组织答案
    分诊 Agent: 分析告警 → 匹配故障模式 → 推荐处置路径
  Memory:
    - 服务画像: 每个服务的历史故障、依赖关系、SLA
    - 专家画像: 每个专家擅长的领域和历史判断
  RAG:
    - 复盘报告库: 500+ 篇结构化复盘
    - SOP 库: 200+ 篇标准操作流程
    - 值班日志: 近 2 年值班记录
  审计规则:
    - 知识引用: 必须标注来源文档
    - 分诊建议: 必须附带历史案例支撑
    - 操作建议: 必须经过双人确认

审计放行:
  RAX 评估:
    风险: 高（金融系统，错误建议可能导致资金损失）
    接受度: 高（团队对知识系统需求强烈）
    体验: 中（检索准确率需持续优化）
  放行条件: 附条件通过
  约束:
    - 分诊建议仅用于辅助定位，禁止自动执行
    - 涉及资金操作的建议必须双人确认
    - 所有知识引用必须可追溯

生产运行:
  可观测性:
    - 知识覆盖率: 已沉淀故障模式占历史故障的比例
    - 检索准确率: Top5 命中率
    - 使用频率: 日均查询次数、活跃用户数
    - 业务效果: 新人培养周期、故障响应时间
  反馈回灌:
    - 每次新故障复盘 → 自动抽取并更新知识库
    - 每次检索未命中 → 标记知识缺口
    - 每次人工修正 → 更新分诊规则
  循环优化:
    - 月度: 知识覆盖率评估，补充缺口
    - 季度: 分诊准确率评估，优化模型
```

### 关键决策点

| 决策点 | 选择 | 理由 |
|--------|------|------|
| 第一批能力 | 知识沉淀 + 智能检索 | 解决知识碎片化核心痛点 |
| 分诊能力 | 辅助建议模式 | 金融场景风险高，暂不做自动分诊 |
| 知识来源 | 复盘报告 + SOP + 值班日志 | 结构化程度高，质量可控 |
| 审计要求 | 全链路可追溯 | 金融合规要求 |