4. SLO台账概述:SLO台账的定义、SLO台账的核心字段(SLI、SLO目标、燃烧速率)、台账的生命周期管理。
SLO台账是服务可靠性管理的“单一事实源”。它不仅仅是记录SLI/SLO的静态表格,更是一套贯穿服务设计、发布、运维、迭代全生命周期的动态配置与状态管理机制。本节将定义SLO台账的核心概念,拆解其关键字段,并阐述台账从创建到退役的完整生命周期。
4.1 SLO台账的定义
SLO台账(Service Level Objective Ledger)是一个集中化的、版本化的配置与状态存储库,用于记录每个服务的可靠性承诺(SLO)、度量方式(SLI)、预算消耗规则(燃烧速率)以及当前合规状态。它充当了服务画像中“可靠性契约”的数字化载体,是质量门禁策略的输入源。
核心定位: SLO台账 ≠ 监控看板。监控看板展示实时数据,而台账定义“什么是好的服务”,并记录历史承诺与变更轨迹。
4.2 SLO台账的核心字段
一个标准化的SLO台账条目通常包含以下三大核心字段组:
| 字段类别 | 字段名称 | 说明与示例 |
|---|---|---|
| SLI 定义 | 指标名称 | 如:http_request_duration_seconds_bucket |
| 指标类型 | 延迟 / 错误率 / 吞吐量 / 饱和度 | |
| 良好事件定义 | 如:status_code < 500 AND duration_ms <= 200 |
|
| 总事件定义 | 如:所有HTTP请求总数 | |
| SLO 目标 | 目标值 | 如:99.9% (三个9) |
| 合规窗口 | 滚动窗口:28天 / 7天 / 1小时 | |
| 目标类型 | 月度SLO / 季度SLO / 发布级SLO | |
| 燃烧速率 | 预算总量 | 如:28天窗口内允许的坏事件总数 |
| 燃烧速率告警 | 如:burn_rate > 2 持续30分钟 → P2告警 |
|
| 剩余预算 | 实时计算:1 - (坏事件数 / 预算总量) |
实践建议: 燃烧速率是SLO台账中最动态的字段。建议在台账中同时记录“当前燃烧速率”和“预测耗尽时间”,以便在燃烧速率告警触发前进行干预。
4.3 燃烧速率详解
燃烧速率(Burn Rate)衡量错误预算消耗的速度。它是连接SLO目标与告警响应的关键桥梁。
- 定义: 燃烧速率 = 实际消耗的错误预算 / 时间窗口内应消耗的错误预算。
- 阈值示例:
- 燃烧速率 > 1:错误预算消耗速度超过预期,需要关注。
- 燃烧速率 > 2:消耗速度是预期的2倍,可能需要在数小时内响应。
- 燃烧速率 > 10:严重燃烧,可能需要在几分钟内响应。
# 燃烧速率计算示例 (PromQL)
# 假设SLO目标为99.9%,窗口为28天
# 错误率 = 1 - (良好事件数 / 总事件数)
# 燃烧速率 = 错误率 / (1 - SLO目标)
# 示例:过去1小时内错误率为0.5%
# 燃烧速率 = 0.005 / (1 - 0.999) = 0.005 / 0.001 = 5
4.4 台账的生命周期管理
SLO台账不是一成不变的,它需要随着服务演进、业务需求变化和运营经验积累而持续迭代。一个完整的生命周期包含以下阶段:
- 创建与初始化: 新服务上线时,根据服务画像中的“关键业务指标”定义初始SLI和SLO目标。通常从“三个9”开始,或根据历史基线设定。
- 评审与校准: 每季度或每次重大发布后,评审SLO的合理性。如果燃烧速率长期为0(过于宽松)或长期告警(过于严格),需要调整目标值。
- 变更与版本化: 任何SLO目标的修改都必须记录变更原因、审批人、生效时间。台账应支持版本回溯,以便审计。
- 退役与归档: 当服务下线或SLI/SLO不再适用时,将对应条目标记为“已退役”,并保留历史数据用于复盘。
常见陷阱: 台账“僵尸化”。很多团队创建SLO台账后就不再维护,导致SLO与实际运营脱节。建议将台账评审纳入每季度的服务画像刷新流程中。
4.5 SLO台账生命周期流程图
下图展示了SLO台账从创建到退役的完整流转,以及它与质量门禁的交互点:
4.6 SLO台账与质量门禁的集成点
台账中的核心字段直接驱动质量门禁的决策逻辑:
- SLI定义 → 门禁的“度量标准”:门禁系统根据SLI定义实时计算合规状态。
- SLO目标 → 门禁的“阈值”:决定发布是否被阻断(如:剩余预算 < 10% 时禁止上线)。
- 燃烧速率 → 门禁的“动态策略”:高燃烧速率时自动触发更严格的审批流程。
关键实践: 将SLO台账与CI/CD流水线集成。每次部署前,流水线自动读取台账中的当前剩余预算和燃烧速率,若低于预设阈值则自动阻断发布,并生成“门禁失败报告”回写到台账的“最近门禁事件”字段。