前端稳定性投入的「最低可接受水位」：监控、降级、SLO 到底做到哪一层就停手？

背景

社区里前端可观测性、稳定性责任边界的话题已经不少：#61 聊过前端该不该背 P99 和 on-call，#121 讨论过上报采样还是全量，#28 讲过错误监控从白屏到 5 分钟定位的 4 步落地。把这些串起来看，我发现大家其实都默认了一个前提——「前端稳定性是一定要做的」，但很少有人把投入水位摆到桌面上算账。

我 5 年前端，做过 B 端 SaaS 也做过 C 端 H5，真实体感是：稳定性投入是强边际递减的。前 20% 的投入（错误上报 + 首屏失败降级）能挡住 80% 的用户可见故障；后 80% 的投入（全链路 tracing、细粒度 RUM、错误预算门禁）边际收益越来越小，但成本是持续性的——SDK 维护、sourcemap 管理、告警噪音治理、值班响应，一年比一年贵。

几种常见做法（分歧所在）

1. 极简派：只上错误上报 + 白屏兜底（window.onerror + 骨架屏重试），其余全靠后端 SLO 兜底。优点是几乎零维护成本；缺点是用户侧的「慢、卡、卡死」完全没信号，故障定位靠用户截图。
2. 标配派：错误上报 + Core Web Vitals + 关键链路埋点（首字、提交成功/失败）+ 一套告警。这是大多数 B 端团队的实际水位，投入大约 1~2 人周 + 持续 5% 维护。
3. 全量派：加 RUM 全采样、分布式 tracing 打通前后端、错误预算门禁、前端 SLO 写进 SLA。收益是「用户体感可量化」，但成本是持续的——我见过一个团队为 sourcemap 存储和告警治理一年花了 2 人月，最后发现真正用的只有 3 个指标。

我的倾向

我倾向标配派 + 一个硬约束：水位按「用户可感知的三类故障」倒推——

• 白屏：必须有（visibilitychange + 首屏资源失败检测）；
• 慢：必须有（首字 / 关键操作 P75、P95，不用 P99，P99 在前端信噪比太差）；
• 功能失败：关键业务动作（提交、支付、保存）的成功率必须单独统计，不能混在 HTTP 200 里。

这三类之外，tracing、全采样 RUM、错误预算门禁，除非你被真实的用户投诉或 P0 复盘逼到，否则不要主动上。理由是：可观测性的成本不是「上线那天」，而是「上线之后每天」——告警要有人看、指标要有人信、噪音要有人治。没有 on-call 的团队上全量 RUM，等于给自己挖一个永远填不满的坑。

想听大家聊的

1. 你们团队的「实际水位」在哪一档？是极简、标配还是全量？当初是谁拍板停在哪的？
2. 有没有反例——某个看起来「过度」的观测投入，事后证明救了你一命的？（我想收集真实案例，用来校准我的「不要主动上」判断）
3. 前端 SLO 到底该不该写进 SLA？我见过两种极端：一种是前端完全背 99.9%，一种是完全只背「不白屏」。你们怎么定的？
4. 如果资源只有 1 人周，你会先做哪个？（我的答案是「关键业务动作成功率」，不是错误上报——但我不确定是不是多数派）

欢迎带真实场景来聊，别只聊原则。