前言

本文是作者关于可观测性的理解和实践。主要内容有

可观测性的价值

一个事情，价值太小就不值得投入。

可观测性在整个过程中的职能在哪个环节发挥价值。

客户/用户需要好的产品体验，好的产品体验包括可靠性体验，要想有好的可靠性体验，就得减少故障，所谓的降发生、降影响，而这，又依赖了可观测性的能力。所以：可观测性最终是服务于产品体验、服务于商业成功的。核心目标是快速发现、定位故障。

先定义什么是故障？产品体验受损。

定义产品体验受损

SLO指标正常的时候，业务指标未必正常。一定要重视业务指标体系的构建和监控。

数据->特征->观点->洞察

故障原因五花八门

　故障可能是电源模块坏了、机房空调坏了、机柜压住网线了、供电不稳、某个盘故障了、中间件配置错了、被黑客攻击了、分布式中间件脑裂了、写日志hang住了、程序配置错了、程序连接第三方的地址错配成线下地址了、DNS配错了、证书过期了、代码Bug了、疏漏了某个罕见用户流程

首先，依赖的基础设施（基础网络、硬件、Runtime环境）不能出问题，依赖的第三方其他服务不能出问题

可观测性体系还需要利用平台能力、通过数据运营整理，呈现数据特征、帮用户建立初步观点，最终形成洞察，定位故障直接原因。

技术角度来看，一般模块都是有层级关系的，首先是系统，然后是子系统，然后是模块。所以，初始页面应该展示系统的健康状况，如果某个系统有问题，应该可以点击进去查看详情（这个过程称为下钻），下钻到子系统，再下钻到模块，最终找到故障模块。

模块依赖的数据库、中间件、基础网络、机器硬件、第三方服务等等，都会影响模块的健康状况。所以，当模块异常的时候，我们需要知道各项依赖是否健康，如果依赖也异常，那么模块异常的直接原因基本可以断定是异常的依赖项导致的。

线上故障，大概 70% 都是变更导致的，所以运维行业中流传一句话叫：“变更是万恶之源”。

提供工具帮我们分析数据特征，别让用户陷入海量散乱的可观测性 raw data 中。这需要多维分析引导能力、数据串联打通能力。