AI 辅助运维：GenAI 在事件响应与排障中的实践

定位：AI 是值班工程师的副驾驶（Copilot），不是无人驾驶
  副驾驶做的事：把上下文整理好、给出假设与证据、推荐 runbook
  必须人做的：最终判断、执行变更、承担责任

AI 质量取决于喂给它的数据：
  告警（结构化） / 日志（半结构化） / 变更记录 / 监控时序 / 知识库 / 历史事件
先接好可观测性数据，再谈 AI；数据不全时 AI 只会"自信地胡说"

输入：告警 + 上下文（服务、环境、时间窗、相关指标）
输出：事件类型（故障/性能/容量/安全/配置变更引发）、
     影响面（哪些服务/用户）、优先级建议
价值：让正确的人第一时间被叫醒，而不是全群轰炸

把几十条告警 + 海量日志压缩成 5 行摘要：
  发生了什么 / 影响多大 / 何时开始 / 疑似源头 / 建议下一步
约束：摘要里每条结论都必须可回指证据（link 到原始告警/日志）

组装 Prompt 的关键：给模型"现场"，不给"作文题"
  时间窗内的告警列表 + 相关日志片段 + 近 30 分钟变更 + 服务拓扑
数据须脱敏：日志里的 token/密码/用户隐私在进模型前必须过滤

AI 产出"根因假设清单"而非"唯一结论"：
  假设 1：数据库连接池耗尽（证据：连接数时序 + 报错日志）
  假设 2：依赖服务超时（证据：拓扑 + 上游 P99 飙升）
  每个假设附置信度与证据链接，值班人按证据决策

值班人提问，AI 基于上下文回答：
  Q: "这个错误从几点开始？"  → A: 引用告警时间戳
  Q: "有相关变更吗？"        → A: 列出近 30 分钟变更记录
  Q: "之前遇到过吗？"        → A: 检索历史相似事件 + 当时的处置
答案必须带来源引用，禁止凭空给"可能是 XX 原因"

AI 通过工具调用（Function Calling）拉实时数据：
  get_metrics(service, range) / get_logs(query, window) /
  get_recent_changes(service) / get_dependencies(service)
让模型"用工具查"，而不是"背数据"，答案实时且可验证

RAG = 先检索后生成：从知识库/历史事件/runbook 召回相关片段，再让模型组织答案
  优势：答案基于内部资料，而不是模型训练时的公开记忆
落地：文档切片 → 向量化 → 存储（pgvector/ES）→ 查询时召回 top-k 片段

# runbook 结构化（概念）：让 AI 能按步骤理解
runbook:
  name: db-conn-pool-exhausted
  when: 连接池耗尽告警
  steps:
    - action: check
      cmd: show processlist
      expect: 大量 Sleep 连接
    - action: run
      cmd: kill <sleeping_conn>
      approval: on-call    # 高危动作需审批
    - action: verify
      cmd: 观察连接数与错误率恢复

知识库只给 AI 有权限访问的内容：按团队/密级隔离，防止敏感信息被"泄漏"进生成内容
文档要有 owner 与更新日期，过期文档召回时标注"可能过时"，避免按旧步骤操作

告警风暴的根因：一条故障引发几十条关联告警 + 重复告警
AI 降噪 = 聚类 + 去重 + 摘要：
  把同一根因的告警归成"一个事件"，保留一条主告警，其余折叠

# 概念：按服务/错误码/时间窗特征聚类告警
clusters = group_alerts(alerts,
    keys=["service", "error_code", "window(5m)"])
for c in clusters:
    promote_main_alert(c)          # 选主告警
    fold_related(c)                # 折叠关联告警

AI 判断"已知问题"：命中历史相似事件且正在处置 → 合并进现有事件单
AI 判断"明显噪声"（短时抖动、误配置探针）→ 自动标记，观察 15 分钟再升级
关键：降噪要可解释，每条被折叠的告警都能在事件详情里找回，不许静默丢

幻觉 = 模型输出看似合理但无依据的内容，运维场景后果严重
对策：
  1. 只允许基于召回证据回答（证据不足 → 明确说"资料不足"）
  2. 强制答案附来源引用，无引用断言 = 无效输出
  3. 敏感/高危建议必须人工确认，不得自动执行
  4. 对输出做"事实核查"：关键断言用工具回查监控/日志验证

模型调用链安全：
  - 模型 API 走私有网络/网关，密钥不入代码，用 Secret 管理
  - 输入日志可能含 Prompt 注入：攻击者写日志诱导模型输出危险指令
    对策：日志内容降权（只作为"数据"不作为"指令"），系统指令固定且不可被覆盖
  - 输出过滤：不展示凭证、密钥、PII，脱敏层在模型前后都部署

每次 AI 交互留审计：Prompt（脱敏）、召回片段、输出、采纳/拒绝结果
高危建议（重启、杀连接、变更配置）必须二次确认，确认记录可追溯

AI 可以把"候选处置方案"排好序，但执行必须走标准流水线：
  变更 → 审批 → 灰度 → 审计，与普通变更同一套流程
价值：AI 提速"发现问题与确定方案"，人负责"批准与执行"，职责清晰

允许 AI 自动执行的前置条件（建议满足后再试点）：
  评估集上连续 N 周正确率达标 / 有自动回滚保护 / 全量动作可审计可回退 /
  高影响动作仍强制人工。多数团队停留在"建议层"就已足够

用历史 200 个事件做标注集：真实摘要/分类/根因，作为回归基线
每次改 Prompt 或换模型，先在评估集上跑分，再决定是否上线

月度：用"未采纳案例"复盘，找出 AI 答错的地方 → 补知识库/调 Prompt
告警降噪单独看：误折叠（把真故障折叠掉）是红线，宁可少折不可错折

某交易平台（概念案例）：日均 1.2 万条告警，值班人 70% 时间在做信息拼图
改造：告警聚类降噪（折叠 65%）+ RAG 接 runbook + 事件摘要 + 根因假设
效果：事件处理前置时间从 25 分钟降到 6 分钟；MTTR 下降 40%；
      一次 DB 故障，AI 在 1 分钟内给出连接池耗尽假设 + 证据链，值班人确认后走审批执行

□ 定位为 Copilot：AI 给证据与建议，人做判断与执行
□ 事件分类/摘要/降噪优先落地，变更执行暂不自动化
□ 上下文组装：告警+日志+变更+拓扑，进模型前脱敏
□ RAG 接知识库与 runbook，答案强制附来源引用
□ 幻觉控制：证据不足说"资料不足"，无引用断言无效
□ 调用安全：密钥管理、Prompt 注入防护、输出脱敏
□ 高危建议人工确认，状态变更走标准变更流水线
□ 用评估集回归，幻觉率 <2%、降噪不误折真故障
□ 每次交互留审计，复盘未采纳案例迭代