报告写完不等于根因对：STAROps 把 30 个故障拆开打分

报告写完不等于根因对：STAROps 把 30 个故障拆开打分

阿里云原生社区在 2026-09-16 介绍了 STAROps。它是一套面向生产的 AgenticOps 框架，AgenticOps 指把巡检、排查和变更交给智能体。文章认为根因分析才是核心：根因错了，影响评估、修复建议和变更执行都会打在错误对象上。智能体只能给建议时，错的根因浪费工程师时间；智能体有权动手时，错的根因就是生产风险。

告警通常只说明哪个指标越过阈值，不说明故障从哪开始。前端 5xx 可能是前端代码，也可能是下游数据库变慢、缓存不可用、节点资源耗尽或刚改过配置。把节点资源问题当成容量不足，扩容的 Pod 仍会落在坏节点上。把慢 SQL 当成前端缺陷，回滚也改不了结果。

概念验证盖不住没见过的故障

团队验证根因分析时，常拿崩溃循环的 Pod、慢 SQL 或 Redis 中断这几类已知故障，看系统是否给出预期答案。文章认为这只证明场景 A、B、C 能跑通，不能证明出现故障类型 D 时知道从哪查起。如果每种告警都预先写好 Skill 或工作流，查询顺序和答案都是事先指定的，换一种告警入口，这条路径就可能失效。Skill 适合作为排查线索和检查清单，不应当划定根因分析的边界。

生产故障没有固定剧本。问题可以出在应用、容器、节点、数据库、缓存或网络，也可以跟在发布、扩缩容或配置变更后面。同一条告警可以有完全不同的原因，同一个根因也可以在不同系统里触发不同告警。根因在数据库，告警却打在前端；根因在节点，用户先看到的却是业务接口流量下降。

文章给的可泛化标准不是「模型事先知道每一种故障的答案」。没有完全匹配的工作流时，智能体仍要能开工：先认出告警指向的实体，再沿关系找到相关服务和资源；出现多个候选时继续取证、核对事件顺序，排除解释不了症状的假设；证据不够就停，而不是硬给一个根因。

先统一对象，再记下查过哪里

很多排查在第一步就错，因为同一对象在不同系统里名字不同。应用性能管理里它是服务，链路里它是一组 span，Kubernetes 里它是 Deployment 和 Pod，再往下是 ECS 实例或节点。日志、指标和变更记录用的字段也不一样。只靠名字匹配，容易把一个对象拆成几个，或把邻居当成根因。

UModel 是阿里云用来记下这些对象和关系的模型：哪些 Pod 跑着这个服务、属于哪个 Deployment、落在哪个节点、依赖哪些数据库，以及指标、日志和链路去哪查。智能体提出假设、解释证据；UModel 提供一张稳定的系统地图。

控制台拓扑只显示对象和依赖。排查还要记下哪些对象已经查过、哪里发现异常、哪些候选仍被怀疑、哪些分支还没解释。STAROps 在 UModel 之上维护一张动态排查拓扑。从告警实体出发，证据增加就扩展；候选被排除，这条分支就停。同一节点上多个 Pod 同时变差，排查就收到宿主机；数据库连接变慢，就去查 SQL、连接池和上下游链路。指标、日志、链路、事件和变更挂在对应对象上。候选根因连同支持和反对的证据一起留下。

用基准揭穿看起来对的答案

只看最终报告，很难分辨智能体是顺着证据走到根因，还是从告警表面症状猜了一个常见答案。所以 RCA-Bench 不只记一个根因标签。公开集 RCA-100 有 103 个故障案例，分 6 大类、28 种故障类型。每个案例记录根因实体、故障类型、传播路径和关键证据。环境可以查询，智能体必须自己决定先看什么、下一步去哪。

评测拆成三件事：找没找到正确的根因实体，认没认出正确的故障类型，排查有没有证据支撑。前两项主要根据 UModel 里的实体关系和故障类型关系打分。确定性规则目前大约占总分的 82%。大模型只帮助判断排查方向和证据是否充分，避免一个模型对另一个模型的分数有完全决定权。

离线基准只能说明能力在不在。生产里还有权限、数据接入、客户自己的拓扑和版本差异。离线分高，仍可能因为取不到数据、选错工具或过早收敛而失败。STAROps 保留生产运行的任务输入、工具调用、查询结果、错误、证据、耗时和用户反馈。低分或失败先归到五类：对象识别、数据获取、排查方向、证据质量、最终结论。能复现的失败变成回归用例。UModel、工具、Skill、模型或排查策略一改，就用这些用例再验一遍。

30 个分层案例上的对照

已发布的 RCA agent benchmark 从 RCA-100 里抽了 30 个分层案例。STAROps 与 OpenClaw 加 DeepSeek-V4-Pro 收到相同任务，用同一套名为 brise 的评分器打分。OpenClaw 在这里是通用智能体对照，DeepSeek-V4-Pro 是对照所用的模型。

原文表格里，根因实体的 STAROps 一栏写成「90.」，故障类型写成「58.」，小数点后没有再写数字。排查过程的差距只有 0.052，表上相当于 5.2 分。通用智能体已经能多轮查询并写出相当完整的分析。真正拉开差距的是根因实体和故障类型。对象选错，后面的指标、日志和链路都会围着错误对象转。

按大类，STAROps 在数据库、节点、代码、资源上分别领先 50.6、29.9、27.6、24.2 分。流量类反而落后对照 11.2 分，主要卡在限流。限流、DNS、CDN、第三方服务和公网路径是文章写明的下一步。

两个看起来像前端的故障

高节点 CPU 的案例从 product-catalog::ListProducts 的流量下降告警开始。只看业务数据，上游 frontend 最像元凶，它的流量和错误率同时变化。通用 ReAct 智能体结论是负载均衡故障，OpenClaw 归到 frontend 的 HTTP 5xx。两条报告都引用了数据，传播路径听起来也成立。

实际根因是 Kubernetes 节点 cn-hongkong.10.0.1.107。该节点 CPU 从大约 10.38% 升到 99.98%，同一节点上多个 Pod 受影响。frontend 流量下降 66.66%，随后 ListProducts 流量下降 62.48%，才触发业务告警。STAROps 没有停在 frontend，而是从告警操作走到服务，再沿 runs-on 关系走到 Pod 和宿主机。其他节点健康，这个节点上多个 Pod 同时变差。这一评里 ReAct 得 15 分，OpenClaw 得 12 分，STAROps 得 94 分。

慢 SQL 案例从 frontend::POST /api/checkout 告警开始。同一窗口里还有结账延迟、Kafka 滞后、JVM 垃圾回收、线程数和 Deployment 扩缩容。ReAct 认为 checkout 有代码缺陷，OpenClaw 停在 frontend 的结账逻辑。STAROps 沿链路继续往下：checkout 依赖 cart，cart 依赖 inventory。一条变慢的 inventory 链路里，SELECT 大约花了 10.8 秒，获取数据库连接又花了 2.1 秒。延迟再经 inventory、cart、checkout 传到 frontend。Kafka 滞后只有毫秒级，解释不了以秒计的超时；垃圾回收、线程数和扩缩容发生在服务已经变差之后，更像慢查询的后果。这个案例里 ReAct 和 OpenClaw 都是 15 分，STAROps 是 84 分。

限制

30 个案例是从 103 个里分层抽出的子集，不是全量。确定性规则约占 82%，不是 100%，大模型仍参与方向和证据是否充分的判断。流量类落后 11.2 分，限流场景没有被说成已经解决。离线分高不等于生产能取到数据。两个案例分数是单题，不是 30 题的平均。表格里的 90. 和 58. 就以原文写法为准。页面没有禁止复制的声明，也没有另附人工复核范围。

阿里云，Alibaba Cloud Native Community，Toward Production-Grade AgenticOps: How STAROps Builds Generalizable Root Cause Analysis，2026-09-16，https://www.alibabacloud.com/blog/toward-production-grade-agenticops-how-starops-builds-generalizable-root-cause-analysis_603555