4. Latency 分布分析：平均值、中位数、百分位数（p50/p90/p99）的适用场景

在可观测性工程中，仅靠单一聚合值（如平均延迟）来描述系统性能是危险的。Latency 数据通常呈现长尾分布，平均值极易被极端值拉偏，掩盖真实用户体验。本章深入剖析平均值、中位数与百分位数的数学含义、适用场景及在 SLO 门限设定中的联动策略。

4.1 平均值（Mean）的陷阱与有限用途

平均值是所有请求延迟的算术总和除以请求总数。计算简单，但对异常值极度敏感。一次 10s 的超时请求，足以将 99 次 100ms 的正常请求平均值从 100ms 拉高到约 200ms，造成“系统变慢”的假象。

平均值仅适用于以下有限场景：

• 容量规划粗筛： 在相同流量水位下，平均值趋势上升可提示资源瓶颈。
• 批处理任务： 对延迟一致性要求不高的离线作业，平均值可衡量整体吞吐效率。
• 与百分位数对比： 当平均值远高于 p50 时，明确指示存在严重长尾。

4.2 中位数（p50）—— 典型用户的体验锚点

中位数（第 50 百分位）表示将延迟数据从小到大排序后，位于中间位置的值。它不受极端值影响，能稳定反映“一半用户”的真实感受。

适用场景：

• 内部性能基准： 衡量代码优化前后的“典型”性能变化。
• 基础设施监控： 网络延迟、磁盘 IO 等底层指标，p50 比平均值更稳定。
• 与 p99 联合分析： p50 低而 p99 高 → 系统存在偶发毛刺；p50 与 p99 同时升高 → 普遍性性能退化。

4.3 百分位数（p90 / p99）—— 长尾与 SLO 的核心

百分位数是 SRE 设定延迟 SLO 的黄金标准。p99 表示 99% 的请求延迟低于该值，只有 1% 的请求可以容忍更慢。这直接对应“绝大多数用户获得良好体验”的业务目标。

4.3.1 p90 vs p99 的选择策略

选择原则：

• 业务重要性： 核心支付链路用 p99，日志导出用 p90。
• 成本与噪声： p999 需要大量数据样本，且易受 GC、网络抖动等偶发因素干扰，门限不宜过紧。
• SLO 预算分配： 将大部分错误预算分配给 p99，小部分给 p90，避免过度投资于极端尾部。

4.4 分布分析可视化：从指标到决策

下图展示了同一系统在两种负载下的延迟分布对比，直观说明平均值如何掩盖长尾，以及百分位数如何暴露真实瓶颈。

4.5 百分位数与 SLO 门限联动实战

在 SLO 定义中，延迟门限通常表述为：“在滚动窗口（如 30 天）内，99% 的请求延迟 ≤ 200ms”。这等价于：p99 ≤ 200ms。以下是联动设定步骤：

1. 采集原始分布： 使用 Prometheus Histogram / DataDog Distribution 等工具，记录每个请求的延迟，不预先聚合。
2. 计算高百分位数： 通过 PromQL histogram_quantile(0.99, ...) 或类似函数实时计算 p99。
3. 设定门限基线： 观察过去 7 天 p99 的 P95（即 p99 的典型值），作为初始门限。
4. 对齐业务容忍度： 与产品团队确认“最慢的 1% 用户最多能接受多少延迟”，转化为 p99 目标值。
5. 设置 SLO 与错误预算： 例如：p99 ≤ 200ms 达成率 99.9%，每月错误预算为 0.1% × 总请求量。
6. 持续校准： 每次发布后对比 p50 与 p99 的变化趋势，判断是普遍退化还是尾部恶化。

4.6 总结：选择矩阵