Software Architect · 模块 17
Observability 回答的是一个问题：在不部署新代码、不从间接现象中猜测的情况下，我们能否理解系统正在做什么。
Logs · metrics · traces · correlation id · alerting
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。
事故中的 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 需要哪些字段才能支撑调查？