2. 误差预算台账设计

误差预算台账是告警降噪与阈值联动的“会计账簿”。没有台账，SRE 团队就无法回答“我们还有多少故障余量”“当前消耗速度是否危险”等核心问题。本章从数据结构与存储选型两个维度，构建可落地的误差预算台账体系。

2.1 台账数据结构设计

误差预算台账的核心是时间窗口、预算总量、已消耗量、剩余量四要素。设计时需区分滚动窗口与固定窗口两种模式，并定义消耗计算规则。

2.1.1 时间窗口模型

2.1.2 台账字段定义

每条误差预算记录应包含以下核心字段：

{
  "service_name":    "payment-api",          // 服务标识
  "slo_name":        "latency_p99_500ms",    // SLO 名称
  "window_type":     "rolling",              // 窗口类型
  "window_seconds":  2419200,                // 28 天 = 2419200 秒
  "budget_total":    0.999,                  // 预算总量（99.9%）
  "good_events":     8640000,                // 好事件数
  "total_events":    8648640,                // 总事件数
  "budget_consumed": 0.001,                  // 已消耗量
  "budget_remaining": 0.998,                 // 剩余量
  "consumption_rate": 0.0000357,             // 消耗速率（/小时）
  "burn_rate":       0.5,                    // 燃烧速率
  "recorded_at":     "2025-03-15T10:00:00Z"  // 记录时间戳
}

2.1.3 消耗计算规则

1. 预算总量 = 1 - SLO 目标值（例如 SLO 99.9% → 预算总量 0.001）
2. 已消耗量 = 1 - (好事件数 / 总事件数)
3. 剩余量 = 预算总量 - 已消耗量
4. 燃烧速率 = 已消耗量 / (窗口时长 × 预算总量)

2.2 台账存储选型

误差预算台账需要同时支持高写入吞吐（每秒数千条记录）、低延迟查询（告警判定 < 1s）、历史回溯（90 天以上）。三种主流方案对比如下：

2.3 推荐架构：Thanos + ClickHouse 分层存储

结合两种存储的优势，推荐采用分层台账架构：

2.4 台账表结构设计（ClickHouse 示例）

若选择 ClickHouse 作为历史存储，推荐使用物化视图 + 聚合表结构：

-- 原始事件表（按天分区）
CREATE TABLE error_budget_events (
  service_name    String,
  slo_name        String,
  window_type     String,
  window_seconds  UInt32,
  good_events     UInt64,
  total_events    UInt64,
  recorded_at     DateTime
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(recorded_at)
ORDER BY (service_name, slo_name, recorded_at);

-- 聚合台账表（每小时聚合）
CREATE MATERIALIZED VIEW error_budget_hourly
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMM(hour)
ORDER BY (service_name, slo_name, hour)
AS SELECT
  service_name,
  slo_name,
  toStartOfHour(recorded_at) AS hour,
  sum(good_events) AS total_good,
  sum(total_events) AS total_events
FROM error_budget_events
GROUP BY service_name, slo_name, hour;

2.5 台账数据生命周期管理