# 17. 可观测性

如何设计 logs、metrics、traces、correlation ids 与 alerts，让团队在事故发生时真正能理解系统。

- **Author:** Fedor Chishchin
- **Level:** advanced
- **Reading time:** 约 25 分钟阅读
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/zh/learn/software-architect-17-observability

---

## 1. 核心思想

Observability 要和系统一起设计——不是等第一次大事故之后再补上。

### 三种信号解决不同的问题

> 温度计、地图和行车记录仪分别展示一次旅行的不同侧面。只靠一种仪器是不够的。

Metrics 展示聚合状态：latency、error rate、queue depth、memory、throughput。Logs 提供事件与上下文。Traces 显示一个请求穿过多个服务的路径。

架构师必须决定哪些 signals 对关键 user journeys 是必要的。对于 checkout：payment latency、failed authorizations、retry count、outbox lag、provider errors。对于内容站点：cache hit ratio、build failures、p95 page load、search freshness。

### Alert 必须能驱动行动

> 每小时无缘无故响一次的报警器，很快就会被当成背景噪音。

糟糕的 alerts 会制造 fatigue。好的 alert 与用户影响绑定，或者与某条危险阈值的临近绑定。它有 owner、severity、runbook 和清晰的行动。

不是所有事都需要半夜把人叫醒。对 SLO 无影响的 error logs 可以进 dashboard 或 ticket。但成功支付率下跌应该立刻 page on-call。

## 2. 例子与反例

事故中的 observability 应该缩短理解时间——而不是添加噪音。

### 例子：贯穿整个 request path 的 correlation id

> 法院的案号可以串起所有文件、证人和裁定。没有案号，一切只能靠记忆翻找。

每个入站请求都获得一个 correlation id。它穿过 API、worker、broker messages 和 downstream calls。Logs 和 traces 都带着它。Support 从用户的错误中拿到 id，工程师立刻就能看到完整的请求路径。

这能大幅压缩 MTTR：团队不再搜索"大约 14:03 那会儿发生了点什么"，而是直接看一条具体的事件链。

### 反例：把 logs 当成一行行文字流

> 一本没有章节、没有页码、没有目录的书，里面有信息，却几乎无法使用。

服务写下 `something failed`、`bad request`、`payment error`，却没有 user id、tenant id、order id、provider code、retry count 或 severity。Incident review 时团队意识到数据是有的——但根本没法用来还原现场。

带上下文的结构化 logs，胜过漂亮的字符串。

#### 自检

- Metrics 里能看到哪些 SLO？- 能否在所有服务中追踪同一个请求？- 哪些 alerts 要求立刻行动？- Logs 需要哪些字段才能支撑调查？

下一模块：[文档](./software-architect-18-documentation)。