了解可观测性 2.0 如何解决技术债务并优化开发者工作流程。
译自 Beyond Monitoring: How Observability 2.0 Is Revolutionizing Developer Experience，作者 Thomas Johnson。
可观测性 已迅速成为现代工程策略的基石，尽管最近对其定义存在激烈争论。可观测性源于控制系统理论，由 Honeycomb 团队在 2016 年推广普及。他们扩展了 Rudolf E. Kálmán 的定义——“根据系统外部输出推断其内部状态的能力的度量”——并将其重新定义为“在无需发布新代码或收集新数据的情况下，向系统提出新问题的能力”。
可观测性很快在应用程序性能监控 (APM) 工具中得到应用，尤其是在 Peter Bourgon 2017 年的博客文章 发表之后，该文章提出可观测性由“三大支柱”组成：指标、日志和跟踪。该框架与 APM 产品紧密结合，迅速成为行业标准。
然而，与最初的含义相比，这种模式限制了可观测性的潜力。
事实上，可观测性超越了传统的监控和数据收集；它旨在揭示系统行为，使团队能够发现“未知的未知”，并完全理解复杂系统。
可观测性 2.0 代表着朝着实现该术语最初承诺迈出的一步，它为开发人员和决策者提供了有关其系统的实时、可操作的洞察力。
在本文中，我将探讨可观测性的演变及其对开发者幸福感、生产力和日常体验的影响。
鉴于可观测性 2.0 非常新——今年夏天由 Charity Majors 正式提出——让我们来阐明这两个版本之间的区别。
可观测性 1.0 与 APM 工具密切相关，指的是传统的做法，即收集大量的遥测数据（指标、日志和跟踪），然后通过仪表板或人们经常渴望的“单一视图”显示出来。
可观测性 1.0 的核心是关注运营：它会在软件投入生产后突出显示已知问题。如果您已经知道要查找什么，它会很有帮助——即“已知的未知”——但它需要手动探索才能找到问题的根本原因。
因此，开发人员不喜欢依赖 APM 工具来执行调试等任务，因为它们提供的是大量的聚合数据，而不是解决问题所需的特定信息。他们经常感觉自己像是在大海捞针。
虽然可观测性 1.0 有助于管理分布式系统，但它并不能完全解决开发人员的日常挑战，也不能帮助他们主动了解其系统。
可观测性 2.0 代表着关注点的转变，从仅仅识别运营问题转变为在整个软件开发生命周期中赋能开发人员。它承认我们对“可观测性”的定义正在演变——或者更确切地说——最终实现了其最初定义的承诺。
可观测性 1.0 强调识别火灾和监控系统健康状况，而可观测性 2.0 则更加以开发人员为中心。它是关于解决问题的根源，并通过将可观测性嵌入到开发过程中来减少事件发生的频率——换句话说，在问题出现在可观测性 1.0 仪表板上之前就解决问题！
可观测性 2.0 为开发人员解决的两个主要问题是：
- 他们需要对其系统进行精确、实时、上下文丰富的洞察，以便他们能够依赖单一的事实来源来了解未知的未知。
- 更快的调试速度，开发人员可以轻松地内省或理解复杂系统。
这是有可能的，因为可观测性 2.0 的构建块是日志事件，与指标（可观测性 1.0 的主力）相比，日志事件更强大、更实用、更具成本效益，因为它们保留了数据之间的上下文和关系。
此外，可观测性 2.0 建立在 OpenTelemetry 等开放标准之上，这使得开发人员可以使用通用的跟踪、日志和指标标准。
开发者体验 (DX) 影响着工程师对工作的看法，进而影响生产力、参与度、幸福感和留存率。强大的 DX 能够营造一个团队可以尽力而为的环境，高效且热情地应对挑战。
最新的 Stack Overflow 调查显示，技术债务仍然是开发者最头疼的问题。它常常导致开发者士气低落，因为开发者必须修复错误，却无法对系统进行重大重构。除此之外，复杂的系统、糟糕的文档和调试工具的缺乏也会造成负担，显而易见，每周会有超过 8 个小时的时间浪费在低效率上。
这直接影响了 DX，阻碍了团队交付可靠、可扩展和可维护软件的能力。研究已经确定了改进 DX 的三个核心领域：
- 反馈循环: 通过快速学习和调整实现持续改进。
- 认知负荷管理: 提供准确、易懂的文档。
- 最佳心流状态: 最大限度地减少干扰，保持深度工作。
可观测性 2.0 通过增强开发人员的可见性并减少手动任务来解决这些问题：
- 实时、上下文丰富的洞察力: 开发人员可以立即获得有关系统更改的反馈，帮助他们更快、更自信地发布代码。可观测性 2.0 使发现系统设计、架构和依赖关系不再像考古挖掘一样，而是清晰地显示所有组件及其关系。
- 减少手动工作: 使用 OpenTelemetry 等可观测性框架进行文档记录意味着您的运行系统可以与您的文档保持一致，而无需进行手动更新。借助上下文丰富的数据，调试也变得更加高效，开发人员无需筛选海量数据即可诊断问题。
可观测性 2.0 为新的用例和工具打开了大门，可以解决开发人员的日常问题，并为他们节省大量时间和精力。
让我们来看看调试过程，以及它是如何随着可观测性 2.0 的出现而演变的。
传统的调试涉及一种“先搜索”的方法：开发人员筛选遥测数据，搜索无休止的日志和跟踪，使用直觉进行模式匹配，并依赖经验、有根据的猜测以及（可能已经过时的）系统心智模型。
他们试图重现问题，尽管由于报告含糊不清和不完整（如果有任何细节的话），这并不总是可能的。
最后，他们可能还必须浏览分散的资源（文档、架构图、决策记录、API 和代码库），才能全面了解系统。
在复杂、分布式系统中，问题很少是孤立的。要了解不仅是什么出了问题，还要了解为什么和如何出错，就需要关联各个系统层的数据，这既耗时又容易出现人为错误。
更不用说，有时由于业务需求和截止日期的压力，团队会被迫“尽快解决问题”。使用可观测性 1.0，这可能会导致只解决了问题的“症状”，而没有解决实际的核心问题。
借助可观测性 2.0，像 Multiplayer.app 这样的新开发者工具利用 OpenTelemetry，可以通过深度会话回放进行平台级调试。开发人员只需单击一下，即可捕获显示重现错误步骤的会话，并附带从前端屏幕到深度平台跟踪的数据、指标和日志。
通过将实时数据映射到整个系统架构，开发人员可以获得从高级设计到单个组件和依赖关系的清晰、上下文丰富的视图，从而大大减少故障排除时间。
可观测性的演变反映了现代软件系统日益复杂，以及需要更复杂的工具来管理和理解它们。
通过利用可观测性 2.0 和 OpenTelemetry 等框架，组织可以对其软件进行全面的实时观察，改善开发者体验，并提高整体生产力和长期可持续性。
他们不再只是解决“症状”（就像因为头痛而不断服用止痛药一样），而是解决根本问题，并在头痛形成之前就将其预防。
展望 2024 年及以后，可观测性将继续推动软件可靠性、可扩展性和可维护性的进步，最终为组织节省时间、资金和工程工作量。
未来，我们可以预期可观测性 2.0 将通过自动化复杂的故障排除流程、实现快速 onboarding 并减少知识孤岛，进一步推动开发团队的发展。可观测性将继续发展，解决软件开发和运营挑战的方方面面，从而打造更高效、更具成本效益和更具弹性的工程组织。