四大黄金信号 · 以及三套方法论的关系

一眼就能看出来：黄金信号 ≈ RED + 饱和度。

所以三套方法论的关系是：

• RED 从服务/请求视角出发，给出三个信号。
• USE 从资源视角出发，给出三个信号。
• 黄金信号从面向用户的整体系统视角出发，把 RED 的三个 + USE 里最重要的那个（饱和度）合在一起。

它们不矛盾，是同一片领土的三张地图。 实践中你不需要“三选一”，而是：对服务用 RED、对资源用 USE，而黄金信号提醒你：别忘了饱和度也是面向用户的一等信号。

因为饱和度是唯一有预测性的信号。 其他三个都是滞后的：

• Latency 涨了 → 已经慢了，用户已经在受苦。
• Errors 涨了 → 已经错了，用户已经看到 500 了。
• Traffic 变了 → 那是外部输入，不是你的健康。

只有饱和度是“提前量”：线程池用了 80%、磁盘还剩 20%、连接池快满了——这些时候用户还什么都没感觉到，但你知道再涨一点就要出事。

这就是“叫醒你”和“叫醒你时已经晚了”的区别。 基于 Latency/Errors 的告警本质上是事后通知（SLO 已经在燃烧了）；基于饱和度的告警是事前预警，你还有时间扩容。

《SRE Book》强调饱和度要看“趋势和预测”，而不只是当前值：

# 不只问"磁盘满了吗",要问"按这个速度,多久会满"
# predict_linear:基于过去 6 小时趋势,预测 4 小时后的值
predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*3600) < 0

这条查询的意思是：“按当前增长速度，4 小时内磁盘会满”——它在磁盘还有 30% 空间时就告警，给你充足的处理时间。这比“磁盘使用率 > 90%”这种静态阈值高明得多：后者在小盘上太晚（90% 时可能只剩几分钟），在大盘上太早（90% 的 10TB 盘还剩 1TB，能撑一周）。第 5 部分讲阈值时会展开这个思路。

失败请求的延迟会污染你的延迟指标——必须把成功和失败分开统计。

两种污染方向，都很致命：

• 失败得快 —— 服务过载时快速返回 503（fail fast），这些请求耗时极短。它们混进整体延迟里，会把 P99 拉低——于是系统越是在崩溃，延迟指标看起来越健康。这是个极其危险的假象：告警不响，但用户全在看错误页。
• 失败得慢 —— 超时的请求耗时 = 超时时间（比如 30s）。它们会把 P99 拉高到超时值附近，掩盖了成功请求的真实延迟变化。

正确做法：延迟按 status 分开看。

# ✅ 只看成功请求的 P99(这才是"用户成功时等了多久")
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket{status=~"2.."}[5m])) by (le)
)

# 失败请求的延迟单独看(它有自己的意义:失败得快还是慢?)
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket{status=~"5.."}[5m])) by (le)
)

记住这个组合：成功率（E）+ 成功请求的延迟（D）。 这两个一起才完整描述了“用户体验”：有多少人成功了，以及成功的人等了多久。混在一起的 P99 是个会骗人的数。

这张看板的关键是分层**，而不是把 50 个图平铺在一页。**

• 第一层（4 个图） —— 回答“现在用户体验好吗”。平时只看这一层。 全绿就可以关掉页面去干活。
• 第二层 —— 第一层红了才看：“是哪一跳的问题”（本服务还是下游）。
• 第三层 —— 定位到某一跳后才看：“是哪个资源”（USE）。

这个分层结构直接对应上一章的排障算法：症状 → 哪一跳 → 哪个资源。看板的结构应该长得像排障的思路，而不是像“我们能采到的指标列表”。

一个检验标准：如果值班的人被叫醒后，能顺着看板从上往下在 5 分钟内定位到根因，这个看板就是好的；如果他还是得去 tail 日志或者问人，那这个看板就是装饰品。