3. SLO 作业模板核心字段
一个标准化的 SLO 作业模板是平台工程团队将可靠性目标从“文档共识”推向“自动化执行”的关键载体。模板中的每个字段都对应着监控系统、告警引擎和 CI/CD 流水线的具体消费逻辑。本章逐一拆解六个核心字段的设计意图、填写规范与集成要点。
3.1 字段总览与职责矩阵
下表列出了 SLO 作业模板的六个核心字段,以及每个字段在平台工程中的主要职责与消费方:
| 字段 | 定义 | 主要消费方 | 集成关键点 |
|---|---|---|---|
| 服务名称 | 唯一标识一个微服务或基础设施组件 | CMDB、服务目录、监控标签 | 与部署单元名称严格一致 |
| SLI 指标定义 | 描述如何从原始数据源计算服务等级指标 | Prometheus / Datadog / 自定义 Exporter | 使用可编程查询语言(如 PromQL) |
| 目标阈值 | SLI 必须满足的数值目标,通常为百分比 | 告警引擎、SLO 计算器 | 区分硬性阈值与弹性预算 |
| 合规窗口 | 评估 SLO 达标情况的时间范围 | 时序数据库、滚动窗口计算器 | 支持 7d / 30d / 自定义日历窗口 |
| 告警规则 | 当 SLO 接近或违反目标时触发的通知逻辑 | Alertmanager / PagerDuty / 飞书 | 多级告警(警告 / 严重)与静默策略 |
| 元数据标签 | 用于分类、过滤、成本分摊的键值对 | 标签引擎、成本中心、仪表盘 | 继承基础设施标签,避免手工维护 |
3.2 字段详解与填写规范
3.2.1 服务名称
服务名称是 SLO 作业的“主键”。平台工程团队应强制要求服务名称与 CI/CD 流水线中的部署单元名称、Kubernetes Service 名称、CMDB 中的业务系统名称保持三统一。推荐使用小写字母、连字符分隔的命名风格,例如 payment-gateway、user-auth-service。
最佳实践: 在模板中为服务名称字段设置正则校验,禁止包含空格、大写字母或下划线,避免下游系统解析异常。
3.2.2 SLI 指标定义
SLI 定义是模板中最具技术含量的字段。它必须包含三个要素:指标来源(如 Prometheus metric name)、过滤条件(如排除健康检查端点)、计算表达式(如成功率 = 成功请求数 / 总请求数)。
# 示例:API 请求成功率 SLI 定义(PromQL)
(
sum(rate(http_requests_total{status_code=~"2..|3..", service="payment-gateway"}[5m]))
/
sum(rate(http_requests_total{service="payment-gateway"}[5m]))
) * 100
常见陷阱: 不要将原始指标名称直接作为 SLI 定义。必须明确聚合方式(rate / avg / histogram_quantile)、时间窗口(5m / 1h)和过滤条件(排除探活请求),否则不同团队计算出的 SLI 值可能不一致。
3.2.3 目标阈值
目标阈值通常以百分比形式填写,例如 99.9(三个九)。平台工程团队应区分两类阈值:
- 硬性阈值: 违反即触发告警,适用于核心支付、登录等关键链路。
- 弹性预算阈值: 基于错误预算消耗速度动态调整,适用于非关键服务或灰度验证阶段。
3.2.4 合规窗口
合规窗口定义了“在多长时间范围内评估 SLO 是否达标”。常见选项包括:
| 窗口类型 | 说明 | 适用场景 |
|---|---|---|
| 滚动 7 天 | 持续评估最近 7 天的 SLI 数据 | 通用微服务 |
| 滚动 30 天 | 月度可靠性评估 | 面向客户的长期稳定服务 |
| 日历月 | 与财务或业务月度对齐 | 合规审计、SLA 报告 |
| 自定义窗口 | 支持指定起始时间与结束时间 | 大促活动、灰度发布期间 |
3.2.5 告警规则
告警规则字段应包含告警级别、触发条件、通知渠道和静默策略。推荐采用多级告警设计:
- 警告(Warning): 错误预算消耗速度超过 50% 或 SLO 剩余时间不足 72 小时。
- 严重(Critical): SLO 已违反或错误预算已耗尽。
- 静默(Silence): 允许在维护窗口或已知故障期间临时抑制告警。
3.2.6 元数据标签
元数据标签是 SLO 作业的可扩展属性,用于分类、过滤和成本分摊。平台工程团队应定义一套强制标签与可选标签:
| 标签键 | 示例值 | 用途 |
|---|---|---|
team |
payment-team | 归属团队 |
tier |
critical / standard / best-effort | 服务等级分层 |
environment |
production / staging | 部署环境 |
cost-center |
fin-ops-123 | 成本分摊 |
3.3 核心字段关系图
下图展示了六个核心字段之间的逻辑关系与数据流向:
3.4 模板 YAML 示例
以下是一个完整的 SLO 作业模板 YAML 示例,展示了六个核心字段在实际文件中的组织方式:
apiVersion: slo.platform.io/v1
kind: ServiceLevelObjective
metadata:
name: payment-gateway-slo
labels:
team: payment-team
tier: critical
environment: production
cost-center: fin-ops-123
spec:
serviceName: payment-gateway
sliDefinition:
metricSource: prometheus
query: |
(
sum(rate(http_requests_total{status_code=~"2..|3..", service="payment-gateway"}[5m]))
/
sum(rate(http_requests_total{service="payment-gateway"}[5m]))
) * 100
unit: percent
targetThreshold:
value: 99.9
type: hard
complianceWindow:
type: rolling
duration: 30d
alertingRules:
- level: warning
condition: error_budget_remaining < 72h
channels: ["slack-platform-alerts"]
- level: critical
condition: slo_value < 99.9
channels: ["pagerduty", "feishu-urgent"]
3.5 字段校验与 CI/CD 集成要点
当 SLO 作业模板被提交到 Git 仓库后,CI/CD 流水线应自动执行以下校验:
- 服务名称唯一性检查: 确保同一集群内不存在同名 SLO 作业。
- SLI 查询语法校验: 使用 Prometheus API 的
/api/v1/query端点验证 PromQL 语法正确性。 - 阈值范围检查: 目标阈值必须在 0 到 100 之间,且合规窗口时长不能小于 1 小时。
- 标签合规检查: 强制标签(如
team、tier)必须存在且值在允许列表中。
平台工程自动化提示: 将上述校验逻辑封装为
slo-validator 容器镜像,在 CI 阶段作为独立 job 运行。校验失败时直接阻断合并请求,确保只有合规的 SLO 作业才能进入生产环境。