可观测性旨在让每一位工程师能够根据对所有系统和应用程序的数据分析，主动地对工作任务进行优先级排序。
译自 'Observability' Is Not Observability When It Comes to Business KPIs，作者 Eric Futoran。
当我们想到“可观测性”时，我们大多数人将其定义为“指标、日志和跟踪”。并非如此。我们真正想说的是丰富和观察那些预定义的数据集，然后在它们之上分层分析，以便更好地衡量和理解业务**关键绩效指标** (KPI) — 主动地。
换句话说，可观测性不仅仅是收集和整理数据集。它不仅仅是关于警报、关联和正常运行时间。可观测性是让每一位工程师，尤其是 DevOps 之外的工程师，能够根据其所有系统和应用程序的数据分析主动地优先考虑工作。
而且这些数据远远超出了指标、日志和跟踪。
我们需要将这三个信号连接到我们公司的真正驱动力——业务 KPI。这需要改变我们团队的运作方式。他们不应该专注于救火演习和技术 KPI，而应该只关注能带来最高业务价值的工作，无论是增加收入、改善最终用户体验还是减少流失。说起来容易做起来难。
让我们讨论一下我们如何达到**可观测性的当前状态以及我们需要重新考虑**我们对它的方法。
从前，我们的目标是观察来自各种应用程序的数据，无论这些应用程序是托管在专用服务器、云中还是最终用户设备（移动和网络）上。想象一下我们可以观察到的数据流。
我们使用代理来更轻松地集成和收集数据；但是，它们从未收集所有数据，只是在特定时间段内收集某些类型的数据。想象一条顶部有水坝的河流，它会涓涓细流，并定期让特定的水滴通过。看着这条河流，我们只看到了水坝允许通过并希望我们看到的东西。
这种 APM 方法导致我们的反应过于迟钝。我们对错误 日志和指标 进行检测以收集更多信息，寻找崩溃，并基本上依靠我们的供应商来决定应该让哪些数据通过。我们失去了对我们系统的完整了解，当我们确实看到错误或异常趋势的指标时，我们通常没有解决它的上下文数据——至少在合理的时间范围内没有。
我们让问题得不到解决，而是专注于最容易解决的问题，比如网络错误。我们无意中对实际上 影响我们业务 KPI 的问题视而不见。
我们这样做是可以理解的，因为使用 APM 解决方案中有限的数据类型来回答以下问题远非易事：
- 错误发生在与最终用户体验相关的什么位置，这些错误真的重要吗？
- 崩溃激增是否导致购买量下降？
- 网络错误的增加是否对我们的业务产生了很大影响——或者根本没有影响？
- 对于我们的路线图和业务来说，Apdex 分数真正意味着什么？
我们想知道的不是“这些问题是否低于某个阈值？”而是“我们是否阻止了客户成功地与我们的业务互动？”
作为一种潜在的解决方案，我们问自己，“如果我们不进行抽样，而是让所有数据通过会怎样？如果我们打破水坝会怎样？”这个问题的承诺很有吸引力，肯定比我们之前（仍然存在）的基于代理的 APM 更好。
所以我们打开了水坝。
有了如此 大量的数据 ，复杂性变得非常大，所以我们把这种非结构化数据流拼凑成我们理解的形式——指标、日志和跟踪。它比之前的 APM 方法好得多，也更容易使用。我们可以更好地识别错误和异常趋势的指标；我们可以在每次发布时减少对代码的检测；我们可以更快地检测到问题；我们希望拥有更多上下文数据以更快地解决问题。
即便如此，当我们将所有 数据推送到可观测性的三个熟悉的支柱 中时，我们又回到了老习惯。迎合不同支柱的数据库和服务出现了，我们创建的工作流通常过于偏向于其中一个支柱，而不是考虑三个支柱可以共同提供的内聚结果。
当工程师着手解决问题——甚至去理解一个问题是否值得投入资源去解决——他们通常从一种与三个支柱之一相关的途径开始。然后，他们必须与其他两个支柱建立连接或进行复杂的查询，这些连接或查询可以综合到一个活动日志中。这项工作通常最终变得非同小可，因为工具提供的连接不足以有效地链接这三个独立的支柱。
因此我们回到了一个地方（尽管有了更多数据），与 APM 范例中的位置没有太大的脱节。
同样变得非常明显的是，更多的数据并不能从根本上解决所有问题。在某种程度上，我们只是用新的问题取代了旧的问题。我们有更多的数据来解决问题，但这常常导致仪表盘蔓延，而不是将数据提炼成有用的信息。
我们的团队构建了收集非结构化数据的系统，但我们未能充分发挥其潜力。
因此，我们的工程团队仍然是被动的，专注于 Apdex、SLO 和 SLA——而不是真正的业务驱动型 KPI。
我们都发现自己在不断寻找更快速地识别和解决问题的方法，但我们真正想要的是转向“主动”的范例。毕竟，如果我们只专注于更快地解决问题——错误地将主动性等同于速度——那么我们将永远根据技术 KPI 应对紧急情况。当然，我们会做得更快，但我们不会为我们的业务做出最佳决策。
“主动性”意味着根据核心业务指标的前瞻性指标来运行所有工程工作。 映射到购买流程、启动时间、用户放弃的指标——这些指标是我们应用程序特有的，反映了我们的业务所关心的内容，如流失、收入和 LTV。
这些前瞻性指标应该针对我们的业务，并最终与我们应用程序的最终用户联系起来。因此，无论我们最终采用何种数据结构，其真正目标都必须反映最终用户体验——而不是近视、脱节的后端指标和 KPI。任何低于此标准，我们都无法将技术故障与业务故障联系起来——肯定无法在没有大量繁琐工作和猜测的情况下做到这一点。
毕竟，应用程序不是后端。仅仅关心网络调用是否失败或进程是否中断是不够的。应用程序也不仅仅是前端。仅仅关心移动应用程序是否崩溃或网站是否冻结是不够的。可观测性是关于理解各个用户体验的一切。
具体到可观测性的当前形式，主动性并不是基于我们的日志、指标和跟踪的前瞻性指标。相反，主动性是关于寻找基于我们用户的前置指标，然后使用指标、日志、跟踪和其他类型的数据来理解我们的应用程序在哪里崩溃，为什么与用户连接的指标趋势不正确，以及需要做什么来解决问题。
因此，当我们查看我们的后端指标时，我们的数据是否揭示了最终用户何时有糟糕的体验？我们的可观测性供应商是否衡量了中断体验和收入损失的下游影响？
不幸的是，现在的答案是：他们没有。
我们知道可观测性需要走向何方。了解我们系统的状态只是第一步。下一步是了解我们用户体验的状态。通过这种方式，我们根据业务 KPI 而不是仅仅根据技术 KPI 做出决策。