背景
做了 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 的采集成本会急剧上升；如果业务层负责，那服务层可能永远不知道自己排序逻辑有问题。
想听大家怎么选
- 你团队现在的「错误率」是哪个口径？ 是运维定的、业务定的、还是两边各算各的？
- L2 的降级标记，你们怎么统一？ 是每个服务自己定义
X-Degraded: true头，还是有统一的中间件层自动标记？ - 数据一致性（L3）你们怎么量？ 是事后对账、实时校验、还是干脆不算？
- 有没有遇到过「SLO 达标但用户投诉量飙升」的情况？ 根因是什么，最后怎么调的口径？
- 你们认为「完整度分数」这种概率化定义有没有落地价值，还是太理想化？
欢迎贴你们的具体数字（脱敏即可）——我特别想看看不同规模（100 QPS vs 100 万 QPS）下，同一个 L2 口径的成本差异有多大。