背景
做了 5 年指标体系，我发现一个反直觉的事实：同一个服务，团队 A 和团队 B 算出来的「错误率」可能差一个数量级，而差异不在于监控系统，在于「什么算一次失败」的定义根本没对齐。
举一个真实场景：一个商品搜索接口，日请求量 2000 万，团队里对「错误」的口径至少有三种：
| 口径 | 算错误的范围 | 月均错误率（示例） | |---|---|---| | 窄口径：只看 HTTP 5xx + 超时 | 503 / 504 / 连接超时 | 0.01% | | 中口径：5xx + 200 但 body 为空 / 降级标记 | 上面 + 熔断降级返回空列表 | 0.15% | | 宽口径：上面 + 200 但数据不一致（如价格与库存不同步） | 上面 + 业务逻辑错误 | 1.2% |
三个口径差了 120 倍。如果 SLO 定在 99.9%，窄口径下永远达标，宽口径下每个月都在违约。团队据此做的容量规划、告警阈值、oncall 响应，完全是两个世界。
常见分歧（我观察到的四种典型立场）
-
「运维视角」：只看 5xx。 理由：SLO 是给 SRE 和 oncall 用的，5xx 是唯一可自动采集、可自动触发告警的信号。200 空数据、脏数据需要业务侧判断，无法统一度量。
- 代价：搜索接口 99% 的请求都返回 200，但用户看到的是空列表或错误价格，SLO 显示一切正常，用户已经在投诉了。
-
「业务视角」：用户感知到不对就算错。 理由：SLO 本质是承诺用户体验，不是承诺 HTTP 状态码。
- 代价：「用户感知」很难自动采集，往往要等客诉或 A/B 实验才能发现；而且不同业务线对「不对」的定义不同，跨团队没法横向比较。
-
「折中视角」：5xx + 明确的降级标记。 理由：在运维可采集和业务有意义之间取交集，凡是走了降级 / 熔断 / 兜底逻辑的请求都标记为「非完整成功」。
- 代价：降级标记需要每个服务自己埋点，口径不统一；而且「部分成功」（返回了 80% 的字段但丢了 20%）算成功还是失败？没有标准答案。
-
「概率视角」：按置信度加权。 理由：与其二分类（成功/失败），不如给每个响应打一个「完整度分数」，SLO 定义为「完整度 ≥ 0.95 的请求占比 ≥ 99.9%」。
- 代价：实现成本高，需要每个接口定义完整度模型；而且 0.95 这个阈值本身又是拍脑袋的，换个人可能就定 0.8。
我的倾向与理由
我倾向于分层定义，而不是统一一个口径：
- L1（基础设施层）：5xx + 超时 + 连接失败。这一层给 SRE 用，阈值紧（99.95%），告警自动化，oncall 直接响应。
- L2（服务层）：L1 + 降级 / 兜底 / 空响应。这一层给服务 Owner 用，阈值稍松（99.9%），纳入月度 SLA 报表，但不直接触发 P0。
- L3（业务层）：L2 + 数据一致性校验（如价格一致性、库存一致性）。这一层给产品 / 业务方用，阈值最松（99.5%），走周报和 A/B 指标，不进 oncall。
关键原则：每一层有独立的阈值、独立的告警通道、独立的责任人。不要试图用一个数字同时满足 SRE、服务 Owner 和产品经理——那只会得到一个谁都不满意的中间值。
但我有一个没想清楚的问题：L2 和 L3 的边界在哪里？ 比如「返回了商品列表但排序错了」，这是服务层的问题还是业务层的问题？如果服务层负责，那 L2 的采集成本会急剧上升；如果业务层负责，那服务层可能永远不知道自己排序逻辑有问题。
一个可落地的量化判据（补）
分层不是「拍三档阈值」，而是要有一个可操作的切换判据，否则团队会在 L1 和 L2 之间反复横跳。我线上用的判据是：
「L2 错误率 / L1 错误率 的比值」决定告警该走哪一层：
- 比值 < 2：L1 就能解释大部分错误，告警走 L1 通道，L2 只做月度报表；
- 比值 2~10：L2 有独立信号（降级 / 兜底在涨，但 5xx 没涨），告警走 L2 通道，L1 保持静默；
- 比值 > 10：L2 是主信号，L1 基本无意义，应该把告警阈值整体迁到 L2。
这个比值的好处是它本身就是一个可采集的指标（L2 错误数 / L1 错误数），不需要额外埋点，只需要把两层的口径都算出来再相除。而且它能捕捉「SLO 达标但体验在变差」的场景：L1 错误率稳定在 0.01%，但 L2/L1 从 3 涨到 30，说明降级 / 兜底在悄悄涨，用户已经开始看到空列表了——这时候 L1 的 SLO 还显示「一切正常」，但 L2 的告警已经响了。
一个边界条件：这个判据对**「200 但数据是脏的」**（L3 层）不敏感，因为 L3 的错误往往是离散的（某次批跑写错了数据），不是连续涨的。L3 层更适合用「事后对账错误数 / 总请求数」的绝对值来告警，而不是用比值。
想听大家怎么选
- 你团队现在的「错误率」是哪个口径？ 是运维定的、业务定的、还是两边各算各的？
- L2 的降级标记，你们怎么统一？ 是每个服务自己定义
X-Degraded: true头，还是有统一的中间件层自动标记？ - 数据一致性（L3）你们怎么量？ 是事后对账、实时校验、还是干脆不算？
- **有没有遇到过「SL