WEBKT

构建可观测性平台时，如何用数学定义系统的"正常"状态？

5 0 0 0

问题的本质：为什么我们需要重新定义"稳态"？

在传统监控体系中，工程师习惯于设置静态阈值：CPU > 80% 报警、Latency > 500ms 报警。这种模式在单体架构时代勉强可用，但在微服务与云原生环境下会导致报警疲劳——系统正常波动时被频繁打扰，真正异常时又被淹没在噪音中。

稳态（Steady State）的量化，本质上是解决"什么是可接受的异常"这一问题。它不是一条红线，而是一个动态置信区间。

稳态的三层模型

构建可观测性平台时，建议将稳态定义为三个递进的数学表达：

1. 业务层：SLO 驱动的误差预算

参考 Google SRE 体系，稳态首先表现为**服务等级目标（SLO）**的达成。关键不是"零故障"，而是"可接受的故障率"。

# 稳态定义示例：支付接口的可用性稳态
SLI: 支付成功率
SLO: 99.9% (30天滚动窗口)
Error Budget: 0.1% = 43.2分钟/月
Burn Rate: 1 (正常消耗), 2 (加速消耗), 6 (紧急)

工程实践：使用 Prometheus 的 histogram_quantile 计算分位延迟，结合 increase() 函数跟踪误差预算消耗速率。

# 计算过去1小时内的错误预算消耗比例
(
  sum(rate(http_requests_total{status=~"5.."}[1h]))
  /
  sum(rate(http_requests_total[1h]))
) 
/ 
(1 - 0.999)  # 对比 99.9% SLO

2. 系统层：动态基线（Dynamic Baseline）

静态阈值无法适应业务的周期性波动（如电商的大促、SaaS 的工作时段）。稳态应基于历史同期数据的统计分布。

算法选择：

算法 适用场景 计算复杂度 敏感度
3-Sigma 原则 正态分布指标（CPU、内存） 低 中
Z-Score 标准化 有季节性波动的指标（QPS） 中 高
STL 分解（季节-趋势分解） 强周期性业务指标 高 极高

实现方案：
利用 Prometheus 的 Recording Rules 预计算历史基线：

# 记录过去7天同一时刻的平均值与标准差
- record: request_latency:moving_avg_7d
  expr: avg_over_time(request_latency[1h] offset 7d)
  
- record: request_latency:moving_stddev_7d  
  expr: stddev_over_time(request_latency[1h] offset 7d)

# 异常检测：当前值超出 3 个标准差
- alert: LatencyAnomaly
  expr: |
    (
      request_latency - request_latency:moving_avg_7d
    ) 
    / 
    request_latency:moving_stddev_7d > 3

3. 资源层：饱和度的非线性建模

Google 提出的"四大黄金信号"中，**饱和度（Saturation）**最难量化。资源使用率的稳态不是线性的——80% 的 CPU 可能在空闲队列充足时完全正常，也可能在上下文切换过高时即将崩溃。

进阶指标设计：

  • 负载因子：load1 / cpu_cores 与 CPU 使用率的相关性
  • 队列延迟：rate(scheduler_wait_seconds_total[1m])
  • 资源争抢指标：cgroup 的 throttled_time、JVM 的 GC 暂停时间

当 CPU使用率 < 70% 但 调度延迟 > 10ms 时，系统已处于亚稳态，需要触发预警而非报警。

工程落地：构建稳态感知流水线

阶段一：指标治理（Telemetry）

避免"指标爆炸"，只采集能描述稳态的关键信号：

  1. USE 方法（利用率、饱和度、错误率）针对资源层
  2. RED 方法（速率、错误、持续时间）针对服务层
  3. 自定义业务指标：如订单创建漏斗的转化率（稳态通常是 23%-25%，而非固定值）

阶段二：特征工程

原始指标需转换为稳态特征向量：

  • 趋势成分：使用 deriv() 计算变化率，稳态要求趋势接近零
  • 波动成分：变异系数 stddev / mean，稳态系统通常 < 0.1
  • 相关性：跨服务指标的相关矩阵，稳态下强相关性应保持稳定

阶段三：异常检测引擎

推荐采用多级检测策略减少误报：

# 伪代码：稳态检测逻辑
def is_steady_state(current_metrics):
    # L1: 硬阈值（绝对异常）
    if current_metrics.error_rate > 0.1:  # 10% 错误率绝对异常
        return False, "CRITICAL"
    
    # L2: 统计异常（3-Sigma）
    if abs(z_score(current_metrics.latency)) > 3:
        return False, "WARNING"
    
    # L3: 趋势异常（漂移检测）
    if trend_slope(current_metrics.qps, window="1h") > 2.0:
        return False, "TRENDING"
    
    return True, "HEALTHY"

阶段四：反馈闭环

稳态定义不是一次性的。平台应提供**事后分析（Post-mortem）**能力：

  • 变更关联：将发布事件与稳态偏离时间点对齐（使用 timestamp() 函数）
  • 基准对比：A/B 测试期间，对比实验组与对照组的稳态参数分布
  • 自适应调整：每月根据业务增长自动调整 SLO 基线（避免长期 100% 达成导致的阈值僵化）

常见陷阱与避坑指南

  1. 维度灾难：在 Kubernetes 环境中，避免对 pod_name 做高基数分组查询，这会破坏稳态计算的实时性。使用聚合标签如 deployment。

  2. 时间窗口错位：业务稳态（日级）与系统稳态（分钟级）的观测窗口不一致，应在不同仪表板呈现，避免混淆。

  3. 忽视长尾延迟：均值（mean）往往掩盖问题，稳态应关注 P99 甚至 P99.9 的波动范围。

  4. 过度拟合历史：疫情期间的流量模式可能与平时完全不同，稳态模型需要异常值剔除机制（如使用 median 替代 mean 计算基线）。

总结：从"监控"到"可观测性"的思维跃迁

量化稳态的核心，是将运维从**"被动响应报警"转变为"主动验证假设"**。当平台能够清晰回答"系统现在处于稳态的哪个置信区间"时，你才真正拥有了可观测性。

建议从单一核心服务（如订单服务）的 SLO 定义开始，逐步建立动态基线，最终形成覆盖全链路的稳态拓扑图。记住：完美的稳态不是一成不变，而是可预期的波动范围。

云途架构师 可观测性SRE

评论点评