服务端说平均请求 100 毫秒，Alice 却觉得平均要等 1 秒。

服务方说 MTTR 小于 1 分钟，Alex 体感一次故障平均接近 1 小时。

这不是谁在撒谎。AWS 工程师 Marc Brooker 6 月 19 日在个人博客里，用这两个简化例子讲了一个很容易被报表遮住的问题：服务方按“请求数”或“事故数”看系统，用户按“自己被卡住的时间”感受系统。

我更在意的是后半句。很多团队并不缺指标，缺的是知道哪个指标会骗自己。

服务指标和用户体感，为什么会同时正确

Brooker 指向的是 inspection paradox，中文常译作“检验悖论”或“观察悖论”。

直白说，用户不是从所有请求里随机抽一条看结果。用户是在时间线上进入系统。一个请求越慢、一次故障越久，被用户撞见的概率就越高。

所以服务端看到的是“按事件计数”的分布，用户看到的是“按持续时间加权”的分布。

核心公式是：

用户体验均值 = E[X²] / E[X] = E[X] + Var(X) / E[X]

这句话的杀伤力在后半截：方差越大，用户体感均值越高。平均值本身没错，但它回答的是服务内部问题，不是用户等待问题。

场景服务方口径用户体感口径关键差异
Alice 的请求延迟平均请求 100ms平均等待约 1s慢请求按持续时间被放大
Alex 的故障恢复MTTR 小于 1 分钟平均故障约 1 小时长故障更容易被用户撞上
Brooker 的恢复示例中位恢复 30 分钟，p99 为 10 小时，MTTR 略超 1 小时用户体验约 6 小时右尾主导实际等待

这些数不是某个 AWS 服务或某个真实系统的实测数据。Brooker 也明确说，文中用 log-normal 分布只是为了数值计算方便，不是在宣称它就是延迟或恢复时间的真实模型。

这点要说清楚。文章讨论的是统计口径，不是云服务可靠性爆料。

MTTR 低，不等于用户觉得恢复快

MTTR 最容易给人安全感。一个月里故障恢复平均不到 1 分钟，听上去很稳。

问题是，MTTR 通常按事故数平均。一次 30 秒的小抖动，和一次 10 小时的大故障，在事件计数里都只算一次。

但对用户不是这样。

用户不是在事故清单里投骰子。用户是在业务时间里碰运气。长故障持续越久，越可能覆盖发布窗口、订单提交、批处理、客户会议和夜间值班。

这也是 Brooker 反对用截尾均值理解延迟或恢复时间的原因。

把最慢的 1% 或 5% 删掉，报表会变干净。但被删掉的，恰好可能是用户最痛的部分。右尾不是噪音，很多时候就是体验本身。

当然，工程团队用均值不是没有意义。均值适合看容量、成本、资源消耗，也适合做系统中心位置的长期对比。

限制在这里：它不能替用户证明“等待不严重”。尤其在分布很偏、方差很大时，均值会把最该处理的问题磨平。

后端、平台和 SRE 该怎么改动作

这篇文章对工程团队的价值，不是多记一个公式。它真正提醒的是：事故复盘和服务看板要从“事件平均”补到“时间加权”。

对后端和平台工程师，慢请求不能只靠 retry 藏起来。重试有用，但有前提：原请求不能长期持有锁，不能占住独占资源，也不能把下游继续打穿。

对 SRE 和可用性负责人，MTTR 也不能单独拿来讲恢复质量。它要和最长恢复、恢复时间分布、受影响用户分钟数一起看。

对象容易误判的指标更该补看的指标直接动作
后端 / 平台工程师平均延迟、截尾均值p99、p999、超时率、慢请求持有资源时长检查 timeout、retry、限流、隔离池，避免慢请求拖垮下游
SRE / 可用性负责人MTTR、事故次数最长恢复、恢复时间分布、受影响用户分钟数复盘时单独拆长尾事故，给降级、回滚、容量冗余设硬阈值

这里也有现实约束。不是所有系统都要追 p999，也不是所有团队都有足够流量支撑稳定分位数。低流量服务看极端分位数，可能抖得很厉害。

但这不等于回到平均值。低流量系统至少可以记录最长等待、最长恢复、事故影响用户分钟数。样本少时，更不能把右尾直接删掉。

接下来该看的也很具体：一个团队是否只汇报平均延迟和 MTTR，还是会把 p99/p999、最长恢复、恢复分布、用户影响分钟数放进发布门禁和事故复盘。

回到开头，Alice 等到的不是 100 毫秒，Alex 感受到的也不是 1 分钟。用户踩中的，是被时间放大的那一段。

报表可以按事件数算，用户不会。