系统指标全绿但用户在掉单：SRE 该不该为「业务成功率」负责？

做 SRE 8 年，我踩过一个印象最深的坑，今天想拿它抛一个我觉得社区里吵得还不够透的问题。

【背景 · 一次"大盘全绿"的掉单事故】 我们一条下单链路（Java + Spring + MySQL + Redis + MQ），某天起业务侧下单成功率（提交→成功）从 99.2% 悄悄掉到 96.8%，持续了 3 天。但我们的监控——CPU、内存、RT P99、接口 5xx 率、JVM GC、DB 慢查询、MQ 堆积——全部正常，一条告警都没触发。最后是产品同学从 BI 报表里发现掉量、反查才定位：上游一个营销/风控系统灰度上线了一条策略，把部分用户请求"静默拦截"了，但接口仍返回 200 + 一个业务失败码，系统层错误率纹丝不动。 3 天、2.4 个点的成功率、零告警——这是我至今最膈应的一次"没出故障的故障"。

【我抛的问题】 当系统层所有指标都正常、但业务在掉单/掉量/掉转化时，SRE 到底该不该负责、以及能不能负责排查？"业务成功"的口径到底该谁来定？

【我见过的三种做法 / 分歧】

1. SRE 只该盯系统层（RT/错误率/饱和度/依赖健康），业务指标是研发和产品的活。理由：业务口径波动大、归因难（掉量可能是渠道、大盘、竞品），让 SRE 背转化率告警，最后只会变成新一轮告警疲劳。
2. SRE 必须把"业务成功率"纳入告警。理由就是我们这次：接口 200 ≠ 业务成功，可观测性如果只覆盖系统层，等于对最伤用户、又最难归因的那类故障集体失明。
3. 折中：SRE 盯"系统→业务"的桥接指标（关键动作成功率、漏斗转化率），但口径和阈值由业务/数据团队共定，SRE 只负责把它变成可靠、低噪的告警与响应流程，不背业务波动本身。

【我的倾向与理由】 我倾向第 3 种，但有一个硬前提：先定义"业务成功"，再谈告警。具体我会做三件事，也是我的避坑清单：

• 给核心链路定 1–3 个"业务北极星动作"（如：下单成功、支付成功、关键 API 返回业务成功码），用业务码而非 HTTP 状态码判定成功——我们那次就是栽在"只看 200 率"上；
• 把"成功率"做成相对基线（环比/同比 + 分位）而非绝对阈值，避免大盘自然波动就触发告警；
• 告警分级：业务成功率跌破基线一定幅度（如 X 个标准差）才进 on-call 通道，平时进"观察"群——既不漏掉"静默劣化"，也不把 SRE 淹死在业务噪音里。 理由：那次根因不在系统层，可观测性的边界如果只画到系统层，等于把最伤用户、最难归因的那类故障默认豁免了。但我也承认，口径不定死就硬上业务告警，结果大概率是"告警疲劳 2.0"。

【想听大家】

• 你们团队里，"业务掉量"到底算谁的告警？SRE / 研发 / 数据，谁在 on-call 通道里？
• 怎么把"业务成功率"定义得既抓得住静默劣化、又不至于天天误报？你们用什么基线/分位/环比口径？
• 有没有"系统全绿但业务在流血"的真实案例？最后是怎么被发现的、拖了多久？