可观测性成熟度模型白皮书

可观测性成熟度模型1 版权声明 本白皮书版权属于稳定性保障实验室、北京爱分析科技有限公司、龙蜥社区、国网上海电力信通公司、杭州乘云数字技术有限公司，并受法律保护。转载、摘编或利用其它方式使用本白皮书文字、图片或者观点的，应注明“来源：《可观测性成熟度模型白皮书》”。违反上述声明者，将追究其相关法律责任。 本声明未涉及的问题参见国家有关法律法规，当本声明与国家法律法规冲突时，以国家法律法规为准。 免责声明 报告中部分图表在标注有数据来源的情况下，版权归属原数据所有公司。本白皮书取得数据的途径来源于厂商调研、用户调研、第三方购买、国家机构、公开资料。如不同意引用，请作者来电或来函联系，我们协调给予处理(或删除)。 报告有偿提供给限定客户，应限于客户内部使用，仅供客户在开展相关工作过程中参考。如客户引用报告内容进行对外使用，所产生的误解和诉讼由客户自行负责，不承担责任。 指导单位 稳定性保障实验室 编写单位 北京爱分析科技有限公司龙蜥社区国网上海市电力公司信息通信公司杭州乘云数字技术有限公司 一引言 —引言 莫听监控繁杂声 何妨观测且徐行 智能诊断快胜马 一键运维定乾坤 ——引用龙蜥社区品文（毛文安）的诗 21世纪，以数字技术为代表的第四次工业革命正在加速改变世界，数字化浪潮对各行各业成席卷之势，网络化、信息化和智能化的深度融合引领着生产模式和组织方式的变革。数字化已经不是—个企业、—个行业的使命，而是全行业、全社会的共同发展趋势。如何用数据为企业赋能，如何利用数字技术实现企业业务的转型、创新和增长，已经成为当下全球企业所面临的重要课题。 数字化正在重新定义企业的未来导向，这与企业的业务模式、业务体系及客户体验息息相关，也为持续提升企业竞争力提供了核心动力。而云计算已经逐渐成为企业数字化转型的最佳选择，尤其是在2020年疫情爆发的背景之下，企业上云这—进程被按下了加速键。 云计算时代下，企业的应用交付链路越来越复杂，云原生、微服务、大型分布式等新技术给企业带来竞争力的同时，也带来了全新的挑战，“云深不可见”难题突显。这些高度动态化、分布式的云原生技术与以往截然不同，这导致复杂性变得一发不可收拾。这些复杂性已经超出了现代IT团队的管理能力极限，并且还在不断扩大。若想解决这些复杂的挑战、并随时了解瞬息万变的环境中所发生的一切，需要全新的技术出现，“可观测性（Observability）”应运而生。 可观测性是当今IT领域最热门的话题之一，Gartner将其列为“2023年度企业十大重要战略技术趋势”之一，并指出可观测性可以帮助企业实现数据价值最大化、加速企业数字化转型。尤其是近年来云计算的广泛普及，“可观测性”逐渐取代“监控”成为了企业IT建设与运营的不可或缺的核心能力。可观测性作为一种技术或方法，具有广阔的发展空间，除了在IT运维领域，还可以在许多其他领域发挥作用并取得突破，为社会发展带来积极影响。 二为什么需要可观测性成熟度模型 成熟度模型 二为什么需要可观测性 自2018年，云原生计算基金会（CloudNativeComputingFoundation，CNCF）正式将可观测性引入IT领域以来，可观测性市场迅猛发展，涌现出一大批可观测性解决方案，企业也在寻求不同的方式打造可观测性能力。然而比较棘手的是，传统的监控厂商与新生的可观测性厂商，均使用了相同的术语与概念，这导致客户对于可观测性的定义变得模糊，甚至很难区分出哪些是真正的可观测性方案。 可观测性能力的成长，并不是简单的工具堆砌 随着软件系统的复杂性不断增加，以及对数字化体验的高质量需求日益增强，可观测性工具的增多成为了必然趋势。根据EnterpriseStrategyGroup(ESG)的一项调查，超过63%的企业组织拥有超过10种以上的工具，但即使拥有这么多工具、故障排查依然面临着困难。 图1：EnterpriseStrategyGroup.echTarget,(ESG)-ObservabilityfromCodetoCloud，2022年2月 各不相同的点式工具或方案组合在一起，反而会放大孤岛效应，这些负面影响会蔓延到每一个环节，使得团队被迫忙于处理各种局部问题或孤岛噪音。由于缺乏联系纽带，团队只能将截然不同的数据模型强行整合在一起，这不仅费时费力，还容易出错。 在测试环境或生产环境采用孤岛式的可观测，会影响到DevOps或SRE团队“测试前移”工作的速度和质量。对基础设施和平台运营者而言，在多重云或混合云平台上使用多种工具会导致可观测能力存在盲区。一旦团队接收到未覆盖区域的警报和征兆，其他团队就可能会面临“翻墙而过”的问题和指责。因此可 观测性能力的成长，并不能简单的依赖工具堆砌。 建立成熟度模型，帮助企业明确发展目标 随着动态云、容器、微服务和无服务器架构的趋势发展，以及需要维护企业原有的遗留系统的需求，对可观测性更高级能力的需求日益增强。在这样的背景下，设计一套可观测性成熟度模型变得非常必要。 基于对生产环境实际问题的丰富处理经验、与不同行业客户的深入交流、对最新技术的持续研究，以及与Gartner等领先机构的对话，我们共同创建了可观测性成熟度模型。我们希望通过制作这个可观测性成熟度模型，帮助企业确定在可观测性道路上的位置，并为前进方向提供指引。 可观测性成熟度模型能够为企业提供一种系统性的方法来评估、改进和提升其可观测性体系建设。它可以帮助组织更有针对性地发展可观测能力、优化资源分配并持续改进。通过合理应用该模型，企业可以更好地应对现代软件系统复杂性带来的挑战，实现更出色的用户体验，提高系统可靠性，并在竞争激烈的市场中取得优势。 三三 可可观观测性测成熟性度成模型熟介绍 图2：可观测性成熟度模型图 本次设计的可观测性成熟度模型，是一种用于衡量和评估企业软件系统内部可观测性的框架或方法，同时也是一种用于反馈企业可观测性体系建设成熟度水平的框架或方法。 该模型设计了五个级别，分别是： Level1——监控（Monitoring） Level2——基础可观测性（BasicObservability）Level3——因果可观测性（CausalObservability）Level4——主动可观测性（ProactiveObservability）Level5——业务可观测性（BusinessObservability） 可观测性成熟度模型的每个级别，都必须建立在前一级别已经建立的基础之上，不能凭空构建，每个级别新增的能力，都应该有助于实现更深度的可观测性能力。 级别的提升不是渐进式的，而是明显的跨越式提升（类似量子跃迁）。尽管我们可以通过改进流程、修修补补，在一个级别之内稍微改善结果，但若想实现级别的实质性提升，需要实质性地增强多项里程碑式能力，企业为了级别的提升甚至有可能要求重构现有的可观测架构。 下面对可观测性成熟度模型各级别的目标与功能做简要概括： 表1：可观测性成熟度模型表 Level1：监控（Monitoring） 目标：确定系统组件是否按预期正常工作 监控（Monitoring），是指对系统、进程、活动或环境的持续观察、度量和记录，以便获取实时或定期的信息和数据。通常跟踪某个系统组件的特定参数，以确保系统组件的状态保持在可接受的范围内，一旦超出预设范围，监控器会触发告警。传统监控大多是专门的单向工具、聚焦在某一个性能领域，通常包括应用性能监控（APM)、基础设施监控（ITIM）、网络性能监控（NPM）、API监控等。 在可观测性成熟度模型中，监控是其中一个关键的层级，通常被认为是成熟度模型中的第一个阶段。在这个阶段，企业开始建立基本的监控能力，监控级的目标之一是设置实时警报，以便在系统出现问题或达到预定阈值时能够及时通知运维人员，这有助于迅速采取行动以防止问题扩大。企业组织收集各种关键性能指标，将收集到的指标数据可视化也是一个重要目标。通过仪表板和图表，运维人员可以更容易地理解系统的状态和性能趋势。 在Level1阶段，被监控的各组件之间几乎没有任何的相关性，此级别的主要目标是了解系统组件是否正常工作。尽管在监控级不会进行深入的性能分析，但会开始对基本的性能问题进行分析，以确保系统在某些情况下不会受到显著影响。总之，监控级的主要目标是建立起最基本的监控能力，以确保系统的基本稳定性和可用性。 汇总： 下表概述了Level1阶段的关键功能： 表2:Level1总结 Level1阶段的监控，通常为企业提供各个组件的健康状况，关注事先定义好的指标或数据，根据经验定义告警策略。这种监控方式往往是被动的，只有在特定事件或条件达到时才会触发警报。然而，这种被动性可能会导致忽略系统内部的复杂交互或潜在问题。它只告诉我们某些东西出错了，但没有解释问题的根本原因，也没有告诉我们问题最初发生的时间或背景。当问题出现时，监控可能只提供有关问题的表面信息，无法提供更多的上下文信息和相关数据。 在Level1阶段，由于可分析的数据有限，想要找到根因或影响面非常困难。调查问题的根源一般需要较长的周期，一个问题的出现经常可能导致整个监控体系处于“红盘”状态，各层的监控信息彼此孤立，相互割裂，难以建立起数据之间的关联。因此，需要从Level1升级到Level2来获得更深入的信息，从而提供更全面的洞察力。 Level2：基础可观测性（BasicObservability） 目标：确定系统为什么不工作 IBM对可观测性的定义：通常是指基于对复杂系统外部输出的了解，能够了解其内部状态或状况的程度。系统越可观测，定位问题根本原因的过程就越快速越准确，而无需进行额外的测试或编码。 为保证复杂动态的系统可靠运行，我们不仅需要知道系统组件是否正常运行，还需要了解它为什么不运行。当出现问题时，我们希望遵循“5W1H”的原则了解问题详情： Who 谁 When 在什么时间 Where 在什么地方 What 发生了什么事情 Why 因为什么原因 How 我该怎么办 在监控方案中，通常会预置仪表板或阈值规则，旨在提醒我们未来可能会遇到的性能问题。但是，这些仪表板或阈值规则依赖于一个关键性的假设，即我们能够在问题发生之前预测将会遇到的问题类型。然而，这种方法并不能提供足够的信息，无法回答5W1H的问题。在云原生环境中，这种类型的监控并不适用，因为云原生环境是动态的、复杂的、多变的。这意味着我们无法事先预知可能会出现什么样的问题。在可观测性方案中，我们可以根据更完整、更深入的可观测性数据，灵活地探索正在发生的事情，并快速找出可能无法预料的问题的根本原因。 可观测性能够为这些问题提供答案。 可观测性三大支柱 在Level2阶段，可观测性通过关注三种关键类型的遥测数据来提供系统洞察力：“链路”、“指标”、“日志”，可观测性可以从这三类数据了解系统内部发生的情况。 Traces链路数据是常规的监控工 具不能采集的数据要素，在可观测性体系中占据着重要作用。 图3：可观测性三大支柱（来源：CNCF可观测性技术白皮书） 可观测性三大支柱的具体定义如下： 帮助我们了解服务性能或状态的度量值 指标 例如，著名的四大黄金信号：延迟、流量、错误率、饱和度 系统中发生的相关事件，帮助我们了解系统在给定时间点的行为 日志 例如，事务、警告、错误、带时间戳的记录 详细的全链路快照显示数据如何端到端的流经应用程序，有助于排查性能问题 链路 可以在代码级了解性能问题 Level2相较于Level1的数据具有更大的广度和深度。然而，将这三类数据采集汇聚，汇总到一个平台是可观测性的核心。可观测性的这三大支柱来自于微服务、应用程序、数据库等IT组件，旨在提供对系统行为的整体视角。每个支柱都提供不同类型的信息，如上表所示。 可观测性统一平台 区别于传统监控的一大特点，可观测性强调数据的统一性，旨在通过构建一个统一的平台来实现三大支柱数据的集中汇聚与数据处理，从而打破单点工具的限制。统一平台的目标是将各种可观