# 32 · 可观测性与可靠性技术栈选型

> 一句话点题:**可观测性(Observability)不是装一堆监控大屏,而是在系统出问题时,你能不能用证据回答:谁受影响、哪里变慢、为什么变慢、该不该叫醒人。可靠性技术栈选型,是在给线上系统装神经系统和免疫系统。**

---

> **🧰 技术栈选型篇第 6 章 · 本章只练一件事**
>
> [31 章](31-云原生与部署平台选型.md) 讲怎么部署。本章讲上线以后怎么知道系统是不是健康,以及不健康时怎么收场。不要从 Prometheus、Grafana、ELK、OpenTelemetry 这些名字开始,要从 SLO(服务等级目标)开始。

---

## 开场:监控和可观测性不是一回事

Monitoring(监控)回答的是:

> 我提前知道要看什么,现在它有没有越线?

例如 CPU 超过 90%、接口错误率超过 5%、队列积压超过 1 万。

Observability(可观测性)回答的是:

> 我不知道问题会从哪里冒出来,但系统留下的证据够不够我追下去?

例如某个用户下单慢,请求穿过网关、订单、库存、支付、第三方接口,到底卡在哪一跳?是某个租户、某个版本、某个可用区,还是某个数据库索引?

> **判断要点:**小系统靠监控也能活;分布式系统只靠监控会瞎。服务越多、调用链越长、版本越频繁,越需要可观测性,而不只是更多仪表盘。

---

## 一、从 SLO 倒推,别从工具倒推

可靠性技术栈的第一步是定义三件事:

```
   SLI(Service Level Indicator,服务等级指标)
      → 你测什么:成功率、P99 延迟、错误率、可用性?

   SLO(Service Level Objective,服务等级目标)
      → 你内部承诺做到多少:99.9% 请求 < 300ms?

   Error Budget(错误预算)
      → 允许失败的额度:预算没烧光,可以继续发版;烧光了,先修稳定性
```

这套语言的价值,是把「系统稳不稳」从感觉变成可讨论的数字。告警也应该从 SLO 倒推:

> 用户真的受影响了,才值得叫醒人。

CPU 高、内存高、线程多,都只是原因候选。如果它们没有影响用户旅程,就不该直接变成半夜电话。

---

## 二、三类证据:指标、日志、链路

可观测性常说三类信号:

| 信号 | 适合回答 | 代价 |
|---|---|---|
| **Metrics 指标** | 系统整体趋势:QPS、错误率、P95/P99 延迟、队列深度 | 便宜、适合告警,但细节少 |
| **Logs 日志** | 单个事件细节:订单为什么失败、鉴权为什么拒绝 | 细节多,但成本和噪音高 |
| **Traces 链路追踪** | 一个请求跨服务的完整路径和每跳耗时 | 对分布式定位很强,但采样和上下文传播要设计 |

OpenTelemetry / OTel(开放遥测标准与工具集)的价值在这里:它尽量把埋点和后端存储/查询解耦。你先用相对标准的方式生成遥测数据,以后后端从开源换到商业、从 A 厂商换到 B 厂商,迁移成本会小一些。

> **判断要点:**工具可以换,埋点习惯很难换。先把 trace id、结构化日志、关键业务指标这些「证据格式」打好,比先纠结大屏配色重要。

---

## 三、可靠性不止看见,还要收场

很多团队买了可观测性工具,可靠性却没有变好,原因是:

> 看见问题不等于能处理问题。

可靠性还需要响应链路:

```
   告警(Alerting)       → 只叫醒能行动的人
   值班(On-call)        → 明确谁负责响应
   Runbook(处置手册)    → 告警来了第一步做什么
   事故管理(Incident)   → 分级、沟通、升级、复盘
   发布治理             → 灰度、回滚、功能开关、熔断降级
```

所以第 32 章的选型不能只选「监控后端」,还要选**事故流程**。严肃系统至少要做到:告警可行动、服务有 owner(负责人)、关键告警有 runbook、事故后有复盘,复盘产出能回写到告警、代码或平台。

---

## 四、告警:少而准,别制造噪音

低质量告警长这样:

- CPU 高了。
- 内存高了。
- 磁盘用了 80%。
- 线程数变多了。

这些都是线索,不一定是事故。更好的告警围绕用户症状:

| 用户症状 | 可行动告警 |
|---|---|
| 登录失败 | 登录成功率低于 SLO |
| 下单慢 | 下单 P99 延迟连续 10 分钟超过目标 |
| 消息发不出去 | 队列积压导致通知延迟超过承诺 |
| 搜索不可用 | 搜索错误率和空结果率异常 |

> **架构智慧:**别告警「机器不舒服」,要告警「用户正在受伤」。否则你会养出一套噪音系统,最后大家对真正事故也麻木。

---

## 五、按成熟度选栈

| 阶段 | 倾向的栈 | 目标 |
|---|---|---|
| **MVP / 小团队** | 托管日志 + 错误追踪 + uptime 探测 + 少量核心指标 | 出事有人知道,能找到大概原因 |
| **标准线上系统** | 指标 + 结构化日志 + 关键链路追踪 + SLO 告警 + runbook | 用户受影响时能定位、能响应、能回滚 |
| **多服务 / 多团队** | OpenTelemetry + 指标/日志/链路统一关联 + 服务目录 + owner | 跨团队协作时不靠喊人破案 |
| **高可靠关键链路** | SLO 平台 + 金丝雀分析 + 合成监控 + 事故演练 | 提前发现退化,限制爆炸半径,缩短 MTTR(平均恢复时间) |

注意成本:日志全量保留、trace 全量采样、高基数标签(取值种类极多的标签)都会迅速烧钱。可观测性不是采得越多越好,而是**为关键问题留下足够证据**。

---

## 六、选型表

| 场景信号 | 更倾向的栈 | 选它的理由 | 警惕代价 |
|---|---|---|---|
| MVP / 内部工具 | 托管日志 + 错误追踪 + uptime 探测 | 快速闭环,出事能知道 | 不要一开始自建全套平台 |
| 标准 Web 应用 | 指标监控 + 结构化日志 + SLO 告警 | 能看错误率、延迟、核心业务是否受影响 | 告警规则要少而准 |
| 微服务 / 多团队 | OTel + Metrics/Logs/Traces 统一关联 | 跨服务定位问题,减少找人时间 | 埋点规范、采样、owner 维护都要治理 |
| 支付 / 交易 / 核心链路 | SLO + 错误预算 + 金丝雀发布 + runbook + 事故管理 | 把可靠性变成可度量、可响应、可复盘 | 成本高,需要值班纪律和组织承诺 |
| 数据量巨大 / 成本敏感 | 分层存储 + 采样 + 聚合指标 + 限制高基数标签 | 保留排障能力,控制账单 | 采样过度会丢关键证据 |

---

## 🎯 随堂检验

<Quiz
  question="一个系统半夜经常因为 CPU 90% 告警叫醒值班,但用户请求成功率和延迟都正常。按本章判断,更合理的改法是?"
  :options="['继续叫醒,CPU 高一定是事故', '把告警改成围绕用户影响的 SLO,CPU 高作为排查线索或低优先级告警;真正叫醒人的应该是成功率、延迟、错误预算等用户症状', '关闭所有监控']"
  :answer="1"
  explanation="告警应该围绕用户是否受影响。CPU 是原因候选,不是用户结果。直接用资源指标叫醒人容易制造噪音,最终让团队对真正事故麻木。"
/>

<Quiz
  question="一个微服务请求跨 6 个服务,偶发 P99 延迟很高。团队只有每个服务各自的日志,很难定位慢在哪。最该补的是?"
  :options="['再加 20 个业务大屏', '补齐链路追踪 traces,统一 trace id 上下文传播,让一次请求跨服务路径可见;同时保留关键指标和结构化日志做关联', '把所有日志打印成纯文本,越多越好']"
  :answer="1"
  explanation="跨服务慢请求最需要 traces 来看请求路径和每一跳耗时。指标告诉你「慢了」,日志告诉你「细节」,链路追踪告诉你「慢在哪条路径上」。"
/>

---

## 本章小结

- **可观测性不是大屏**:它是系统留下足够证据,让你能追问未知问题。
- **从 SLO 倒推技术栈**:先定义用户眼里的好,再决定指标、日志、链路和告警。
- **三类证据各有用处**:Metrics 看趋势和告警,Logs 看细节,Traces 看跨服务路径。
- **可靠性还需要响应流程**:告警、值班、runbook、事故分级、复盘、回滚,缺一块都会断。
- **按成熟度投入**:小团队先闭环,大系统再统一标准和平台化;采集不是越多越好,证据要够用且付得起。

> **承上启下**:通用系统需要看得见和救得回,AI 系统还多了模型、上下文、检索质量、成本和评测这些新变量。下一章 [33 · AI 基础设施技术栈选型](33-AI基础设施技术栈选型.md),我们把技术栈选型推进到 LLM 时代。

---

## 相关链接

- 方法论本体:[06 · 质量属性与取舍](06-质量属性与取舍.md) · [12 · 为失败而设计](12-为失败而设计.md) · [13 · 规模化的力学](13-规模化的力学.md)
- AI 协同:[24 · 审查清单](24-审查清单AI产出默认缺什么.md) · [25 · 评测驱动](25-评测驱动把够好写进架构.md)
- 案例对照:[StarArena](../cases/stararena-ticketing/README.md) · [SyncRoom](../cases/syncroom-collaboration/README.md) · [CodePilot](../cases/codepilot-agent/README.md)