文章通过Alice和Alex的例子，说明用户感知的服务延迟和故障时长往往远高于系统统计的平均值，揭示了平均指标与个体体验之间的差异。

好的，这是根据您的要求，对原文主要内容进行的中文重述，保留了核心细节并删除了与主题无关的个人介绍和链接部分。

标题：爱丽丝的等待

爱丽丝在使用你的网络服务。和大多数人一样，她以秒和分钟来衡量时间。她说你的服务很慢。你告诉她，服务的平均请求完成时间是100毫秒，但爱丽丝坚持说她感受到的平均等待时间是1秒。你们俩都对。

亚历克斯也在使用你的服务。他说你的服务中断时间很长，让他非常恼火。你告诉他，你们的平均修复时间（MTTR）不到1分钟。但亚历克斯说他经历的平均中断时长是1小时。同样，你们俩也都对。

这是怎么回事？关键在于，你是在用“请求次数”或“中断次数”来计量时间，而爱丽丝和亚历克斯是用“秒”和“分钟”来计量。当一个请求或一次中断耗时很长时，爱丽丝和亚历克斯会认为这段时间很长，并赋予它很大的权重；但在你的统计里，它只算作一次。

从技术上讲，这被称为“检查悖论”。用户并非体验你的延迟分布，而是体验其加权版本。大多数时候，用户等待的正是那些耗时很长的请求。这大致就是人类感知时间的方式。

我们可以通过一个模拟来理解。输入你的中位数延迟（或恢复时间）和第99百分位延迟（或恢复时间），我们会拟合一个对数正态分布，然后分别绘制出你的服务指标所看到的情况和用户实际体验的情况。

例如，假设中位数恢复时间为30分钟（即一半的事故恢复时间在30分钟内），第99百分位恢复时间为600分钟（即每100次事故中，有一次恢复需要10小时）。那么，你的平均修复时间（MTTR）仅略高于1小时。但你的用户所体验到的平均恢复时间却接近6小时！

理解尾部延迟（和长恢复时间）之所以重要，有很多原因，但这一点我认为是最容易被忽视的。对于服务延迟，超时和重试有时可以掩盖这种长尾效应（只要正在运行的请求不持有锁或其他独占资源）。但对于恢复时间，这种掩盖是不可能的。尾部的“沉重”程度至关重要。这也是我不喜欢使用修剪后的测量值（如修剪均值）来评估服务延迟或恢复时间的原因之一，因为它们丢弃了关于右尾形状的关键信息，而正是这个右尾主导了用户体验。

注：此处选择对数正态分布是出于数值计算的便利性，并非认为它是延迟或恢复时间指标的最佳分布模型。

根据评论内容，总结主要观点如下：

1. 关注尾部延迟（p99）比中位数更重要
- 评论1（trb）强调：所有用户都会经历尾部延迟，优化最差情况比优化中位数更能帮助用户。
- 引用："By focusing on the tail and optimizing worst cases you help users more than by improving your median latency."
- 引用："All users will at some point experience a <1% request..."

2. 批评文章缺乏数学严谨性
- 评论2（rustybolt）认为文章内容空洞，要求提供数学推导。
- 引用："This article contains very little substance. Show me the math!"
- 评论3（zaik）质疑公式的直观性。
- 引用："Is the formula for E_a[X] trivial? I don't see it immediately..."

3. 反对传统尾部指标，主张用户视角的“不可接受体验”
- 评论4（perching_aix）认为p99误导，应关注“多少用户经历了糟糕体验”，并指出p99导致服务容忍过高故障率。
- 引用："What I look at these days is what share of unique users experience an 'unacceptable experience'..."
- 引用："It's pretty hard to argue for fixing something when it's presented as only going wrong 0.5% or less..."

4. 文章核心洞察：系统视角与用户视角的统计差异
- 评论8（glitchc）肯定文章揭示了“观察者体验的统计与系统性能统计不同”的深刻见解。
- 引用："An observer using the system experiences different statistics from the system operator."
- 引用："One must not confuse the two when designing systems."

5. 对“时间加权”概念的质疑与澄清
- 评论7（amluto）批评文章对“时间加权”的解释不清，认为应区分请求延迟和故障时长。
- 引用："I found this article to be a very poor explanation of what (I think) it's trying to say."
- 引用："What does the statement that 'Alex and Alice experience E_a[X]' even mean?"
- 评论9（penteract）类比红绿灯，指出时间加权更适合衡量故障而非请求延迟。
- 引用："It's a better metric for looking at outages - instantaneous outages don't affect anyone..."

6. 建议引入排队论
- 评论10（reisse）指出排队论可更真实估计等待时间，文章未提及。
- 引用："There is a branch of math dedicated to... truthfully estimating the waiting time, called queueing theory."
- 引用："I wonder why it wasn't mentioned in the article."

7. 对亚马逊实践的讽刺
- 评论5（ggm）以亚马逊搜索为例，指出公司明知用户体验差却因平均利润高而容忍。
- 引用："Amazon can show on average they make more money doing this..."
- 引用："apply that to Amazon design heuristics like author name search on books..."

8. 对文章主题的误解与兴趣
- 评论6（uberex）误以为文章讨论TTFB与渲染时间，但发现是其他内容，表示兴趣。
- 引用："At first I assumed it would be about TTFB vs. time to render... but it isn't that..."
- 引用："I am very interested in this article though."