数据可观测性的基础知识

第 8 章 让不透明的系统变得透明 让不透明系统变得透明

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在前几章中，当我介绍低代码无代码解决方案时，我列举了一些开箱即用的策略，这些策略可用于生成数据观测结果，直到这些解决方案发展成为原生的数据可观测方案。

其他通常为人熟知的系统与这些解决方案类似，因为它们具有相同的特点：数据使用发生在引擎盖下的引擎中。打开它既没有效率（成本和时间效益），也不值得推荐。

如果系统不能清楚地显示其引擎或数据的使用情况，就会存在重大风险。主要问题是，用户无法访问系统，分析是否存在任何可能导致问题的问题。缺乏透明度意味着用户无法找出问题的根本原因，这就迫使他们为下游系统打补丁，而不是解决上游问题。这些系统的另一个问题是丧失了对其内部行为的了解。

虽然人们过去可能已经成功配置或开发了它们，但很少有人仍然拥有了解其作用的内部知识。因此，第 4 章和第 5 章中介绍的实现数据可观察性的策略可能并不适用。不过，本章将介绍针对这些不透明系统的策略，这些策略可以让用户更接近数据可观察性，而不一定要满足其所有原则。

这些策略将使系统的部分数据可被观察到，或者说是 "数据半透明"，从而让用户更好地了解其内部行为。

数据半透明

想象一下，你有一个钢制保险箱，后面有一束强光。你只能看到保险箱的外面，里面的东西都被隐藏起来了。 这就是一个不透明系统。现在再想象一个磨砂玻璃制成的盒子放在灯光前。你仍然无法看清盒子里到底有什么，但你可以看到它的形状。也许影子看起来像一个机械钟。现在你知道了，你可以听一听 "嘀嗒嘀嗒 "的声音，看看时钟是否在正常工作。数据半透明性代表了部分数据可观测系统新增或原生支持的数据可观测能力。

在第 2 章中，我定义了数据可观测性原则，认为这是产生和利用数据价值的基础。回顾一下，数据可观测系统会同步生成数据观测结果，并不断验证其预期。

因此，数据透明系统可分为以下一类或两类：

• 至少有一条数据可观察性原则未得到遵守。

• 至少有一项数据可观测性原则仅得到松散的支持。

让我们举几个例子来说明这一概念。

滞后数据观测

一个应用程序会生成有关其数据使用环境的观察结果并验证其预期，但由于它使用的是预先计算的指标（例如，在前一步中），因此它所消耗数据的指标与其运行时间并不同步。可能出现的问题之一就是验证失败。应用程序会停止运行，因为它估计会产生垃圾。然而，指标是每两小时计算一次的，在此期间会应用解决程序。在这种情况下，连续验证会产生错误的否定结果。

部分语境

应用程序生成的数据观测结果会遗漏某些上下文要素，例如报告其当前版本。这将导致在开发具有更新数据转换和验证功能的新版本应用程序时出现问题。你可以看到这种情况的出现；生产环境可能同时运行两个版本，或者旧版本没有经过适当部署（即无法运行，但部署过程中没有错误），从而导致数据源被不适当地视为有效，或者验证失败。另一方面，您可能会认为已经部署了新版本。因此，您会从错误的地方（如数据或新的应用程序版本）来了解出现的情况。

你可能会问，如果这些系统无法实现完全的数据可观测性，那为什么还要为它们费心呢？这很公平。我的回答是，数据可观察性不足而无法发挥作用的情况远少于数据半透明能为您节省时间、金钱、精力和信任的情况（即number of “not enough” << number of “good enough” ）。不过，由于您知道这些系统并非完全数据可观测，因此在利用从其暴露信息中获得的洞察力时，您会采取额外的预防措施--这种意识有助于降低做出不恰当决策的概率，例如在滞后数据观测和部分上下文示例中。 ...