Alice 很没耐心：为什么你的服务和你的用户对延迟的理解完全不同

原文来源：Marc Brooker — 服务端工程师用请求视角度量延迟，用户用时钟视角体验延迟，两者之间的鸿沟远比你以为的大

Alice 很没耐心

Alice 用你的 Web 服务。Alice 和所有人一样，用秒和分钟来度量时间。她说你的服务很慢。你告诉她，服务的平均请求延迟是 100ms。

但 Alice 说，她感受到的平均等待时间是 1 秒。

你们俩都没错。

再认识一下 Alex。Alex 也用你的服务。他说你们出故障的时候，故障持续很长时间，让他非常恼火。你告诉他，服务的平均故障恢复时间（MTTR）不到 1 分钟。

但 Alex 说，他经历的平均故障时长是 1 小时。

你们俩也都没错。

到底发生了什么？

你在用请求或故障的视角度量时间，而 Alex 和 Alice 在用秒和分钟来度量时间。当一个请求特别慢、一次故障特别长时，Alex 和 Alice 会感受到很长的时间，给它很大的权重。但你只把它算作一次。

技术上，这叫做检查悖论（inspection paradox）。

Alex 和 Alice 体验的不是你的延迟分布 $f(t)$，而是它的加权版本——权重就是时间本身。如果你的平均延迟（或 MTTR）是 $E[X]$，那么 Alex 和 Alice 体验到的其实是：

E_a[X] = E[X²] / E[X] = E[X] + Var(X) / E[X]

他们等待的大部分时间里，等的都是那些花了很长时间的事情。这就是人类体验时间的真实方式。

为什么尾巴比你以为的重要得多

我们来做一个小模拟。

假设服务的中位恢复时间是 30 分钟——也就是说，你有一半的事故复盘里，恢复时间不超过半小时。而 P99 是 600 分钟——每 100 次故障里，有一次要花 10 小时才能恢复。

你的 MTTR 算出来刚过 1 小时。

但你的用户感受到的故障平均恢复时间是多少？大约 6 小时。

6 倍差距。

这个差距来自方差。当方差大时，时间加权平均值远高于普通平均值。那些极少发生的长时间故障，在用户的感受中被极大地放大了。

你的事故复盘里，"平均恢复时间 1 小时"看起来还不错。但你的用户在客服投诉里说的是"昨天晚上有将近 6 个小时用不了"——他们也是诚实的。

超时重试能救吗？

对于服务延迟，超时加重试可以在一定程度上掩盖尾延迟的问题——只要正在处理的请求没有持有锁或其他独占资源。客户端超时后重试，可能会落在正常的节点上，躲开那个慢的。

但对于故障恢复时间，没有任何隐藏手段。尾部的厚重程度至关重要。

这也是我不喜欢用截断均值（trimmed mean）之类的方法来衡量延迟或恢复时间的原因之一。它们扔掉了关于右侧尾部形状的关键信息——而恰恰是那个尾巴，主导了用户的真实体验。另一个原因和利特尔定律（Little's Law）以及容量使用有关，我之前写过。

这对你意味着什么

如果你的延迟分布有较大的方差，你的指标和用户的感受之间就会有巨大的鸿沟。"平均延迟 100ms"是真实的，"用户感觉 1 秒"也是真实的。两者同时成立。

这意味着几件事：

不要只看平均值。 平均值告诉你的是"我的服务表现如何"，而不是"用户觉得我的服务表现如何"。如果想理解后者，你需要看 P50、P95、P99，更需要理解分布的形状。

方差是敌人。 如果所有请求都在 50-100ms 内完成，用户的感受和你的指标会很接近。但如果 90% 的请求在 50ms 完成，10% 的需要 1 秒，用户就会觉得你的服务慢——因为他们的大部分等待时间都花在了那 10% 上。

不要截断你的指标。 去掉极端值来看看"典型表现"的做法，实际上是在扔掉那些决定用户体验的信息。那个让你难堪的 P99.9 延迟，恰恰是用户注意到你的服务变慢的原因。

尾巴哲学

Marc Brooker 是 AWS 的资深工程师，参与过 EC2、EBS、数据库、Serverless 等核心服务的构建。这篇文章用一个简单的数学公式，解释了服务指标和用户体验之间那个令人困惑的鸿沟。

下次你的仪表盘显示一切正常，但用户抱怨却不断涌来的时候，先别急着怀疑监控。想想 Alice 和 Alex——他们用时钟度量时间，而你用请求度量时间。在你们的视角合二为一之前，那些"不公平"的抱怨，其实都有它的道理。

这个悖论还有个让人不太舒服的推论：如果你的系统足够大、请求足够多，那么在任何一个时刻，都有正在忍受慢请求的用户。你改善尾延迟的每一分努力，都直接转化为这些用户节省下来的等待时间——这就是为什么以尾巴为中心的优化，最终会变成以用户为中心的优化。