前言
在 StackState，我们在监控和可观测性领域工作了八年。 在这段时间里，我们与无数 DevOps 工程师、架构师、SRE、IT 运营负责人和 CTO 进行了交谈，我们一遍又一遍地听到了同样的挣扎。
今天的消费者已经习惯了始终有效的伟大技术。 他们对中断或性能问题几乎没有容忍度。 这些期望促使企业通过频繁发布、更快的响应和更高的可靠性来保持竞争力。 与此同时，向基于云的应用程序（及其所有不断变化的功能、微服务和容器）的转变使 IT 环境比以往任何时候都更加复杂和难以操作和监控。
因此，我们在全球范围内展开的监控挑战中看到了很大的共性，例如客户描述的这个丰富多彩的问题：
“当基础设施、存储、网络设备或类似的东西出现重大问题时……每次我们都看同一部电影。监控会变成红色、红色、红色，成千上万的警报，没人知道根本原因是什么。 每个人都很恐慌——真正的混乱。”
—— Georg Höllebauer，APA-Tech 的企业指标架构师
八年前我亲眼目睹了这个问题，当时我是荷兰一家大型银行的两名顾问团队的一员，帮助他们提高关键任务应用程序的可靠性。 他们是一家成熟的企业，针对复杂的环境配备了多种监控工具，但他们无法快速找到问题的根源。 由于许多孤立的工具和缺乏统一的 IT 环境视图，客户体验受到直接影响。 当出现问题时，找到并解决核心问题的时间太长了。 我们知道我们必须找到更好的方法，而我们为满足这家银行的需求而构建的技术成为 StackState 的基础。
自从我们在 2017 年发布了最初的监控成熟度模型以来，很明显，最初的监控工具——它只是在出现问题时通知 IT 团队——对许多其他组织来说也不再足够了。 今天的工程师需要立即了解问题的优先级和背景：对客户体验和业务结果有何影响？ 那么，如果影响很大：它为什么会崩溃，我们如何修复它？
可观测性的概念已经从监控演变为回答这些问题。 可观测性对于维持业务成功所需的服务可靠性水平至关重要。 不幸的是，在监控和可观测性空间中导航是很困难的，尤其是当 AIOps 进入画面时。 许多供应商在市场上大放异彩，新的开源项目层出不穷。 很难知道谁真正做了什么，更难知道哪些能力真正重要。
可观测性成熟度模型基于对实际环境中实际问题的广泛经验、与客户和潜在客户的讨论、对最新技术的研究以及与 Gartner 等领先分析公司的对话。 我们希望它能帮助您在黑暗中发光。 我们的目标不是向您展示您的可观测性之旅应该是什么样子的完美模型。 我们知道它不是那样工作的。 引用一位著名的英国统计学家的话，“所有模型都是错误的，有些是有用的。”
相反，我们编写此可观测性成熟度模型是为了帮助您确定您在可观测性路径上的位置，了解前方的道路并提供地图以帮助您找到自己的方式。
愿此模型对您的旅途有用！
Co-founder and Chief Technology Officer
StackState
简介：为什么要使用可观测性成熟度模型？
监控作为 IT 运营团队深入了解其系统的可用性和性能的一种方式已经存在了几十年。 为了满足市场需求、更快地创新并更好地支持业务目标，IT 组织需要更深入、更准确地了解其技术环境中正在发生的事情。 获得这种洞察力并不容易，因为当今的基础设施和应用程序跨越多种技术，使用多种架构，并且本质上更加动态、分布式和模块化。
变化也是 IT 的一种生活方式，研究表明 76% 的问题是由变化引起的。为了在面对所有这些挑战时保持可靠性，公司的监控策略必须发展为可观测性。
66% 的 MTTR 用于识别导致问题的变化
大多数企业发现很难找到正确的监控策略来可靠地管理他们的环境。 超过 65% 的企业组织拥有 10 多个监控工具，通常作为孤立的解决方案运行。这种分离的结构限制了 SRE 和 IT 运营团队快速检测、诊断和解决性能问题的能力。 出现问题时，团队会尝试通过组合团队、流程和工具，或通过手动拼凑孤立的数据片段来找到根本原因。 这种传统的监控方法非常耗时，并且无法提供改善业务成果所需的洞察力。 故障排除速度太慢，您最重要的面向客户的系统可能会停机数小时，从而导致数百万美元的收入损失。
向动态云、容器、微服务和无服务器架构的转变，加上维护混合环境和遗留记录系统的需要，进一步加剧了对更高级功能的需求。
云和容器迁移推动了对更高可观测性成熟度的需求
可观测性实践已经发展以满足这些需求，将监控方面的进步与更全面的方法相结合，提供更深入的洞察力和对跨技术环境正在发生的事情的更准确的理解。 可观测性成熟度模型定义了可观测性演变的四个不同级别，如下页表 1 中所述。
| 等级 | 目标 | 功能 |
|---|---|---|
| 1. 监控 | • 确保各个组件按预期工作。 | • 跟踪 IT 系统中各个组件的基本健康状况 • 查看事件； 触发警报和通知 • 告诉您出了点问题...但不是什么 |
| 2. 可观测性 | • 确定系统不工作的原因。 | • 通过观察其输出来深入了解系统行为 • 侧重于从指标、日志和跟踪中推断出的结果，并结合现有的监控数据 • 提供基线数据以帮助调查问题所在 |
| 3. 因果可观测性 | • 查找事件的原因并确定其对整个系统的影响 | • 提供更全面的见解以帮助确定问题的原因 • 建立在第 1 级和第 2 级基础上，添加了跟踪 IT 堆栈中拓扑结构随时间变化的能力 • 生成广泛的相关信息，有助于减少确定问题所在、问题发生的原因 |
| 4. AIOps 的主动可观测性 | • 分析大量数据，自动响应并防止异常成为问题。 | • 使用人工智能和机器学习在大量数据中寻找模式 • 将 AI/ML 与 1-3 级数据相结合，提供最全面的堆栈分析 • 及早发现异常并发出足够的警告以防止故障 |
表 1：定义可观测性成熟度级别
每个级别的可观测性都建立在先前级别建立的基础之上，以增加捕获、跟踪和分析数据的能力。 新功能支持在每个阶段进行更深入的观察，从而提高 IT 可靠性和客户满意度，如下面的图 1 所示。 虽然您可以通过增强流程在某个级别内略微改进结果，但大多数团队需要收集新类型的数据以推进到下一个成熟度级别并实现更大的收益。
可观测性成熟度模型基于与跨行业企业的研究和对话，并已得到其他从业者、分析师和思想领袖的验证。 它旨在帮助您：
• 了解不同类型的数据以及监控和可观测性实践如何帮助您的组织收集可操作的信息。
• 了解监控、可观测性和AIOps 之间的区别。
• 评估您的组织当前的成熟度水平。
• 引导您的团队达到更高的成熟度。
使用此模型了解您可以采取哪些清晰的步骤来提高组织中的可观测性，以便您最终可以向客户交付更可靠和更具弹性的应用程序。
第一级：监控
目标：确保各个组件按预期工作。
第一级，监控，对 IT 来说并不陌生。 监视器跟踪单个系统组件的特定参数，以确保它保持在可接受的范围内。 如果该值超出范围，监视器将触发一个操作，例如警报、状态更改、通知或警告。
传统监控通常包括应用程序性能监控 (APM)、基础设施监控、API 监控、网络监控和各种其他以域为中心的工具，用例是“当某些事情运行不满意时通知我”。 您可以根据交通灯颜色来考虑监控：
- 组件可用且健康（绿色）
- 组件存在风险（橙色或黄色）
- 组件损坏（红色）
监控着眼于预定义的值集和预定义的故障模式集。 它关注基本的组件级参数，例如可用性、性能和容量，并生成报告监视值状态的事件。
事件是 IT 环境中值得注意的变化。 尽管事件可能纯粹是提供信息，但它们通常描述需要采取行动的关键事件。 事件可能会触发通过各种渠道到达的警报或通知，例如电子邮件、聊天、移动应用程序或事件管理系统。
作为实现可观测性的第一步，实施监控以获得对各个组件的健康和状态的基本洞察，并在出现问题时收到通知。 下面的表 2 概述了级别 1 的关键功能。
| 说明 | |
|---|---|
| 第一级：监控 | 使用基本的交通信号灯监控来了解构成 IT 服务的各个组件的可用性。 |
| 系统输入 | 事件和组件级指标（例如，“API 响应时间高于我们五秒的 SLO”） |
| 系统输出 | 警报或通知（例如，“订单履行服务已关闭”） |
| 你得到什么 | • 基本信息，例如组件的健康状态——它在工作吗？ • 出现问题时的警报和通知 • 最简单的入门方式； 许多开源和 SaaS 解决方案可用 |
表 2：第 1 级总结
下一步：可观测性
监控使您对整体环境状态的了解有限。 它向您显示单个组件的运行状况，但通常没有关于全局的信息。 它会告诉您出现问题，但不会告诉您原因、联系谁，也不会告诉您原始问题出现的时间和地点。
设置和维护监控检查和通知渠道需要大量手动工作。 在第 1 级，您还需要手动进行根本原因分析和影响分析，并且您的数据集有限。 调查问题的根源需要时间。 此外，单个问题可能会导致来自多个组件的警报风暴，导致进一步的混乱和延迟查明根本原因。
虽然监控可以检测到有限数量的已知类型的故障或“已知的未知数”，但第 2 级可观测性可以帮助您发现未知和意外的故障模式或“未知的未知数”。 当您从级别 1 升级到级别 2 时，您将获得更深入的信息，从而更好地了解服务的可用性、性能和行为。
第二级：可观测性
目标：确定系统不工作的原因。
为了让当今复杂和动态的 IT 系统可靠地运行，您不仅需要知道什么在工作（监控），还需要了解它为什么不工作（可观测性）。
传统监控跟踪组件或系统的基本健康状况。 随着时间的推移，可观测性自然演变，以提供对系统行为的更深入洞察。 当出现问题并且您的团队收到警报时，您需要快速弄清楚，“发生了什么事？ 我们在哪里、什么时候、为什么以及给谁打电话？” 可观测性数据可以帮助您回答这些问题。 在其完全成熟（第 4 级）时，可观测性在适当的上下文中提供您需要的所有数据，以自动检测和修复问题，甚至主动识别和预防问题。
当弹出警报时，您希望了解系统的状态以找到问题的根源。 在第 2 级，可观测性通常通过关注三种关键类型的遥测数据来提供系统洞察力：指标、日志和跟踪。 可观测性的这三大支柱是从 IT 组件（例如微服务、应用程序和数据库）中收集的，以提供对系统的整体视角。 系统的行为。 每个支柱提供不同类型的信息，如下表 3 所示。
| 支柱 | 定义 |
|---|---|
| 指标 | 帮助您了解服务性能和状态的数值测量——例如，著名的四个黄金信号：延迟、流量、错误率和饱和度。 |
| 日志 | 系统中发生的相关事件（例如事务、警告、错误）的时间戳记记录，可帮助您了解系统在给定时间点的行为。 |
| 追踪 | 显示数据如何从端到端流经应用程序的详细快照（例如，用户请求），这有助于解决性能问题，有时还可以在代码级别了解您的应用程序的执行情况。 |
表 3：可观测性的三大支柱
这三大支柱以及事件和警报通常绘制在仪表板上，因此团队可以轻松跟踪重要活动。 一些可观测性工具提供开箱即用的仪表板，将这些不同类型的数据汇集在一个屏幕上，并允许您深入研究它们以进行进一步调查。
2 级数据比 1 级数据具有更大的广度和深度，并且它通常涉及将整个环境中的一些数据整合到单个视图中。 如果您想要获得更多见解，您可能需要构建额外的仪表板，尤其是当您的环境有多个域并且您正在使用多个监控工具时。
| 说明 | |
|---|---|
| 第 2 级：可观测性 | 除了事件和健康状态之外，还可以通过捕获指标、日志和跟踪来观察 IT 环境的行为。 |
| 系统输入 | 1 级输入 + 综合指标、日志和跟踪 |
| 系统输出 | 1 级输出 + 带有图形、仪表、火焰图、日志等的综合仪表板。 |
| 你得到什么 | • 通过从更多来源收集更多数据，更深入、更广泛、更全面地了解整个系统的健康状况，从而更好地支持问题诊断 • 除已知故障类型外，还能够发现未知故障模式 • 从各种类型的数据中获得有益的洞察力——例如，跟踪有助于识别性能瓶颈，指标可提供出色的 KPI，日志可用于查找软件缺陷 |
表 4：2 级总结
那么挑战就变成了如何解决来自太多仪表板的信息。 在第 2 级，您可以通过手动关联数据来推断事件的可疑原因，但这种方法通常涉及跨系统的复杂手动查询。
在第 2 级，团队尚未开发出一种自动化方法来统一和关联来自各种工具和领域的孤立数据，因此查明问题的根本原因仍然是劳动密集型和耗时的。 因此，MTTD 和 MTTR 高于它们应有的水平，与较高成熟度水平相比，客户受到的不利影响更大，收入损失更多。
下一步：因果可观测性
可观测性会产生大量数据，并且整理出有意义的信息可能很困难。
在第 2 级，您的团队可能面临数据孤岛和数据量的挑战，这会导致跨域和跨团队故障排除效率低下。
当出现问题时，因为没有人知道问题出在哪里，所以涉及的人太多，导致事件乒乓球和推诿游戏。 您可能需要构建临时解决方案来查询多个可观测性孤岛以解决单个问题。 创建这些查询需要从业者具备开发技能、数据结构知识和对系统架构的理解。
此外，第 2 级中典型的以遥测为中心的孤立视图通常需要大量手动工作才能提取可操作的见解。 设置高效的仪表板可能需要相当长的时间，并且需要持续维护。 根本原因分析、影响分析和警报降噪对于维护可靠和有弹性的堆栈很重要，但这些活动在这个级别上具有挑战性。
注意：团队越来越多地采用 OpenTelemetry 标准来促进指标、日志和跟踪的捕获。 OpenTelemetry 非常有助于有效地收集这些类型的数据，但它并不是为了弥合孤岛、为数据创建更好的上下文或分析数据而设计的。
为了进入第 3 级并了解您的可观测性数据是如何相关的，您需要为 IT 环境中的数据孤岛中的事件、日志、指标和跟踪提供上下文。 在第 3 级，因果可观测性，您可以获得业务流程、应用程序和基础架构的精确拓扑图，并且您可以跟踪它是如何随时间变化的。 当出现问题时，您可以结合自动化使用此上下文数据来快速确定问题的原因，而无需手动处理不相关的数据孤岛。
级别 3：因果可观测性
目标：找到事件的原因并确定其对整个系统的影响。
毫不奇怪，大多数故障是由系统中某处的更改引起的，例如新代码部署、配置更改、自动缩放活动或自动修复事件。 当您调查事件的根本原因时，最好的起点是找出发生了什么变化。
要了解是什么变化导致了问题以及什么影响在您的堆栈中传播，您需要能够看到堆栈组件之间的关系如何随时间变化：
• 问题开始时堆栈是什么样子的？
• 哪些组件受到影响？
• 所有警报如何关联？
我们将此级别的洞察力称为因果可观测性，它可以让您跟踪堆栈中的因果关系，即因果可观测性——它建立在第 1 级和第 2 级奠定的基础之上。
“从拓扑中的数据导出模式将建立相关性并说明隐藏的依赖关系。 使用拓扑作为因果关系确定的一部分可以大大提高其准确性和有效性。”
—— Gartner® AIOps 平台市场指南，2022 年 5 月，Pankaj Prasad、Padraig Byrne、Gregg Siegfried
拓扑是因果可观测性的第一个必要维度。 拓扑是 IT 环境中所有组件的映射，它跨越所有层，从网络到应用程序再到存储，显示一切是如何相关的。 拓扑结合了组件之间的逻辑依赖性、物理接近性和其他关系，以提供人类可读的可视化和可操作的关系数据。
拓扑描述了环境中离散组件之间的一组关系和依赖关系，例如，业务服务、微服务、负载平衡器、容器和数据库。
在当今的现代环境中，随着新代码不断被推入生产环境以及底层基础设施的快速变化，拓扑结构也在迅速发展。 管理这些动态环境需要能够跟踪拓扑随时间的变化（时间序列拓扑），为堆栈中发生的活动提供历史和实时上下文。
现代环境由如此多的动态层、微服务、无服务器应用程序和网络技术组成，因此向您的可观测性组合添加最新拓扑对于区分因果关系至关重要。 拓扑为数千个未连接的数据流提供锚点
赋予它们结构，使以前不可见的连接可见。 拓扑可视化让您可以在全栈活动的上下文中查看来自网络、基础设施、应用程序和其他领域的遥测数据； 它还为您提供了重要的背景信息，让您了解发生故障时您的业务会受到怎样的影响。
然而，对于大多数公司而言，仅添加拓扑不足以提供因果可观测性。 尤其是在当今具有微服务、频繁部署、不断变化的云资源和上下旋转的容器的动态现代环境中，拓扑结构变化很快。 您的堆栈现在看起来可能不是问题刚开始时的样子。 因此，第二个维度对于创建因果可观测性的基础是必要的：时间。
最后，要了解现代 IT 环境的动态行为并获得实现因果可观测性所需的上下文，您需要将环境的拓扑与其关联的指标、日志、事件和跟踪数据关联起来。
在第 3 级，与遥测数据相关的拓扑和时间的其他维度向您显示跨不同层、数据孤岛、团队和技术的任何更改或故障的原因和影响——显着缩短解决时间和业务成果。 您还具备开始自动化根本原因分析、业务影响分析和警报关联的基础。 更高级的 AIOps 也需要这种更深层次的数据，正如您将在第 4 级中了解到的那样。
建立因果可观测性和 AIOps 基础的 4 个关键步骤
- 整合：首先，您需要确保整合了来自整个企业的数据堆放在一个地方，这样您就可以看到完整的视图。
- 收集拓扑数据：接下来，您需要构建环境的拓扑图，这是堆栈中组件的映射，显示它们如何相互关联。 可视化拓扑可以快速回答以下问题：“哪个组件依赖于其他组件？ 如果一项服务失败，还有什么会受到影响？”
- 关联：您需要关联所有这些统一的数据，这样您的整个 IT 环境就可以作为一个整体进行分析，甚至可以跨孤岛进行分析。 拓扑中的每个组件都需要与其关联的指标、日志、事件和跟踪数据相关联。
- 随着时间的推移跟踪一切：最后，如果您想了解一个组件中的更改如何在您的堆栈中传播，您需要将您的拓扑数据与随时间变化的指标、日志和跟踪数据相关联。
| 说明 | |
|---|---|
| 级别 3：因果可观测性 | 通过单个拓扑将遥测数据（指标、跟踪、事件、日志）关联起来。 随着时间的推移关联所有数据以跟踪变化在您的堆栈中传播。 |
| 系统输入 | 级别 1 和 2 + 时间序列拓扑级别 |
| 系统输出 | 1 和 2 + 相关拓扑、遥测和时间数据显示在上下文可视化中，显示堆栈中更改的影响 |
| 你得到什么 | • 通过统一时间序列拓扑中的孤立数据，获得统一、清晰、相关的环境状态上下文视图 • 通过拓扑可视化和分析了解因果关系，显着加快根本原因识别和解决时间 • 基本自动化调查的基础，例如根本原因分析、业务影响分析和警报关联 • 自动将与同一根本原因相关的警报集中在一起，从而减少噪音和干扰所需的上下文 • 能够可视化网络、基础设施和应用程序事件对业务服务和客户的影响 |
表 5：第 3 级总结
下一步：使用 AIOps 主动观察
如上所述，Gartner 指出拓扑可以大大提高准确性和有效性
因果决定。 第 3 级是向前迈出的一大步，但统一来自不同孤岛的数据在数据规范化、相关性和质量方面提出了挑战，这些挑战可能需要新功能甚至组织变革来解决。 此外，很难大规模收集和操作高质量的拓扑数据，尤其是在不太现代化的环境中。
每个拓扑源都需要不断流入主拓扑，因此您需要确保您的系统能够随时间存储拓扑。 随着时间的推移存储与遥测数据相关的拓扑结构提出了更大的挑战。
“随着十几个或更多不同领域的数据量达到或超过每分钟千兆字节，人工手动分析数据以满足运营预期已不再可能，更不实用。”
—— Gartner® AIOps 平台市场指南，2022 年 5 月，Pankaj Prasad、Padraig Byrne、Gregg Siegfried
在制定实施计划时考虑这些问题。 另请记住，第 3 级数据的速度、数量和种类通常如此之大，以至于要实现您的总体可靠性目标，可能需要 AI 来帮助将信号与噪声分开。 当您进入第 4 级时，您可以在第 1-3 级之上添加用于 IT 运营的人工智能 (AIOps)，以获得更准确的洞察力。
第 4 级：AIOps 的主动可观测性
目标：分析大量数据，自动响应事件并防止异常成为问题。
第 4 级，使用 AIOps 的主动可观测性，是最高级的可观测性。 在此阶段，用于 IT 运营的人工智能 (AIOps) 被添加到组合中。 在监控和可观测性的背景下，AIOps 是关于应用人工智能和机器学习 (ML) 对堆积如山的数据进行分类，以寻找模式
• 推动更好的回应
• 尽快
• 由人和自动化系统共同完成。
在 Gartner 2022 年 5 月由 Pankaj Prasad、Padraig Byrne 和 Gregg Siegried 撰写的“AIOps 平台市场指南”中，Gartner 通过以下方式定义了 AIOps 平台的特征：
“AIOps 平台分析遥测和事件，并确定有意义的模式，这些模式提供了支持主动响应的见解。 AIOps平台有五个特点：
1.跨域数据摄取和分析
- 资产关系和依赖的隐式和显式来源的拓扑组装
- 与事件关联的相关或冗余事件之间的关联
- 模式识别以检测事件、其主要指标或可能的根本原因
- 可能补救协会”
我们对 AIOps 的看法与 Gartner 相同。 AIOps 建立在该成熟度模型中先前级别的核心功能之上——例如收集和操作数据、拓扑组装和数据关联——并添加了模式识别、异常检测和更准确的问题修复建议。 因果可观测性是一个必要的基础：时间序列拓扑提供了一个必要的框架。
AIOps 可以帮助团队更快地发现问题，甚至可以完全预防问题。 AI/ML 算法寻找警告、警报和故障之前的模式变化，帮助团队了解服务或组件何时开始偏离正常行为，并在出现故障之前解决问题。
“发现异常很容易，因为它们一直都在发生。 当您每天收集十亿个事件时，每两分钟就会发生一百万分之一的事件。 可观测性工具的关键是发现与手头问题相关的异常，然后从可能相关的日志文件/指标中链接其他信息。 通过在上下文中显示相关信息，操作员可以更快地找出问题的潜在根本原因。”
– Gartner®“Innovation Insight for Observability”，2022 年 3 月，Padraig Byrne 和 Josh Chessman
一盎司的预防胜过一磅的治疗。 有什么比完全阻止事件发生更好的提高可靠性的方法呢？
然而，异常经常发生。 它们并不一定意味着会发生问题，也不意味着补救应该是高优先级。 AIOps 有助于确定哪些异常需要注意，哪些可以忽略。
AIOps 的另一个可观测性目标是通过 IT 服务管理 (ITSM) 和自我修复系统推动自动修复。 例如，如果这些系统接收到不正确的根本原因输入，它们可以自我纠正错误的问题并导致更大的问题。 AIOps 提供更准确的输入，从而提高其有效性。
在第 4 级，您应该注意到更高效和无事故的 IT 运营，提供更好的客户体验。 为实现这些目标，设置 AIOps 以超越孤岛并摄取从整个环境中收集的数据。 AI/ML 模型应该分析我们在之前级别讨论的所有可观测性数据类型：事件、指标、日志、跟踪、更改和拓扑，所有这些都随着时间的推移而关联。
注意事项：不要跳过第 3 级
AIOps 的主动可观测性是确保 IT 系统可靠运行的最佳方式，但直接进入第 4 级并跳过第 3 级中的因果可观测性步骤（数据整合、拓扑、所有数据流随时间的关联）是错误的 ).
此可观测性成熟度模型中的每个级别都建立在先前级别建立的能力之上，但拥有完整的基础对于第 4 级的成功最为重要。如果您在没有全面数据基础的情况下应用 AI/ML，您实际上可能会造成损害。 例如，假设您在自动自我修复系统的前端使用 AI/ML。 如果算法确定的根本原因不正确，则自我修复系统会尝试纠正错误的事情，并可能进一步破坏系统。 如果你在数据不足或质量差的数据之上应用 AI/ML，你可能会在错误的方向上推动自动化，因为算法会学习到错误的东西。
如果没有随着时间的推移与指标、日志和跟踪数据相关的拓扑数据，AIOps 工具可能无法理解这些不同类型的数据在聚集在一起时之间的相关性。 AIOps 需要拓扑和时间提供的额外上下文，以便准确评估根本原因、确定业务影响、检测异常并主动确定何时提醒 SRE 和 DevOps 团队。
| 说明 | |
|---|---|
| 第 4 级：AIOps 的主动可观测性 | 使用 AIOps 对堆积如山的数据进行分类并确定最重要的模式和有影响力的事件，这样团队就可以将时间集中在重要的事情上。 |
| 系统输入 | 1-3 级 + AI/ML 模型 |
| 系统输出 | 1-3 级 + 实现快速 MTTR 和防止故障的主动洞察 |
| 你得到什么 | • 使用 AI/ML 从大量数据中收集和关联可操作信息，对 IT 环境运营有新见解 • 在问题影响业务之前突出显示问题的预测和异常检测 • 团队将精力集中在最具影响力的事件上，从而提高效率并减少工作量 • 提高了自动根本原因分析、业务影响分析和警报关联的准确性 • 事件数据足够准确，可有效用于自动化 ITSM 和自我修复系统 |
表 6：第 4 级总结
下一步
如今，大多数 AIOps 解决方案都需要大量的配置和培训时间，但通常会产生不准确的结果，尤其是在未考虑拓扑随时间变化的情况下。 团队常常带着不切实际的期望和不明确的目标来实施它们，然后发现自己很失望。
4 级是目前最终的可观测性成熟度级别，但随着 IT 的不断发展，我们完全期待出现 5 级。
总结
几十年来，IT 运营团队一直依靠监控来深入了解其系统的可用性和性能。 但向更先进的 IT 技术和实践的转变推动了对监控的更多需求——因此可观测性得到了发展。
借助跨越多个动态、分布式和模块化 IT 环境的基础架构和应用程序，组织需要更深入、更准确地了解这些系统中发生的一切。 可观测性提供了全面的洞察力，在每个成熟度级别提供清晰的功能。
