指标与目标

本章定位：把「性能要好」这句空话，翻译成一张可测量、可判定通过/失败、可被他人复现的目标表。

前置知识：第 0 章（尤其是 0.3 延迟是分布） 预计总时长：约 2.5 小时（阅读 1.5 小时 + Lab 1 约 1 小时） 配套代码：docs/code/01-metrics-and-slo/

---

一、本章要回答的六个问题

1. 一个服务该监控哪些指标？为什么「只看 QPS 和延迟」一定会卡在排查半路？（第 1 节）
2. 为什么多台机器的 P99 不能求平均？工程上正确的做法是什么？（第 2 节）
3. 客户端看到 200 ms、服务端日志写 30 ms，哪个是真的？（第 3 节）
4. 「P99 < 200 ms」这句话为什么不能作为验收标准？（第 4 节）
5. 接口变慢了，怎么在不猜的情况下知道是哪一环变慢的？（第 5 节）
6. 怎么判断这台机器还能扛多少流量，而不是等它垮掉？（第 6 节）

---

二、为什么「定义目标」排在「学工具」之前

很多人的学习路径是：先学 k6 / Grafana / 火焰图，然后拿到一堆数字，最后发现不知道该拿这些数字跟什么比。

• 压出来 P99 = 180 ms —— 这是好还是坏？
• CPU 用了 65% —— 还能不能加流量？
• QPS 是 3200 —— 够不够用？

没有目标，这些数字都没有意义。 就像体检报告上写着「血红蛋白 145 g/L」——没有参考范围，你不知道该不该担心。

更现实的问题是：性能目标几乎从来不是技术问题，而是业务问题。 只有产品和业务方知道：

• 峰值到底是多少？（活动期间会不会翻 10 倍？）
• 用户能接受多慢？（超过多久会放弃？）
• 数据会涨到多大？（明年是现在的几倍？）

所以本章的另一半任务是：学会向业务方问出这几个数字，并把它们写成技术可执行的表格。

---

三、小节地图

节	标题	一句话内容	时长	要动手
1	指标分四层，缺一层就无法定位	业务 / 延迟 / 资源 / 饱和度，各回答一个不同的问题	20 min	✅ 埋点
2	百分位不可平均：直方图才是正解	多实例的 P99 求平均会错得离谱	25 min	✅ 实验
3	测量点：同一个请求，三个不同的数字	客户端 / 网关 / 应用内，混用必错	20 min	✅ 埋点
4	SLO 的四要素写法	指标 + 阈值 + 负载前提 + 测量点与时长	20 min	✅ 填表
5	延迟预算：把 200 ms 拆到每一跳	让「优化」变成「找出哪一跳超预算」，并指导超时设置	25 min	✅ 填表
6	基线与容量曲线：拐点才是容量	高速公路的相变：车流到某点后速度骤降	20 min	✅ 压测
7	实验元数据：没有它，数字等于没有	九项清单，缺一项就可能无法复现	15 min	✅ 脚本
8	案例解剖：P99 达标，用户仍然不满	四个常见原因与对应检查方法	20 min	—
9	Lab 1：写出你的第一份 SLO 与延迟预算	交付两张表 + 找出一个错误埋点	60 min	✅ 实验

建议节奏：第 1–3 节是「看懂指标」，第 4–5 节是「写出目标」，第 6–7 节是「让目标可验证」，第 8 节是「防坑」，第 9 节收口。

---

四、本章的产出物

1. 一份 SLO 表：至少 2 个接口，每个都含四要素。
2. 一份延迟预算表：为其中较复杂的接口拆分每一跳的预算（预期值先填，实测列留空，第 4 章搭好观测后回来补）。
3. 一个被修正的埋点：找出你现有代码里一处「只统计成功请求」或「测量点写错」的埋点，并说明它会导致什么错误结论。
4. 一条实验记录：按 docs/experiments/ 的格式记录本章的埋点实验。

---

五、学完本章的验收标准

• 能说出四层指标各回答什么问题，并说出「缺了饱和度层」会导致什么后果。
• 能解释为什么多实例 P99 不能平均，并说出工程上的正确做法。
• 能识别一个埋点属于哪个测量点，以及它能否和另一个测量点的数据做对比。
• 写出的 SLO 让别人能独立复现出同样的测试条件。
• 能用延迟预算表指出「接口变慢」是哪一跳的问题。
• 知道自己的服务当前容量是多少，以及这个数字是怎么测出来的。