关于我 我的名字是Marc Brooker。我喜欢构建能够运行的事物，并做一些酷炫的事情。我喜欢建造大型物件。我还涉猎机械加工、焊接、烹饪和滑雪。我是亚马逊网络服务（AWS）的一名工程师，工作地点在西雅图，专注于代理人工智能，尤其是代理人工智能的安全性和政策。在此之前，我曾参与过EC2、EBS、数据库、无服务器和无服务器数据库的工作。所有观点均为我个人所有。 链接 我的出版物和视频 @marcbrooker在Mastodon上 @MarcJBrooker在Twitter上 这篇博客是由人工智能写的吗？你是什么意思？ 认识爱丽丝。 爱丽丝使用你的网络服务。和大多数人类一样，爱丽丝用秒和分钟来衡量她的时间。爱丽丝说你的服务很慢。你告诉爱丽丝，你的服务平均请求完成时间为100毫秒，但爱丽丝说她的平均等待时间是1秒。你们两个都是对的。 认识亚历克斯。 亚历克斯使用你的网络服务。像大多数人一样，亚历克斯也用秒和分钟来衡量他的时间。亚历克斯说当你出现故障时，持续时间很长，他真的很烦恼。你告诉亚历克斯，你的平均故障恢复时间（MTTR）不到1分钟。亚历克斯说他看到的平均故障持续时间为1小时。同样，你们两个都是对的。 发生了什么？ 发生的事情是你在以请求或故障的数量来衡量时间，而亚历克斯和爱丽丝是在以秒和分钟来衡量时间。当你有一个长请求或长故障时，亚历克斯和爱丽丝会将其视为很长一段时间，重量很重。但你只把它计算为一次。从更技术的角度来看，这里发生的事情是检查悖论。亚历克斯和爱丽丝并没有体验到你的延迟分布$f(t)$，他们体验到的是其t加权版本。如果你有平均故障恢复时间或平均请求时间$ ext{E}[X]$，亚历克斯和爱丽丝的体验为$ ext{E}_a[X] = rac{ ext{E}[X^2]}{ ext{E}[X]} = ext{E}[X] + rac{ ext{Var}(X)}{ ext{E}[X]}$。他们大多数时间都在等待，他们在等待的事情往往需要很长时间。这就是人类体验时间的（大致）方式。 让我们通过一个小模拟来玩一下。插入你的中位延迟（或恢复时间）和99百分位延迟（或恢复时间），我们将对此拟合对数正态分布，然后绘制你的服务指标所看到的和你的客户所看到的。 中位数：毫秒 99百分位数：毫秒 你的服务的平均看到：–毫秒。 你的客户的体验平均：–毫秒。 例如，输入30作为中位数（我们暂时忽略毫秒，假装这些是分钟）作为30分钟的中位故障恢复时间（即，在你的一半事故分析中，你看到的恢复时间为$ ext{≤}30$分钟），输入600作为99百分位数（每100个事件中，有1个事件的恢复时间为10小时）。你的平均故障恢复时间稍超过1小时。你的客户的平均恢复时间大约为6小时！ 有许多理由说明为什么尾部延迟（和长恢复时间）如此重要（例如，多个样本），但我认为这是我认为最少被理解的一个理由。对于服务时间，超时和重试可以在某些时候隐藏这种延迟（只要正在运行的请求不持有锁或其他独占资源）。但是，对于恢复时间，无法做到这种隐藏。尾部的严重性非常重要。这也是我不喜欢修剪测量（如修剪平均值）作为思考服务延迟或恢复时间的一种方式的原因之一。它们抛弃了一些关于右尾形状的真正关键上下文，这支配着客户体验（另一个原因与Little定律和容量使用有关，我之前也写过）。 关于对数正态的说明：我在这里选择对数正态是因为数值上的方便。它具有一个良好的特性，即 $ ext{lognormal}( ext{μ}, ext{σ}^2)$ 变成 $ ext{lognormal}( ext{μ}+ ext{σ}^2, ext{σ}^2)$。另外，它在0附近表现良好。我不认为对数正态是延迟或恢复时间指标的特别好选择，通常会完全以非参数的方式处理这些问题。