上周三凌晨两点，我在公司楼下的鸭血粉丝汤店蹲到了刚从机房出来的张工。他手里攥着半凉的鸭油酥，电脑屏幕上的告警红得像老板上周批的绩效改进单。
那天他们刚搞完双11的压测，支付接口的超时率飘到了12%，查了三个小时，所有人都快把Grafana的看板翻烂了，连个根因的影子都没摸到。
别把监控当可观测性
说实话，这事我太有共鸣了。
之前我们团队也踩过一模一样的坑。
总觉得埋了Prometheus的指标，配了几十块Grafana的看板，再把ELK的日志搜得飞起，就是做了可观测性。
屁。
可观测性的核心从来不是把数据堆到看板上，而是能从任意一个异常点，顺藤摸瓜找到根因。
监控是啥？是你提前知道CPU会飙高，内存会溢出，然后设个阈值等着告警。但可观测性是你根本不知道下一个坑在哪，甚至连坑在哪一层都摸不清，出了问题能顺着链路摸过去，不用瞎猜。
上次压测的问题，最后是张工拿脚本扒了所有接口的调用耗时，才发现是个没人注意的用户画像同步接口，每次同步的时候会占满数据库的连接池，导致支付接口拿不到连接。
这个接口的CPU、内存指标全正常，日志里也没写”我占满连接池了”，之前的监控根本覆盖不到这个隐性的问题。
你说这是监控没做全吗？也不是。
总不能提前给每个可能出问题的点都设个告警吧？那告警能多到把企业微信炸穿。
我们之前试过。
告警最多的时候，一天能收到两千多条告警，一半都是误报，最后大家直接把告警群设成免打扰，真出了大问题反而没人看见。
落地别贪大求全
后来我们改了思路。
别听那些厂商吹的什么全栈可观测性，上来就让你把所有系统、所有接口都接入探针，光接入就得搞三个月，等你搞完，业务都迭代了八版了。
我们就挑最核心的支付链路搞。
从用户点”提交订单”，到订单生成、风控校验、库存扣减、支付回调，这一整条链路拆成17个节点，每个节点的日志自动带上统一的traceID，指标和链路直接绑定，点开任意一个节点的告警，就能看到它上下游的调用情况、耗时、错误率，连日志都不用单独搜。
核心链路的可观测性覆盖率，比全系统的指标覆盖率重要100倍。
搞完这套东西，也就花了两周。
上次大促的时候，真出了个支付回调超时的问题，告警刚弹出来，开发点进去就看到是回调接口的一个时间戳字段格式错了，导致第三方支付的回调解析失败，从告警触发到修复，总共花了47秒。
张工那天的鸭油酥，终于不用凉着吃了。
还有个细节，我们没搞那种花里胡哨的大盘。
就给每个开发配了自己负责的链路的看板，不用翻几十块面板找自己的东西。
之前运维每次出问题要挨个看板翻，翻到最后都忘了自己在找啥。现在打开看板，直接就能看到自己负责的那一段的情况，省了超多事。
别让可观测性变成运维的单人活
最开始搞可观测性的时候，全是运维在扛。
开发根本不关心埋点对不对，日志写的啥。
之前有个开发写的错误日志，就一句”接口报错”，连个请求参数、错误码都没有，出了问题根本不知道是啥错，还要运维去找开发对代码，一来一回半小时过去了。
后来我们改了上线评审的规则。
新功能要上线，必须先把对应的链路埋点、日志规范、告警规则配好，才能过评审。日志里必须带traceID、请求参数、错误原因，埋点必须覆盖核心的调用节点，不然直接打回。
可观测性不是运维的专属工具，是每个开发写代码的时候就要刻进骨子里的习惯。
对吧？
你总不能写个漏了参数校验的代码，出了问题还要运维帮你擦屁股吧？
搞了三个月，现在开发出了问题，自己打开看板就能定位，不用再追着运维要数据，省了超多扯皮的时间。
上周我又去那家鸭血粉丝汤店，张工已经把鸭油酥换成了刚出炉的，屏幕上的告警也很少跳红了。
其实哪有什么玄学的技术概念啊。
不过是少点虚头巴脑的东西，多做点能解决实际问题的事而已。