压测跑了30分钟，支付接口突然从平均200ms飙到3s。
没人知道为啥。
监控面板上所有服务的CPU、内存、JVM线程池都绿得晃眼，告警规则一条没触发，运维同学盯着满屏的折线图翻了40分钟日志，最后才发现是新上线的优惠券服务里加了个没做缓存的数据库查询，刚好卡在了支付链路的下游。
当时那个团队其实已经花了十几万买了商业APM工具，说起来也算是早就在做“可观测性建设”的先行者。
别把可观测性当成监控的付费升级
说真的，这种状态跟开车只看时速表有啥区别？
仪表盘没报警。
不代表车没出问题。
你看不到发动机舱里的皮带在慢慢磨断，等抛锚在半路上的时候，再慌慌张张翻说明书找故障点，浪费的全是业务真金白银的损失。
很多团队对可观测性的理解，还停留在“把原来的监控系统升级个版本，多接几个数据源，做几个更炫酷的可视化大屏”的层面。说白了还是盯着提前知道要监控的指标做阈值告警，根本没意识到，线上的大部分故障，从来都不会按照你预设的告警规则来发生。
我见过太多被厂商销售忽悠的团队，听了两场发布会就掏了几十万预算，上了号称“全栈可观测”的平台，结果用了三个月，除了在季度汇报的时候能放个动态大屏撑场面，真碰到问题的时候，还是得切三个系统来回查，跟之前没做升级的时候没有本质区别。
真正的可观测性是能回答没预设的问题
传统监控的逻辑很简单：你提前知道要监控什么，就把对应的指标采回来，设好阈值，出问题了就报警。但可观测性的逻辑完全反过来——它要能帮你回答那些你之前根本没预设到的问题。
就像那次支付接口时延飙高的事，如果你提前预设到“优惠券服务的某个SQL会慢”，你早就给这个查询加监控了。但真实的线上场景里，你根本不可能提前把所有可能出问题的点都列全。这时候可观测性的价值就出来了：当你碰到一个从来没见过的问题时，不用临时加监控、不用重启服务、不用登服务器逐台翻日志，就能从已经收集到的全量数据里，顺着线索直接定位到根因。
很多人说指标、日志、链路是可观测性的三支柱，但我觉得核心根本不是这三个东西凑齐了就行——是这三个东西之间必须是打通的、可关联的。
我见过太多团队，指标存Prometheus，日志存ELK，链路存Jaeger，三个系统各玩各的，数据之间连个统一的关联ID都对不上，碰到问题的时候运维要在三个浏览器标签页之间来回切，手动拼数据找关联，比纯靠日志翻还累。
这也叫可观测性？
纯纯形式主义。
落地别贪大，先从最痛的故障点切入
很多团队一开始做可观测性建设就贪大求全，想把所有微服务的全量数据都接进来，存几个PB的时序数据，光存储成本就扛不住，最后项目不了了之，连个水花都没打出来。
其实根本没必要。
当时那个电商团队后来的调整根本没搞什么大动作：他们先把过去半年线上报过的故障全部拉出来，列了个清单，发现80%的故障都集中在下单、支付、优惠券这三个核心链路上。然后就先给这三个链路做了全链路的TraceID打通，所有的日志、指标都带上同一个TraceID，碰到问题的时候顺着TraceID一搜，链路拓扑、对应时段的指标波动、相关的错误日志全出来了。
就这么个小调整，后来双11当天的故障平均定位时间从之前的40分钟降到了3分钟。当时运维组长跟我吐槽，之前每次出故障都要在群里@各个服务的负责人，现在自己点两下鼠标就找到问题了，群里的@消息少了80%，连带着跨团队吵架的次数都少了。
哦对，还有个很多人容易忽略的点：可观测性从来不是运维团队单独的事。研发在写代码的时候，如果能把关键的业务事件——比如用户领了优惠券、优惠券核销失败、权限校验不通过——当成结构化的可观测数据打出来，比光盯着服务的CPU、内存指标有用得多。之前碰到个做企业SaaS的团队，之前定位租户权限的问题要花2个小时，后来研发在权限校验的关键节点打了结构化日志，带上租户ID、权限校验结果、关联的资源ID，现在碰到租户反馈用不了功能，直接搜租户ID，5分钟就能定位是权限配置错了还是接口逻辑有问题。
其实根本没必要贪大，先从过去半年最痛的故障场景切入，把核心链路的关联数据打透，比什么全量接入的宏大叙事有用得多。
上周跟那个电商团队的运维负责人吃饭，他说现在再也不担心大促的时候半夜被告警电话炸醒了。
其实哪有什么神奇的技术魔法。
不过是把之前散落在各个系统里的碎片信息，拼成了能看到问题全貌的地图而已。
能省时间。
能少熬夜。
能少背锅。