📚 课程目录第4章基线定义与标准化

4. 基线定义与标准化：如何定义服务健康基线、SLO/SLI与基线的关系

在值班自动化体系中，基线（Baseline）是判断服务是否“健康”的参照系。没有基线，告警阈值只能靠经验拍板，SLO 缺乏落地锚点。本章将系统讲解如何定义服务健康基线，并厘清基线、SLI、SLO 三者之间的标准化关系。

4.1 服务健康基线的三层定义

服务健康基线不是单一指标，而是从资源层、性能层、业务层三个维度构建的复合参照系。每一层对应不同的观测粒度和告警敏感度。

层级	典型指标	基线用途	更新频率
资源层	CPU 使用率、内存占用、磁盘 IO、网络带宽	基础设施容量规划与异常检测	每 5–15 分钟滚动
性能层	P99/P95/P50 延迟、错误率、吞吐量（RPS）	服务响应质量监控与 SLO 对齐	每 1–5 分钟滚动
业务层	订单成功率、支付转化率、用户登录耗时	业务健康度评估与告警降噪	每 5–10 分钟滚动

基线定义原则：基线必须基于历史数据（至少 14 天）的统计分布，而非单次采样。推荐使用 中位数 ± 3σ 或 百分位区间（P5–P95） 作为动态基线上下界。

4.2 SLI、SLO 与基线的映射关系

SLI（Service Level Indicator）是原始测量值，SLO（Service Level Objective）是目标承诺值，基线则是 SLI 的“正常波动区间”。三者关系可概括为：

SLI → 实时观测数据（如：过去 5 分钟 P99 延迟 = 320ms）
基线 → SLI 的历史正常范围（如：P99 延迟基线 = 200ms–400ms）
SLO → 对 SLI 的长期目标约束（如：月度 P99 延迟 ≤ 500ms 达成率 99.9%）

当 SLI 持续偏离基线但未突破 SLO 时，属于亚健康状态，应触发预警而非告警；当 SLI 突破 SLO 阈值时，才进入故障状态，需立即响应。

  关键公式：

  基线窗口 = 滑动时间窗（如 1 小时）内的 SLI 统计分布

  异常偏离 = |当前 SLI − 基线中位数| > 基线标准差 × 系数（通常 2–3）

  SLO 违反 = 当前 SLI 超出 SLO 阈值且持续超过燃烧率预算

4.3 基线标准化流程：从采集到校准

基线定义不是一次性工作，需要建立标准化生命周期。以下流程适用于 PagerDuty 集成场景：

数据采集：从 Prometheus、Datadog、CloudWatch 等源拉取 SLI 原始时间序列。
基线计算：使用滑动窗口（如 7 天/14 天）计算均值、标准差、百分位。
基线存储：将基线参数写入配置中心（如 Consul/Etcd）或监控系统 Annotation。
基线校验：每日自动比对当前 SLI 与基线，标记漂移幅度。
基线校准：当服务发布、架构变更或流量模式改变后，手动或自动触发基线重算。

常见陷阱：不要使用固定阈值（如 CPU > 80%）作为基线。固定阈值无法适应昼夜波动、促销流量、灰度发布等场景，会导致大量误告警或漏告警。基线必须随业务周期自动调整。

4.4 基线、SLO、告警阈值的协同关系图

下图展示了从 SLI 采集到告警触发的完整链路，以及基线在其中扮演的“动态参照系”角色：

4.5 基线标准化模板示例

以下是一个标准化的基线定义 YAML 模板，可直接用于 PagerDuty 事件规则或监控系统配置：

# baseline_definition.yaml
service: payment-gateway
version: "1.2"
baseline_window: 14d
refresh_interval: 5m

indicators:
  - name: p99_latency_ms
    type: performance
    unit: ms
    baseline:
      method: percentile
      p50: 180
      p95: 350
      p99: 480
      std_dev: 45
    slo:
      target: 500
      compliance: 99.9
      window: 30d
    alert:
      warning: baseline_median + 2 * std_dev   # 570ms
      critical: slo_target                      # 500ms

  - name: error_rate_percent
    type: performance
    unit: "%"
    baseline:
      method: mean_std
      mean: 0.12
      std_dev: 0.08
    slo:
      target: 0.5
      compliance: 99.99
      window: 30d
    alert:
      warning: baseline_mean + 3 * std_dev      # 0.36%
      critical: slo_target                      # 0.5%

自动化建议：将基线定义模板纳入 Git 仓库，通过 CI/CD 流水线自动部署到监控系统和 PagerDuty 事件规则。每次基线更新后，自动触发一次“基线核验”演练，确保告警阈值与最新基线一致。

4.6 基线漂移与持续校准

基线不是静态的。服务发布、基础设施扩缩容、用户行为变化都会导致基线漂移。标准化基线管理需要包含以下校准机制：

触发条件	校准动作	影响范围	自动化程度
服务版本发布	重算基线，对比发布前后差异	性能层、业务层	半自动（需人工确认）
流量模式突变（如促销）	启用临时基线窗口（24h）	资源层、性能层	全自动
持续偏离超过 7 天	自动更新基线为新常态	所有层级	全自动（带回滚）
SLO 违反率上升	触发基线审核，检查阈值是否过松	性能层、业务层	半自动（生成报告）

通过将基线标准化为可版本化、可审计的配置，值班团队能够快速定位“是服务变慢了，还是基线过期了”，从而减少故障排查中的认知负载。