⚡

SLO、SLI与错误预算管理Skill slo-sli-error-budget

此技能专注于定义服务级别目标（SLOs）、选择服务级别指标（SLIs）以及管理错误预算，以实现服务可靠性和开发效率的平衡。适用于DevOps团队和可靠性工程师，涉及监控、警报和策略制定。关键词：SLO、SLI、错误预算、可靠性工程、DevOps、服务监控、错误管理。

DevOps 0 次安装 0 次浏览 更新于 3/11/2026

name: slo-sli-error-budget description: 在定义SLOs、选择SLIs或实施错误预算政策时使用。涵盖可靠性目标、SLI选择和错误预算管理。 allowed-tools: Read, Glob, Grep

SLOs、SLIs和错误预算

定义服务级别目标、选择有意义的指标以及通过错误预算管理可靠性的模式和实践。

何时使用此技能

  • 为服务定义SLOs
  • 选择适当的SLIs
  • 实施错误预算政策
  • 平衡可靠性和速度
  • 设置基于SLO的警报

核心概念

SLI（服务级别指标）

SLI = 服务级别的定量测量

测量内容：
- 可用性：% 成功请求
- 延迟：% 请求快于阈值
- 吞吐量：每秒请求数
- 错误率：% 失败请求

公式：
SLI = (良好事件 / 总事件) × 100%

示例：
可用性SLI = (成功请求 / 总请求) × 100%
             = (99,500 / 100,000) × 100%
             = 99.5%

SLO（服务级别目标）

SLO = SLI的目标值

格式：SLI >= 目标值 在时间窗口内

示例：
- 99.9% 的请求在30天内成功
- 95% 的请求在7天内完成时间 <200ms
- 99.95% 可用性按月测量

组件：
┌─────────────────────────────────────────────────────┐
│ SLO = SLI + 目标值 + 时间窗口                    │
│                                                      │
│ "99.9% 的HTTP请求返回非5xx响应             │
│  在滚动30天窗口内"                      │
└─────────────────────────────────────────────────────┘

错误预算

错误预算 = 允许的不可靠性

如果SLO = 99.9% 可用性：
错误预算 = 100% - 99.9% = 0.1%

超过30天：
总分钟数 = 30 × 24 × 60 = 43,200
错误预算 = 43,200 × 0.001 = 43.2分钟

或以请求计（假设每月100万请求）：
错误预算 = 1,000,000 × 0.001 = 1,000个失败请求

预算消耗：
┌────────────────────────────────────────────────────┐
│ 剩余错误预算：65%                        │
│ ████████████████████░░░░░░░░░░                    │
│ 已消耗：35% (15分钟 / 43.2分钟)                │
│ 窗口中剩余天数：12                       │
└────────────────────────────────────────────────────┘

选择SLIs

SLI类别

1. 基于请求的SLIs：
   - 可用性（成功率）
   - 延迟（响应时间）
   - 质量（正确响应率）

2. 基于处理的SLIs：
   - 吞吐量
   - 新鲜度（数据陈旧度）
   - 覆盖率（% 数据处理）

3. 基于存储的SLIs：
   - 持久性
   - 数据可用性

SLI选择框架

针对每个用户旅程：

1. 识别关键交互
   └── 用户关心什么？

2. 映射到可测量信号
   └── 我们可以测量什么？

3. 定义好与坏
   └── 什么是可接受的？

4. 与用户/利益相关者验证
   └── 这符合期望吗？

良好SLI特征

✅ 良好SLIs：
- 直接反映用户体验
- 可测量和可观察
- 简单易懂
- 违反时可采取行动

❌ 不良SLIs：
- 内部指标（CPU、内存）
- 太复杂难以解释
- 无法可靠测量
- 没有清晰的好/坏阈值

按服务类型SLI示例

API服务：
- 可用性：% 非5xx响应
- 延迟：% 请求 < 200ms
- 质量：% 有效响应

数据管道：
- 新鲜度：% 数据 < 10分钟旧
- 覆盖率：% 记录处理
- 正确性：% 匹配预期

存储服务：
- 持久性：% 对象未丢失
- 可用性：% 成功读取
- 延迟：% 读取 < 50ms

Web应用程序：
- 页面加载：% 页面 < 3秒
- 交互性：% 交互 < 100ms
- 核心Web指标：LCP、FID、CLS

设置SLO目标

目标选择方法

1. 测量当前性能：
   基线是什么？

2. 理解用户期望：
   用户需要什么？

3. 考虑业务约束：
   可靠性的成本是什么？

4. 从保守开始：
   最好超过而非错过

5. 基于数据迭代：
   随着学习调整

SLO目标指南

服务类型        | 可用性 | 延迟（p99）
--------------------|--------------|---------------
内部API       | 99.5%        | 500ms
外部API       | 99.9%        | 200ms
支付系统     | 99.99%       | 300ms
静态内容      | 99.95%       | 100ms
批处理    | 99%          | -

"九"级标尺：
99%    = 每月7.2小时停机
99.9%  = 每月43.8分钟
99.99% = 每月4.38分钟

时间窗口

滚动 vs 日历：

滚动（推荐）：
- 30天滚动窗口
- 平滑，无悬崖效应
- 始终相关

日历：
- 每月重置
- 与业务周期对齐
- 创建"预算重置"行为

窗口选择：
短（7天）：更敏感，反馈更快
长（30天）：更稳定，趋势更平滑

错误预算政策

政策组件

错误预算政策定义：

1. 何时采取行动
   └── 预算阈值（75%、50%、25%、0%）

2. 采取什么行动
   └── 冻结功能、专注于可靠性

3. 谁决定
   └── 团队、管理层、升级路径

4. 如何恢复
   └── 恢复预算的步骤

示例政策

OrderService的错误预算政策

剩余预算 | 所需行动
-----------------|------------------------------------------
> 50%            | 正常开发、自由部署
25-50%           | 审查部署、增加测试
10-25%           | 冻结非关键功能
< 10%            | 全员专注于可靠性、无新功能
0%（耗尽）   | 需要事后分析、领导审查

升级：
- 预算 < 25%：提醒团队领导
- 预算 < 10%：提醒工程经理
- 预算耗尽：宣布事件

预算恢复

当预算耗尽时：

1. 停止非关键部署
2. 专注于稳定性改进
3. 进行彻底的事后分析
4. 实施预防措施
5. 预算恢复时恢复正常工作

预算恢复通过：
- 时间流逝（滚动窗口）
- 可靠性改进
- SLO调整（如果合适）

多窗口SLOs

为何多窗口？

单窗口问题：
- 长窗口：检测问题慢
- 短窗口：对峰值太敏感

解决方案：多窗口

快速消耗：短窗口（1小时）
- 快速检测重大中断
- 高紧急警报

缓慢消耗：长窗口（30天）
- 检测逐渐退化
- 低紧急度、更多上下文

多窗口配置

警报配置：

快速消耗（立即寻呼）：
- 30天预算在1小时内消耗2%
- 30天预算在6小时内消耗5%

缓慢消耗（工单）：
- 30天预算在3天内消耗10%
- 30天预算在7天内消耗20%

计算：
如果30天预算 = 43.2分钟
1小时内2% = 0.864分钟 = 52秒错误
→ 重大中断，立即寻呼

基于SLO的警报

警报设计

传统警报：
- CPU > 80% → 警报
- 错误率 > 1% → 警报
- 延迟 > 500ms → 警报
→ 常常嘈杂，可能不反映用户影响

基于SLO的警报：
- 错误预算消耗率太高 → 警报
→ 直接与用户影响挂钩
→ 更少、更有意义的警报

消耗率计算

消耗率 = 预算消耗速率

如果预算应持续30天：
正常消耗率 = 1x（每天消耗3.33%）

快速消耗率 = 14.4x
→ 每天消耗48% → 2天内耗尽
→ 寻呼：重大事件

缓慢消耗率 = 3x
→ 每天消耗10% → 10天内耗尽
→ 工单：需要关注

仪表板设计

显示的关键指标

SLO仪表板组件：

1. 当前SLI值
   └── "99.85%可用性（目标：99.9%）"

2. 剩余错误预算
   └── 带阈值的条形图

3. 消耗率趋势
   └── 随时间线图

4. 预算耗尽时间
   └── "按当前速率：15天"

5. 历史SLO合规性
   └── 我们多久满足SLO？

6. 关键错误贡献者
   └── 什么在消耗预算？

可视化示例

┌─────────────────────────────────────────────────────┐
│ OrderService SLO仪表板                          │
├─────────────────────────────────────────────────────┤
│ 可用性SLI：99.87%     目标：99.9%    ⚠️   │
│ ██████████████████████████████████████░░░░ 99.87%  │
│                                                     │
│ 错误预算（30天）：                              │
│ ████████████████░░░░░░░░░░░░░░ 55%剩余       │
│ 已消耗：19.4分钟 / 43.2分钟                       │
│                                                     │
│ 消耗率：1.3x（轻微超支）                   │
│ ────────────────────────────────                   │
│                      ↑ 现在                          │
│                                                     │
│ 顶部预算消耗者：                               │
│ 1. 数据库超时（8.2分钟）                      │
│ 2. 支付网关错误（5.1分钟）                 │
│ 3. 速率限制（3.8分钟）                          │
└─────────────────────────────────────────────────────┘

实施检查表

入门

1. [ ] 识别关键用户旅程
2. [ ] 为每个旅程定义SLIs
3. [ ] 设置初始SLO目标（保守）
4. [ ] 实施SLI测量
5. [ ] 创建错误预算跟踪
6. [ ] 设置消耗率警报
7. [ ] 创建SLO仪表板
8. [ ] 定义错误预算政策
9. [ ] 与利益相关者沟通
10. [ ] 基于学习迭代

常见陷阱

1. SLOs太多
   → 专注于3-5个关键SLOs

2. 不切实际的目标
   → 从可实现的开始，随时间收紧

3. 内部指标作为SLIs
   → 使用面向用户的指标

4. 没有错误预算政策
   → 政策使SLOs可操作

5. 直接基于SLI警报
   → 基于消耗率警报

最佳实践

1. 以用户为中心的SLIs
   测量用户体验

2. 保守的初始目标
   最好超过而非错过

3. 文档化的错误预算政策
   每个人都知道规则

4. 定期SLO审查
   季度审查和调整

5. 无责文化
   专注于学习，而非责备

6. 自动化跟踪
   SLI/SLO计算必须可靠

相关技能

  • observability-patterns - 指标和监控
  • distributed-tracing - 基于跟踪的SLIs
  • incident-response - 在事件中使用SLOs