可观测性从来不是监控的升级补丁

上周三凌晨两点，我在南京新街口的出租屋被电话炸醒。是之前共事过的后端leader，他们做的连锁餐饮小程序崩了——饭点高峰付不了款，客诉已经炸到了二十多家门店的店长群。

我爬起来开电脑的功夫，他在电话那头急得声音都劈了：公司花了大价钱买的商用监控全在正常转，CPU、内存、核心接口QPS的阈值告警弹了几百条，愣是没一条说清楚到底哪坏了。

那天我们前后折腾了四十分钟，翻了三个开发的本地日志，才找到根因：上周刚上的优惠券核销接口，把用户手机号当查询参数拼到了第三方支付的请求头里，对方因为参数长度限制，直接把这类请求全打回了空响应。

没人提前想到会出这种问题。

监控管得了阈值管不了未知故障

监控的本质是对已知风险的规则匹配。你提前知道要盯CPU超过80%要告警，知道接口成功率低于99%要弹通知，这些所有的规则，都建立在你对故障场景有预判的前提上。可那些你预判不到的事呢？比如开发拼错了参数位置，比如第三方接口悄悄改了参数校验规则，比如机房某根网线松了半格——这些场景永远不可能被提前写进监控规则里。

那天那个leader在电话里骂，说早知道上周花一下午把核心链路的追踪串起来，也不至于凌晨两点在公司蹲地板上翻日志。我没接话，毕竟我自己当年也干过这种事：上线前觉得监控配全了就万事大吉，真出问题的时候，对着满屏的绿灯大屏，连问题出在哪个服务上都摸不准。

可观测性和监控的区别从来不是谁的功能多。它是你遇到完全没见过的故障时，能顺着请求的流转路径，一层一层把根因挖出来的能力——而不是等着某条提前写好的规则给你弹个告警。

别把高基数指标当可观测性的全部

不过话说回来，这两年我见过太多对可观测性的误解。最常见的一种，就是觉得“存得越多越厉害”。

前阵子跟一个做电商的运维聊天，他们光订单查询接口的指标就打了17个标签，从用户ID、设备型号、请求头的UA值，全量塞进了时序数据库。一天下来的指标数据量就有120G，光存储成本每个月就快两万块，算下来够给他们团队发两个月的下午茶福利了。真出问题的时候，运维要等五分钟才能把某一个用户的请求链路拉出来，黄花菜都凉了。

高基数指标从来不是可观测性的核心，只是冗余的成本。你总不能为了查一个用户的故障，把全平台所有用户的ID都当标签存三个月吧？这种玩法除了给云厂商送钱，对排障没有半分帮助。

说实话，很多团队对可观测性的理解，还停留在“多打日志多存指标”的阶段，觉得这是运维团队的事，和业务开发没关系。真不是。你写的代码里漏了关键的上下文记录，就算把监控系统堆成山，真出问题的时候还是要靠人拍脑袋猜。

搭可观测性不需要一步到位

别信那些吹得天花乱坠的厂商话术，说什么要把全链路全量覆盖，要把所有系统的日志、指标、追踪全打通，没有几十万预算根本玩不转。

那个连锁餐饮团队，后来真的落地可观测性，前后只花了三天时间。没买新的商用系统，就干了三件事：先把所有跨服务的请求全加上统一的traceID，不搞复杂的智能采样，就把核心的支付、优惠券两个链路全量打追踪；日志里别只写“请求成功”“请求失败”这种没用的废话，把关键参数、第三方返回的错误码、异常栈全带上；再整个极简的查询页，输入用户的付款手机号，就能把这个用户从进小程序到付款失败的全链路记录拉出来。

成本是绕不开的坎。

上周六他们做店庆活动，又出现了零星的支付报错。这次从发现问题到定位到是第三方接口临时限流，只用了一分二十秒。搁以前，这至少得耗半个小时。

可观测性的落地永远从最痛的故障场景切入。别上来就追求大而全，先把每次熬通宵排障的那个最烦的场景解决掉，比什么都强。

那天挂电话的时候，那个leader说之前总觉得可观测性是大厂才需要搞的花架子，现在才明白，小团队的钱本来就不多，经不起每次故障都靠人熬通宵翻日志的折腾。

没人天生会排障。

好的工具，本来就是帮人少熬点没必要的夜。