可观测性工程

从这篇 【第3209期】中后台平台化探索和演进 里提到的一句话：“对全部业务的可观测能力建设，了解业务资产和债务”，对可观测能力这个词有点好奇，就稍微了解一下。
本文来自观测云创始人 & CEO@蒋烁淼

可观测性已成为一个热门话题，并广受关注。随着它的普及，“可观测性” 不幸被误作 “监控” 或 “系统遥测” 的同义词。可观测性是软件系统的一个特征。而且，只有当团队采用新的实践进行持续开发时，才能在生产软件系统中有效利用这一特征。因此，将可观测性引入系统既是一个技术挑战，也是一个文化挑战。

第一次工业革命的基础是蒸汽动力的发明，第二次工业革命的基础是电力驱动的发明，那么当前信息革命最大的基础就是互联网驱动的数字革命，而互联网还在各行各业不断渗透，已经成为整个社会和人类进步的基本因素。
如今各行各业都在快速互联网化，未来不仅仅是传统意义上的互联网公司提供互联网应用，每一个行业都会变成互联网应用。在零售行业，不仅仅只是线下门店、APP、小程序、数字门店、电商，整个零售行业都变成了一个互联网应用。在汽车行业，我们看到新能源汽车的蓬勃发展，但更要看到所有的汽车都变成了互联网汽车，每一辆车都是联网的，汽车本身从传统的硬件变成了某种情况下的软件，成为互联网应用。政府和医院也开始互联网化，我们现在可以通过线上平台、便民 APP 或小程序使用各种公共服务，这些服务也变成了一个个互联网应用。可见，越来越多的产业都在发生这样的变化。
在互联网化的巨大业务需求下，整个 IT 基础设施正发生重大变化 — 从传统的单体应用逐步向微服务演化。这不仅体现在不同软件之间能通过 API 连接，随着容器和云原生技术的发展，软件内部也变成一个个微服务。在云计算的加持下，面向互联网的软件从传统的信息化支撑软件演进成业务的关键核心系统，此时对软件系统本身的生命周期管理也在改变，比如，以前交付后能以初始版本不升级就连续运行几年，变成现在每几天就会在线热更新一次。此刻，我们不仅要解决软件系统运行时产生的稳定性问题，更需要发现潜在的线索，包括找到如何持续优化软件本身的思路，以及如何进一步提升最终用户体验，等等。
传统的监控软件整体设计思路是被动的，是基于阈值或者事件驱动的逻辑，或者说是一种基于故障触发的逻辑。这对传统系统是有效的，因为监控软件的主要使用者是运维工程师，他们只需要保证 IT 系统本身的稳定性，并不过多关注上层业务，更不用说最终用户体验了。而构建可观测性的目标可不只是做一个更庞大的传统监控，而是要让所有与该系统相关的工程师能从全局角度去理解整个系统的运行状态，包括理解软件的运行情况、理解代码的执行逻辑等，最终目标是服务所有研发、测试和运维团队，使大家能够在同一个上下文中阅读系统，对问题有一致的理解并给出真正能触及根因的解决方案。可观测性面向的不仅是已显现的故障，更重要的是能够通过主动探索系统去发现问题，这些问题包括传统意义上的已定义的故障，也包括代码内隐蔽的 Bug、架构上的瓶颈点、执行逻辑里的漏洞、用户体验的缺陷、某一个最终用户操作中遇到的各种麻烦，等等。
说到这里，你可能会认识到，若要实现整个可观测性工程，就需要有一个记录软件运行状态的实时数据仓库，这个数仓的数据规模要比传统监控大得多，不仅包含指标、链路和日志，还包括用户行为事件、网络数据、安全数据、业务数据等，并要有能力去综合采集、存储、分析、管理各类海量的数据，同时又要保证整体成本可控。它要能以统一标准的方式全量接入相关的数据，而不是只收集那些你自认为需要监控的数据，因为若很多数据没有被记录，那将无法完整还原真实历史状态；它能提供更多的测量手段去观测数据以探明动态的因果关联，而不像传统监控软件那样只能用固定格式的仪表盘来展示数据；它需要大幅度降低使用者的学习门槛，不仅面向运维工程师，还有研发测试团队，甚至涉及产品运营团队，大家共同来解决共识问题，快速理解这些软件问题与业务问题间的上下文关联。
因此，可观测性工程不只是一个更好的监控工具，更是一种现代化的互联网软件基础设施，是团队执行力的体现。我们会清晰地发现，能否有效地构建可观测性工程直接反映了整个公司产品的质量，间接反映了整个公司的发展潜力和工程师文化。构建可观测性工程本质上就是整个互联网软件本身的数字化，使用可观测性平台的组织才会成为基于数据驱动的现代化组织。
《可观测性工程》一书非常详细地描述了为什么要构建可观测性、可观测性的价值、可观测性构建过程中的原则和可能存在的陷阱，也指出了现代化软件工程的发展方向和趋势，值得每位工程师（包括所有技术管理者）好好阅读和思考。我相信，当你看完本书后，一定会迫不及待地在公司内开始构建可观测性工程。


对这《可观测性工程》有兴趣的读者，可以通过下方解详情。





免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！