2. 核心概念：Policy Check 规则库的定义、组成要素与生命周期
Policy Check 规则库是 SLI 口径集成架构中的“决策大脑”。它并非简单的规则列表，而是一个具备版本控制、依赖解析和运行时评估能力的结构化知识库。规则库的核心职责是将抽象的 SLO 目标转化为可被监控系统执行的、精确的判定逻辑。
2.1 规则库的定义
Policy Check 规则库是一个由判定规则、元数据和依赖关系组成的集合，用于定义“什么样的原始观测数据可以被计为一次有效请求、一次成功请求或一次失败请求”。它充当了原始指标（Raw Metrics）与最终 SLI 之间的转换层。
关键定位：规则库是“口径”的代码化表达。它确保不同团队、不同服务对“成功”与“失败”的理解完全一致，消除因口径歧义导致的 SLO 争议。
2.2 组成要素
一个完整的 Policy Check 规则由以下五个核心要素构成，缺一不可：
| 要素 | 定义 | 示例 |
|---|---|---|
| 匹配条件 | 定义规则适用的数据范围（服务、端点、标签） | service = "payment-api" AND endpoint = "/checkout" |
| 判定逻辑 | 布尔表达式，决定该数据点是否计入 SLI 分母或分子 | http.status_code >= 200 AND http.status_code < 500 |
| 权重 | 该规则在聚合计算中的优先级或影响系数 | weight: 1.0（默认） |
| 标签输出 | 规则通过后，为数据点附加的额外维度标签 | slio_result: "valid_request" |
| 元数据 | 规则的版本、作者、变更说明、生效时间 | version: "2.1.0", author: "sre-team" |
2.3 规则的生命周期
规则库中的每一条规则都遵循严格的生命周期管理，确保变更可追溯、可回滚。生命周期分为五个阶段：
- 起草（Draft）：规则在代码仓库中以 YAML 或 JSON 格式编写，尚未生效。此阶段可进行代码审查（Code Review）。
- 预发布（Staging）：规则被部署到预发环境，与历史数据回放（Replay）进行比对，验证口径变更对 SLI 数值的影响。
- 生效（Active）：规则通过审批，正式推送到生产环境的 Policy Engine 中，开始影响实时 SLI 计算。
- 废弃（Deprecated）：规则被新版本替代，但仍保留在库中用于历史数据回溯。引擎不再对新数据应用此规则。
- 归档（Archived）：规则被彻底移除出活跃库，仅保留在 Git 历史中作为审计依据。
常见陷阱：跳过“预发布”阶段直接上线规则，是导致 SLI 突降或突升的主要原因。任何口径变更都必须经过历史数据回放验证。
2.4 规则库的架构关系
下图展示了规则库在 Policy Check 体系中的核心位置及其与上下游组件的关系：
2.5 规则库的版本化与存储
规则库必须像代码一样进行版本管理。推荐使用 Git 作为底层存储，并遵循以下目录结构约定：
policy-rules/
├── services/
│ ├── payment-api/
│ │ ├── v1.0.0.yaml
│ │ ├── v2.0.0.yaml
│ │ └── v2.1.0.yaml
│ └── user-service/
│ └── v1.0.0.yaml
├── global/
│ └── base-rules.yaml
├── tests/
│ └── replay-data/
└── policy-config.yaml
最佳实践：每个规则文件头部必须包含
version、effective_from 和 change_log 字段。建议使用语义化版本号（SemVer），主版本号变更表示口径不兼容。
2.6 规则评估流程
下图展示了单条规则从接收到输出的完整评估流程：
2.7 规则冲突与优先级
当多个规则匹配同一数据点时，必须通过优先级机制解决冲突。优先级规则如下：
- 精确匹配优先：匹配条件中标签维度更多的规则优先级更高。
- 显式权重：规则定义中的
weight字段可覆盖默认优先级。 - 最后匹配胜出：在同等优先级下，规则列表中的最后一条规则生效。
设计原则：规则库应保持“无冲突”设计。如果两条规则可能匹配同一数据点，应通过重构规则条件或引入排他标签来消除歧义，而非依赖运行时优先级。