前端稳定性该信 RUM 真实用户监控还是合成拨测？谁该当「主信号」

背景

社区里前端可观测性的讨论已经不少：#28 讲过错误监控从白屏到 5 分钟定位的落地路径，#121 聊过采样还是全量的成本权衡，#431 讨论过稳定性投入的最低水位。但我一直觉得有个更前置、却少被正面摆上桌面的分歧——当你同时有 RUM（Real User Monitoring，真实用户浏览器里采到的 LCP/INP/错误率）和合成拨测（Synthetic，CDN 节点定时打你的核心页面）两套数据时，到底该以哪一个作为「稳定性是否 OK」的判定依据和告警主信号？

我前阵子给一个 B 端 SaaS 做发布验证，正好撞上这个矛盾，把两种做法的代价摊开来看：

做法 A：以 RUM 为主信号。 真实用户视角，最接近「用户到底卡没卡、白没白屏」。但坑也很实际：

• 数据稀疏且分布长尾，一个低概率 bug 可能要等几百个真实用户命中才浮出来，告警天然滞后；
• 信号被「用户侧变量」严重污染——弱网、老机型、插件、公司代理都能把 LCP 拉爆，你很难区分「是我的代码回归」还是「用户网络差」；
• 成本与合规：全量 RUM 的采集、存储、分析费用不低，行为回放类更是隐私敏感，很多团队开了采样又不敢开太高。

做法 B：以合成拨测为主信号。 可控、稳定、覆盖确定性路径，适合盯「核心链路是否可用」，告警干净、可回放。但代价同样真实：

• 它测的是「拨测节点到服务」，不是「真实用户到服务」，CDN 边缘、运营商链路、弱网场景全部失真；
• 你只测了你写进脚本的那几条路径，长尾路由、组合态、偶发竞态基本覆盖不到；
• 拨测脚本本身要维护，页面一改版脚本就废，长期是有隐性成本的。

我的倾向

我倾向「双信号、分职责」，而不是二选一：合成拨测当「可用性/回归的守门人」——核心链路挂了、发版回归了，靠它第一时间兜底告警，因为信号干净、可复现；RUM 当「体验质量的裁判」——真实用户感知到的慢、错、白屏，靠它做趋势判断和 SLO 达成率核算，但用聚合分位数（P75/P95）而非单点，且对弱网做分群。换句话说：「能不能用」信合成，「用得好不好」信 RUM。这样既守得住 P0，又不被用户侧噪声淹没告警。

但我很清楚这个倾向偏「资源充足、有专人维护两套」的团队，落地成本不低。

想听大家怎么选

特别想知道在不同约束下你们的取舍：

1. B 端 SaaS vs C 端高并发 H5：你们哪边更依赖合成、哪边更依赖 RUM？
2. 成本敏感的小团队：只让你保一套，你会保哪个？为什么？
3. 告警怎么设计：RUM 这么「脏」，你们靠什么手段把「用户网络差」和「我的回归」区分开（分群？基线对比？拨测交叉验证）？
4. 发布卡口：谁该有「拍板全量」的否决权，合成拨测绿就放行，还是必须 RUM 核心指标不劣化？

欢迎带具体场景和数字来聊，哪怕是「我们只用了拨测，RUM 只看不告警」这种折中方案也想知道背后的理由。