作者王涛灵亦线上稳定性里有一些潜在很容易被人忽视的问题。发布刚过去半小时告警没响错误率也没越线。可支付页转化比平时低了一点移动端首屏慢了一点按钮重复点击多了一点某个接口的 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 要上传跟构建产物匹配的 sourcemapAndroid 要上传对应版本的 mapping.txtNative 崩溃还得留着 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。定制的目的不是多写几段话是把下一步的沟通成本压下去。真正能用的报告会把排查对象、判断依据、负责人和复查口径都写到位。快速上手前提需要接入用户体验监控参考文档[1]然后登录 STAROps 控制台[2]。你也可以直接去演示 DEMO[3]点击智能巡检体验。在 STAROps 控制台点左侧的智能巡检菜单再点 RUM 智能巡检卡片等它输出巡检方案后输入确认就行。巡检的对话里你随时可以改 prompt主要说清四件事对象、时间、场景、输出。发布巡检可以写得很具体巡检 xxx 应用 /checkout 支付链路每小时运行一次对比发布前同周期重点看移动端的 LCP、INP、API p95、慢会话、重复点击和转化变化输出风险对象、证据链和接手建议。活动看护或者用户反馈的场景prompt 可以更贴近现场活动入口页过去 1 小时用户反馈点了没反应重点看移动端、低端 Android、主地域和新版本结合重复点击、长任务、接口耗时和 Replay 样本给出接手判断和下一步排查方向。任务建好以后先确认报告里的对象和时间窗口对不对。范围铺太大就把页面、版本、端或地域收窄一点再跑一遍。prompt 写得越像真实问题报告越容易直接进入排查也越不容易跑成一份大而全的指标清单。如何阅读报告每种模板的阅读报告的方式不同先确认三件事发生了什么凭什么这么判断接下来谁接。每小时报告更像值班时的一张接手卡它回答的是“这一小时哪些对象开始不对劲”。第一屏先扫健康状态、风险等级和 Top 风险对象再往下确认支撑结论的指标和样本。小时报告结构上抓三层上面给结论中间摆证据下面跟风险。读完值班同学至少得清楚该不该接、接哪个对象、下一小时盯什么。每日诊断报告把一天里反复出现、影响范围更稳定、适合复盘的弱信号收拢到一起。小时报告偏“此刻该不该处理”日报偏“今天哪些问题得进讨论”。我们团队是怎么用 RUM 巡检的我们团队的做法挺简单告警继续管那些已经明确炸出来的问题RUM 巡检做日常体检。每天固定生成一份全量 RCA 巡检早上看报告时不急着翻所有明细先看有没有新的风险对象冒出来。日常最常见的其实不是“告警响了”而是那些还没到告警阈值的问题——某个页面比上周同时段慢了一截某个版本的慢会话比例一直偏高某类崩溃每天都有但单日数量不大。这类问题一旦集中在关键路径上就会被单独拎出来看。确认要处理我们会直接建 issue。issue 里不写泛泛的“页面性能变差”而是把对象和证据写清楚哪个页面或链路影响哪些版本和端偏离了哪条基线有哪些样本会话、热力图、错误样本或崩溃聚合能支撑建议谁先看复查时看哪些指标。每周再看一次周报。周报不重复每天的诊断过程只看本周和上周的差别新增了哪些 issue哪些问题延续了下来哪些已经恢复哪些高频根因还在反复冒。一周下来团队就知道自己处理的是不是同一批问题也能看出体验治理到底有没有往前挪。总结RUM 巡检的价值不在于多一套报表。它做的事是把真实用户体验里那些弱信号整理成能处理的问题。告警告诉你哪里已经越界巡检补上的是越界之前那段观察哪些对象正在变差证据是不是指向同一个原因下一步该由谁接。等崩溃解析、报告生成、issue 和周报对比这几件事连起来体验问题就不再散落在大盘、告警和用户反馈之间。团队能更早发现退化也能更稳地追踪它到底修没修掉。立即体验前往云监控[4]创建用户体验监控应用拿到 endpoint 就能开始接入。访问演示 DEMO[5]立即体验创建 RUM 巡检。社区交流加入钉钉群[6]和阿里云可观测团队聊聊。相关链接[1] 参考文档https://help.aliyun.com/zh/arms/user-experience-monitoring/web-h5-app-quickstart[2] STAROps 控制台https://starops.console.aliyun.com/mission?staropsClusterRegioncn-beijing[3] / [5] 演示 DEMOhttps://sls.aliyun.com/doc/playground/staropsdemo.html[4] 云监控https://cmsnext.console.aliyun.com/[6] 钉钉群https://www.dingtalk.com/download?actionjoingroupcodev1,k1,LOiEgutAbsd2s2z8GIFPhrM0FQlj3azIvtpnJ0CXH0_dt_no_comment1origin11
