上周去杭州找做电商的老周喝精酿。
他刚熬了三个大夜。
大促前压测的时候系统明明跑的好好的，流量一上来支付链路直接卡成PPT，监控面板上所有指标全绿，连CPU内存都飘着绿的对勾，愣是找了四个小时才发现是下游一个冷门的风控接口超时拖垮了整个线程池。
这种事，但凡搞过可观测性的人都遇见过。
监控和可观测性到底差在哪
说实话，我之前也踩过这个坑，刚入行的时候总觉得把Prometheus的告警阈值配好，ELK的日志收全，再整个链路追踪工具，就算搞定了可观测性。
直到有次线上故障，订单接口的耗时突然从200ms涨到了2s，监控面板上CPU、内存、数据库连接池全在正常阈值里，告警一条都没发，我们对着日志翻了俩小时，才发现是新上的一个优惠计算模块，碰到了某个特殊用户的优惠券组合，死循环算优惠，把整个接口的线程占满了。
那时候才反应过来，监控是告诉你”哪里坏了”，可观测性是让你知道”为什么坏了”。
监控的逻辑是你预先定义好哪些指标需要盯，超过阈值就告警，本质上是对已知问题的兜底。但线上的故障从来不会按你预设的阈值来，你不可能提前把所有可能出问题的场景都写成监控规则。
可观测性的核心，是让你能从任意一个异常的蛛丝马迹出发，顺着数据链路一直挖到根因，不管这个问题你之前有没有见过。
很多团队做可观测性第一步就错了
现在厂商的销售话术吹得太凶了，什么”全栈可观测””零代码埋点””一键覆盖所有链路”，听着就像买回去就能解决所有故障一样。
我见过最离谱的一个团队，花了几十万买了商业可观测方案，把前端每一次点击、每一个接口调用、甚至每一行代码的执行耗时全埋了点，日志全量往平台里塞，结果存储成本每个月翻了三倍，告警每天炸几百条，运维群里消息刷得比外卖群还快，真出故障的时候，反而要在几千条噪音告警里找有用的信息，折腾半天才找到根因。
老周之前就是这样。
他去年斥资二十万上的可观测平台，埋点埋到了每一个方法的入参出参，连用户在商品详情页滑了多少屏都记，结果大促当天支付链路超时，告警直接刷了三百多条，他盯着面板翻了十分钟，愣是没看到支付接口的异常率已经涨到了5%。
说白了，大部分团队从一开始就把可观测性当成了一个”要覆盖全所有系统”的项目，而不是一个用来提效排障的工具。
埋点不是越多越好，没用的数据越多，排障的时候反而越容易被干扰。
小团队做可观测性的务实路径
别信那些动辄要做半年的可观测性建设方案，尤其是十几个人的小团队，根本没那个精力折腾。
我给老周出的主意，就三步。
第一步，先把你业务里最容易出问题、出了问题影响最大的三个核心链路拎出来，比如电商的支付、下单、库存，别的链路先不管，哪怕它天天出小问题，只要不影响核心交易，先放着。
第二步，给这三个链路加埋点，只留有用的信息：全链路的traceid，请求的核心标识（比如订单号、用户id、下游接口的调用结果），接口的耗时和异常栈，别的什么入参出参全量、前端点击埋点，全删了。
第三步，告警别搞那些虚的，什么CPU超过80%告警、磁盘超过70%告警，先把核心链路的异常率、耗时P99的告警配上，比如支付接口的5xx比例超过1%、P99耗时超过1s就告警，比你盯一百个基础指标有用得多。
老周回去折腾了三天，把之前没用的埋点全清了，存储成本直接砍了三分之二，告警每天只剩不到十条。上周他做小范围压测的时候，支付接口突然超时，他顺着traceid点进去，十秒就查到是风控接口的超时配置写错了，把原来的1s超时改成了5s，直接改了配置就好。
他说现在终于不用熬大夜了。
没有银弹。
可观测性从来不是一劳永逸的采购项目，你不用一开始就追求覆盖所有系统，也不用跟大厂比谁的埋点全。你今天遇到了什么没见过的故障，就给对应的链路加一点相关的埋点，下次再遇到同类问题，就能直接顺着数据挖出来根因，慢慢迭代就行。