3. SLO 作业模板设计原则：模板化思维、可复用性、可扩展性、版本控制

在服务目录与 SLO 治理体系中，作业模板（Job Template）是连接定义与执行的桥梁。一个设计良好的 SLO 作业模板，能够将重复的配置工作抽象为标准化构件，使 SRE 团队从“手写每个告警规则”转变为“声明式组装”。本节围绕四大核心原则展开：模板化思维、可复用性、可扩展性、版本控制。

3.1 模板化思维：从“写死”到“参数化”

模板化思维的核心是将变化的部分抽离为变量，将不变的部分固化为骨架。在 Prometheus 生态中，这通常通过 text/template 或 jsonnet 实现。

以下是一个基于 Prometheus recording rule 的模板示例：

# slo_burnrate_template.yml
groups:
  - name: slo_burnrate_{{ .ServiceName }}
    interval: 1m
    rules:
      - record: job:slo_errors_total:rate1m_{{ .ServiceName }}
        expr: |
          sum(rate({{ .ErrorMetric }}{{ .MetricSelector }}[1m]))
      - record: job:slo_burn_rate_{{ .ServiceName }}
        expr: |
          job:slo_errors_total:rate1m_{{ .ServiceName }}
          / (1 - {{ .SLOTarget }}) * {{ .WindowSeconds }}

通过模板引擎渲染时，只需传入参数映射：

{
  "ServiceName": "api-gateway",
  "ErrorMetric": "http_requests_total{status=~\"5..\"}",
  "MetricSelector": "{job=\"api-gateway\"}",
  "SLOTarget": 0.999,
  "WindowSeconds": 3600
}

3.2 可复用性：一次定义，多处生效

可复用性要求模板能够跨服务、跨环境、跨团队使用。设计时需关注以下维度：

可复用的模板通常采用分层组合策略：

1. 基础模板（Base Template）：定义通用的 recording rule 结构、告警表达式骨架。
2. 策略模板（Policy Template）：封装特定的 SLO 策略，如“30 分钟燃烧率告警”、“多窗口多燃烧率告警”。
3. 服务实例模板（Instance Template）：注入具体参数，生成最终 Prometheus 规则文件。

3.3 可扩展性：预留扩展点，拥抱变化

随着服务规模增长，SLO 需求会不断演进。可扩展性要求模板能够在不破坏现有实例的前提下，支持新策略、新指标类型、新告警路由。

设计可扩展模板的四个关键扩展点：

3.4 版本控制：模板即代码

将 SLO 作业模板纳入版本控制，是保障可追溯性、可回滚、可审计的基础。推荐采用以下实践：

• 单一仓库（Monorepo）：将所有模板、参数文件、生成脚本放在同一个 Git 仓库中，便于原子性变更。
• 语义化版本（SemVer）：对模板本身打标签，如 v1.2.0。当模板结构发生不兼容变更时，递增主版本号。
• 变更记录（CHANGELOG）：每次模板更新，在 CHANGELOG 中记录变更内容、影响范围、升级指南。
• CI/CD 校验：在合并到主分支前，自动校验模板语法、参数 schema、生成结果是否符合预期。

3.5 四大原则的协同关系

这四个原则并非孤立存在，而是相互支撑、层层递进：

• 模板化思维是基础，将重复劳动抽象为参数化骨架。
• 可复用性建立在模板化之上，通过分层组合实现“一次定义，多处生效”。
• 可扩展性为模板注入生命力，预留扩展点使其能够适应未来的 SLO 策略变化。
• 版本控制为整个体系提供安，确保变更可追溯、可回滚、可审计。