随着云原生和微服务的进一步普及，可观测性开始越来越受到关注。对于可观测性的价值，随着时间变化也越来越清晰。可观测性对于践行现代化软件研发体系的企业，已经不是一个可选项，而是一个必选项，企业开始认识到可观测性不仅仅是运维保障工具，而是一个生产力工具。

可观测性对于提升生产力的价值

在现代化的软件研发体系下，软件从开发、测试到交付需要的时间越来越短，但这种高效的模式下其实也面临着不少的冲突：

• 第一类冲突可以总结为开发和运维之间的冲突。对于开发工程师来说，希望自己的代码能够尽快发布。而对于运维工程师来说，最大的目标是保障系统的稳定性。但实际上，这两者之间存在很大的矛盾。敏捷的发布会增加不确定性，为了保障稳定性，运维希望减少发布次数，以降低出现问题的可能性。
• 第二类冲突是我们业务代码运行环境的冲突。实际上，我们业务代码在开发环境的执行效果、测试环境验证过程的执行效果和生产环境实际的执行效果都有可能不一样。
• 第三类冲突是团队之间的冲突。康威定律指出，组织的结构会影响技术架构。严格划分的职能边界反而导致部门之间的壁垒，降低了信息传递的效率。

那么如何应对这些冲突呢？大部分公司都是从生产环境到测试环境再到预发环境，最后到生产环境。然而，往往我们只关注生产环境。我们会在生产环境搭建各种系统来保障系统的稳定性，这就是传统意义上的监控。监控的目的是保障生产环境的稳定性。如果站在可观测性的角度，我们不仅仅要关注开发环境，还要关注测试环境、预发环境和生产环境，所有环境都需要全方位、全面的观测能力。这就是可观测性相对于监控非常重要的一个区别，可观测性应该是面向软件全生命周期的。

如果践行了软件全生命周期的可观测性工程，相当于监控左移，可以让整个开发过程整体可观测。这也是开发能力的右移，测试运维通过可观测性数据能够更加了解系统的运行情况。

如果实践了软件全生命周期的可观测性工程，可观测性的三大支柱可以总结为以下三个方面：

• 监控数据融合：传统意义上的可观测描述。所谓可观测性就是把指标、链路和日志整合串联起来，形成对系统全面的了解。
• 业务环境融合：可观测性也是将开发环境、测试环境和生产环境全方面地观测起来，实现软件全生命周期的观测能力。
• 团队视角融合：通过可观测工具将开发团队、测试团队和运维团队有效地整合起来，让大家养成用数据说话的习惯，而不是靠经验说话。比如一个用户或者客户使用我们软件出现问题的时候，如果没有记录下来当时的行为轨迹数据、调用链和日志数据的话，事后我们是很难复现出来的。如果有完整的上下文信息记录下来的时候，这个效率会大大提升。包括再测试环境下，测试工程师发现系统 bug 提交测试用例，开发工程师针对这个 bug 通常也要去复现。但这样的复现不一定和当时测试同学触发的 bug 一致。这又需要开发同学和测试同学不断地对这个测试用例进行沟通。如果当时没有记录现场的数据，这种沟通的效率一定是低下的。所以，可观测也是将开发团队、测试团队和运维团队连接起来的一个很重要的数据工具。

传统监控面临的一些问题，这些问题导致原来的传统意义上的监控工具无法成为面向软件全生命周期的可观测性工具：

• 分散建设：传统监控工具是运维用来保障生产环境可靠性的，所以一般需要什么监控就使用什么监控。网络有问题就使用网络监控，kubernetes 就使用 kubernetes 监控，日志有日志监控系统。为了解决具体的问题，就使用具体的监控系统。这样导致我们应用保障的监控系统可能就有好几套，比如 ELK、Prometheus、Skywalking等等。这就是传统监控非常显著的一个特点。
• 缺少上下文：传统的监控分散建设导致所有记录，包括告警和事件，都没有记录当时发生的更多信息。因此，在定位问题时，工程师往往需要依靠经验来寻找问题的根源，这个过程中会耗费很大的精力。
• 脱离新技术：传统监控在今天的云原生时代下，也面临着很多新的问题。在云原生时代，Kubernetes 的普及已经是必然结果。传统的监控面临这些新的技术、新的中间件、新的服务网格、混沌工程等等，基本上已经无法适应。如果再加上大量的云服务，传统监控面临的复杂性越来越高。其实我们也可以看到，最近很火的 OpenTelemetry，其实都是说明传统的监控已经在慢慢淘汰了。
• 无法面向用户和业务：传统的监控的目的是保障系统整体的稳定性，但是，随着各种互联网应用的发展，我们不仅需要保障整个系统的稳定性，还需要关注每个用户和租户遇到的体验和问题，以确保我们的业务稳定性。

那么，建立可观测性工具，能够给我们带来哪些变化呢？

第一个变化是传统监控是一个被动系统，而可观测性是一个主动系统。可观测性要求系统主动暴露其运行情况，我们可以利用可观测工具主动发现系统中隐藏的问题。第二个变化是传统监控以运维团队为主，而可观测性是开发、测试、运维协作的。第三个变化是监控仅仅面向生产系统，而可观测性是面向软件全生命周期的。第四个变化是监控仅仅面向故障告警，而可观测性则具有修复 bug 并对性能进行优化的能力。此外，传统监控面对单点告警，而可观测性则具有完整的上下文信息。因此，我们可以看到，传统的监控无法实现可观测性的目的。如果你按照实现监控的目的去实现可观测工程，最终的结果只是实现了一个新的监控工具，而不是可观测性工具。

这里有一份国外的研究报告，对于上了可观测性供应商的方案后，第一个重视的是提高团队的生产力，可靠性只排到了第二位。这说明海外对于可观测性的定位不仅仅是一个运维保障工具，而是一个生产力工具。

Gartner 把可观测性技术列为 2023 年战略技术趋势之一。在 2022 年的技术成熟度曲线中，可观测性已经处于膨胀期。但实际上，可观测性在国内的发展趋势还处于萌芽期到膨胀期的过程中。

可观测性工程落地完整指南

可观测性带给我们的好处不仅是运维保障，也会极大地提升我们的软件研发效能。因此，我们现在应该认识到应该建立业务的全面可观测能力。这种能力是从业务开始的，将我们的客户端、服务端、中间件和云全部串联起来。只有构建了完整的业务可观测能力，才能算得上是落地了一个可观测性工程。

那么怎样才能实现一个可观测性工程呢？无论是采用商业的可观测性工具还是企业自建可观测工具，我们必须有以下清晰的认识，否则我们建立的可观测性工具最终仍将是一个传统的运维监控工具，而不是一个业务可观测工具。

• 构建完整统一的可观测平台：需要建立一个完整统一的可观测平台。如果像传统监控数据一样是独立的，那么上下文 context 也一定是独立的，我们就无法统一关联检索。因此，我们需要实现覆盖全业务、统一采集、统一存储和统一分析。
• 面向软件全生命周期：其次，需要清楚地认识到，可观测性要面向软件全生命周期，一定要让开发、测试和运维协同构建。这一点非常重要，因为可观测性平台最终一定是要开发、测试和运维协同使用的一个平台，不仅仅是运维保障平台。
• 基于数据驱动的能力：要用基于数据驱动的能力来构建可观测平台，让团队习惯用数据说话，把经验沉淀成数据，避免开发、测试和运维用“复现”来沟通。这也要求平台具备数据的快照能力，方便快捷地分享这些上下文数据。
• 持续建设与覆盖：可观测性平台一定要持续建设和覆盖，不断适配新的技术和新的系统，集成第三方产品。

可观测性提升软件研发实践探索

对于软件全生命周期的可观测能力，从开发、测试、运维角度来看，应该具备哪些可观测能力呢？开发可观测能力要求我们具备收集 Tracing 的能力、以及代码剖析 Profile、日志查看 Logging、还有持续集成和持续交付 CI/CD 的可观测能力。对于测试可观测性，我们要有指标 Metrics、Dashboard 能力，用来衡量我们压测的数据，日志查看 Logging，会话重放 Session Replay 相关的能力，对于运维可观测性，重要在于 Dashboard、监控告警、SLO、RUM、Tracing、Logging 的能力。

实践：开发阶段的性能观测工具

对于软件开发阶段，开发同学排查代码性能问题时，经常会在日志里面记录执行的耗时来分析性能问题。这是一个非常普遍的现象，从而反映出来我们其实非常缺乏对于开发环境的性能观测工具，如果构建了开发阶段的可观测性工具，通过链路火焰图非常清楚了解到每个接口调用的时间，以及每个 SQL 执行的时间，再通过调用链关联到代码热点，通过代码热点查看 Profile 代码剖析数据，查看堆栈、方法栈上的相关性能数据。

实践：测试环境的全链路分析工具

对于软件开发测试阶段，测试工程师和开发工程师之间最常用的词汇一定是“复现”这个词，测试同学往往会针对各种测试用例 bug 进行截图，开发同学再根据这些现场截图进行复现，但实际上会经常出现无法复现的问题，甚至测试同学也无法复现当时的测试用例上下文，这种沟通协同模式不光会影响效率，而且有可能在我们软件交付过程中隐藏了不少问题。 对于测试工程师，利用可观测性工具创建跟踪 ID（测试用例），测试用例为通过时再生成快照进行分享，把相关快照链接贴到 bug issue 系统中，开发同学只需要通过快照链接就可以准确定位到测试同学当时触发 bug 的上下文信息，这样让团队养生用数据来沟通的习惯，而不是靠“复现”。

如果使用可观测性的 Session Replay 能力，开发同学甚至都可以使用视频这种非常直观的方式回放当时测试同学触发 bug 的过程，通过可观测性数据，使用回放的技术可以完整记录用户页面浏览过程。

实践：生产环境的端到端全链路可观测工具

在生产环境中，我们需要构建完整的端到端的全链路可观测性能力。从用户的会话访问出发，具备从访问到接口的联动分析，从接口到调用链的分析，以及从调用链关联日志，关联基础设施的能力。这样完备的上下文信息可以帮助我们在应对线上故障时迅速定位根本原因。

可观测性工具的落地能够快速提升企业的生产力，使得团队能够更快地发现问题并及时解决，避免因为系统故障带来的业务损失，其次，可观测性可以提高用户满意度，可以帮助企业更好地理解用户需求和行为，并根据这些信息进行优化和改进。此外，可观测性还可以帮助企业快速了解业务状况和趋势，以便及时做出决策从而实现其业务价值。