可观测性的「军备竞赛」陷阱

「别人都在建全链路可观测平台，我们也不能落后」——抱着这种心态启动的可观测性项目，往往陷入军备竞赛：采集的数据量越来越大、存储成本越来越高、告警越来越多，但故障处理时间并没有缩短，工程师对监控平台的信任度反而下降。可观测性建设的正确起点不是工具选型，而是回答两个问题：给谁看？解决什么决策？

按角色分层的建设路径

• 第一层：面向运维的「系统健康」观测。解决「系统挂了没有、影响多大」：主机与容器资源、服务存活、基础设施告警。这是最基础的投入，工具成熟、见效直接，多数企业已具备。
• 第二层：面向研发的「应用诊断」观测。解决「为什么慢、错在哪」：链路追踪 + 日志关联 + 错误堆栈，让研发能独立定位问题而无需反复「让运维查日志」。这一层的价值可直接用 MTTR 缩短衡量。
• 第三层：面向业务的「体验与容量」观测。解决「用户体感如何、容量够不够」：核心业务链路的黄金指标（吞吐、延迟、错误率、饱和度）、用户体验采样与容量预测。这一层开始把技术指标与业务结果挂钩，是获得管理层持续投入的关键。

价值度量建议

可观测性投资的汇报不能只讲「采集了多少 TB 数据」，而要讲三个数字：平均故障恢复时间（MTTR）的变化、因提前预警避免的事故次数与损失金额、以及研发自助定位问题（无需跨团队协调）的比例。用业务语言汇报技术投入，是可观测性项目持续获得预算的通行证。