自然语言驱动的故障诊断实践
本文介绍如何通过智能会话，使用自然语言与数字员工（Agent）进行多轮对话，完成从告警发现到根因定位的完整故障诊断流程。文中包含云监控（CMS）入口和日志服务（SLS）入口两种场景的对话示例，以及 AI 回答不理想时的追问技巧。
业务场景
收到告警通知或发现系统异常时，需要快速定位问题根因。传统方式需要手动查询多个监控系统、日志平台和拓扑图，效率低且容易遗漏关联信息。STAROps 智能会话支持用自然语言描述问题，数字员工会自动关联多源数据进行分析，将故障诊断的时间从数十分钟缩短至几轮对话。
方案架构
故障诊断流程涉及以下核心环节：
问题输入：通过云监控（CMS）智能助手或日志服务（SLS）智能助手发起对话，描述告警内容或异常现象。
数据关联：数字员工根据问题描述，自动查询 Prometheus 指标、SLS 日志、拓扑关系等多源数据。如果使用了 @实体引用，数字员工会以该实体为起点展开分析。
多轮推理：基于首轮分析结果，数字员工可能提出进一步的检查方向。通过追问可以引导分析向特定维度深入。
根因输出：输出包含异常指标、日志证据和拓扑关联的根因分析报告，并给出修复建议。
实施步骤
环境确认
在开始故障诊断前，确认以下环境已就绪：
检查项 | 确认方式 |
数字员工已创建 | 在STAROps 控制台侧边栏单击数字员工管理，确认目标数字员工状态正常。 |
工作空间已接入可观测数据 | 在工作空间详情页确认已接入指标（Prometheus）、日志（SLS）等数据源。 |
可观测模型（UModel）已配置 | 在对话框中输入 |
数字员工已配置默认规则（推荐） | 配置默认规则可显著提升诊断质量。具体操作参见打造专属运维智能体。 |
场景一：通过云监控（CMS）入口进行故障诊断
云监控智能助手支持 @实体引用，适合从告警出发、沿拓扑关系逐步排查的场景。
使用 @实体引用
在对话框中输入 @，系统会弹出工作空间中的实体列表。实体类型包括集群（Cluster）、节点（Node）、服务（Service）、Pod 等，具体取决于可观测模型（UModel）的配置。
选择目标实体后，数字员工会以该实体为分析起点，自动关联其上下游拓扑和关联指标。
对话示例：Pod 异常重启排查
以下是一个完整的多轮对话示例，展示如何从一条 Pod 重启告警出发，逐步定位根因。
第 1 轮：描述问题
@Service:order-service 最近 1 小时内有 Pod 频繁重启，帮我分析一下原因。数字员工将自动执行以下操作：
查询 order-service 关联的 Pod 列表和重启次数。
检查重启 Pod 的容器退出码和最近日志。
分析 Pod 的资源使用趋势（CPU、内存）。
第 2 轮：深入追问
如果首轮分析显示 OOMKilled，可以继续追问：
帮我看看这个 Pod 的 JVM 堆内存使用趋势，以及最近是否有大查询请求。数字员工会进一步查询 JVM 指标和请求日志，定位内存泄漏或大查询导致的 OOM。
场景二：通过日志服务（SLS）入口进行故障诊断
日志服务智能助手擅长从日志维度切入分析，适合错误日志激增、请求延迟异常等场景。
对话示例：错误日志激增排查
第 1 轮：描述问题
payment-service 从 14:00 开始出现大量 500 错误，帮我排查原因。数字员工将自动执行以下操作：
查询 payment-service 在 14:00 前后的错误日志分布。
按错误类型分类统计，提取高频异常堆栈。
关联上游调用链，检查是否存在级联故障。
第 2 轮：验证修复
我已经重启了数据库连接池，帮我确认 payment-service 的错误率是否恢复正常。数字员工会对比修复前后的错误率趋势，确认问题是否解决。
追问技巧：提升 AI 诊断效果
当 AI 首轮回答不够深入或方向偏差时，可以通过以下追问策略引导分析方向：
场景 | 追问示例 | 预期效果 |
分析不够深入 | "请从 JVM、连接池和下游依赖三个维度分别分析。" | 引导 AI 从多维度展开分析，避免单一视角。 |
方向偏差 | "问题不在网络层，重点看应用层的错误日志。" | 纠正分析方向，避免在无关维度上浪费时间。 |
缺少上下文 | "这个服务在今天 14:00 刚做过一次发布，镜像版本从 v2.3.1 升级到 v2.4.0。请结合这个变更重新分析" | 主动补充 AI 无法自动获取的业务上下文（如发布记录、配置变更等）。 |
需要时间对比 | "对比一下昨天同时段和今天的指标差异。" | 通过基线对比发现异常偏移。 |
需要拓扑分析 | "检查 order-service 的上下游服务是否也有异常。" | 沿拓扑关系追踪级联故障源头。 |
验证修复效果 | "我已经扩容了 Pod 副本数，帮我确认延迟是否下降。" | 实时验证修复措施是否生效。 |
诊断结论的输出格式
诊断完成后，您可以要求 AI 输出结构化的诊断结论。推荐使用以下 prompt：
请汇总刚才的分析，输出一份结构化的诊断报告，包含根因、影响范围、级联关系和建议操作。
AI 通常会输出如下格式的结论：
故障诊断报告
根因
pod-storage-02 因内存 Limit 配置过低（2GiB）触发 OOM Killed。
影响范围
- 直接影响：service-storage 可用 Pod 从 3 个降至 2 个。
- 间接影响：上游 pod-data-processor 触发重试风暴，node-03 CPU 飙升至 92%。
级联故障链
pod-storage-02 OOM → service-storage 延迟上升 → pod-data-processor 重试风暴 → node-03 CPU 飙升
建议操作
1. [立即] 调整 pod-storage-02 内存 Limit 至 4GiB。
2. [立即] 确认 pod-storage-02 是否已恢复。
3. [短期] 为 service-storage 配置 PDB（minAvailable=2）。
4. [长期] 为 pod-data-processor 配置指数退避重试策略。
从诊断到持续跟踪
如果诊断发现的问题需要持续关注，您可以通过创建长期任务（Mission）进行自动化监控：
帮我创建一个长期任务，每天巡检 service-storage 的内存使用情况和 Pod 健康状态，如果发现 OOM 风险立即通知我。
AI 会引导您完成 Mission 的创建和蓝图规划。详细操作请参见创建与规划长期任务。