AIOps 告警归因中的提示工程：从能用到可上生产（4 阶梯）

适用对象：做生产运维 / SRE / 平台工程 / ITSM 流程治理的团队，想把 LLM 用在 告警归因（Root Cause Analysis, RCA） 上，并且做到“可控、可复用、可评测”。

---

1. 背景：为什么 AIOps 归因需要提示工程

在 AIOps 语境里，“告警归因”通常不是单点推理，而是对以下信息做证据链整合：

• 监控与告警：AppDynamics（APM/Trace/Health Rule）
• 日志：Splunk（异常模式、时间分布、关键字统计）
• 流程与变更：ServiceNow（变更/发布/事件、关联 CI）
• 配置与依赖：CMDB（service ↔ CI ↔ owner ↔ site、上下游依赖拓扑）

LLM 能把碎片信息快速汇总成“可执行的排查路径”，但如果提示不够严谨，容易出现：

• 结论拍脑袋（缺证据、幻觉）
• 输出结构不稳定（难写回 ITSM、难自动化）
• 变更后回归（prompt 一改，效果不可控）

提示工程（Prompt Engineering）的目的不是“写得更像人”，而是让 LLM 在你的业务流程里表现得像一个可控的组件：有输入契约、有输出契约、有失败策略、有可评测指标。

---

2. 提示工程 4 阶梯总览（从最简单到最严谨）

下面四个层次并非互斥，而是逐步增强“可控性”和“可工程化程度”。

1. 入门版：把提示当成“会说话的需求说明”
2. 进阶版：把提示当成“可控对话流程”，用结构化稳定输出
3. 专业版：把归因当成“API”，输出 JSON 契约便于系统集成
4. 严谨版：把提示当成“可实验、可回归的系统工程”（评测集 + 指标 + A/B）

---

3. 通用 Prompt 骨架（强烈建议先统一团队口径）

你后续无论做告警归因、事件复盘、变更评审，都可以沿用这个骨架。

• Role：模型扮演的专业身份（SRE / AIOps 分析器 / 值班工程师）
• Objective：本次任务（归因 + 验证路径 + 行动建议）
• Context：输入材料（告警 payload、APM/日志/变更/CMDB）
• Rules：硬约束（不得臆测、必须引用证据、信息不足要拒答）
• Output：固定结构（Markdown 或 JSON Schema）
• Quality Checklist：输出前自检（证据覆盖、格式合规、owner 明确）

---

4. AIOps 告警归因：4 阶梯提示模板（可直接复制粘贴）

4.1 入门版：一条提示得到“可读的初步归因”

适用场景

• 你只想把“告警消息”快速变成“可执行排查清单”
• 输入信息不完整也没关系，需要模型告诉你“缺什么”

Prompt

你是AIOps值班SRE。请对下面告警做初步归因（不要臆测；只基于输入）。输出必须包含：
1) 现象摘要（1-2句）
2) 最可能根因（Top 1）+ 置信度（low/medium/high）+ 证据（来自输入的要点）
3) 备选原因（Top 2-3）
4) 建议的下一步排查（按优先级列出，包含要查的系统：AppDynamics/Splunk/ServiceNow/CMDB）
5) 若信息不足，明确写 INSUFFICIENT_CONTEXT 并列出缺少的3-5项信息

【告警输入】
- 告警名称：
- 触发时间（含时区）：
- 服务/应用：
- CI/主机/Pod（如有）：
- 指标与阈值：
- 影响面（用户/区域/站点）：
- 近期变更/发布（如有）：
- 相关日志/trace摘要（如有）：

---

4.2 进阶版：结构化提示，让输出更稳定、更像“值班手册”

核心增强

• 强制走“证据 → 假设 → 反证 → 验证路径”的链路
• 用枚举类目控制输出口径，降低“甩锅式叙述”

Prompt（分块 + 明确约束）

【ROLE】
你是AIOps事件归因分析器（偏保守），目标是“先证据、后结论”，不允许编造事实。

【TASK】
对本次告警做归因分析并给出行动建议。你必须按以下步骤在心中完成（不要展示推理过程），然后输出结果：
A. 识别症状（symptom）与可能原因（cause）的区别
B. 生成 3 个候选根因假设（Hypotheses）
C. 为每个假设列出“支持证据/反证/需要补证据”
D. 选择Top1根因，并给出最短验证路径（2-5步）

【CONTEXT】
1) Alert Payload:
- name:
- time:
- service:
- severity:
- metric:
- threshold:
- entity (CI/pod/host):
2) AppDynamics 摘要（如有）:
- health rule / BT / error rate / latency / top exceptions:
3) Splunk 摘要（如有）:
- 错误关键字统计、最频繁异常、时间分布:
4) ServiceNow 摘要（如有）:
- 近24h变更/发布/事件/关联CI:
5) CMDB 摘要（如有）:
- service->CI依赖、owner、site、上下游:

【RULES】
- 只能基于CONTEXT，不得引入外部“常识性事实”当作已发生事件
- 每条结论必须附“证据点”（引用输入中的字段或摘要）
- 输出必须包含：root_cause_category（从枚举中选）与confidence
- root_cause_category 枚举：
  {Deployment/Change, CodeDefect, DependencyDown, InfraHost, Kubernetes, Network, Database, Capacity, Config, ObservabilityNoise, Unknown}

【OUTPUT（Markdown）】
## 1. Summary
## 2. Top Hypothesis (Root Cause)
- category:
- confidence:
- evidence:
- quickest verification steps:
## 3. Alternative Hypotheses
## 4. Next Actions (Owner-aware)
- owner（来自CMDB，如缺失写unknown）:
- action list:
## 5. Missing Context (if any)

---

4.3 专业版：把归因当成“API”，输出 JSON 契约以便自动化

核心增强

• 输出为机器可消费的 JSON，便于：
  • 写回 ServiceNow（更新事件描述/建议/关联 CI）
  • 触发 runbook 自动化
  • 做归因统计与 SLO/MTTR 关联分析

Prompt（JSON Schema + 错误码策略）

你是AIOps RCA 引擎。只输出 JSON，必须严格符合下面 schema。不要输出任何额外文本。

【约束】
- 只使用输入数据；不允许推测“发生了某次发布/某次故障”，除非输入明确提供
- evidence 必须引用输入中的具体字段路径（例如 "AlertPayload.metric" 或 "SplunkSummary.top_errors[0]"）
- 如果无法给出 Top1 根因，root_cause.category = "Unknown"，并填 reasons + missing_context

【输入】
AlertPayload = {...}
AppDynamicsSummary = {...}
SplunkSummary = {...}
ServiceNowSummary = {...}
CMDBSummary = {...}

【输出 JSON Schema】
{
  "incident_scope": {
    "service": "string",
    "entity": "string|null",
    "site": "string|null",
    "start_time": "string",
    "severity": "string"
  },
  "symptoms": [
    {"signal": "metric|log|trace|event", "description": "string", "evidence": ["string"]}
  ],
  "root_cause": {
    "category": "Deployment/Change|CodeDefect|DependencyDown|InfraHost|Kubernetes|Network|Database|Capacity|Config|ObservabilityNoise|Unknown",
    "title": "string",
    "confidence": "low|medium|high",
    "reasons": ["string"],
    "evidence": ["string"]
  },
  "hypotheses_ranked": [
    {
      "rank": 1,
      "category": "same as above",
      "hypothesis": "string",
      "supporting_evidence": ["string"],
      "counter_evidence": ["string"],
      "verification_steps": ["string"]
    }
  ],
  "recommended_actions": [
    {
      "priority": "P0|P1|P2",
      "action": "string",
      "owner": "string|null",
      "system": "AppDynamics|Splunk|ServiceNow|CMDB|K8s|Other",
      "expected_outcome": "string"
    }
  ],
  "missing_context": ["string"],
  "automation_hints": {
    "splunk_queries": ["string"],
    "appd_views": ["string"],
    "servicenow_lookups": ["string"]
  }
}

---

4.4 严谨版：可评测、可回归的“归因系统工程”

核心增强

• 不是“写 prompt”，而是做一套小型研发体系：
  • Prompt-as-Code（版本管理、变更记录）
  • 评测集（真实历史事件样本）
  • 指标体系（幻觉率、证据覆盖率、合规率）
  • A/B 测试与回归门槛

4.4.1 更严格的“拒答阈值 / 置信度规则”

在 4.3 的 JSON 输出基础上，增加硬规则：

• 若 Top1 根因没有 ≥ 2 个独立信号源 支持（例如 metric+log / trace+change），则 confidence 不得为 high
• 若 evidence 为空或仅有单一弱证据，必须输出：
  • root_cause.category = "Unknown"
  • 并把缺少信息写进 missing_context

---

5. 推荐的“归因输入包”格式（把数据喂得对，模型才会稳）

为减少信息缺口，建议你组织成统一输入包，至少包含：

• AlertPayload：告警原文 + 关键字段（service/entity/metric/threshold/severity/time）
• 时间窗：建议 T-30m ~ T+30m 的指标摘要（错误率/延迟/吞吐/饱和度）
• AppDynamics：Top BT、Top Exceptions、依赖调用失败分布
• Splunk：Top error patterns + 时间直方图 + 新增异常类型
• ServiceNow：近 24h 变更/发布（关联CI）、相关事件/发布窗口
• CMDB：服务依赖拓扑（上下游）、owner、site、重要性/SLO

---

6. 两个关键流程图（Mermaid，可直接放进 Markdown）

6.1 告警归因（RCA）最小闭环

6.2 Prompt 工程化迭代（Prompt-as-Code + 评测）

---

7. 指标体系（含数学公式，便于评测与验收）

在 AIOps 归因里，你往往更关心 “证据是否真实存在” 和 “输出是否可执行”，而不仅是“类别命中率”。

7.1 常用指标定义

(1) 归因类别命中率（Category Accuracy）

若你对每个样本标注了真实根因类别，则：

Accuracy=∣{ i∣y^i=yi }∣N \mathrm{Accuracy} = \frac{\left|\{\, i \mid \hat{y}_i = y_i \,\}\right|}{N} Accuracy=N∣{i∣y^​i​=yi​}∣​

其中：

• $y_i$：真实类别
• ${\hat{y}}_i$：模型预测类别
• $N$：样本数

(2) 证据精确率（Evidence Precision）

定义为：模型输出的 evidence 中，有多少条 确实能在输入中找到（防幻觉核心指标）。

$$\mathrm{EvidencePrecision}=\frac{\left|E_{out}\cap E_{in}\right|}{\left|E_{out}\right|}$$

其中：

• $E_{out}$：输出 evidence 集合
• $E_{in}$：输入可核验证据集合（字段/片段/ID）

(3) 证据覆盖率（Evidence Coverage）

是否满足你的工程门槛，例如“Top1 根因至少 2 条证据，且来自两个独立信号源”。

$$\mathrm{Coverage}=\frac{1}{N}\sum _{i=1}^{N}1\left(\left|{\mathrm{Evidence}}_i\right|\ge 2\wedge \left|{\mathrm{Signals}}_i\right|\ge 2\right)$$

其中：

• ${\mathrm{Evidence}}_i$：样本 $i$ 的证据集合（或证据条目列表）
• ${\mathrm{Signals}}_i$：样本 $i$ 的独立信号源集合（如 metric/log/trace/event）
• $1(\cdot )$：指示函数，条件成立取 1，否则取 0
• $N$：样本数

(4) 结构合规率（Schema Compliance）

JSON 是否可解析、字段齐全、枚举合法（结构层面的硬指标）：

Compliance=∣{ i∣JSONi is valid }∣N \mathrm{Compliance} = \frac{\left|\{\, i \mid \mathrm{JSON}_i\ \text{is valid} \,\}\right|}{N} Compliance=N∣{i∣JSONi​ is valid}∣​

其中：

• ${\mathrm{JSON}}_i$：样本 $i$ 的模型输出 JSON
• “is valid”：表示可解析且满足 schema/枚举/必填字段等约束
• $N$：样本数

7.2 建议的验收门槛（可作为 PoC Exit Criteria）

• Schema Compliance ≥ 99%
• Evidence Precision ≥ 95%（或更高，视风险等级）
• Coverage（≥2 证据且≥2信号源）≥ 80%（可逐步抬高）
• Actionability（人工评分 1–5）平均 ≥ 4

---

8. 常见坑与最佳实践（面向生产落地）

8.1 常见坑

• 只写“帮我归因”：没有结构与边界，输出不可控
• 没有拒答策略：信息不足时模型会“编一个最像的”
• 没有证据引用：无法审计，难以被 on-call 接受
• 输出不可机读：无法写回 ITSM，无法触发 runbook
• 没有评测集：prompt 改动后效果靠感觉，回归无法发现

8.2 最佳实践

• 先用进阶版（Markdown 结构）跑通流程，再升级专业版（JSON 契约）
• 强制 evidence 引用输入字段路径（可审计、可自动验证）
• 设定置信度规则：证据不足即 Unknown
• Prompt-as-Code：版本化、变更记录、回归测试门槛
• 逐步引入 few-shot 示例：先解决“结构稳定”，再解决“准确率提升”

---

9. 附录：一页速查（你可以贴在团队 Wiki）

9.1 最小输入包（Checklist）

• AlertPayload（service/entity/metric/time/severity）
• AppDynamics 摘要（Top BT/Exceptions/依赖失败）
• Splunk 摘要（Top errors/时间分布/新增异常）
• ServiceNow（近24h变更/关联CI/发布窗口）
• CMDB（owner/site/依赖拓扑）

9.2 最小输出包（Checklist）

• Top1 根因 + 类别枚举 + 置信度
• ≥2 条证据（最好来自 ≥2 信号源）
• 最短验证路径（2–5 步）
• Owner-aware 行动清单（可落地、可分派）
• 信息不足时：Unknown + Missing Context

---

10. 下一步建议（如何把它接到你的 AIOps Pipeline）

如果你已经有 ServiceNow + AppDynamics + Splunk + CMDB，常见落地路线是：

1. 事件触发：告警进入（AppDynamics → 事件总线 / ITSM）
2. 上下文聚合：按 service/entity/time window 拉取 APM/日志/变更/CMDB
3. 调用 LLM（RCA Prompt vN）：输出 JSON 契约
4. 自动写回：更新 ServiceNow 事件描述、建议、owner、关联 CI
5. 验证与闭环：人工确认/自动 runbook → 结果回写形成评测样本

（在高风险系统里，建议将 LLM 定位为“建议生成器”，最终决策由 on-call 或规则引擎把关。）

---

完