IT系统为什么需要可观测性（解读版）

May the force be with you.

“the force”，即原力，来描述可观测性的作用。

可观测性无论对工程师、架构师还是技术主管都是一种赋能。

对工程师而言，可观测性能够让大家抓住技术趋势，深入理解云原生技术和分布式系统。让开发工程师理解基础设施，让系统和网络工程师理解应用。云原生时代，全栈能力是一个工程师自我修养的重要部分，当然也是大家未来职业道路中升职加薪的保证。

对于架构师而言，通常面临的挑战是如何让IT系统能够支撑业务量以十倍速增长。这样的增速，不采用云原生等新技术是无法实现的。然而，技术创新的背后是巨大的风险。可观测性为新技术的采用奠定了坚实基础。一方面通过监控自服务，大大加快新业务的开发测试速度，另一方面通过全栈链路追踪，保障业务上生产之后的稳定运行。

对于CTO等技术领袖而言，组织能力的提高极为重要。公司数字化业务虽在快速增长，但IT团队组织架构，人力资源等却难有大的变化。因此，需要借助可观测性建立“数据即事实”的团队协作原则，以此消除部门之间的协作壁垒，有效提升组织的协同作战能力。

说到这里，解释下可观测性为何可以比做“原力”。

可观测性的数据，本就存在，只是散布在各个部门。而可观测性平台的建立，就是数据的汇聚，可以认为是从各个部门收集到了原力。可观测性服务，则是通过汇聚的数据去反哺各个部门，即形成能够控制的“原力”，成为Y、Yoda老师那样的绝地武士。

​

可观测性有很多种不同的定义，最广为流传的是三大支柱说。三大支柱即metrics、tracing、logging。

三大支柱说广为流传的原因，在于他最容易被工程师理解并接受。

然而，三大支柱的提出者，Peter Bourgon的原意恐怕不是所有人都真正理解。

Peter非常务实的指出，讨论可观测性，需要明确讨论对象，对不同的数据类型应该有不同的优化处理方法。注意，Peter原意并不是说可观测性就是三大支柱，而是让大家具体问题具体分析。即便是Metrics，在不同场景下也有不同的含义和处理方法。

Google Dapper（谷歌的分布式追踪系统）作者Ben Sigelman更是直言，metrics、tracing、logging只是三种数据类型。言外之意，还是具体问题要具体分析。Google Dapper的论文，大家多少应该去了解一下。看看google是如何通过零侵扰、轻量级的追踪技术，帮助团队调试和诊断分布式应用的。

因此，三大支柱的合理解读，应当是可观测性需要多类数据类型，每类数据也要在不同场景下选择不同的处理方法。希望大家能够记住这点。如果将来看到把可观测性等同于三类数据结构的兄弟，最好建议他去读读Peter的Blog原文。

Charity Majors是我非常尊重的一位创始人，她是连续创业者，也在Facebook工作过，近几年创立了Honeycomb公司，专注可观测性。

她提出了一个非常独到的看法，即可观测性是用来解释“unknown-unknown“问题的，这个说法听起来似乎有点儿玄而又玄的感觉。

我跟大家解读下：unknown-unknown可以简单理解为探索未知问题。

软件工程中，有一套完整的debug工具，帮助开发人员发现软件中的未知问题。

分布式系统监控中，可观测性扮演了类似debug工具的角色，通过交互式的追踪，定位未知问题。

这里请大家注意，探索未知的说法，其实是Charity借用了软件工程的理论来做可观测性。这样的思路，跟Google SRE的思路完全一致。

在