前端到底该不该背 P99 和 on-call？聊聊稳定性责任的边界

背景

最近几次复盘 P0/P1 故障，我发现一个挺尴尬的现象：故障根因明明在网关超时、DB 抖动、第三方 SDK 异常，但被拉进 on-call、被写进复盘文档「改进项」的，往往还是前端。原因是用户看到的是「页面卡了 / 白屏了 / 按钮点了没反应」，前端成了「用户体验」的默认责任人。

与此同时，前端这几年越来越重：SSR、微前端、长连接推送、客户端 SDK 里塞了埋点/风控/AB，很多所谓「后端故障」，前端其实是第一个观察到、也最后一个恢复的。

常见的几种做法

我观察到的团队大致分三档：

1. 前端只背功能：可用性、P99、错误率全由后端和 SRE 负责，前端最多报一下「白屏率」，不进 on-call。
2. 前端背指标不背人：前端要保 LCP / INP / 错误率，但故障时由值班 SRE 统一拉群，前端只在被 @ 时响应。
3. 前端进 on-call：核心链路前端和后端一起轮值，按完整 SLO 考核，前端要写 runbook、做故障演练。

我的倾向

我比较偏向**「按可执行的动作划边界，而不是按数字划边界」**。具体说：

• 前端对「能热修 / 能发版 / 能降级」的那部分负责。比如 SDK 崩溃 → 前端必须进 on-call，因为热修只能我们做；
• 对「改代码也没用」的部分（网关、DB、第三方服务），前端负责观测与上报，不参与 on-call，避免变成背锅侠；
• 指标上，前端背前端可控的指标（JS Error 率、LCP P75、INP P75），不背端到端 P99 —— 端到端 P99 应该由链路 owner 背。

这样划的好处是：责任清晰，复盘时不会扯皮；坏处是边界需要每个链路单独定义，前期沟通成本高。

想听大家聊聊

• 你们团队里前端进 on-call 吗？多久一轮？
• 前端背哪些指标？LCP/INP 还是错误率？
• 遇到「根因在后端、但用户投诉到前端」的场景，你们的复盘机制是怎样的？
• 有没有遇到过因为责任边界不清，导致故障响应慢了 30 分钟以上的案例？