七分钟内掌握如何正确测量延迟
正确测量延迟需要高质量的数据。KPMG 的 2016 Global CEO Outlook（ibm.com 外部链接）发现，84% 的 CEO 对他们用来做决策的数据质量表示担忧，这是因为数据往往可能具有误导性。
重视数据与不重视数据的公司之间存在巨大差异。麻省理工学院的研究人员发现（ibm.com 外部链接），采用数据驱动设计的公司，其产出比根据其他投资和信息技术使用情况预期的产出高出 5%–6%。仅这一点就足以说明，理解延迟对企业成功至关重要。
只需七分钟，就能掌握关于测量延迟的所有关键内容：
- 如何测量延迟
- 为什么正确测量很重要
- 查看延迟数据时常见的陷阱
- 即时反馈的重要性
- 为什么需要未抽样数据
Dictionary.com （ibm.com 外部链接）将延迟定义为“硬件系统的一个组件在等待另一个组件执行某个操作时的延迟时间”。更简单地说，它指的是调用一个函数与其实际执行之间的时间。延迟存在于所有系统中；即使我们拥有一个完美的系统（实际上不存在），也仍然会存在延迟，因为电子在计算机中切换晶体管的开关状态需要时间。
在小规模操作中，延迟并不是什么大问题，但在处理数百万次操作时，数百万次延迟会迅速累积。延迟并不是由工作单元和时间定义的，而是取决于它的行为。监控工具会报告从函数开始到函数结束所需的时间。
延迟可能对业务产生重大影响例如（ibm.com 外部链接）：“在移动端速度方面，每一秒都很关键，每增加一秒移动页面加载时间，转化率可能下降多达 20%。”
延迟几乎从不遵循正态（高斯）分布或泊松分布。即使您的延迟确实符合其中一种分布，由于我们观测延迟的方式，也会导致平均值、中位数甚至标准差变得无用。例如，如果您在测量页面加载时间，99.9999999999% 的加载可能比您的中位数更慢。这也是随机抽样延迟会导致数据不准确的原因之一，关于这个话题，我们稍后会详细讨论。
此时，您可能会问自己，如果我们不使用标准差，如何才能有意义地描述延迟呢？答案是我们必须关注百分位数和最大值。大多数人会想，好吧，我查看 P95，就能理解“常见情况”。问题在于，这种方法会掩盖所有不良情况。正如 Azul Systems 首席技术官 Gil Tene 所说：“这是一种‘营销系统’。有人被骗了。”
以这张图为例：
当您看到这张图时，就能清楚地理解为什么其中位数和平均值没有实际意义，它们无法显示问题区域。当看到第 95 百分位数向左急剧上升时，您可能认为自己看到了问题的核心。然而，事实并非如此。当您调查程序出现波动的原因时，实际上忽略了表现最差的 5%。要出现这种尖峰，数据中表现最差的 5% 必须明显更糟。
现在看看同一张图，同时显示了第 99.99 百分位数：
红色线表示第 95 百分位数，而绿色线表示第 99.99 百分位数。您可以清楚地看到，第 95 百分位数仅显示了 22 个问题中的 2 个，这也说明了为什么必须查看数据的完整范围。
许多人可能认为最后 5% 的数据并不重要。当然，这可能只是虚拟机 (VM) 重启、系统出现短暂波动或类似情况，但如果忽略它，您就等于在说这些情况不会发生，而它们可能正是您最需要关注的关键问题之一。
Gil Tene 喜欢发表大胆的言论：“永远不应该舍弃的首要指标是最大值。那不是噪声，那是信号。其余的都是噪声。”确实，在大规模系统中，最大值是一个很好的单一指标，但单纯追求最大值往往不切实际。没有系统是完美的，波动在所难免。在大规模的实际系统中，仅追求最大值往往会让开发团队不堪重负。
当查看第 99.99 百分位数时，您看到的是大多数客户的实际体验，任何在那里出现的尖峰都是实际问题；而最大值中的尖峰可能只是系统中的一次短暂波动。当您的 DevOps 团队将精力集中在这些小波动上时，他们付出了巨大的机会成本，因为无法同时处理更重要的问题。
值得注意的是，如果您的第 99.99 百分位数和最大值非常接近，并且两者都有尖峰，那么这就是一个很好的信号，表明这是您的团队应当处理的问题。从这个角度来看，Gil 的观点部分正确：最大值确实是一个很好的信号，但他认为其余数据都是噪声的说法则不对。正如这张图所示，在前面的例子中，我们的第 99.99 百分位数和最大值完全一致。这是一个很好的信号，表明您看到的是真正的问题所在，而不仅仅是一次短暂波动：
比仅查看第 95 百分位数更糟糕的一个陷阱，是未能意识到他们的百分位数被取了平均值。对百分位数取平均在统计学上是荒谬的；它会完全消除所关注数据的意义。我们已经展示了在观察延迟时平均值并不可靠，如果查看的是平均后的百分位数，您实际上又回到了原点。许多软件程序都会对百分位数取平均。例如，看看这张 Grafana 图表：
无论您之前是否意识到，这张图表上的所有百分位数都是平均值。x 轴图例上也明确写了这一点。几乎所有监控服务都会对您的百分位数取平均值。这是由于预计算造成的现实。当监控服务接收您的数据时，它会计算该分钟数据的百分位数。
然后，当您查看第 95 百分位数时，它显示的是所有百分位数的平均值。这种为了“方便您”而采取的、旨在加快服务速度的捷径，实际上却消除了数据的所有统计意义。
无论您是否意识到，当监控工具参与数据抽样时，它们实际上是在生成平均数据。几乎所有监控工具都会对数据进行抽样。例如，Datadog 就存在重大数据丢失问题。如果在一分钟内发送 300 万个数据点，它不会全部接收。而是随机抽样这些数据点，然后将它们聚合为每分钟一个点。
要了解延迟，必须使用未抽样数据。采用抽样数据本质上无法获取完整的数据分布。您的最大值不是真正的最大值，您的全局百分位数也不能准确反映实际情况。
当您对数据进行采样时，就遗漏了数据。例如，假设您在一分钟内有 10,000 次操作，每次操作向监控系统发送 2 个数据点。假设系统中存在一个 bug，每 10,000 次操作中只有 1 个数据点显示该 bug。您的监控系统选择这个 bug 作为显示最大值的数据点的概率只有 1/20,000。
如果运行足够长时间，该数据点最终会出现，但结果看起来像是偶发的边缘情况，即使它实际上每分钟都发生在某位客户身上。当您不对数据进行抽样时，这类尖峰会在第 99.99 百分位数中清晰显示，最大值也会接近它，从而提示程序中存在 bug。然而，如果对数据进行抽样，它出现的频率就会降低，这意味着您不会将其视为 bug，而只会认为是一次短暂波动。这个结果意味着您的工程团队将无法意识到它的重要性。
不要让监控工具误导您，以为自己了解延迟的真实情况。IBM Instana 软件的一个关键功能是能够高效测量延迟。IBM Instana 软件使用先进的分析和机器学习 (ML) 技术，实时自动检测延迟问题，使开发人员和 IT 团队能够快速识别性能问题的根本原因，并在影响用户之前采取纠正措施。
请选择不提供抽样数据的工具。请选择不对全局百分位数取平均的工具。