去年双11前我去杭州找老同事蹭饭，他们团队做自营电商的，正卡在大促前的最后一轮压测上。
接口突然崩了。
三个小时，运维翻了几万行日志，开发把每个服务的代码都过了一遍，最后才发现是新上的库存服务连接池参数没配，把数据库的可用连接全占满了。
他们有监控的。Grafana大盘上CPU、内存、磁盘曲线飘的整整齐齐，ELK集群存了半个月的日志，甚至还买了商用的链路追踪服务。
没用。
你以为的监控和真的可观测性根本不是一回事
很多人对可观测性的认知，还停留在“把系统的运行数据都采集上来”的阶段。但可观测性的核心是你能在不提前写代码埋点的前提下，回答系统出现的未知问题。
就像刚才那个电商团队，他们的监控只能回答“数据库当前连接数是不是满了”这种已经提前想过的问题。但当连接数真的满了的时候，他们没法立刻回答“是哪个服务、哪个请求占了这些连接”——所有的数据都是割裂的，指标归指标，日志归日志，链路归链路，没有关联。
说真的，我见过太多团队踩这个坑。
他们花几十万买了所谓的一体化可观测平台，把所有的指标、日志、链路数据都堆在一个大盘上，看起来花团锦簇，真到出问题的时候，还是要运维拿着命令行挨个机器翻日志，找半天定位不到根因。
白花钱。
别上来就买工具先理清楚你要回答什么问题
之前接触过一个做生鲜配送的团队，刚上可观测性的时候走了大弯路。
什么数据都采。
光业务指标每天就存几十T，查询慢的要死，打开一个大盘要等半分钟，最后没人愿意用，成了摆设。后来他们干脆把平台停了，拉着开发、运维、仓管、配送的人开了一下午会，就聊一个事：过去三个月，线上出的最头疼的三个问题是什么？
列出来的三个问题特别具体：第一，配送员端提交订单经常超时，不知道是网关卡了还是配送服务出问题；第二，库存扣减有时候对不上，不知道是并发冲突还是消息丢了；第三，用户付完款没收到确认短信，不知道是短信服务挂了还是MQ消息没发出去。
他们就针对这三个问题，调整了埋点逻辑，把每个环节的耗时、错误率、关联日志全部绑定到同一个请求链路上。最后问题定位时间从原来的40分钟，降到了5分钟。
没有业务上下文的可观测数据，本质上就是占存储的垃圾。
当然不是说那些商业化的可观测平台不好，只是你得先想清楚你要解决什么问题，再去匹配工具，而不是反过来。
落地可观测性最容易被忽略的团队协作问题
我见过至少一半的团队，推可观测性推不下去，根本不是工具的问题，是人的问题。
最常见的场景就是，SRE团队写了厚厚的一本埋点规范，扔给开发团队，要求大家按规范埋点，不埋就扣绩效。结果呢？开发本来就要赶业务需求，哪有空仔细研究规范？埋的点要么漏了，要么参数错了，链路断的七零八落，最后平台上的数据根本不能用。
别搞道德绑架。
后来那个生鲜团队换了个思路。他们把埋点SDK做的尽量无感——只要用团队封装好的HTTP客户端和数据库驱动，自动就会把trace id透传下去，不用开发写一行额外的代码。甚至连日志里的trace id，都用日志框架的拦截器自动加上。
这下大家都愿意用了。
谁也不想出了问题还要背锅对吧？之前开发要花两个小时复现线上问题，现在只要在平台上搜对应的trace id，请求经过的每个接口的参数、堆栈、耗时全在，五分钟就能定位是自己写的哪段代码出了问题。可观测性做好了，是给开发减负的，不是加活。
上周和那个电商的朋友吃饭，他们现在大促压测，只要链路里哪个环节的错误率超过0.1%，直接能跳出来是哪个服务的哪个实例出的问题，再也不用全员熬夜翻日志了。
挺好。
本来技术就是用来给人省事的，对吧？