把「可观测性」从口号变成习惯：一个云上系统的三段演进

引言

很多团队上云之后，第一件事是把业务迁上去，第二件事是发现——系统一旦出问题，排查起来比自建机房还难。原因往往不是云不好用，而是「可观测性」被当成了上线后再补的功课。本文不从某个具体产品讲起，而是分享一个云上系统在可观测性上通常会经历的三个阶段，以及每个阶段真正该补上的那块短板。

第一阶段：能用日志定位，就算及格

最初的系统通常只有日志。请求进来了、数据库慢了、任务失败了，全靠 grep 去翻。

这个阶段的关键不是上多复杂的平台，而是把日志结构化：

• 每条日志带上请求 ID、用户维度、耗时、结果状态；
• 统一时间戳与时区；
• 错误日志和业务日志分开采集。

做到这三点，就已经能回答 80% 的「刚才发生了什么」。云上的日志服务天然支持采集、检索、按关键字告警，把散落在各台机器上的日志汇聚到一处，是投入产出比最高的一步。

第二阶段：有了指标，才知道「慢在哪」

日志回答「发生了什么」，但回答不了「整体健康度如何」。这时候要引入指标：

• 黄金四指标：延迟、流量、错误率、饱和度；
• 资源层指标（CPU、内存、连接数、磁盘 IO）与应用层指标（QPS、P99、队列积压）分开看；
• 设定有意义的告警阈值，而不是把所有指标都配上告警——告警疲劳比没有告警更危险。

这个阶段最容易犯的错，是把仪表盘做得花里胡哨却没人看。真正有用的仪表盘，应该让值班的人在三秒内判断「现在是不是故障、故障在哪一层」。

第三阶段：用链路追踪串起「一次请求的一生」

当系统拆成多个服务后，只看单个服务的指标已经不够了。一次用户请求可能穿过网关、鉴权、业务服务、缓存、数据库，任何一环抖动都会体现为用户侧的延迟。

分布式链路追踪的价值在于：

• 把一个请求经过的所有调用画成一条时间线；
• 快速定位「慢」是出在自身逻辑、下游依赖，还是数据库；
• 配合采样策略，在高并发下也能保持可用的成本。

到这一步，日志、指标、追踪三者才算真正闭环：指标告诉你「有问题」，追踪告诉你「问题在哪」，日志告诉你「为什么」。

写在最后

可观测性不是买一个平台就有的能力，而是一种工程习惯：在写代码时就想好它出问题后该怎么被看见。 从结构化日志开始，到有意义的指标，再到关键链路的追踪，这三步不需要一次做完，但方向对了，系统的「可解释性」会随着时间不断变好。云平台提供了工具，而把工具用成习惯，才是团队真正的护城河。