从标 CPU 到设计 SLO：一个 SRE 对监控的重新理解
这篇想说什么
我真正开始懂 SLO，不是因为读了 Google SRE 那本书，而是因为换了个位置——从 Intel 的 demo，到 DataVisor 的 production。
这篇记录这个转变里最核心的一件事：监控不是把指标标出来，而是从"谁在关心什么"往下设计。 这也是我判断自己从 junior SRE 迈向 senior 的那条线。
一、SLO 是什么时候变"真"的
在 demo 环境里，SLO 是个概念。系统挂了，重启就好，没人真的因此损失什么。所谓"可用性 99.9%"是 PPT 上的数字，感性上是空的。
到了 production，背后站着一个真实的客户。这时候才明白：
- SLA 是一个承诺，是你对客户签字画押的那条线。
- 它是系统稳定性的具象化——抽象的"稳定"被翻译成"月度可用性 ≥ 99.9%，否则赔偿"。
- infra 被推到了前台。以前它躲在业务后面，现在它的抖动直接变成客户的损失、客户的电话、客户的流失。
对"客户"有责任、有承诺——这件事一旦成立，SLO 就不再是术语，而是一种压力。我对 SLO 的所有真正理解，都是从这个压力里长出来的。
二、junior 的错误：把指标横着切
我曾经这样理解监控：分两类，system metrics（CPU、内存、磁盘、网络）和 application metrics（QPS、错误率、延迟）。把它们都采下来，标到 dashboard 上，监控就算做完了。
现在看，这个划分错在它是一个水平切分。它按"指标长在系统的哪一层"来分类，而不是按"谁需要它、用它回答什么问题"来分类。结果就是：
- dashboard 上摆满了 CPU 曲线，但没人能从一屏里看出"客户现在有没有在受影响"。
- 一堆指标都"绿"，客户却在投诉——因为绿的是主机，痛的是请求。
- 出事时，dashboard 帮不上忙，因为它不是为回答问题建的，是为"把能采的都采上"建的。
横切的监控，本质是仪表堆砌，不是监控设计。
三、senior 的转向：从上往下做
真正的做法是 top-down，从最上层、从 user 的视角往下推。
核心是一句话：不同的"主体"关心不同的"指标"。
- 客户 / 业务：我的请求成功吗？够快吗？数据当天到了吗？——这是 SLA/SLO 层。
- 服务 owner：哪个接口在烧 error budget？哪个依赖在拖后腿？——这是服务黄金信号层。
- on-call / 值班：现在哪里坏了、坏在哪一层、怎么止血？——这是排障链路层。
- 平台 / 容量：资源够不够撑到下个季度？——这才轮到 CPU、内存这些系统指标登场。
CPU 不是不重要，而是它属于最下面那个主体。把它摆到最上层给客户看，是层级错位。
由此推出三条：
- 每个主体的 SLO 不同。 客户的 SLO 是可用性和延迟；容量团队的"目标"是利用率和余量。别用一套指标假装服务所有人。
- 每个主体的 dashboard 不同。 一块面板服务一个主体、回答一类问题。给客户看的面板上不该有 CPU；给 on-call 看的面板不该只有一条总可用率。
- dashboard 的存在意义是回答问题，不是展示数据。建之前先问：这块板要回答谁的什么问题？答不上来的曲线，就是噪声。
四、这条成长线
把这两种状态并排放，转变就很清楚了：
| junior 的我 | senior 的我 | |
|---|---|---|
| 监控是什么 | 把能采的指标标出来 | 从主体和问题往下设计 |
| 怎么分类 | 横切：system vs app | 纵切：谁关心、答什么问题 |
| SLO | PPT 上的数字 | 对客户的承诺，有压力 |
| dashboard | 数据展示墙 | 为特定主体回答特定问题 |
| CPU 的位置 | 最显眼的第一屏 | 容量主体的下层指标 |
我不再把"标出 CPU"当作监控。监控是先想清楚谁在看、他要回答什么，再决定标什么、怎么标、给谁看。
这个顺序反过来的那一刻，我知道我对 SLO、对监控设计的理解，终于从 junior 迈过了那条线。
延伸：SLI 的完整维度（availability / latency 之外的 correctness / freshness / coverage / durability / consistency）以及一个 Feature Platform 的 SLA/SLI/SLO/Error Budget 完整推演，见我的工作笔记。核心是同一套方法：先问服务是哪一类、谁在关心，再挑指标。