1. 课程导论：为什么需要回滚护栏、租户配额校准的背景与目标、课程整体架构
1.1 为什么需要回滚护栏：从配置事故说起
在 Prometheus 生态中，策略即代码（Policy as Code, PaC） 已成为管理告警规则、Recording Rules 和 Scrape 配置的标准实践。然而，当 PaC 配置被直接应用到生产环境时，一次错误的规则推送可能导致：
- 告警风暴：误报规则触发数万条告警，淹没 On-Call 工程师。
- 指标丢失：Scrape 配置错误导致关键业务指标采集中断。
- 租户资源争抢：未校准的配额使某个租户的查询消耗全部集群资源。
核心痛点：传统 GitOps 流程缺乏“回滚护栏”，一旦错误配置合并到主分支，自动同步工具会立即将其推送到所有 Prometheus 实例，造成大规模故障。
回滚护栏 是一组自动化校验与回退机制，在配置生效前进行语法检查、语义验证、影响范围评估，并在检测到异常时自动回滚到上一个稳定版本。它解决了以下关键问题：
| 问题维度 | 无回滚护栏 | 有回滚护栏 |
|---|---|---|
| 配置错误检测 | 依赖人工 Code Review | 自动化语法 + 语义校验 |
| 故障恢复时间 | 分钟级 ~ 小时级 | 秒级自动回滚 |
| 影响范围控制 | 全局生效 | 灰度 + 熔断 |
| 审计追溯 | Git 日志 | 回滚事件 + 快照对比 |
1.2 租户配额校准的背景与目标
在多租户 Prometheus 架构中（如 Thanos、Cortex、Mimir），每个租户拥有独立的指标存储和查询资源。然而，实际运营中常出现以下问题：
- 配额超卖：初始分配的 Series 数量、查询并发、数据保留周期与实际使用量严重不匹配。
- “吵闹邻居”效应：某个租户的突发查询耗尽共享查询前端资源，导致其他租户超时。
- 成本分摊失真：缺乏基于实际用量的配额校准，导致计费模型不公平。
租户配额校准 的目标是建立一个动态、可审计的配额管理机制：
| 校准维度 | 校准前（静态） | 校准后（动态） |
|---|---|---|
| Series 上限 | 固定值（如 100 万） | 基于过去 7 天 P99 用量 + 20% 缓冲 |
| 查询并发 | 全局统一限制 | 按租户优先级 + 历史负载动态调整 |
| 数据保留期 | 所有租户相同 | 按业务等级差异化配置 |
| 成本分摊 | 按租户数均摊 | 按实际 Series 数 + 查询量计费 |
关键指标：校准后，租户配额命中率应保持在 70%~85% 之间，既避免资源浪费，又防止突发流量导致限流。
1.3 课程整体架构
本课程共 30 章，分为四大模块，从理论到实战逐步深入：
| 模块 | 章节范围 | 核心内容 |
|---|---|---|
| 基础篇 | 第 1~6 章 | 回滚护栏原理、Prometheus PaC 基础、租户模型设计 |
| 实现篇 | 第 7~16 章 | GitOps 集成、自动校验流水线、配额校准算法、回滚策略 |
| 进阶篇 | 第 17~24 章 | 多集群配额同步、成本分摊模型、告警抑制与熔断 |
| 实战篇 | 第 25~30 章 | 生产环境部署、故障演练、监控大盘、持续优化 |
前置要求：学员需具备 Prometheus 基础运维经验，了解 PromQL 和 Kubernetes 基本概念。建议先完成《Prometheus 运维实战》前 10 章的学习。
通过本课程，你将掌握：
- 设计并实现 Prometheus 策略即代码的回滚护栏系统。
- 基于实际用量动态校准多租户配额，避免资源争抢。
- 构建可审计的配额变更流程，满足合规要求。
- 在生产环境中验证并持续优化配额模型。