认识爱丽丝。爱丽丝没耐心

# 认识一下爱丽丝。爱丽丝很没耐心。 来源：https://brooker.co.za/blog/2026/06/19/waiting.html ## 关于我 我叫 Marc Brooker。我喜欢构建能用的东西，做酷炫的事。我喜欢构建大型系统。我还会些机械加工、焊接、烹饪和滑雪。 我是亚马逊云服务（AWS）在西雅图的一名工程师，从事智能体AI方面的工作，特别是智能体AI的安全与策略。在此之前，我参与过EC2、EBS、数据库、无服务器计算以及无服务器数据库等项目。所有观点都是我个人的。 ## 链接 我的出版物和视频 (https://brooker.co.za/blog/publications.html) @marcbrooker on Mastodon (https://fediscience.org/@marcbrooker) @MarcJBrooker on Twitter (https://twitter.com/MarcJBrooker) 这个博客是AI写的吗？(https://brooker.co.za/blog/2026/06/18/my-blog-and-ai.html) 你指的是什么？ 认识一下爱丽丝。爱丽丝在使用你的网络服务。爱丽丝和大多数人一样，用秒和分钟来衡量时间。爱丽丝说你的服务很慢。你告诉爱丽丝你的服务平均请求完成时间是100毫秒，但爱丽丝说她平均等待时间是1秒。 你们俩都对。 认识一下亚历克斯。亚历克斯在使用你的网络服务。亚历克斯和大多数人一样，用秒和分钟来衡量时间。亚历克斯说当你的服务发生故障时，故障持续时间很长，让他非常恼火。你告诉亚历克斯你的MTTR（平均修复时间）不到1分钟。亚历克斯说他看到的平均故障持续时间是1小时。 你们俩又都对。 这是怎么回事？其实很简单：你在用请求或故障次数来度量时间，而亚历克斯和爱丽丝在用秒和分钟来度量时间。当一个请求或故障持续很长时间时，亚历克斯和爱丽丝会把它算作很长的一段时间，权重很大。但你只把它算作一次。 更技术化地说，这里涉及的是**检查悖论**。亚历克斯和爱丽丝体验到的并不是你的延迟分布 $f(t)$，而是它的一个加权版本，权重就是时间本身。如果你的MTTR或平均请求时间为 $\mathbb{E}[X]$，那么亚历克斯和爱丽丝体验到的平均值是 $\mathbb{E}_a[X] = \frac{\mathbb{E}[X^2]}{\mathbb{E}[X]} = \mathbb{E}[X] + \frac{\mathrm{Var}(X)}{\mathbb{E}[X]}$。 他们等待的大部分时间里，都是在等待那些耗时很长的事情。这（大致上）就是人类体验时间的方式。 让我们通过一个小模拟来实验一下。输入你的中位数延迟（或恢复时间）和99百分位延迟（或恢复时间），我们将拟合一个对数正态分布，然后分别画出你的服务指标看到的值和你的客户体验到的值。 中位数：毫秒 p99：毫秒 你的服务看到的（平均值）：**–毫秒**。你的客户体验到的（平均值）：**–毫秒**。 举个例子，输入30作为中位数（先忽略毫秒单位，假设这些是分钟），即中位数恢复时间为30分钟（也就是说，在一半的事后分析中，你会看到恢复时间 $\leq 30$ 分钟），再输入600作为p99（每100次事件中有一次，恢复需要10小时）。那么你的MTTR刚过1小时。而你的客户体验到的平均恢复时间大约是6小时！ 有很多理由说明为什么尾部延迟（以及较长的恢复时间）对于理解非常重要（例如多重采样 (https://brooker.co.za/blog/2021/04/19/latency.html)），但我觉得上面这一点是最不被广泛理解的。对于服务延迟来说，超时重试有时可以隐藏这种延迟（只要正在运行的请求不持有锁或其他独占资源）。但对于恢复时间来说，无法进行类似隐藏。尾部的厚重程度影响巨大。这也是我不喜欢用修剪后的度量（如修剪均值）来思考服务延迟或恢复时间的原因之一。它们丢弃了一些至关重要的上下文信息，即右尾的形状，而正是这个右尾主导了客户体验（另一个原因与利特尔法则和容量使用有关，我之前写过 (https://brooker.co.za/blog/2017/12/28/mean.html)）。 *关于对数正态分布的说明：*我选择对数正态分布是出于数值计算上的便利。它有一个很好的性质：$\mathrm{lognormal}(\mu, \sigma^2)$ 经过变换后会变成 $\mathrm{lognormal}(\mu + \sigma^2, \sigma^2)$。而且它在0附近的表现也很好。我并不认为对数正态分布是延迟或恢复时间指标的特别好的分布选择，通常我会完全用非参数的方法来处理这些问题。