「可观测性工程」(Observability Engineering) 是一个近年来在软件工程和系统管理领域中逐渐受到关注的概念。它主要关注的是：如何更好地理解、监控和调试复杂的分布式系统。
DevOps 浪潮已经给「软件工程」相关的实践带来了极大的影响。首先表现在各个职能团队越来越紧密的协作和沟通，开发、测试、运维等融合在一起独立发布产品。其次软件流水线的工艺也更加自动化。
然而，不管我们如何娴熟的使用云平台、容器平台和微服务所带来的高可靠性、自愈能力和稳定性等等优势，当我们在生产环境中 Debug 故障时，我们依然是凭经验猜测，还是不得不在多种监控工具之间解读着七长八段的数据， MTTR 故障修复时间仍然长的忍无可忍。我们应该能逐渐意识到：应用系统的现代化所带来的也不是好处，还有更多的是「复杂度」。
软件应用系统本身和其运行环境的复杂度在逐渐攀升，四分五裂的运维管理的工具正在迅速蔓延。
简单的信号量数据的叠加和关联就足够了么？监控工具手段的更新换代是否就可以实现可观测性？在持续没有找到答案的时候，《observability engineering》这本书出版了。
观测云团队译-中文版可至各大电商平台购买
本书是第一本只讨论「可观测性」主题的书籍，围绕这个主题做了相当深度和广度的讨论，下面是关于核心内容的脑图。
「可观测性」 应该成为软件在交付生命周期中的不容忽视的一个重要属性。
增强可观测性的主要好处是提高系统的可靠性、性能和安全性。 当系统出现问题时，拥有良好的可观测性意味着可以更快地发现、定位和解决问题。随着现代软件系统变得越来越复杂，可观测性工程成为了确保高可用性、性能和用户满意度的关键要素。
《可观测性工程》这本书分为五个部分，从历史到未来，从理论到落地，从团队到组织，从商业到文化，内容非常全面。对不同角色和职位的人都有不同的意义：
● 运维：可以提升眼界和实践能力，你会更好的识别和反思当前所处的困局，会从分门别类的监控工具集应用，转向「聚焦生产环境问题的快速识别和解决」。
● SRE：使得对基于 SLO 的监控更加有信心，特别是升级对遥测数据采集、数据结构、后台存储和在团队中推广等方面的认知。你将会更有效的和产品团队合作。
● 开发：可以掌握可观测性驱动开发的概念，以后就会对应用系统的运行状态了如指掌，它是 DevOps 和 SRE 技能组合中不可缺少的一个部分。
● 经理和管理者：这是在产品团队中，在整个组织里大范围落地可观测性左移的必备常识，分布在各个章节里的真实案例分析也是不可错过的内容。
● CXO：轻易了解到投资可观测性的技术要点，用于前期的投资和收益的评判，用于中后期管理的成熟度模型。
《可观测性工程》书籍中的亮点和创新之处在于： 将可观测性的基础知识部分，用开发一种全新的可观测性程序的方式进行描述。首先解释：这个程序最底层的构建要素的角度、分析可观测性的最底层数据结构。然后，我们可以很容易的将这些数据应用到用它们来描述：应用系统在生产环境中的状态的变化过程。同时还提到了如何对接开源的 OpenTelemetry 数据；希望开发的同学能对此种描述方法倍感亲切，同时让运维和 SRE 同学也能拥有一个全新的视角。
《可观测性工程》一书的另外一个独特之处，是引入的「用第一性原理调试应用故障」。
虽然可观测性管理的基本流程也是收集、存储和分析使用数据的过程，这看起来和其它单点的监控功能相似。但是，有没有一个统一的思路可以贯穿这个过程始终，并且推动这个过程不断的循环起来？本书中所描述的「核心分析循环」是会令你耳目一新。在生产环境排错的过程中，所有人都将关注点和焦虑点都放在「谁？什么时候？可以在系统中定位到哪个最准确的唯一（假想）的根因（root cause）」。这种过分关注的结果想法，让我们已经忽略了在 Debug 过程中，我们应该使用什么思路，去探索未知现象中隐藏的未知应用运行的多重故障原因。
本图源于 Honeycomb 文档网站
「核心分析循环」并不是系统宕机后的救命稻草，而是一种理性冷静的思考方法，我们可以在事故的前中后任何时刻想到它。它能指导我们进行更加深度的分析思考，在一个理智的探索过程中，你会更加有条理的得出一连串假设，并逐个求证，在评判各种已知数据的时候，你同样需要不停的怀疑一切，推翻一切结论的勇气。切勿让单点工具的片面观察角度、对历史经验数据的依懒性，限制了我们 debug 生产系统的想象力，限制了人脑更适合做网状的复杂关联分析的能力。
下面是本书中的一些精彩片段。
■ 【序言 - Cindy Sridharan】：本书没有关注协议或标准，甚至各种遥测信号的低级表示，而是将可观测性的三大支柱设想为结构化事件、假设的迭代验证以及「核心分析循环」的三位一体。根据第一性原理对可观测性的构建要素进行整体重构，有助于强调仅通过遥测信号（或简单使用获取这些信号的工具）并不能最大限度地践行观测系统的所有行为。
■ 【11.6 章 – 可观测性左移】：可观测性驱动开发允许工程团队将他们的玻璃城堡变成可以互动的游乐场。生产环境不是一成不变的，而是充满了活力。工程师应该有能力和自信来应对任何异常并且取得胜利。
■ 【14.4 章 - Slack 案例研究结论】：我分享了Slack 如何探测CI 流水线以及如何调试分布式系统的示例。开发人员了解生产环境中的代码情况，首先要考虑的应该是调试分布式系统的复杂性。但是，在发布到生产环境之前，如何正确理解和调试分布式系统同样具有挑战性。
小编个人认为：本书完整地回答了大量的问题，可观测性是什么？如何构建？如何左移？实现可观测性管理平台中的重要技术要点？如何在团队和组织中落地和规模化可观测性？怎样构建可观测性文化？等等。
总的来说：这是一本在「可观测性」主题上用心良苦的作品，意在引导大家走上构建应用系统可观测性的正确道路。
Amazon 上关于本书的评论总结：
- 可观测性在大型公司内部的推广是社会问题，需要说服管理层，书中提供了这方面的指导。
- 书中包含了一些行业领导者的案例研究，介绍了他们如何应用可观测性方法监控生产环境。
- 书中讨论了可观测性的基本概念，它是社会技术系统，能够促进开发人员和业务人员之间的沟通。
- 强烈推荐本书，它适用于任何希望为客户构建系统的人，并具有实际应用价值。
最后，小编认为一个软件系统应该拥有三只眼：
1. 稳定之眼： 从 SRE 站点稳定性工程的角度讲，系统的稳定性是最重要的feature，没有之一。稳定性包含了服务必须具备的可用性和足够的性能。只有运行在生产环境中，被用户能正常访问和使用的代码才能发挥出它应有的价值。在运行的过程中，应用系统会宕机、运行环境可能会出问题，这都会导致应用系统的无法访问和使用；或者系统的 Bug 导致的高错误率，让系统处于半死不活的状态，用户也能从界面上看到千奇百怪的错误。系统是否进入了非正常的不可用状态？系统是否正在经历着性能抖动的过程？错误率是否高涨到即将溃坝？这些现象本质是产品的稳定性不足导致的，而这些现象是否可见，故障根源是否能快速定位？我们就需要用到第三只眼。
2. 混沌之眼： 它是混沌工程，旨在对生产环境中注入人为的故障，在云环境中可以使用的手段很多：随机的关闭虚拟机、随机的杀死正在运行的进程、在网络中注入导致网络拥塞的数据包等等。在错误注入的过程中，我们关注于应用系统还是否能正常使用；应用系统如果宕机了的话，它的故障模式是怎样的。然而，可视化这个过程，可视化应用宕机现场的细节，都需要用到第三只眼。对于混沌工程的复盘和数据分析能帮助应用系统提高稳定性，消除单点故障，提升故障容忍度和自动化迁移等等。
3. 可观测之眼： 可观测性是应用系统本身的一种属性，可观测性的呈现不仅需要在应用程序代码中进行埋点增强（充分条件），还需要方便的采集遥测数据，这些都需要用到可观测性管理平台：可观测信号量的收集、上报、存储和展现分析等功能。可观测性管理平台是「可观测性」显现/表现出来的必要条件。
