// AI Native 产品方法论——AIOps 行业案例模板 Skill。 用户提供 AIOps 场景和业务背景，Skill 自动执行全链路方法论： 方向定界 → 试验展开 → 系统构建 → 审计放行 → 生产运行，输出完整案例方案。 基于《AI Native 产品方法论》第19章 AIOps 案例，适用于高风险、强约束、重责任场景。
[HINT] Download the complete skill directory including SKILL.md and all related files
| 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 |
| stage | p10b |
| homepage | https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p10b-aiops-case |
| AIOps 特征 | 对方法论的影响 |
|---|---|
| 高风险：错误建议直接导致故障扩大 | 必须有强审计放行和人在回路机制 |
| 知识密集：依赖专家经验 | 需要知识沉淀和检索增强 |
| 实时性强：响应时间要求高 | 模型延迟必须纳入评估 |
| 可解释性：决策必须可追溯 | 上下文工程和日志是基础设施 |
| 责任边界清晰：谁决策谁负责 | Agent 边界设计是核心 |
@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
→ 价值信号识别与反馈
→ 输出：价值发现方案
```yaml
方向定界: 核心问题: [选择最值得先 AI 化的运维节点] 目标场景: [故障分诊 / 告警处理 / 日志分析 / 容量规划] 约束条件: [响应时间要求 / 风险边界 / 可解释性要求] Direction Brief: [输出]
试验展开: 能力实验: - 日志解释: [模型/准确率/结论] - 告警聚类: [模型/准确率/结论] - 案例召回: [模型/准确率/结论] 产品实验: - 值班面板原型 - 采纳率/满意度 商业实验: - MTTR 缩短目标 - ROI 测算
系统构建: Agent 设计: - 值班 Agent - 分诊 Agent - 知识库 Agent Memory: [会话状态 / 故障上下文 / 历史案例] Context: [告警上下文 / 服务拓扑 / 业务影响] RAG: [运维知识库 / SOP / 历史故障库] 审计规则: [风险等级 / 升级条件 / 人工接管点]
审计放行: RAX 评估: [风险/接受度/体验评分] 放行条件: [通过/附条件/拒绝] 约束: [高风险动作必须人工确认]
生产运行: 可观测性: [五层观测设计] 反馈回灌: [故障案例 → 知识库更新] 循环优化: [月度复盘 + 季度能力沉淀] ```
AIOps 最值得先改写的不是"最终执行动作"，而是"高频、重复、信息密集的故障分诊与判断链"。故障分诊同时满足四个条件：高频、重复、可比较、价值直接。系统能更快做出初步判断，值班工程师就能缩短定位时间、减少无效升级，并把注意力放到真正高风险的信号上。
AIOps 系统应按风险等级分三层递进建设：
AIOps 输出的不应该只是一个"可能原因"，还应该包含：基于什么证据、建议优先看哪些线索、是否命中历史故障模式、以及什么情况下必须升级人工。没有证据链的 AIOps 充其量只是一个生成式分析器。
过去分散在群聊、个人习惯和少数专家脑中的判断逻辑，应被写进案例库、规则系统和反馈回路里。每一次新故障、每一次人工修正、每一次升级路径变化，都会反过来让系统更懂本组织真实的运行环境。AIOps 的长期价值不只是"帮人快一点看日志"，而是把值班体系从依赖少数人，逐步推进到依赖组织能力。
AIOps 场景最大的特点，是错误代价往往远高于一般信息类产品。一次错误归因可能让工程师沿错误方向排查半小时；一次错误建议可能触发错误扩容或重启；一次边界失守可能把局部问题放大成跨服务事故。因此，审计放行不是附加动作，而是产品成立的一部分。
输入：运维团队现状、历史故障工单、监控体系、值班流程
执行要点：
输出：Direction Brief（含目标场景、风险边界、响应时间要求、可解释性要求）
输入：Direction Brief、历史样本、评估标准
执行要点：
输出：能力实验报告（含各故障模式的准确率、召回率和置信度分析）
输入：试验结论、可用数据源、系统架构约束
执行要点：
输出：系统架构方案（含 Agent 设计、Skill 清单、Tool 映射、升级路径）
输入：系统架构方案、风险评估标准
执行要点：
输出：放行决策（通过 / 附条件 / 拒绝）+ 审计规则清单
输入：放行决策、生产环境配置
执行要点：
输出：生产运行方案（含监控面板、反馈流程、优化节奏）
输入：生产运行数据、业务目标
执行要点：
输出：价值发现方案
某电商平台运维团队有 15 人，日均告警 200+ 条，大促期间峰值 1000+ 条。当前痛点：
# 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、误判率、升级率
- 用户行为: 建议查看率、采纳率、修改率
- 价值发现: 故障处理效率趋势
反馈回灌:
- 每次人工修正 → 更新分诊规则
- 每次新故障 → 沉淀到案例库
- 每次误判 → 分析原因并优化模型
循环优化:
- 月度: 复盘误判案例，更新知识库
- 季度: 评估能力分层，决定是否进入下一层
| 决策点 | 选择 | 理由 |
|---|---|---|
| 第一批能力 | 告警聚类 + 故障分诊 | 高频、可比较、价值直接 |
| 自动处置时机 | 暂不进入 | 边界和回退机制尚未验证 |
| 人工接管设计 | 所有建议仅供参考 | 高风险场景，边界先于自动化 |
| 知识沉淀方式 | 案例库 + 规则库 + 反馈回灌 | 形成组织级能力资产 |
某银行核心系统运维团队有 30 人，管理 500+ 微服务。当前痛点：
# 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 + 值班日志 | 结构化程度高，质量可控 |
| 审计要求 | 全链路可追溯 | 金融合规要求 |