在领导IT运营的时间里，我喜欢听数据领导者讨论趋势数据主题，无论是数据网格还是在这个博客中，数据可观察性。通常情况下，这个概念看起来是新的，因为它对数据世界来说是新的。尽管如此，像大多数概念和体系结构一样，它们往往在CIO组织中有很深的根基，这种背景有助于更好地理解。
我们是怎么走到这一步的?什么是数据可观察性?
之前数据可观测性，有IT可观察性。IT可观察性代表了IT日志记录和监控的发展——一种支持分类的技术解决方案，而不仅仅是识别或量化。为了帮助扩大我们的理解，我们可能想把话题分开。
- 日志记录。可以将其视为原始应用程序数据。持续交付方法要求我们应该跟踪应用程序的数据并对其进行管理。这种方法导致了大量的最佳实践，包括日志的存在。今天，对于应用程序来说，产生它们正在做的事情的输出，而不仅仅是执行函数，这是相当标准的，而过去并不总是这样。
- 监控。将其视为应用日志记录，利用原始应用程序数据通过度量来验证应用程序性能。它组织一组预定义的日志，以确定现状或“我的系统是否正常工作?”监视带来了一些更广为人知的应用程序，如Dynatrace。
- 现在,可观察性．我喜欢谷歌的定义“可观察性是一种工具或技术解决方案，允许团队主动调试他们的系统。可观察性是基于探索未预先定义的属性和模式”。除了度量和日志之外还包括跟踪，可观察性有效地采取了反应性监视并添加了主动洞察层。为了使其有形，可观察性通常使用Splunk和DataDog等工具来执行。
因此，对于数据可观察性，我们看到贯穿整个软件系统的IT可观察性已经扩展到数据系统。数据可观察性的重点是生产级数据对其消费者的影响。我们如何看待数据功能与任何应用程序一样，都对输出有期望。当你的“数据不正确”时，同样的挫折会发生在你的“邮件发送不出去”时。
我们如何量化数据可观察性?
回溯到IT可观察性，这些指标可能集中在正常运行时间和停机时间。他们有像RTO(恢复时间目标)和RPO(恢复点目标)这样的关键项目。
RPO可能是数据可观察性的一个很好的度量标准。然而，作为行业领导者，我们听到的是-测量数据可观察性到数据停机的概念。数据停机时间是指您的数据部分、错误、缺失或其他不准确的时间段。
我认为，虽然数据停机的成本与IT中任何宕机应用程序的影响一样大，但在软件交付生命周期中有一个更强的预防模型。所有软件都在“较低”的环境中通过用户验收测试(User Acceptance Tests)进行严格的测试，而高质量的软件不一定处于IT可观察性的象限，例如，像Cucumber这样的工具用于开发人员测试。
但数据始终处于生产状态。考虑到创建机制并不完全是SDLC(软件开发生命周期)，控制数据质量的挑战。可以应用类似sdlc的测试措施，例如，在数据迁移之前进行较低的环境压力测试。但是它经常被跳过，并且与应用程序开发的SDLC中的质量控制相比只是半途而用。
此外，人们可能忍受了优先级1 (P1)影响数据停机时间而不知道它。就上下文而言，生产级软件的P1票通常意味着许多人在尖叫，“交易不起作用”或“电子邮件宕机”。但对于数据来说，糟糕的数据质量可能是一个潜伏的问题，只有在做出业务决策之后才会显现出来。
因此，与IT可观察性一样，业务也关心数据何时停机，但这不是最简单的警报机制。这就更难分清轻重缓急了。进入我们的行业20年，我们发现数据停机是一个需要陷入优先级模糊的需求。
谁帮助我们避免数据停机?
参与IT可观察性的团队的最新术语是DevSecOps。为了与操作的命名法保持一致，可以将此角色称为DataOps。为了限定这个术语，就像DevOps或SecOps一样，DataOps角色代表了与业务操作一致的软件开发生命周期的相同焦点。我们可以称之为数据开发生命周期。简而言之，他们是对抗数据停机的团队。
这个角色可以包含一系列基于所需专业知识的更传统的角色，就像我们在DevSecOps中看到的那样。
有一个数据用户，这个角色代表数据停机时间的L0。他们发现数据是错误的，然后升级。然后是数据操作员，这可能是DataOps团队中的角色，L1/L2支持能力，有助于减少数据停机时间并恢复系统。
但是数据操作中的主要角色是数据工程师。这个角色不仅代表数据生命周期的L3/L4，而且还有助于围绕数据操作构建数据管道和基础设施。类似于站点可靠性工程师，这个角色将在预防或解决数据停机方面发挥最大的作用。这个角色最看重数据的可观察性。
DataOps是数据生产者和消费者之间的桥梁。它是一套构建数据产品和操作数据管理的实践和技术，以提高质量、速度和协作，并促进持续改进的文化。”
——Sanjeev Mohan, SanjMo和前Gartner研究副总裁，大数据和高级分析
那么，我们应该如何努力实现更好的数据可观察性呢?
值得关注It可观察性趋势。如果CIO发现一种新的哲学对他们的软件工程师有帮助，那么数据工程师可能也会重视它。在CIO组织中，我看到可观察性可以归结为两个可翻译的趋势。
- 我们看到了与CI/CD的深度集成。到目前为止，新的代码合并仍然是最常见的麻烦来源。新的代码合并会产生一个缺陷，从而导致应用程序停机，因此生产前测试的CI/CD越强，应用程序进入生产的可能性就越小。这一事实得到了可观察性工具集成到代码(而不仅仅是日志)的趋势的支持，有助于跟踪问题的原因到有问题的代码。
要涉及到数据可观察性，请考虑到数据管道的集成。可能是新的数据ETL导致了最新的数据质量问题。数据可观察性解决方案与数据管道的集成越紧密，就越能在中断点上看到问题——有助于跟踪数据停机的原因到有问题的ETL。
- 第二个趋势是技术“堆栈”的端到端统一。除了识别并帮助对应用程序的停机时间进行分类之外，还可以帮助在深入基础设施的应用程序之间导航停机时间。当某人或某个监控系统说，“我的Tableau不能工作”时，可观察性简化了分类，以帮助找到Tableau工作正常但Salesforce源宕机的根本原因。
应用于数据可观察性，考虑数据沿袭．我们越能更好地将结果集成到谱系中，就能更好地帮助减少数据停机期间的分类-最终有助于防止未来出现其他问题。
那么数据可观测性的未来是什么呢?
不管解决方案的发展趋势如何，我对数据可观察性的优先级排序持乐观态度。感觉今天的口头禅是“每个公司都是软件公司”，这使得可观察性作为跟踪软件的一种方式很有价值。同样，我们听到“每个公司都在成为数据公司”，这也将趋向于数据可观察性。
总之，数据可观察性是存在的，是时候让它成为技术堆栈的重要组成部分了。
