4. Metric Design方法论

Google SRE 实践提炼出的四个黄金信号——延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）——是构建可观测性度量的基石。在 SLO 台账设计中，黄金信号并非简单的指标罗列，而是需要转化为可量化、可告警、可归因的度量基线。本章将逐一拆解每个信号在 SLO 设计中的具体映射方法。

4.1 黄金信号四象限模型

四个信号分别从不同维度描述系统健康状态，组合使用可以覆盖绝大多数故障场景。下表总结了每个信号在 SLO 设计中的核心关注点与典型度量方式：

4.2 延迟（Latency）——用户体验的标尺

延迟度量的是请求从发出到收到完整响应的时间。在 SLO 设计中，延迟不是平均值，而是高百分位值（P99、P95、P50）。平均值会掩盖长尾请求对用户体验的伤害。

• P99 延迟 SLO：99% 的请求在阈值内完成。例如“P99 ≤ 200ms”意味着每 100 个请求中最多 1 个超过 200ms。
• 分桶直方图：使用 Prometheus 直方图或 OpenTelemetry 直方图记录延迟分布，避免只存平均值。
• 客户端 vs 服务端：优先使用客户端感知的延迟（真实用户体验），服务端延迟仅作为辅助。

# Prometheus 延迟直方图示例（单位：秒）
http_request_duration_seconds_bucket{le="0.1"} 1024
http_request_duration_seconds_bucket{le="0.2"} 2048
http_request_duration_seconds_bucket{le="0.5"} 3072
http_request_duration_seconds_bucket{le="1.0"} 3584
http_request_duration_seconds_bucket{le="+Inf"} 4096
http_request_duration_seconds_count 4096
http_request_duration_seconds_sum 512.0

4.3 流量（Traffic）——系统负载的晴雨表

流量反映系统当前承受的请求压力。在 SLO 设计中，流量本身不是目标，而是用于容量规划和异常检测的上下文信号。

• QPS / RPS：每秒请求数，按服务、接口、地域等维度拆分。
• 吞吐量：每秒处理的数据量（如 MB/s），适用于流处理或存储系统。
• 并发连接数：适用于网关、数据库连接池等有连接上限的系统。

流量 SLO 通常不直接作为用户承诺，而是作为内部容量告警。例如：当 QPS 达到预估容量的 80% 时触发预警，预留扩容时间。

4.4 错误（Errors）——故障的直接体现

错误率是 SLO 中最直观的指标。但错误定义需要精细：

# 错误率计算示例（PromQL）
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
* 100

4.5 饱和度（Saturation）——容量危机的预警

饱和度衡量系统资源接近极限的程度。与延迟和错误不同，饱和度通常在故障发生前就给出信号，是预防性指标。

• CPU 饱和度：CPU 使用率 + 运行队列长度（Load Average）。
• 内存饱和度：内存使用率 + 交换分区使用量（Swap）。
• 磁盘饱和度：磁盘 I/O 等待时间 + 队列深度。
• 网络饱和度：带宽使用率 + 丢包率。
• 连接池饱和度：数据库连接池、线程池的使用率。

饱和度 SLO 的阈值通常低于 100%，预留缓冲空间。例如：CPU 饱和度 ≤ 75%，磁盘 I/O 等待 ≤ 10ms。

4.6 黄金信号联动分析

单个信号可能产生误判，四个信号联动才能准确判断故障根因。下图展示了黄金信号在典型故障场景中的联动关系：

4.7 黄金信号到 SLO 台账的映射流程

将黄金信号落地到 SLO 台账，建议遵循以下步骤：

1. 识别关键用户旅程：确定哪些请求路径对用户体验最重要（如登录、下单、搜索）。
2. 为每个旅程定义延迟和错误 SLO：基于用户期望和业务容忍度设定阈值。
3. 关联流量和饱和度指标：为每个服务设定容量上限，作为内部告警线。
4. 建立信号联动告警：单一信号触发不一定是故障，两个以上信号同时异常才升级。
5. 定期校准基线：随着系统演进，黄金信号的阈值需要重新评估。

4.8 黄金信号在 SLO 台账中的呈现

下图展示了黄金信号在 SLO 台账中的结构化呈现方式，每个信号独立记录但统一展示：

4.9 黄金信号设计避坑清单

• 不要只选一个信号：延迟正常不代表没有错误（如返回错误码但速度快），错误率低不代表系统不饱和。
• 不要忽略隐式错误：业务层错误（如“商品已下架”）在 HTTP 层面可能是 200，但用户感知为失败。
• 不要用平均值代替百分位：平均值会掩盖长尾延迟，P99 才能反映真实用户体验。
• 不要将饱和度阈值设得太高：CPU 100% 时系统已经严重排队，应提前在 70%-80% 告警。
• 不要忘记流量季节性：流量 SLO 基线应区分高峰/低谷时段，避免误告警。