3. 核心指标定义：黄金信号与 SLO/SLI/SLA 基础
在 On-Call 自动化故障排查体系中，指标是决策的“眼睛”。没有明确定义的指标，告警就是噪音，排查就是盲人摸象。本章将系统讲解 黄金信号（The Four Golden Signals）、自定义业务指标以及 SLO/SLI/SLA 的基础概念与落地方法，帮助你建立值班基线核验的量化标准。
3.1 黄金信号：系统健康的四大支柱
Google SRE 团队提出的“黄金信号”是衡量用户侧与系统侧健康度的核心维度。任何 On-Call 值班基线都必须覆盖这四个方面。
| 信号 | 定义 | 典型指标示例 | 故障排查价值 |
|---|---|---|---|
| 延迟（Latency） | 请求从发出到收到响应所消耗的时间 | P50/P95/P99 响应时间、平均延迟 | 识别性能瓶颈、慢查询、网络抖动 |
| 流量（Traffic） | 系统承载的请求量或数据吞吐量 | QPS、RPS、带宽使用率、并发连接数 | 判断是否遭遇流量突增、DDoS、容量不足 |
| 错误（Errors） | 请求失败的比率或数量 | HTTP 5xx 率、4xx 率、异常堆栈计数 | 直接定位功能故障、代码缺陷、依赖异常 |
| 饱和度（Saturation） | 系统资源被消耗的程度，接近极限的程度 | CPU 使用率、内存占用、磁盘 I/O 队列、连接池耗尽率 | 预警即将发生的性能退化或系统崩溃 |
值班基线核验要点： 在 On-Call 手册中，必须为每个黄金信号定义明确的“异常阈值”和“升级路径”。例如：P99 延迟 > 500ms 持续 5 分钟 → 触发 P2 告警；错误率 > 5% → 触发 P1 告警并自动拉起故障群。
3.2 自定义业务指标：从技术指标到业务价值
黄金信号解决的是“系统是否在正常工作”，而自定义业务指标回答的是“业务是否在正常运转”。On-Call 工程师不能只看 CPU，还要看订单量、支付成功率、用户登录率。
- 定义原则： 指标必须与用户可感知的体验或收入直接挂钩。
- 常见类别：
- 转化率类： 下单成功率、支付完成率、注册转化率。
- 核心流程类： 搜索响应率、视频播放成功率、消息投递率。
- 业务吞吐类： 每分钟订单数、每小时活跃用户数。
- 采集方式： 通过应用层埋点（SDK）、业务日志解析、数据库聚合查询。
实战案例： 某电商平台在“大促”期间，黄金信号显示 CPU 和延迟正常，但自定义指标“购物车加购成功率”从 99% 骤降至 60%。最终排查发现是 Redis 缓存热 key 导致库存扣减接口超时。如果没有自定义业务指标，该故障会被延迟 30 分钟才发现。
3.3 SLO / SLI / SLA 基础：量化可靠性的语言
这三个概念是 SRE 故障排查和值班基线核验的“度量衡”。没有它们，你无法判断当前故障是否“值得”被叫醒。
| 术语 | 全称 | 定义 | On-Call 场景作用 |
|---|---|---|---|
| SLI | Service Level Indicator | 服务水平的具体度量指标，如请求延迟、错误率 | 作为告警的原始数据源，直接计算是否达标 |
| SLO | Service Level Objective | SLI 的目标阈值，如“P99 延迟 < 200ms” | 定义告警触发边界，决定是否升级为故障 |
| SLA | Service Level Agreement | 对客户承诺的服务水平协议，通常包含赔偿条款 | 决定故障的严重等级和响应时效要求 |
常见误区： 不要把 SLA 直接当作告警阈值。SLA 通常是宽松的（如 99.9%），而 SLO 应该比 SLA 更严格（如 99.95%），留出“燃烧预算”空间，避免在 SLA 违约边缘才告警。
3.4 黄金信号与 SLO 的联动关系（SVG 架构图）
下图展示了从原始指标采集到 SLO 违约判断的完整链路，这是 On-Call 自动化故障排查的数据基础。
3.5 自定义业务指标与 SLO 的映射（SVG 架构图）
技术指标必须映射到业务指标，才能让 On-Call 工程师理解“这个告警对用户意味着什么”。
3.6 值班基线核验清单
在 On-Call 交接班或系统上线前，使用以下清单核验核心指标是否就绪：
- 黄金信号全覆盖： 每个服务是否都采集了延迟、流量、错误、饱和度四个维度的数据？
- SLI 定义明确： 每个 SLI 是否有明确的采集方式、聚合窗口（如 1 分钟、5 分钟）？
- SLO 阈值合理： SLO 是否比 SLA 严格 10%~20%？是否设置了燃烧预算告警？
- 业务指标映射： 核心业务流程（登录、下单、支付）是否都有对应的技术 SLI？
- 告警可执行： 当 SLO 被违反时，On-Call 手册是否明确说明了“先看哪个仪表盘、先查哪个日志”？
自动化核验脚本示例（伪代码）：
# 核验黄金信号覆盖率
for service in services:
if not (has_metric(service, "latency_p99") and
has_metric(service, "qps") and
has_metric(service, "error_rate") and
has_metric(service, "cpu_util")):
alert("服务 {} 缺少黄金信号指标".format(service))
# 核验 SLO 燃烧预算
for slo in slos:
burn_rate = calculate_burn_rate(slo)
if burn_rate > 0.1: # 每小时消耗超过 10%
trigger_p1_alert(slo.name, burn_rate)通过以上定义，On-Call 工程师不再需要猜测“系统是否正常”，而是基于明确的 黄金信号 → SLI → SLO → 告警 链路，快速定位故障根因并执行恢复操作。