【背景】 做了 15 年前端，最近碰了一个很典型的扯皮：我们一个核心下单页，后端接口 P99 稳定在 85ms（SLA 写得清清楚楚 < 100ms），但 RUM 数据里用户侧 FCP P75 已经 2.8s、LCP P75 飙到 4.1s。用户投诉「页面卡」，后端同学回一句「我的接口没超时，SLO 达标」。
这不是个例。我见过至少三个团队，后端 SLO 全线绿，前端 RUM 全线红，事故复盘时两边都觉得自己没问题。
【常见分歧 / 三种做法】 我观察下来，团队里大致分三派：
派一：端到端 SLO，用户感知说了算。 "用户不关心你接口 85ms 还是 200ms，他关心的是 3 秒后页面还能不能点。SLO 必须从用户视角定，后端 SLA 只是内部拆解。" 这派通常由产品或 SRE 牵头，把 FCP / LCP / INP（Core Web Vitals）写进 SLO，后端按"预算"分。
派二：前后端 SLO 分开定，各管各的。 "前端慢可能是用户 4G 网络、低端机、CDN 边缘节点抖动，这些不是后端的锅。把 FCP 写进后端 SLO，等于让后端为运营商背锅。" 这派通常由后端或平台团队主导，后端管 TTFB + 接口 P99，前端管 JS 执行 + 渲染。
派三：不定 SLO，定"性能预算"（Performance Budget）。 "别纠结 SLO 归谁，每个 bundle 限 300KB、每个接口限 200ms、首屏请求数限 15 个，超了就 CI 卡住。" 这派偏工程治理，不直接回答"谁对谁错"，而是把问题前置到开发流程里。
【我的倾向与理由】 我倾向派一为主、派三兜底，但有个关键前提：
- SLO 必须以用户感知为锚，否则就变成"各部门自嗨"。后端 P99 85ms 是事实，但用户 FCP 3s 也是事实——两个都对，但只有一个对用户负责。
- 但必须做归因拆解：FCP 3s 里，网络传输占 1.2s（CDN + 用户网络），JS 执行占 0.8s（bundle 太大），服务端 TTFB 占 0.3s，渲染占 0.7s。不拆解就追责，必然扯皮。
- 性能预算（派三）是落地手段，不是替代品。没有预算，SLO 就是"出了事再查"；有了预算，至少能在上线前拦住 80% 的退化。
落地成本我算过：端到端 SLO 需要 RUM 数据管道（Sentry/自建）、Core Web Vitals 上报、以及一个"性能归因看板"——大概 2 人周搭基建，之后每季度复盘一次。比起"出了 P0 事故再花一周复盘"，这笔账怎么算都划算。
但我也承认一个现实问题：如果你们的 RUM 覆盖率不到 30%，端到端 SLO 的数字根本不可信，这时候硬推派一会比没有 SLO 更危险——你会基于噪声数据做决策。
【想听大家怎么选】
- 你所在团队的性能 SLO 是端到端还是分侧定的？谁拍板的？
- 如果 FCP 超标但接口 P99 达标，你们怎么定责？有没有过"两边都没问题但用户骂"的尴尬？
- 性能预算你们怎么做的？CI 卡 bundle size 还是卡接口耗时？卡了之后有没有"绕过"的情况？
- RUM 覆盖率低（< 30%）的团队，你们怎么定 SLO？是先用代理指标（TTFB + 资源加载时间）凑合，还是先补 RUM 再定？
抛砖引玉，想看看不同规模团队（10 人 vs 100 人 vs 1000 人）在这个问题上的做法差异。