序

最近几年，“可观测性”（observability）从小众的系统工程师社区逐步延伸到了更广泛的软件工程师社区，随着这个术语变得越来越有影响力，其不可避免地与“监控”（monitoring）产生了一些重叠。

当然，接下来的事情也不可避免地发生了，监控工具的提供商开始选择并使用那些试图区分可观测性和监控的哲学和社会技术人员所使用的语言和词汇。这些人也充当了“把水搅浑”的角色，使得广大的技术从业者无法有效地分辨“监控”与“可观测性”的真正差异。

把可观测性视为监控是非常愚蠢的。可观测性并不是一个纯粹的技术概念，无法通过购买可观测性工具（无论那些监控厂商怎么说）或者实施开放性标准来实现。相反，可观测性更像是一种社会技术理念，成功地应用可观测性要依靠整个组织的文化，其愿意选择正确的工具去帮助和改善软件的开发、部署、调试和运维。

在大多数（甚至是全部）场景中，团队需要有效地应用监控和可观测性来成功地开发和运维服务。但是，想成功实施要先从根本上理解监控和可观测性两者之间的差异。

区分监控和可观测性的主要依据是基于系统行为的状态空间，以及人们希望探索状态空间的方式和探索的详细程度。“状态空间”指的是系统在不同阶段所要关注的最重要的行为，比如系统设计阶段、开发阶段、测试阶段、部署阶段、用户使用阶段和故障调试阶段。系统越复杂，这种状态空间也就越多，而且互相之间的转换也越多。

可观测性允许这种状态空间被精心绘制出来，并且会对其进行深度探索，以便帮助我们理解系统行为中不可预测的、长尾的或者各种状态下的分布情况。这需要我们对整个系统有更深入的了解。相比之下，监控系统往往只是展示了系统整体运行状态的大致走势。

因此，从收集数据到如何存储数据，再到如何探索这些数据来更好地理解系统行为，这一切都取决于你的目标是监控还是可观测性。

在过去的几十年里，监控的理念影响了无数工具、系统、流程和实践的发展，其中许多已经成为事实上的行业标准。这些为特定领域设计的监控工具已经出色地完成了任务。但它们不能，也不应该被称为“可观测性”工具并推销给无法区分二者的客户。这样做除了给客户带来大量时间、精力和金钱损失外，几乎没有任何明显的好处。

此外，工具只是问题的一部分。一家公司因构建和使用了可观测性工具而获得成功并不意味着同样的事情会发生在其他的组织里。因为大部分情况下，该公司并不会告诉大众其在应用工具过程中所做出的组织文化上的调整和背后一步步演进的过程，以及解决所遇问题的方法，等等。

如果不首先在公司内部建立一个有利于团队成功的工程师文化，那么自建或购买最好的可观测性工具也解决不了问题。一种根植于监控准则（仪表盘、告警、静态阈值）的心态和文化无助于释放可观测性的全部潜力。可观测性工具可以帮助团队访问大量的运行态的细粒度数据，但成功地理解堆积如山的数据从而在软件的整个生命周期中获得收益，才是明确使用该工具的价值，也才能体现出可观测性本身的价值！这个过程本身就需要用假设驱动的、迭代调试的心态来逐步推进。

简单地使用最先进的工具并不能自动在实践者中培养这种心态。如果不把这些想法提炼成具有交叉性的实际解决方案，那么就是在对监控和可观测性之间模糊的哲学区别夸夸其谈。例如，本书中有些章节对将日志、指标和链路作为“可观测性的三大支柱”持负面看法。虽然批评没有什么意义，但事实上，指标、日志和链路一直是人们遥测实际运行系统的手段，其实我们一直在使用“三大支柱”，所以基于此来讨论可观测性也不可避免。

与在现实世界中构建系统的实践者产生共鸣的最佳方式，不是抽象的、不切实际的理念或者概念，而是能够解决他们所面临的技术和文化问题的切实可行的蓝图。本书试图通过提供这样一个具体的蓝图，帮助人们将这些理念付诸实践，从而弥合可观测性的哲学原则与实践之间的鸿沟。

本书没有关注协议或标准，甚至各种遥测信号的低级表示，而是将可观测性的三大支柱设想为结构化事件、假设的迭代验证以及“核心分析循环”的三位一体。根据第一性原理对可观测性的构建块进行整体重构，有助于强调仅通过遥测信号（或简单使用获取这些信号的工具）不能最大限度地观测系统行为。本书也阐明了工程师在团队中建立可观测性文化时可能面临的挑战，并就如何以可持续的方式开展这项工作提供了宝贵的指导，这有利于可观测性实践者获得长期的成功。

——Cindy Sridharan
基础设施工程师
2022年4月26日于旧金山