可观察性成熟度模型

提高IT可靠性的要点

现代系统和应用跨越了众多的架构和技术--它们在本质上也变得越来越动态、分布和模块化。为了支持其系统的可用性和性能，IT运营和SRE团队需要高级监控能力。本参考卡回顾了可观察性成熟度的四个不同级别，每个阶段的关键功能，以及组织应采取的下一步措施，以加强他们的监控实践。

免费的PDF，便于参考

为您带来的是

refcard cover

简介

作为IT运营团队深入了解其系统的可用性和性能的一种方式，监控已经存在了几十年。可观察性是监控实践的演变，它的发展是为了帮助团队满足市场需求，更快地进行创新，并更好地支持业务目标。今天的IT基础设施和应用跨越了多种技术和架构，并且在本质上更加动态、分布式和模块化，因此需要先进的能力来为客户保持一致的高质量服务。

在这张参考卡中，我们概述了可观察性成熟度的四个阶段。我们涵盖了每个阶段的典型能力，这些能力是如何影响可靠性结果的，以及它们通常在公司的可观察性实施进程中的位置。我们讨论了可观测性成熟度模型中每个级别的缺点、常见的挑战和注意事项。使用该模型来确定你在可观察性旅程中的位置，并了解在你的组织中建立更好的可观察性所需的步骤。

第二节

可观察性和成熟度等级的概述

大多数企业发现很难确定正确的监控策略来可靠地管理其环境。超过65%的企业组织拥有10个以上的监控工具，这些工具通常作为孤立的解决方案运行。1这种分离的结构限制了SRE和IT运营团队检测、诊断和解决性能问题的能力。当问题发生时，团队试图通过结合团队、流程和工具，或通过手动拼凑孤立的数据碎片来找到根本原因。这种传统的监控方法很耗时，而且不能提供改善业务成果所需的洞察力。

可观察性实践已经发展到应对这些挑战，将监测方面的进展与更全面的方法相结合，提供更深入的洞察力，并更精确地了解整个技术环境正在发生什么。如表 1 所述，可观察性成熟度模型在可观察性的发展过程中定义了四个不同的级别。

**表1:**可观察性成熟度等级的定义

级别	目的
1.监测	- 追踪IT系统中各个组件的基本健康状况 - 观察事件；触发警报和通知 - 告诉你出了问题。
2.2.观察性	- 通过观察系统的输出来了解系统的行为 - 侧重于从指标、日志和跟踪中推断出的结果，结合现有的监控数据 - 提供基线数据，以帮助调查出错的原因。
3.3. 因果可观察性	- 提供更全面的见解，以帮助确定问题的原因 - 建立在第一和第二层次的基础上，并增加了跟踪IT堆栈中随时间变化的拓扑结构的能力 - 生成广泛的、相关的信息，以帮助减少确定出错的原因、问题发生的原因、何时开始、以及其他哪些领域受到影响所需的时间
4.使用AIOps的主动观察能力	- 使用AI和ML在大量数据中寻找模式 - 将AI/ML与1-3级的数据结合起来，在整个堆栈中提供最全面的分析 - 尽早发现异常并发出足够的警告，以防止故障发生

每个级别的可观察性都建立在之前级别建立的基础上，以增加捕捉、跟踪和分析数据的能力。新的功能使每个阶段的可观察性更加深入，从而提高了IT的可靠性和客户满意度，如图1所示。尽管你可以通过加强流程来略微改善一个等级内的结果，但大多数团队需要收集新类型的数据来推进到下一个成熟度等级，实现更大的收益。

**图1：**可观察性成熟度以及它如何影响IT可靠性

第三节

可观察性成熟度模型要点

在这一节中，我们将详细介绍在成熟度模型的每个级别中你需要什么功能，以及你应该期待什么好处。

第1级：监控

确保个别组件按预期工作。

可观察性成熟度模型的第一个层次，即监控，对IT行业来说并不陌生。监控器跟踪单个系统组件的特定参数，以确保它保持在一个可接受的范围内；如果数值超出范围，监控器就会触发一个动作，如警报、状态变化、通知或警告。对于传统的监控，有时被称为应用性能监控（APM），其用例是："当某些东西的运行不令人满意时通知我"。

你可以用交通灯的颜色来考虑监控。

该组件是可用的和健康的（绿色）
该组件处于危险之中（橙色或黄色）
该组件已损坏（红色）

监测着眼于一组预先定义的值和预先定义的故障模式。它专注于基本的组件级参数，如可用性、性能和容量，并产生报告监测值状态的事件。事件是IT环境中值得注意的变化。虽然事件可能是纯粹的信息，但它们往往描述需要采取行动的关键事件。事件可以触发警报或通知，通过各种渠道到达，如电子邮件、聊天、移动应用程序或事件管理系统。

作为实现可观察性的第一步，实施监控以获得对单个组件的健康和状态的基本了解，并在出现故障时得到通知。监控为更成熟的可观察性打下了基础，但它并不能为你提供可操作的信息来快速解决问题。表2给出了第1级的关键能力概述。

**表2:**第1级概要

监测
使用基本的交通灯监控来了解构成IT服务的各个组件的可用性。
系统输入	系统输出
事件和组件级指标（例如，"API响应时间高于我们的SLO的5秒"）。	警报或通知（例如，"订单执行服务中断了"）。
你得到什么
- 基本信息，如一个组件的健康状态--它在工作吗？ - 问题发生时的警报和通知 - 最容易入门的方法；有许多开源和SaaS解决方案可用

下一步。可观察性

第一级让你对整个环境的状态有有限的了解。它向你显示单个组件的健康状况，但一般没有关于大局的信息。它告诉你有些东西坏了，但没有告诉你原因，也没有告诉你该找谁，更没有告诉你原始问题是什么时候和什么地方开始的。设置和维护监控检查和通知通道需要大量的手工工作。

在第1级，你还需要手工做根本原因分析和影响分析，而且你的数据集有限。调查问题的来源需要时间。此外，一个问题可能会引起来自多个组件的警报风暴，造成进一步的混乱和延迟，无法准确地找出根本原因。

第1级，监控，可以检测有限的已知故障类型，第2级，可观察性，可以帮助你发现未知的故障模式。当你从第1级到第2级，你将获得更深入的信息，对你的服务的可用性、性能和行为有更好的理解。

第2级：可观察性

确定系统为什么不工作。

为了保持当今复杂多变的IT系统的可靠运行，你不仅需要知道什么在工作（监控），还需要了解它为什么不工作（可观察性）。传统的监控跟踪一个组件或系统的基本健康状况。可观察性自然而然地发展起来，以提供对系统随时间变化的行为的更深入的洞察力。当出了问题，你的团队收到警报时，你需要迅速搞清楚："发生了什么？在哪里，什么时候，为什么，我们应该找谁？"可观察性数据帮助你回答这些问题。

在完全成熟的情况下（本模型中的第四级），可观察性提供了你所需要的所有数据，在适当的背景下，自动检测和补救问题，甚至主动识别和预防问题。当一个警报出现时，你要了解系统的状态，以找到问题的根源。在第二级，可观察性通常通过关注三种关键类型的遥测数据来提供系统洞察力：指标、日志和**跟踪。**2

可观察性的这三个支柱是从IT组件（如微服务、应用程序和数据库）收集的，以提供对系统行为的整体看法。每个支柱都提供不同类型的信息，如表 3 所示。

**表 3：**可观察性的三个支柱

支柱	定义
衡量标准	帮助你了解服务的性能和状态的数字测量，例如，著名的四大黄金信号：延迟、流量、错误率和饱和度。³
日志	对系统中发生的相关事件（如事务、警告、错误）的时间标记记录，帮助你了解系统在某一特定时间点的行为。
痕迹	详细的快照，显示数据如何从头到尾流经应用程序（例如，用户请求），这有助于解决性能问题，有时还能从代码层面了解你的应用程序的性能。

这三个支柱，连同事件和警报，通常被绘制在仪表盘上，这样团队就可以轻松地跟踪重要的活动。一些可观察性工具提供了开箱即用的仪表盘，将这些不同类型的数据集中在一个屏幕上，并允许你深入研究这些数据以进一步调查。

第二级数据的广度和深度比第一级大得多，它通常涉及到将整个环境中的一些数据整合到一个单一的视图中。如果你想获得更多的洞察力，你可能需要建立额外的仪表盘，特别是当你的环境有多个域，并且你使用多个监控工具时。然后，挑战就变成了如何解决来自太多仪表盘的信息。在第2级，你可以通过手动关联数据来推断事件的可疑原因，但这种方法往往涉及跨系统的复杂手动查询。

在第2级，团队还没有开发出一种自动化的方法来统一和关联来自不同工具和领域的孤岛数据，所以要找出问题的根本原因仍然需要耗费大量的人力和时间。因此，MTTD和MTTR比它们应该的要高，客户受到更多的不利影响，并且比更高的成熟度水平损失更多的收入。

**表4：**第2级总结

可观察性
除事件和健康状态外，通过捕获指标、日志和跟踪来观察IT环境的行为。
系统输入	系统输出
1级输入+综合指标、日志和跟踪	1级输出+综合仪表盘，包括图表、仪表、火焰图、日志等。
你得到什么
- 通过从更多的来源收集额外的数据，更深入、更广泛、更全面地了解整个系统的健康状况，从而更好地支持问题诊断 - 除了已知的故障类型外，还能发现未知的故障模式 - 从个别类型的数据中获得有益的见解 - 例如，跟踪有助于识别性能瓶颈，指标是优秀的KPI，而日志可用于发现软件缺陷

下一步。因果观察能力

可观察性产生了大量的数据，而整理出有意义的信息可能很困难。在第二级，你的团队很可能受到数据孤岛和数据量的挑战，这导致跨领域和跨团队的故障排除效率低下。当出现问题时，太多的人参与进来，因为没有人知道问题出在哪里，导致 "事件乒乓 "和指责游戏。你可能需要建立专门的解决方案来查询多个可观察性筒仓，以解决单一问题；创建这些查询需要从业人员具备开发技能、数据结构知识以及对系统架构的理解。

此外，第二级中典型的以遥测为中心的孤岛式视图，往往需要大量的手工工作来提取可操作的见解。设置高效的仪表盘可能需要相当长的时间，并且需要持续的维护。根源分析、影响分析和减少警报噪音对于维护一个可靠和有弹性的堆栈是很重要的，但这些活动在这个级别是具有挑战性的。

注意：团队越来越多地采用OpenTelemetry标准，以促进指标、日志和追踪的捕获。OpenTelemetry对于有效地收集这些类型的数据是非常有帮助的，但是它的设计并不是为了弥补孤岛，为数据创造更好的背景，或者分析数据。

为了进入第三级，了解你的可观察性数据是如何关联的，你需要为IT环境中的事件、日志、指标和追踪提供跨数据孤岛的上下文。在第三级（因果可观察性），你可以得到你的业务流程、应用程序和基础设施的拓扑结构的精确地图，并且你可以跟踪它是如何随时间变化的。当出现问题时，你可以使用这些上下文数据与自动化相结合，快速确定问题的原因，而不必手动处理那些不相关的数据孤岛。

第三级：因果可观察性

找到事件的原因并确定其对整个系统的影响。

毫不奇怪，大多数故障是由系统中某个地方的变化引起的，4例如新的代码部署、配置变化、自动扩展活动或自动修复事件。当你调查一个事件的根本原因时，最好的开始是看一下什么变化。为了了解什么变化导致了问题，以及什么影响传播到了整个堆栈，你需要能够看到堆栈组件之间的关系是如何随时间变化的。

当一个问题开始时，堆栈是什么样子的？
哪些组件受到了影响？
所有的警报是如何关联的？

我们把这种让你跟踪整个堆栈的因果关系的洞察力称为因果可观察性--它建立在第一和第二层次的基础上。

拓扑结构是因果观察能力的第一个必要维度。拓扑结构是IT环境中所有组件的地图，它跨越了所有的层次，从网络到应用到存储，显示了所有东西的关系。拓扑结构包含了逻辑上的依赖性、物理上的接近性以及组件之间的其他关系，以提供人类可读的可视化和可操作的关系数据。

现代环境由许多动态层、微服务、无服务器应用和网络技术组成，因此在你的可观察性组合中添加最新的拓扑结构对于区分因果关系至关重要。拓扑结构为数以千计的未连接的数据流提供了锚点，使它们具有结构性，使以前看不见的连接变得可见。拓扑可视化让你在全栈活动的背景下查看来自网络、基础设施、应用程序和其他领域的遥测数据；它还为你提供了重要的背景，让你知道当某些事情发生时你的业务是如何受到影响的。

对于大多数公司来说，增加拓扑结构本身并不足以提供因果观察能力。第二个必要的维度是时间。为了理解现代IT环境的动态行为，并获得实现因果观察能力所需的上下文，你需要将环境的拓扑结构与其相关的指标、日志、事件和跟踪数据在时间上进行关联。

**图2：**捕获时间序列拓扑结构以跟踪堆栈变化并找到根本原因

在第三级，拓扑和时间的额外维度向你展示了任何变化或故障的原因和影响，跨越不同的层、数据仓、团队和技术--大大改善了解决时间和业务成果。你也有了开始自动进行根本原因分析、业务影响分析和警报关联的基础。

**表5：**第3级总结

因果观察能力
通过单一的拓扑结构将遥测数据（指标、跟踪、事件、日志）上下文化。随着时间的推移，对所有数据进行关联，以跟踪在你的堆栈中传播的变化。
系统输入	系统输出
1级和2级+时间序列拓扑结构	第1级和第2级+相关的拓扑、遥测和时间数据显示在上下文的可视化中，显示整个堆栈的变化效果。
你会得到什么
- 通过在时间序列拓扑中统一孤立的数据，对环境状态进行清晰、相关的上下文查看 - 通过拓扑可视化和分析了解因果关系，大大加快了解决时间 - 为基本的自动调查奠定基础，如根本原因分析、业务影响分析和警报相关性 - 自动聚类与同一根本原因相关的警报，减少噪音和干扰所需的上下文 - 能够将网络、基础设施和应用程序事件对业务服务和客户的影响可视化

下一步。利用AIOps的主动观察能力

第3级是一个很大的进步，但统一来自不同筒仓的数据在数据规范化、关联性和质量方面带来了挑战，可能需要新的能力甚至组织变化来解决。此外，很难大规模地收集和操作高质量的拓扑数据，特别是在不太现代化的环境中。储存与遥测相关的拓扑结构，随着时间的推移会带来更大的挑战。在你制定实施计划时要考虑这些问题。

3级数据的速度、数量和种类通常非常大，为了实现你的总体可靠性目标，可能需要人工智能来帮助把信号和噪音分开。当你迈向第4级时，你在第1-3级的基础上增加了IT运营的人工智能（AIOps），以获得更准确的洞察力。

第4级：利用AIOps的主动观察能力

分析大量的数据，自动响应事件，并防止异常情况成为问题。

AIOps的主动观察能力是观察能力成熟度模型的最先进水平。在监控和可观察性方面，AIOps是指应用人工智能和机器学习（ML）来整理大量的数据。AIOps平台分析指标、日志、跟踪、事件和拓扑结构，以寻找模式，推动人类和自动化系统在最短的时间内做出主动反应。它们为可观察性提供了四个关键功能。

分析跨域、跨层和跨团队的复杂数据
对相关事件和警报进行关联，以减少噪音
识别模式，对即将发生的问题发出早期警告，并指出可能的根本原因
协助自动修复，通常为自我修复系统提供更精确的信息（可能的根本原因、相关的警报等）

AIOps建立在这个成熟度模型中前几个级别的核心能力之上--如收集和操作数据、拓扑结构组装和数据的相关性--并增加了模式识别、异常检测和更精确的问题补救建议。因果可观察性是一个必要的基础。时间序列拓扑结构提供了一个基本框架。

AIOps可以帮助团队更快地发现问题，甚至完全防止问题。AI/ML算法寻找警告、警报和故障之前的模式变化，帮助团队知道服务或组件何时开始偏离正常行为，并在事情失败之前解决这个问题。然而，反常现象经常发生。它们不一定意味着问题会发生，也不一定意味着补救措施会成为高度优先事项。AIOps帮助确定哪些异常情况需要关注，哪些可以忽略。

AIOps可观察性的另一个目标是通过IT服务管理（ITSM）和自我修复系统推动自动修复。例如，如果这些系统收到不正确的根本原因输入，它们可以自我纠正错误的问题并导致更大的问题。AIOps提供了更准确的输入，增强了它们的有效性。

在第四级，你应该注意到更有效和无事故的IT运营，提供更好的客户体验。为了实现这些目标，设置AIOps以超越孤岛，并摄取从整个环境中收集的数据。AI/ML模型应该分析我们在前几个级别中讨论的所有可观察性数据类型：事件、指标、日志、跟踪、变化和拓扑，所有这些都是随时间变化而关联的。

**表 6:**第4级总结

使用 AIOps 的主动观察能力
使用AIOps对堆积如山的数据进行分类，并确定最重要的模式和有影响的事件，这样团队就可以把时间集中在重要的方面。
系统输入	系统输出
1-3级+AI/ML模型	1-3级+主动洞察力，实现快速MTTR并防止故障发生
你得到什么
- 利用AI/ML从大量数据中收集和关联可操作的信息，对IT环境运行有新的见解 - 预测和异常检测，在问题影响业务之前突出问题 - 提高效率，减少劳累，因为团队将精力集中在最有影响的事件上 - 提高自动根本原因分析、业务影响分析和警报关联的准确性 - 事件数据足够准确，可与自动化ITSM和自我修复系统有效地使用

接下来的步骤

目前大多数AIOps解决方案需要大量的配置和培训时间，但往往产生不准确的结果，特别是如果不考虑拓扑结构随时间的变化。现在，AIOps需要很长的时间来显示结果和证明投资回报率，但平台会继续改进。4级是目前最终的可观察性成熟度水平，但随着IT的不断发展，我们完全期待5级的出现。

第四节

结论

几十年来，IT运营团队一直依靠监控来了解其系统的可用性和性能。但今天，随着基础设施和应用跨越多个动态、分布式和模块化的IT环境，企业需要更深入、更精确地了解这些系统中发生的一切。Observability 提供了这种全面的洞察力，在每个成熟度级别提供了明确的能力。