导语：
近期很多团队在尝试让大模型成为“运维副驾”。要把 AIOps 助手用在生产，难点不在“能不能回答”，而在“是否可验证、可审计、可控执行”。本文提供一套可执行方案：观测对话、自动化 Runbook、执行安全门禁、可验证评测，并附核查清单。
1. 目标与指标
- 正确性：告警归因/建议的命中率、误报率、覆盖率。
- 时效：从告警到建议/执行的 P95 时长。
- 安全：越权/误执行次数=0；高危动作必须二次确认。
- 审计：每次对话/执行可回放，带证据包。
2. 观测对话：上下文就是证据
- 对话上下文绑定告警/Trace/日志链接，带时间窗与过滤条件。
- 结构化存储：
trace_id,alert_id,service,version,region。 - 提示模板强制“引用驱动”：必须引用具体指标/日志片段后再下结论。
3. 自动化 Runbook
- Runbook 模板：触发条件、诊断查询、处置步骤、回滚步骤、验证口径。
- 将 Runbook 作为工具暴露给助手，参数白名单+正则校验。
- 高危 Runbook（重启/扩容/清理/回滚）默认需要人工确认或双人审批。
4. 安全门禁与权限
- 执行沙箱：限制网络/文件/时间，必要时在隔离容器执行。
- 权限分级：只读查询与变更分离；变更动作单独凭证且短时有效。
- 预算与频控：对诊断/执行设频次与成本上限，超限自动拒绝。
5. 评测与门禁
- 评测集：高频告警、Top 事件类型、跨服务依赖问题、误报易发场景。
- 离线评测：合并前/每日定时跑，生成通过率与失败 Top。
- 影子评测：线上抽样影子执行，评分但不落地。
- 门禁阈值：正确率/引用覆盖/无引用断言/越权尝试，未达标降级为只读建议。
6. 证据包（Evidence Pack）字段
- 对话：
request_id/alert_id/trace_id/user/role - 引用：指标/日志/Trace 链接与时间窗
- 决策：结论、信心水平、引用覆盖
- 执行动作：Runbook 名、参数、退出码、耗时、审核人
- 评测：离线/影子得分、阈值、动作（放行/降级/阻断）
7. 一周落地SOP
- Day1：定义字段/模板，准备评测集与 Runbook 白名单。
- Day2：接入对话观测与证据包；跑离线评测。
- Day3：上线影子评测与看板，设置告警-对话链路。
- Day4：接入执行沙箱与权限分级；验证频控与预算。
- Day5-6：灰度 1%-10%-50%，覆盖峰值；记录差异报告。
- Day7：输出评测/性能/安全报告，形成改进项与责任人。
8. 风险提示
- “看似正确”但无引用：必须做引用覆盖/断言校验。
- 越权执行：高危 Runbook 默认人工确认；凭证短时有效。
- 成本与频控：日志/Trace 查询易爆成本，需预算与限频。
结语：
让 AIOps 助手真正可用，核心在“证据化、门禁、可回放”。按照上述流程落地，既能减轻值班压力，又能保持安全与可追责。
9. 补充：运行看板
- 质量看板：归因正确率、建议采纳率、失败 Top 告警类型。
- 效率看板：告警→建议/执行的 P95 时长、自动化执行比例。
- 安全看板：越权尝试、执行拒绝、手工确认率、成本超限次数。
- 例外管理：高危操作的例外审批必须有期限与责任人，到期自动提醒。
