在过去的九个月中，生成式人工智能的快速发展影响了几乎所有行业。这对我们如何观察和监控我们的生产系统产生了什么影响？
我认为，在这个领域的下一个发展阶段将是一类新的解决方案，即“推理”，即以合理的准确性直接确定开发人员错误的根本原因。
在本文中，我们将探讨以下内容：
- 推理作为观察性的自然下一步。
- 从AIOps的经验教训-为什么它没有起飞以及对推理的影响。
- 推理解决方案类别的一些新原则。
我们现在的状况
为了理解观察性的下一代，让我们从所有这些工具的根本目标开始。它是为了确保生产系统保持健康运行，如预期那样，如果出现任何问题，让我们能够快速理解原因并解决问题。
如果我们从这个角度出发，我们可以看到工具在支持我们方面有三个不同的层次：
- 级别1：“当我的系统出现异常时，提醒我”-监控。
- 级别2：“告诉我为什么有异常（以及如何修复）”-让我们称之为推理。
- 级别3：“自己修复并告诉我你做了什么”-自动修复。
监控工具在级别1（检测问题）方面表现得相当好。自然的下一步是级别2，即系统自动告诉我们为什么会出现问题。我们还没有能够做到这一点的解决方案，所以我们在级别1和级别2之间添加了一类工具，称之为观察性，其目标是“帮助我们理解为什么会出现问题”。这本质上变成了“任何可能帮助我们理解正在发生的事情的数据”。
观察性与推理
当今观察性的问题
当今观察性的主要问题是其定义和执行都不够明确。这是因为我们事先不知道我们需要什么数据；这取决于具体问题。生产错误的性质是它们是长尾和意外的；如果它们可以预测，它们就会被解决。因此，我们收集各种各样的数据类型：度量指标、日志、分布式跟踪、堆栈跟踪错误数据、K8s事件和持续性分析，以确保在出现问题时我们有一些可见性。
理解观察性在实践中的实现方式的最佳方法是：“度量指标之外的所有内容，再加上度量指标。”
实践中的观察性
观察性平台还必须在捕获和存储多少数据方面做出选择。目前，这个决策由客户来决定，而客户的默认选择是尽可能收集尽可能多的数据。快速采用云和SaaS模型使得收集和存储大量数据成为可能。
收集更多类型和容量的观察性数据背后的人类动因是：“如果发生故障，我没有足够的数据来进行故障排除怎么办？”这是每个工程团队的噩梦。因此，我们今天面临的情况是：
- 观察性数据类型不断扩展。
- 观察性数据量激增。
- 工具泛滥-平均每个公司使用5个以上的观察性工具。
在这一切中，我们开始遇到新的问题。对于开发人员来说，通过手动导航数十个数据密集型仪表板来识别错误变得越来越困难。观察性也变得难以承受，因此公司不得不开始在存储哪些数据方面进行复杂的权衡，有时会失去可见性。由于这两个问题以及生产系统复杂性的持续增加，我们发现生产错误的MTTR实际上在多年内有所增加。
推理-观察性与人工智能
我认为，观察性之后的下一步是推理-一个平台可以合理地解释为什么会发生错误，以便我们可以修复它。这在过去几个月中，随着人工智能模型的快速发展，现在成为可能。
想象一个解决方案：
- 自动显示需要开发人员立即关注的错误。
- 告诉开发人员导致问题的具体原因和位置-这个Pod、这个服务器、这个代码路径、这种类型的请求。
- 指导开发人员如何修复。
- 使用开发人员的实际操作不断改进推荐。
这个领域已经有一些早期的活动，但我们仍处于非常早期阶段，可以预计在接下来的几年里会出现几家新公司。
然而，任何关于AI +可观测性的讨论都不完整，如果不讨论AIOps，它是同样承诺（使用AI自动化生产运维）并在’15-20年间经历了一波投资，但取得了有限的成功并逐渐消失。要全面探讨为什么AIOps失败，请阅读这篇文章 – AIOps已经死亡。
避免AIOps的陷阱
AIOps的最初前提是，如果我们将来自五六个不同的可观测性来源的数据推送到一个统一的平台上，然后对所有这些数据（指标、日志、依赖关系、跟踪、配置、更新、K8s事件）应用AI，我们将能够得到关于为什么某些东西出错的洞察。
AIOps平台的架构。
虽然在理论上很有吸引力，但这个论点在某些方面不足。
首先，将所有内容联系在一起是不切实际的，而且比预期的要困难得多。不同的可观测性工具在不同的时间间隔内收集不同系统的不同数据，并且它们向第三方工具公开其收集到的数据的不同子集。此外，每个客户都有自己的数据收集实践。例如，企业通常会使用多种不同的可观测性工具，具有高度定制和非标准的数据收集，企业需要手动为任何新的AIOps工具提供有关它们的上下文信息。所有这些都影响了机器学习模型能够达到的响应/根本原因分析的质量和它们提供的价值。
其次，AIOps的模型过于广泛，没有针对用例进行驱动。例如，模型所针对的具体错误类型是什么？基础设施错误/代码错误/硬错误/软错误？大多数AIOps平台在这方面都很广泛，试图摄取八种不同的数据类型，希望找到模式和异常，并且过于依赖客户将多少数据以及什么质量推送到平台，这会影响他们的输出质量。
第三，每家公司的集成过程过于复杂。大公司有许多不同团队运行的可观测性工具。一个AIOps平台需要将所有这些工具集成到一起，才能增加价值。即使在像Datadog或DynaTrace这样的大型可观测性平台的AIOps模块的情况下，要求整个可观测性堆栈移至单一供应商（跨基础设施和应用程序指标、日志、分布式跟踪、错误监控等），以使AIOps模块发挥作用。
第四，巨大的数据量和处理所需的计算能力也使得这些工具在与他们可疑的价值相比非常昂贵。
所有这些导致了许多AIOps工具的早期采用者产生了一定程度的幻灭感，并且大多数公司都回到了简单的“收集数据并在仪表板上显示”的机制来满足他们的需求。
从这里可以得出一些有用的经验教训，并且可以在我们尝试推理时进行学习和应用。
推理原则
为了更有效地实现最终目标，推理将必须在某些方面与以往不同。
从根本上以AI为中心进行架构设计
推理解决方案将必须从根本上为AI用例进行架构设计，即数据收集、处理、流水线、存储和用户界面都是为“使用AI进行根本原因分析”而设计的。
它可能不会像我们尝试过的AIOPs那样，在现有可观测性解决方案或现有可观测性数据上添加AI，因为我们在AIOPs方面尝试过并失败了。它将必须是一个全套系统，其中所有内容都是围绕使用AI进行根本原因分析的明确目标而设计的。
在实践中，这会是什么样子？
具有数据收集、处理、存储和可视化的全栈AI原生架构
推理解决方案将必须是垂直集成的 – 也就是说，它将必须收集遥测数据，处理数据，并拥有与用户的数据流和交互层。
这一点很重要，因为它将允许解决方案使用用户的交互来学习和更新其数据处理和收集机制。
对于推理解决方案来说，能够以所需的格式、所需的上下文，从客户环境中收集所需数据是至关重要的，以便对根本原因和用户体验的有效性进行控制。
自适应数据收集
推理解决方案本身必须具备嵌入式数据收集智能。这意味着代理应该能够在数据流进来的时候即时判断是否捕获或丢弃。
今天，所有的仪器代理都是“愚蠢”的，它们只是对所有数据进行快照并进行传输，然后稍后进行处理。这在现今是有意义的，因为我们主要使用代码代理，我们希望代理尽可能轻量化，增加最小的开销。
然而，随着像eBPF这样的技术的出现，它允许我们以几乎零开销的方式从内核进行带外数据收集，我们可以想象出一种智能仪器代理，它可以主动解决推理模型所需的数据质量问题。
针对特定用例调整的数据处理
在推理中，所有的数据处理技术都必须围绕特定的用例展开，例如：“如何可靠地识别错误类型A？错误类型B呢？等等。”
所有的数据处理模型都应遵循以下原则：能够可靠地根因某些类型的错误，并随着模型的演进逐渐增加识别其他类型的错误。这可能会导致不同的数据类型、数据管道和每种错误类型的不同数据集、不同的数据处理流程和不同的模型框架。
它们可能不会进行”一般异常检测”，然后再回溯查看可能导致异常的原因。这是因为根因错误所需的数据与”识别/定位”错误所需的数据非常不同。
为人工智能设计的存储
在推理世界中，存储的观点已经与监控或可观察性世界不同。现在我们有了用于存储发生的一切的大规模数据存储，但是在推理中，我们只需要存储人工智能模型需要可靠地根因错误的最相关和最新的数据。这可能涉及到几种做法：将数据存储在向量数据库中以便进行轻松聚类和提取，仅存储少部分成功案例并丢弃其他案例，去重错误等。
因此，推理解决方案所需的存储量实际上可能比传统的监控和可观察性解决方案所需的存储量更少。
更简单、更交互的用户界面
推理界面可能看起来不太像一堆带有数据的仪表板，而更像一个为开发团队调整的对话式界面。也许它有一个简单的优先级错误表格，需要人工关注的每个错误都可以点击，然后它会给出最可能的根本原因列表以及准确性概率。然后，它可以采用人类反馈强化学习（RLHF），让用户确认是否正确识别了根本原因，以便模型能够随着时间的推移提高性能。在这方面的可能性是广泛的。
总结
总之，随着通用人工智能(Gen. AI)的最新发展，监控和可观察性领域很可能会出现重大变革。
第一波解决方案很可能类似于过去的AIOPs平台，只是在现有的可观察性数据周围添加了薄薄的通用人工智能包装。现有的主要参与者在这一波中处于最有利的位置。这可能类似于Github Copilot – 您大约有10%的时间会得到一个好的建议。然而，真正的飞跃可能要再过几年，那时将出现一类新的推理解决方案，能够在超过80%的时间内准确地根因错误。为了能够做到这一点，它们需要是全栈的，并拥有数据收集、处理、存储、模型和用户交互的能力。我们在每个部分的堆栈中探讨了一些关于推理解决方案与现有实践的早期假设。