上周三凌晨三点被微信电话震醒。
是做电商运维的老周。
说大促前的全链路压测炸了，查了俩小时，所有监控大屏绿得发亮，CPU、内存、QPS、接口平均耗时全在阈值以内，就是用户下单环节随机报500，二十多个人挤在会议室里，盯着几个大屏转得像陀螺，连个故障根因的影子都摸不到。
大屏全绿的时候才最容易出大事
我当时在电话里翻了个白眼。
这场景太熟了。
很多团队对监控的认知还停留在”阈值告警”的阶段，只要指标没碰着红线，就觉得系统稳得一批。可偏偏那种随机触发、没有明显规律的故障，最容易在全绿的大屏里躲猫猫。大屏全绿不代表系统没问题，只代表你预设的指标没出问题。
老周他们的监控体系做了快五年，从最开始的Zabbix到后来的ELK，再到去年上的商业链路追踪平台，该有的组件全有，可真到压测出问题的时候，只能看到”下单接口耗时超过2s”这个结果，至于时间到底耗在哪了？
是订单服务调库存接口的时候超时？
是库存服务扣减Redis库存的时候key冲突？
还是下游风控网关临时抽风，多耗了几百毫秒？
没人知道。
本质上还是因为，他们的监控全是「预设好的指标」——你提前知道要监控啥，才会埋点，可故障永远是你预设之外的东西。
别把可观测性当成监控的贵价皮肤
老周后来跟我吐槽，说他们去年花了大几十万上的所谓”可观测性平台”，销售当时吹得天花乱坠，说能实现全链路的黑盒变透明，结果真出问题的时候，还是跟原来的监控没啥区别。
说白了。
他们理解的可观测性，就是把原来散在各个系统里的指标、日志、链路追踪，全搬到一个统一的大屏上，换个更炫的可视化效果，就完事了。
这哪是可观测性啊。
这就是给原来的监控系统买了个贵价皮肤，看起来高级了，该瞎的地方还是瞎。可观测性的核心从来不是可视化的炫酷程度，而是你能不能应对没预料过的故障。
我当时跟老周说，你去看看你们链路追踪的埋点，是不是只加在了服务的入口和出口？中间的业务逻辑，比如下单的时候要校验用户风控等级，要扣减用户成长值，要给库存服务加分布式锁，这些中间环节，你们是不是全没埋点？
老周愣了半天，说好像是。
最后他们熬到早上六点，才查出来问题的根因——压测的时候为了模拟爆款商品的并发，把库存分布式锁的粒度设成了按商品ID加锁，所有请求都抢同一把锁，排队等锁的时间最长到了3秒，可这个锁等待的耗时，他们从来没埋过点，监控里看不到，链路追踪也只记了库存接口的总耗时，把锁等待的时间和实际扣减库存的时间混在了一起，所有人盯着总耗时涨，根本不知道时间全耗在排队等锁上了。
这就是可观测性和传统监控最核心的区别：监控是你提前知道要盯啥，你就盯着啥，出了你没预设的问题，你就抓瞎；可观测性是当系统出现你从来没预料过的问题的时候，你不用临时加埋点，不用紧急发版，就能顺着已有的观测数据，一层层把根因挖出来。
说真的，太多团队把这个概念搞反了。
落地可观测性先别着急买全套工具
说实话，我见过太多团队，一听到要搞可观测性，第一反应就是找厂商报价，买最贵的平台，接全量的日志、指标、链路，恨不得把用户的点击行为数据都塞进去。
结果呢？
钱花了不少，平台里存了几百T的日志，大家出问题还是习惯登服务器grep日志，从来不会去平台上查。
为啥？
因为你接进来的数据，根本不是大家排查故障的时候需要的东西。
比如老周他们团队，之前每个月都要遇到个两三次”接口超时找不到根因”的问题，那你落地可观测性的时候，根本没必要一开始就搞全量埋点，先盯着这个高频踩坑的场景，把所有可能导致超时的中间环节的耗时，做成可下钻的指标就行。
比如刚才说的分布式锁等待时间、Redis的命令执行耗时、下游HTTP调用的超时时间、甚至是JVM的垃圾回收停顿时间，这些东西你不用全量埋，先把你之前踩过的坑对应的环节补上，就已经能解决80%的排查难题了。
当然，可观测性也不是啥万灵药。
要是你团队连核心业务的全流程都理不清楚，就算把系统产生的每一个字节都记下来，你还是不知道该看啥。
我见过有的团队，连用户下单要经过多少个服务、多少个中间环节都数不清，就算给他们再好的工具，也是白搭。
要是你现在正打算启动可观测性的项目，先别急着走采购流程。
拉着开发、测试、运维的核心成员，花两个小时，把过去半年遇到的最头疼的三次故障列出来，看看当时排查的时候卡在哪一步，缺了啥数据，就先补啥数据。
比你买啥顶级工具都管用。
真的。