STAROps RUM 智能巡检实践：把体验退化提前看清楚

RUM 巡检：把体验退化提前看清楚

线上稳定性里，有一些潜在很容易被人忽视的问题。

发布刚过去半小时，告警没响，错误率也没越线。可支付页转化比平时低了一点，移动端首屏慢了一点，按钮重复点击多了一点，某个接口的 p95 也轻轻抬了头。每个指标单独拎出来看，都像一次可以先放过的小波动。

问题是用户不会按指标拆开体验。他们看到的是页面迟迟没出来，点了按钮迟迟没反馈，提交后等得更久，最后有人退出，有人重试，有人跑去找客服。

RUM 巡检管的就是这段灰区。它按固定节奏，把页面性能、接口耗时、用户行为、崩溃、转化和版本变化放到同一个对象上一起看，尽早判断体验是真在变差，还是只是抖了一下。

RUM 数据看什么

RUM 看的是用户在真实环境里到底经历了什么。设备、网络、浏览器、版本、页面、首屏时间、点击后的响应、接口耗时、资源失败，还有整段访问里的卡顿，都会留下痕迹。

下面是几个常见 RUM 指标：

• LCP 对应核心内容露出的时间。它变差，用户的直接感受就是页面打开慢。
• INP 对应交互响应。按钮点下去没反应、输入后页面卡住，都可以看这个指标。
• API p95 盯的是尾部请求。平均值看着正常，最慢的那批用户可能已经被拖住了。
• 慢会话记录整次访问顺不顺。单个点慢一点还能忍，整段流程都慢，完成率就要受影响。
• Replay、热力图、重复点击更接近现场证据，用来确认用户到底卡在哪一步。
• 崩溃和异常说明流程已经被打断，得结合版本、设备、页面和符号化结果一起读。

现场是留下来了，但它不会自动变成判断。数据越多，后面的活反而越重：持续巡一遍，确认这些变化指向的是同一个问题，还是几条互不相干的波动，再把指标、样本和行为证据拼成一条能往下推的线索。

STAROps 是阿里云基于大模型和智能体技术打造的全域智能运维平台。它深度融合跨域可观测数据与大语言模型推理能力，突破传统运维工具使用门槛高、数据孤岛严重等局限，支持用户通过自然语言定义目标，由运维智能体自主完成动态规划、安全执行与结果验证的全闭环。通过长期任务，可以让数字员工（Agent）按计划或事件驱动地自动执行巡检、变更、分析等运维操作，并在需要时发起人工干预（HIL）请求。

RUM 巡检结合 STAROps 长期任务服务，运用了告警触发后的自动分析与 RCA 产出周期性报告生成，如巡检报告、问题汇总、告警分析摘要两大功能。正好能够解决上面的问题。

告警与巡检的边界

告警适合抓确定性故障。接口不可用、错误率明显越线、核心流程大面积失败，这些事就该第一时间通知、升级、止血。

大盘回答"现在是什么状态"——流量、耗时、错误率、版本分布，用户随时都可以查看所有的统计指标，每个指标的走向都非常明确。

巡检看的场景更靠前：单个指标还没严重到必须报警，可多个信号已经在同一个对象上一起往下走了。巡检相比告警和大盘，更多的是解释多信号融合、多指标退化的能力：哪些信号一起动了，落在哪个对象上，波及了哪些用户，下一步该谁接。

拿 /checkout 举例。新版本上线后它并没有彻底不可用，错误率也没明显越界，但移动端用户的 LCP 慢了，INP 差了，payment/create 的 p95 抬了，慢会话多了，重复点击多了，转化率比同周期低了。单拎任何一条，都还能解释成波动；摆在一起，就很难继续装作没看见。

巡检是周期性的任务，不用每次都写长报告。每小时扫一遍，看哪些对象开始偏离基线；每天做一次解释，把联合退化的证据链和处理建议补齐；每周沉淀那些长期偏尾、反复出现、该进治理清单的问题。

基于对象巡检

传统的基于指标的分析很容易把问题拆碎，例如这里一个慢页面，那里一个慢接口，还有一个错误签名，每个都看起来很严重，但是却指向分散的问题，严重但是不一定紧急

巡检得反过来做：先找对象，再看指标。

对象可以是一个页面、一条业务路径、一个版本、一类设备、一个地域、一个渠道，也可以是它们的组合。对象定住了，指标才有落点。不然"LCP 上升 8%"就只是一句话；而"/checkout + v2.8.1 + 移动端的 LCP、INP、API p95、慢会话、重复点击、转化率同时变差"，才像一个值得排查的问题。

这一步最怕误判。只有几十个访问样本的页面，不该跟每天几十万访问的核心页面用同一把尺子；今天 14 点的变化，也别只跟今天 13 点比，得拉上昨天同时段、上周同时段，还有发布前后的窗口。

维度也要落到具体的排查动作上。移动端慢了，就往下拆机型、系统、浏览器、地域、版本；接口 p95 抬了，就追是哪批尾部请求拖坏了体验；转化掉了，就回到等待、重复点击、离开位置这些行为里去看。

证据最后得合起来。单个指标变差，只能说明有波动；等业务结果、性能指标、请求耗时、用户行为和现场回放都指向同一个对象，结论才站得住。

两类容易漏掉的问题

一类是"业务先变弱，技术指标还没炸"。

比如支付完成率掉了 3%，可错误率没什么动静，告警也没响。这时候只盯错误数，很容易就把问题放过去。正确的做法是把支付路径摊开摆：入口页加载、提交按钮响应、支付接口 p95、慢会话的版本分布、重复点击的按钮，全塞进同一张图。

要是这些信号同时冒头，Replay 里又能看到用户提交后越等越久、反复点、返回重试，那报告写成"转化有波动"就太轻了。它该直接点出来：问题集中在支付链路的移动端新版本，主要表现是请求尾延迟和交互等待；研发这边先排支付创建接口的尾部耗时，顺带复查按钮反馈和防重复提交的逻辑。

另一类是"低端设备长期偏尾"。

这种问题通常不吵。按天看，它只是慢一点点；按周看，它一直慢。低端 Android 上长任务更多，INP 长期偏差，慢会话占比更高，跳出率略高，完成率略低。当天夜里未必值得把人拉起来处理，可长期没人管，它就变成一批用户一直在承担的体验成本。

巡检正好适合把这类问题拎出来：影响面有多大，持续了多久，进治理排第几，最后交给谁判断。

自动解析崩溃，聚合高频根因

可很多崩溃报告只甩一条堆栈。看的人知道出了错，却不知道该追哪个版本、哪个页面、哪段代码。所以崩溃进巡检之后，系统得先做归一和聚合：把同类异常、相似堆栈、页面、版本、端、设备、浏览器、WebView、发布窗口放到一起看，报告里优先亮出高频根因和影响范围。

自动解析有个前提，符号文件得跟着发布一起走。前端和 Web 要上传跟构建产物匹配的 sourcemap，Android 要上传对应版本的 mapping.txt，Native 崩溃还得留着 symbols。文件一缺，报告就只能看到 bundle 的行列号或者混淆后的类名；匹配上了，才谈得上还原到源码文件、方法、Activity、Adapter 或者点击回调。RUM 用户体验监控支持 cli 上传 sourcemap 或者 mapping.txt 等文件，参考 https://help.aliyun.com/zh/arms/user-experience-monitoring/use-cases/upload-rum-symbol-table-files-by-using-cms2-cli

崩溃的解读也要帮人少走几步。就说 Android 的 IndexOutOfBoundsException，报告别只写"数组越界"，还得说清楚它是在用户点了列表项之后发生的，访问了超出 list.size() 范围的元素，再带上受影响版本、设备分布、样本数、用户数和建议的排查方向。前端那种 undefined 访问，也尽量落到具体的组件、接口字段或者灰度资源版本上。

符号文件本身也得管起来。sourcemap 可能带着源码信息，mapping.txt 也会暴露代码结构，更适合放进受控空间，按应用、环境、版本、构建号和资源 hash 绑好。这样崩溃一发生就能自动匹配，报告也能稳定给出高频根因，而不是只留一堆没法读的原始堆栈。

默认报告与自定义报告

巡检报告支持多种报告格式。默认可以先覆盖四类常用的：小时报告用来发现刚开始偏离基线的对象；每日诊断报告用来解释一天里反复出现的退化；每周报告用来沉淀那些长期偏尾、反复出现、适合进治理清单的问题；全量 RCA 巡检则用来对一次明确的问题做完整根因分析，把时间线、影响范围、证据链、根因判断、处置建议和复查口径一路串起来。

不管是哪一种，有几块信息应该稳定地留下来。先给结论，这次影响的到底是哪条路径、哪个版本、哪类设备或哪组用户。再把影响对象写清楚：页面、接口、版本、端、地域、用户规模、业务路径，一个都别含糊。然后是组合证据，说明哪些信号一起变差、跟基线比差在哪。现场证据得跟上——Replay、热力图、样本会话、错误样本，都是用来支撑结论的，不是凑图。最后落到接手建议：研发先查接口还是交互，SRE 继续盯多大的影响面，产品跟哪条转化，多久之后复查哪些指标。

用户也可以根据自己的场景定制报告。基于现有的报告，把几个需求和 agent 讲清楚。定制不用从零开始，把几件事改清楚就行：巡检对象是页面、接口、版本还是业务路径；时间窗口按小时、按天还是按发布前后；重点指标看性能、异常、转化、行为还是崩溃；输出偏接手卡、复盘摘要、治理清单、风险日报还是 RCA。定制的目的不是多写几段话，是把下一步的沟通成本压下去。真正能用的报告，会把排查对象、判断依据、负责人和复查口径都写到位。

快速上手

在 STAROps 控制台点左侧的智能巡检菜单，再点 RUM 智能巡检卡片，等它输出巡检方案后输入确认就行。

巡检的对话里，你随时可以改 prompt，主要说清四件事：对象、时间、场景、输出。

发布巡检可以写得很具体：

巡检 xxx 应用 /checkout 支付链路，每小时运行一次，对比发布前同周期，重点看移动端的 LCP、INP、API p95、慢会话、重复点击和转化变化，输出风险对象、证据链和接手建议。

活动看护或者用户反馈的场景，prompt 可以更贴近现场：

活动入口页过去 1 小时用户反馈点了没反应，重点看移动端、低端 Android、主地域和新版本；结合重复点击、长任务、接口耗时和 Replay 样本，给出接手判断和下一步排查方向。

任务建好以后，先确认报告里的对象和时间窗口对不对。范围铺太大，就把页面、版本、端或地域收窄一点再跑一遍。prompt 写得越像真实问题，报告越容易直接进入排查，也越不容易跑成一份大而全的指标清单。

如何阅读报告

每种模板的阅读报告的方式不同，先确认三件事：发生了什么，凭什么这么判断，接下来谁接。

每小时报告更像值班时的一张接手卡，它回答的是"这一小时哪些对象开始不对劲"。第一屏先扫健康状态、风险等级和 Top 风险对象，再往下确认支撑结论的指标和样本。

小时报告结构上抓三层：上面给结论，中间摆证据，下面跟风险。读完，值班同学至少得清楚该不该接、接哪个对象、下一小时盯什么。

每日诊断报告把一天里反复出现、影响范围更稳定、适合复盘的弱信号收拢到一起。小时报告偏"此刻该不该处理"，日报偏"今天哪些问题得进讨论"。

我们团队是怎么用 RUM 巡检的

我们团队的做法挺简单：告警继续管那些已经明确炸出来的问题，RUM 巡检做日常体检。每天固定生成一份全量 RCA 巡检，早上看报告时不急着翻所有明细，先看有没有新的风险对象冒出来。

日常最常见的其实不是"告警响了"，而是那些还没到告警阈值的问题——某个页面比上周同时段慢了一截，某个版本的慢会话比例一直偏高，某类崩溃每天都有但单日数量不大。这类问题一旦集中在关键路径上，就会被单独拎出来看。

确认要处理，我们会直接建 issue。issue 里不写泛泛的"页面性能变差"，而是把对象和证据写清楚：哪个页面或链路，影响哪些版本和端，偏离了哪条基线，有哪些样本会话、热力图、错误样本或崩溃聚合能支撑，建议谁先看，复查时看哪些指标。

每周再看一次周报。周报不重复每天的诊断过程，只看本周和上周的差别：新增了哪些 issue，哪些问题延续了下来，哪些已经恢复，哪些高频根因还在反复冒。一周下来，团队就知道自己处理的是不是同一批问题，也能看出体验治理到底有没有往前挪。

总结

RUM 巡检的价值不在于多一套报表。它做的事，是把真实用户体验里那些弱信号，整理成能处理的问题。告警告诉你哪里已经越界，巡检补上的是越界之前那段观察：哪些对象正在变差，证据是不是指向同一个原因，下一步该由谁接。

等崩溃解析、报告生成、issue 和周报对比这几件事连起来，体验问题就不再散落在大盘、告警和用户反馈之间。团队能更早发现退化，也能更稳地追踪它到底修没修掉。

立即体验：前往 云监控 创建用户体验监控应用，拿到 endpoint 就能开始接入。访问 演示 DEMO 立即体验创建 RUM 巡检。

社区交流：加入钉钉群，和阿里云可观测团队聊聊。