1. 课程导论：误差预算（Error Budget）的概念、SLO与SLI的关系、为什么需要聚合查询优化

1.1 从可用性到误差预算：SRE 的核心量化工具

在站点可靠性工程（SRE）实践中，传统的“9 的个数”可用性指标（如 99.9%、99.99%）虽然直观，但存在两个致命缺陷：粒度粗糙和无法指导决策。误差预算（Error Budget）正是为了解决这些问题而诞生的量化框架。

误差预算的定义非常简单：

这个预算代表了服务所有者可以“消耗”的不可靠性额度。只要实际错误率未超出预算，团队就可以放心地进行功能发布；一旦预算耗尽，则必须暂停发布并优先投入稳定性工作。这种机制将模糊的“可靠性”转化为可量化的、可操作的决策依据。

1.2 SLO 与 SLI 的关系：指标金字塔

要理解误差预算，必须先理清三个核心概念之间的层级关系：

三者之间的关系可以用下面的结构图来概括：

1.3 为什么需要聚合查询优化？—— 台账场景的挑战

在实际的误差预算台账系统中，我们通常需要按多维度（服务、集群、版本、区域）实时计算每个 SLO 的预算消耗情况。这直接依赖 PromQL 的聚合查询能力。然而，未经优化的聚合查询会带来严重的性能问题：

聚合查询优化的必要性体现在以下三个层面：

1. 计算效率：误差预算需要按 滑动窗口（如 28 天、7 天）反复计算，低效的 PromQL 会导致查询延迟从秒级恶化到分钟级。
2. 资源消耗：嵌套的 avg、sum、rate 组合会触发 Prometheus 的多次数据扫描，内存和 CPU 开销呈指数增长。
3. 准确性保障：错误的聚合顺序（如先平均后求和 vs 先求和后平均）会直接导致误差预算计算偏差，误导发布决策。

1.4 优化前后的对比：一个直观的例子

假设我们需要计算每个服务的月度误差预算消耗率（Budget Burn Rate），典型的优化路径如下：

avg by(service) (
  (1 - sum(rate(http_requests_total{code=~"5.."}[5m]))
       / sum(rate(http_requests_total[5m])))
)

1 - avg by(service) (
  sum(rate(http_requests_total{code=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))
)

1.5 本章小结

• 误差预算 是 SRE 将可靠性量化为可消耗额度的核心工具，公式为 1 − SLO。
• SLI → SLO → Error Budget 构成从原始指标到决策依据的完整链路。
• 在大规模误差预算台账场景中，PromQL 聚合查询优化 是保障系统实时性、降低资源消耗、确保数据准确性的必要手段。
• 本课程将从 PromQL 聚合原理、常见反模式、Recording Rules 设计、台账架构等维度，系统讲解优化实践。