企业可观测性的演进之路

近 10 年间，企业线上服务与 IT 基础设施的规模不断扩大，各种与之匹配的研发实践、生态如微服务、DevOps、云原生等等也不断的发展。在 Canonical 发布的 Kubernetes and cloud native operations report 2022 中显示：超过 40% 的受访者所在的组织运行了超过 100 台机器（包括VM、Bare Metal 等），而超过 20% 的受访者所在的组织，拥有超过 10 个 Kubernetes 生产集群。

业务复杂度的提升以及规模的扩大，让运维工作愈发关键且困难，而为了快速响应业务变化，对 DevOps 的要求也越来越高。例如在 DORA Four Keys 中提到，对于发布频率这一指标，精英级别要求能够按需发布，实现每日变更多次。但发布变更常伴随着故障。

「76% 的 IT 系统故障是由变更引起的」

-- 18 Key Areas Shaping IT Performance Markets in 2020

多数故障都是由变更引起的，而对变更频率的要求又越来越高，虽然可以通过提升软件质量来降低故障率，但故障是不可避免一定会发生的。为了降低故障对业务的影响，我们便期望修复故障的时间尽可能的短，但修复故障的前提是定位故障。

「66% 的 MTTR 用于识别是什么变化导致了故障」

-- 2022 State of Managing IT Performance Study – Key Takeaways

日趋复杂的系统让故障根因难以直观地显现，毕竟规模越大的业务，其所涉及到的各种应用、服务、基础设施等环节可能越复杂。因此系统复杂度的上升，导致处理故障的大部分时间都花费在定位问题上。

对系统发生了什么了如指掌是定位问题的前提，因此如何监控整个线上系统，如何获悉规模巨大的系统的运行状态，成为了一大挑战。这种挑战反过来也促进了可观测性领域的发展。

对于数字化落地较早的企业，为了应对挑战，可能早已构建了 APM、NPM 监控系统，以及开源的或是商用的追踪系统等。而对于传统企业可能数字化的步伐才刚刚开始，线上服务还停留在从无到有的阶段。

那么企业处于自身特定的发展语境下，对可观测性的要求有什么异同呢？

总体上看，可观测性代表了对系统形成洞察的能力，可观测性水平越高，对系统形成的洞察就越深。因此不论企业的数字化程度是低是高，其构建可观测性能力的目标都是不会改变的。

这些目标包括：

• 更全面的收集系统上下文 

系统可观测的前提是收集数据，各种遥测数据反映了系统当时的上下文。因此数据越多越全，对系统运行的还原度就越高。但由于采样底噪以及数据管理等问题，既要获得全面的上下文，又要限制收集的规模，权衡并不容易。

• 更有效的关联各层级数据 

遥测数据是单一而孤立的，基础设施层关心的数据与业务应用关心的数据可能相去甚远。数据之间只有建立起关系，人脑才易于从中发现问题，抽丝剥茧。数据形成关联的有效程度，与能从中获得洞察的深度成正比。

• 更自动化的寻找问题根因 

数据规模可能会指数增长，但人脑的产出只能随着时间线性增长。因此如何通过自动化的手段，降低人脑的认知成本，缩短人工时间，逐渐变得愈发重要。

不同企业之间可观测性能力建设的差异，可能主要体现在对上述目标的完成程度上。

企业可观测性能力的建设是持续深入的过程，那么如何才能衡量现状，发现不足进而指导未来的方向呢？

StackState 作为一家提供可观测性解决方案的咨询公司，发布了一份 《可观测性成熟度模型》，基于其对真实问题、客户讨论以及技术研究，旨在帮助企业在可观测性能力建设上作为指导。

《可观测性成熟度模型》将可观测性分为四个等级，从低到高，越高的等级代表越能深入的对系统进行观测洞察。

Level 1：监控

监控代表了相对古老而简单的观测手段：跟踪数值。

跟踪的数值通常专注于基本的组件、应用层面的参数指标，如可用性、性能、容量指标等等。每一次对指标的采集将产生一个事件，事件结合某些阈值，则可能引发报警。

作为最初级的可观测性，通过跟踪数值和指标报警的能力，企业能够获悉组件或应用的健康状态，并在出现故障后得到通知。然而，跟踪数值加报警的形式，的确能告诉运维人员组件出了故障，但故障的原因是什么，需要联系谁来解决该问题，都无法在这一级别得到很好的处理。

此外，随着时间的推移，越来越多的指标项被加入监控系统，结果一个问题可能会导致一连串的指标报警，从而出现 “到处亮红灯，但不知道发生了什么” 的窘境。

Level 2：可观测性

可观测性是可观测性成熟度模型的第二个等级（名字起得差强人意）。由于上一级别遗留的问题，即只知道出了故障但难以得知故障产生的具体原因。因此第二级的目标就是能确定系统不工作的原因。

第二级可观测性，通常可以采用 “指标”、“日志”、“跟踪” 这三种关键类型的遥测数据来提供系统洞察力。“指标” 与上一级的跟踪数值基本一致。“日志”是对系统中发生事件的带时间戳的记录。”跟踪“则能显示数据是如何从头至尾流经系统的。

实际上，我们会发现这三种关键数据（某些文章称之为三大支柱）已经广泛的应用在了成熟的微服务系统中，围绕着“三大支柱”的各种解决方案也层出不穷。总之，通过合理的方案采集这些遥测数据，并展示在仪表板上，就实现了第二级的可观测能力。

诚然，借助”三大支柱“的有力支持，第二级可观测能力能够更广泛而全面的了解整个系统的运行状态。但随着系统规模的扩大，遥测数据会越来越多，不同的遥测数据也可能会存在于不同的系统中（数据孤岛）。那么当出现问题时就需要通过人工从大量遥测数据中抽丝剥茧，关联因果关系。随着规模的扩大，受限于人力排查，MTTR 的时间也会不断延长。

Level 3：因果可观测性

通过人工建立数据相关性，低效且不直观。因果可观测性，作为第三个级别，能够通过某些手段揭示这种相关性，从而达到找到事件发生的原因且确定其对整个系统影响的目的。

具体通过何种手段建立相关性，将在下一节描述。那么假如已经实现了因果可观测性能力，可能会遇到的新的挑战可能是什么？

如何对数据规范化，如何长期存储并高效使用这些数据可能会是下一阶段的挑战。另外，巨大的数据量也会导致即使揭示了数据的相关性，但仍然需要耗费大量时间来从噪音中分离出有用的信号。

Level 4：使用 AIOps 的主动式可观测性

通过 AI 和 ML 的方式从堆积如山的数据中寻找模式，从而能帮助团队更快的发现问题。在指标报警和警告中找到模式的变化，可以帮助团队提前预知可能发生的故障，进而实现预防性的、无事故的运维目标。

AIOps 能够提升效率，提高根因分析的准确率，甚至预测异常和实现系统自愈。

从前面可观测性的四个成熟度等级可以发现，可观测性成熟度第二级别，得益于开源技术的成熟，是目前多数系统能够达到或是已经处于的位置。而更进一步，达到因果可观测性，则是相对清晰的发展方向。那么，如何实现因果可观测性的目标，建立数据之间的相关性呢？

《可观测性成熟度模型》中给出的方法，是建立时间序列下的拓扑结构变化视图。

对系统进行故障根因调查时，先看看系统 “发生了哪些变化”，是一个合理的切入点。毕竟大多数故障都是因系统发生了变更而引起的，比如新的代码部署、配置变更、自动扩缩容等等。

但复杂的系统可能会发生不止一处变化，如果能对比故障发生前后，整个系统栈的拓扑结构变化以及组件之间的关系变化，就能清晰的辨别出变化点及其之间的关系。

拓扑结构是系统内所有组件的地图，它跨越了所有层次，是离散组件之间关系和依赖的集合。

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

--《可观测性成熟度模型》

来源：《可观测性成熟度模型》

如上图所示，将原本孤立的数据比如服务的注册发现、自动化部署、请求追踪等等数据汇聚，形成完整的拓扑结构，那么第一级与第二级已经实现收集的各种遥测数据就都可以挂载在拓扑图上。

此外，单有拓扑图还不够。对实施自动化运维的现代系统环境中，频繁的发布、不断变化的基础设施以及动态扩缩容使得拓扑结构变化的很快，处理问题时刻的系统拓扑，可能已经与发生问题时刻完全不同了。

因此，除了构建拓扑结构来关联数据，留存基于时间的快照也非常关键。一旦拥有了随时间变化的拓扑结构快照，就可以在时间线上自由的对比拓扑的变化并查看对应的遥测数据。

来源：《可观测性成熟度模型》

透过时间序列下的拓扑结构视图，数据孤岛被弥合起来，大大加快了根因分析的速度。关联起来的数据也易于建立模式，为自动化分析奠定基础。当然，建立这样的数据模型并不容易，除了技术上的挑战，可能还涉及组织上的变革。目前已经有例如 OpenTelemetry 这类开放标准，尝试先从遥测数据收集的角度建立初步的关联，虽然遥测数据只是第一步，但也是一个良好的开始。

成熟度模型为企业可观测性演进的方向提供了阶段性的参考，那么在建立系统可观测性过程中，为了覆盖企业需求，具体需要关注什么样的能力呢？有哪些技术可以引领可观测性向着更高的成熟度而演进呢？

Gartner 在 2022 年年中发布的 Critical Capabilities for Application Performance Monitoring and Observability 梳理了APM 和可观测性的六项关键能力：

应用程序调试及分布式剖析（ADDP）：识别代码内的缺陷及错误的根源，来缓解性能下降问题

行为分析：支撑对用户及应用行为的探索和分类

业务分析：通过统计各项业务 KPI （如转化率、弃购率、业务健康度）来为营销人员和应用开发者提供对整个业务条线的洞察力

IT 服务和基础设施监控：以类似 SLA、OLA、SLO 的形式为开发者、DevOps、运维团队等提供基础设施、关键服务的健康度

根因分析：通过 APM 等技术建立问题、原因、影响的关系链条，支撑故障修复

运行时应用程序自我保护（RASP）：在运行时识别易受攻击的组件并在一定程度上阻止风险请求

以上六大关键能力，从包括开发者、运营者、管理者等多个视角覆盖了不同角色对可观测性的要求，在通往因果可观测性，甚至是 AIOps 的主动式可观测性的道路上，对上述能力的演进要求，可能会聚焦在以下两个方面：

1. 如何更全面的收集数据，更好的聚合、关联数据，避免数据孤岛

在链路追踪和性能优化等场景下，传统可观测系统能提供的数据更多在应用层面，而系统、内核以及硬件层面的数据，通常不易获取，且难以关联。通过 eBPF 技术获取底层栈的信息并与上层栈数据进行关联，这种解决方案逐步贴近了“全栈、全链路”的追踪目标，很可能会成为今后链路追踪的标配。

2. 如何主动的基于数据洞察形成建议，引导人类做出管理决策

收集的数据越全面，关联越多，数据规模势必越来越大，目前很多大规模企业的观测数据规模早已超出了人力所能处理甚至理解的程度。今后通过 AI 来帮助人类处理和分析数据也许是必然的结果，在以 ChatGPT 为代表的大语言模型日趋成熟的今天，结合企业自身垂直领域的观测数据进行深度训练而得到的增强 AI，预计能够为人类提供更准确和理性的决策。

本文通过介绍《可观测性成熟度模型》，描述了企业可观测性演进的阶段性参考。在成熟度模型中，因果可观测性是指通过建立数据之间的相关性来打破数据孤岛从而建立对数据更深层次的认知。可以基于时间序列下的拓扑结构变化视图的方法来实现因果可观测性。

可以预见，企业对可观测性的重视程度会越来越高，未来通过更加成熟的可观测性能力，企业不仅能洞察在线服务的运行状况，还可以支撑商业分析、精细化成本管理、自动化运维等多种场景的需要。