mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
3385 字
10 分钟
SLO 驱动的可观测性
2025-10-18

凌晨 3 点,你的手机响了。又是一个 CPU 使用率 > 80% 的告警——但系统运行正常,用户没有受到影响。你翻了个身继续睡。第二天早上,你发现昨晚有 30 条告警,你忽略了 28 条——其中 2 条是真正重要的。

这就是阈值告警的困境:告警太多,真正重要的被淹没

SLO(Service Level Objective)驱动的告警从根本上改变了这个问题——告警不再基于”某个指标超过阈值”,而是基于”错误预算的消耗速度”。如果错误预算在快速燃烧,说明用户体验正在恶化,需要立即处理;如果错误预算消耗缓慢,说明系统在可接受范围内运行,不需要告警。

一、SLO 基础#

1.1 SLI → SLO → SLA#

graph LR SLI["SLI<br/>服务级别指标<br/>可度量的数值"] --> SLO["SLO<br/>服务级别目标<br/>SLI 的目标值"] SLO --> SLA["SLA<br/>服务级别协议<br/>未达 SLO 的后果"] style SLI fill:#e3f2fd,stroke:#1565c0 style SLO fill:#e8f5e9,stroke:#2e7d32 style SLA fill:#fff3e0,stroke:#e65100
概念说明示例
SLI可度量的服务质量指标成功率 = 99.95%、P99 延迟 = 200ms
SLOSLI 的目标值成功率 ≥ 99.9%、P99 ≤ 500ms
SLA未达 SLO 的商业后果可用性 < 99.9% → 赔付 10% 费用

1.2 SLI 设计#

好的 SLI 应该从用户视角度量服务质量

类型SLI计算方式说明
可用性请求成功率成功请求数 / 总请求数用户能否成功使用服务?
延迟请求延迟P99 ≤ 500ms 的请求比例用户体验是否流畅?
正确性数据一致性一致性检查通过率数据是否正确?
吞吐量处理能力每秒处理请求数系统容量是否足够?

1.3 SLI 定义方法论#

定义 SLI 不是拍脑袋的事。一个好的 SLI 需要满足以下条件:

原则 1:从用户行为出发

不要从系统指标出发定义 SLI,而要从用户行为出发:

错误的 SLI正确的 SLI原因
CPU 使用率 < 80%请求成功率 ≥ 99.9%用户不关心 CPU,关心请求是否成功
内存使用率 < 70%P99 延迟 ≤ 500ms用户不关心内存,关心响应是否够快
磁盘 I/O 延迟 < 10ms数据写入成功率 ≥ 99.95%用户不关心 I/O,关心数据是否写入成功

原则 2:SLI 必须可度量且可计算

SLI 应该可以用 PromQL 直接计算:

# 可用性 SLI:成功请求比例
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
# 延迟 SLI:P99 延迟
histogram_quantile(0.99, sum(rate(http_request_duration_bucket[5m])) by (le, service))
# 正确性 SLI:数据一致性检查通过率
sum(rate(consistency_check_total{result="pass"}[5m]))
/
sum(rate(consistency_check_total[5m]))

原则 3:区分”好事件”和”坏事件”

大多数 SLI 可以用”好事件 / 总事件”来计算:

SLI 类型好事件坏事件总事件
可用性HTTP 2xx/3xx/4xx 响应HTTP 5xx 响应所有 HTTP 响应
延迟耗时 ≤ 500ms 的请求耗时 > 500ms 的请求所有请求
正确性一致性检查通过一致性检查失败所有检查
Note

注意:HTTP 4xx 是客户端错误,不应该算作服务端的”坏事件”。只有 5xx 才是服务端的问题。如果你的可用性 SLI 把 4xx 也算作坏事件,那么客户端的一个 bug 就会烧光你的错误预算。

1.4 SLO 定义模板#

# SLO 定义
apiVersion: sloth.slok.dev/v1
kind: PrometheusSLO
spec:
service: order-service
slo:
- name: "availability"
objective: 99.9
description: "99.9% 的请求成功返回"
sli:
events:
error_query: sum(rate(http_requests_total{service="order-service",status=~"5.."}[{{.window}}]))
total_query: sum(rate(http_requests_total{service="order-service"}[{{.window}}]))
alerting:
name: OrderServiceAvailabilitySLO
labels:
team: order-team
page_alert:
labels:
severity: page
ticket_alert:
labels:
severity: ticket
- name: "latency"
objective: 99.0
description: "99% 的请求在 500ms 内完成"
sli:
events:
error_query: |
sum(rate(http_request_duration_seconds_bucket{service="order-service",le="0.5"}[{{.window}}]))
/
sum(rate(http_request_duration_seconds_count{service="order-service"}[{{.window}}]))
total_query: "1"

二、错误预算#

2.1 什么是错误预算?#

错误预算(Error Budget)是 SLO 的”反面”——如果 SLO 是 99.9%,那么错误预算就是 0.1%:

错误预算 = 1 - SLO
30 天错误预算 = 30 × 24 × 60 × 60 × 0.1% = 2592 秒 ≈ 43.2 分钟
SLO错误预算30 天允许停机1 年允许停机
99.9%0.1%43.2 分钟8 小时 45 分钟
99.95%0.05%21.6 分钟4 小时 22 分钟
99.99%0.01%4.3 分钟52 分钟
99.999%0.001%26 秒5 分钟

2.2 错误预算的计算#

错误预算的计算需要考虑时间窗口和请求量:

30 天总秒数 = 30 × 86400 = 2,592,000
错误预算秒数 = 2,592,000 × 0.1% = 2,592 秒 ≈ 43.2 分钟
30 天总请求数 = 1000 × 2,592,000 = 2,592,000,000
允许失败请求数 = 2,592,000,000 × 0.1% = 2,592,000
请求量SLO 99.9%30 天允许失败数每小时允许失败数
100 QPS99.9%259,200360
1,000 QPS99.9%2,592,0003,600
10,000 QPS99.9%25,920,00036,000
Warning

错误预算的计算要基于实际请求量,而不是理论值。低流量服务的错误预算天然更紧张——如果一天只有 1000 个请求,10 个失败就是 1% 的错误率,已经烧掉了 10 天的错误预算。对于低流量服务,考虑使用更宽松的 SLO 或更长的评估窗口。

2.3 错误预算的使用#

错误预算不是”可以浪费的额度”,而是”创新的燃料”:

错误预算状态行动说明
充裕(> 50%)可以发布新功能、做实验创新期
紧张(10-50%)谨慎发布、加强测试过渡期
耗尽(< 10%)停止发布、专注稳定性稳定期
超支(< 0%)事故复盘、优先修复救火期
Note

错误预算的核心价值不是惩罚,而是对齐——它让开发团队和 SRE 团队在”什么时候应该优先稳定性”这个问题上有了客观的判断标准,而不是靠主观感觉。

2.4 错误预算策略#

不同团队可以采用不同的错误预算策略:

策略描述适用场景
滚动窗口过去 30 天的错误预算通用
日历月每月 1 日重置与业务周期对齐
消耗式不重置,直到 SLO 恢复严格模式
分级核心服务严格,非核心宽松多服务场景

三、燃烧率与多窗口告警#

3.1 燃烧率#

燃烧率(Burn Rate)是错误预算消耗速度的度量:

燃烧率 = 实际错误率 / 允许错误率
燃烧率含义错误预算消耗
1恰好按预算消耗30 天耗尽
22 倍速消耗15 天耗尽
66 倍速消耗5 天耗尽
14.414.4 倍速消耗2 天耗尽
43.243.2 倍速消耗16.7 小时耗尽

3.2 燃烧率的计算详解#

燃烧率的计算需要理解”错误率”和”允许错误率”的关系:

# 完整 PromQL
(
sum(rate(http_requests_total{status=~"5.."}[1h])) by (service)
/
sum(rate(http_requests_total[1h])) by (service)
)
/
(1 - 0.999) # 允许错误率 = 1 - SLO

燃烧率告警的关键洞察:燃烧率越高,错误预算消耗越快,告警越紧急

3.3 多窗口告警#

Google SRE 推荐的多窗口告警策略,使用两个时间窗口来平衡灵敏度和误报率:

# 多窗口告警规则
groups:
- name: slo-burn-rate
rules:
# 快速燃烧:14.4x 燃烧率,1h/5m 窗口
- alert: SLOFastBurnRate
expr: |
(
sum(rate(http_requests_total{status=~"5.."}[1h])) by (service)
/
sum(rate(http_requests_total[1h])) by (service)
)
/
(
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/
sum(rate(http_requests_total[5m])) by (service)
)
> 14.4
for: 5m
labels:
severity: page
# 慢速燃烧:6x 燃烧率,6h/30m 窗口
- alert: SLOSlowBurnRate
expr: |
(
sum(rate(http_requests_total{status=~"5.."}[6h])) by (service)
/
sum(rate(http_requests_total[6h])) by (service)
)
/
(
sum(rate(http_requests_total{status=~"5.."}[30m])) by (service)
/
sum(rate(http_requests_total[30m])) by (service)
)
> 6
for: 30m
labels:
severity: ticket

3.4 多窗口告警参数#

告警级别燃烧率短窗口长窗口检测时间误报率
Page(立即处理)14.4x5m1h~5 分钟
Ticket(工作时间内处理)6x30m6h~30 分钟极低

3.5 为什么是 14.4 和 6?#

这两个数字不是随意选择的,它们来自 Google SRE 的数学推导:

# 快速燃烧(Page 级)
# 条件:14.4x 燃烧率在 1 小时窗口内持续
# 错误预算消耗:14.4 × (1h / 720h) = 2%
# 含义:1 小时内消耗 2% 的 30 天错误预算
# 30 天错误预算在 2 天内耗尽 → 需要立即处理
# 慢速燃烧(Ticket 级)
# 条件:6x 燃烧率在 6 小时窗口内持续
# 错误预算消耗:6 × (6h / 720h) = 5%
# 含义:6 小时内消耗 5% 的 30 天错误预算
# 30 天错误预算在 5 天内耗尽 → 工作时间处理
燃烧率30 天预算耗尽时间告警级别理由
1x30 天正常消耗
6x5 天Ticket需要关注但不紧急
14.4x2 天Page需要立即处理
Warning

不要设置太多 SLO 告警。每个 SLO 最多两个告警级别(Page + Ticket)。如果 Page 告警超过每周 1-2 次,说明 SLO 太严格或系统需要改进。

3.6 告警规则模板#

以下是一个通用的 SLO 告警规则模板,可以直接复用:

# SLO 告警规则模板
# 替换 {{SERVICE}} 和 {{SLO_THRESHOLD}} 即可使用
groups:
- name: slo-{{SERVICE}}-burn-rate
rules:
# ===== 可用性 SLO =====
- alert: {{SERVICE}}AvailabilityFastBurn
expr: |
(
sum(rate(http_requests_total{service="{{SERVICE}}",status=~"5.."}[1h]))
/
sum(rate(http_requests_total{service="{{SERVICE}}"}[1h]))
) > (1 - {{SLO_THRESHOLD}}) * 14.4
for: 5m
labels:
severity: page
slo: availability
service: "{{SERVICE}}"
annotations:
summary: "{{SERVICE}} 可用性 SLO 快速燃烧"
runbook_url: "https://wiki/runbooks/{{SERVICE}}-availability"
- alert: {{SERVICE}}AvailabilitySlowBurn
expr: |
(
sum(rate(http_requests_total{service="{{SERVICE}}",status=~"5.."}[6h]))
/
sum(rate(http_requests_total{service="{{SERVICE}}"}[6h]))
) > (1 - {{SLO_THRESHOLD}}) * 6
for: 30m
labels:
severity: ticket
slo: availability
service: "{{SERVICE}}"
annotations:
summary: "{{SERVICE}} 可用性 SLO 慢速燃烧"
# ===== 延迟 SLO =====
- alert: {{SERVICE}}LatencyFastBurn
expr: |
(
1 -
sum(rate(http_request_duration_bucket{service="{{SERVICE}}",le="0.5"}[1h]))
/
sum(rate(http_request_duration_count{service="{{SERVICE}}"}[1h]))
) > (1 - 0.99) * 14.4
for: 5m
labels:
severity: page
slo: latency
service: "{{SERVICE}}"
annotations:
summary: "{{SERVICE}} 延迟 SLO 快速燃烧"

四、SLO 实施方法论#

4.1 SLO 选择原则#

原则说明反模式
从用户视角定义度量用户体验,而非系统指标CPU 使用率 SLO
少即是多3-5 个核心 SLO 足够20 个 SLO
可行动SLO 违规时你知道该做什么无法行动的 SLO
渐进式收紧先设宽松 SLO,逐步收紧一开始就设 99.999%
分类分级核心服务严格,非核心宽松所有服务同一个 SLO

4.2 SLO 分类#

服务类型可用性 SLO延迟 SLO告警策略
核心服务(支付、认证)99.95%P99 < 200msPage 级
重要服务(订单、搜索)99.9%P99 < 500msPage + Ticket
一般服务(推荐、通知)99.5%P99 < 1sTicket 级
实验性服务99.0%无告警

4.3 不同服务的 SLO 示例#

示例 1:支付服务(核心)

spec:
service: payment-service
slo:
- name: availability
objective: 99.95
description: "99.95% 的支付请求成功完成"
sli:
events:
error_query: sum(rate(payment_requests_total{status!="success"}[{{.window}}]))
total_query: sum(rate(payment_requests_total[{{.window}}]))
- name: latency
objective: 99.9
description: "99.9% 的支付请求在 3s 内完成"
sli:
events:
error_query: |
sum(rate(payment_duration_bucket{le="3"}[{{.window}}]))
/
sum(rate(payment_duration_count[{{.window}}]))
total_query: "1"
- name: correctness
objective: 99.99
description: "99.99% 的支付金额一致"
sli:
events:
error_query: sum(rate(payment_reconciliation_errors_total[{{.window}}]))
total_query: sum(rate(payment_requests_total[{{.window}}]))

示例 2:搜索服务(重要)

spec:
service: search-service
slo:
- name: availability
objective: 99.9
description: "99.9% 的搜索请求返回结果"
sli:
events:
error_query: sum(rate(search_requests_total{status=~"5.."}[{{.window}}]))
total_query: sum(rate(search_requests_total[{{.window}}]))
- name: latency
objective: 99.0
description: "99% 的搜索请求在 500ms 内完成"
sli:
events:
error_query: |
sum(rate(search_duration_bucket{le="0.5"}[{{.window}}]))
/
sum(rate(search_duration_count[{{.window}}]))
total_query: "1"

示例 3:通知服务(一般)

spec:
service: notification-service
slo:
- name: delivery
objective: 99.5
description: "99.5% 的通知在 5 分钟内送达"
sli:
events:
error_query: sum(rate(notifications_total{delivered="false"}[{{.window}}]))
total_query: sum(rate(notifications_total[{{.window}}]))

4.4 SLO 生命周期#

graph TB DEFINE["1. 定义 SLO<br/>与产品团队对齐"] --> MEASURE["2. 度量 SLI<br/>建立基线"] MEASURE --> ALERT["3. 配置告警<br/>燃烧率策略"] ALERT --> REVIEW["4. 定期回顾<br/>月度 SLO 评审"] REVIEW --> ADJUST["5. 调整 SLO<br/>收紧或放宽"] ADJUST --> DEFINE style DEFINE fill:#e3f2fd,stroke:#1565c0 style MEASURE fill:#e8f5e9,stroke:#2e7d32 style ALERT fill:#fff3e0,stroke:#e65100 style REVIEW fill:#f3e5f5,stroke:#6a1b9a style ADJUST fill:#c8e6c9,stroke:#2e7d32

4.5 SLO 最佳实践#

实践说明常见错误
先度量后定义先收集 SLI 数据,再设定 SLO凭直觉设 SLO
从宽松开始先设 99.5%,逐步收紧到 99.9%一开始就设 99.99%
月度评审每月回顾 SLO 达成情况设了就不管
区分 SLO 和 SLASLO 是内部目标,SLA 是外部承诺把 SLA 当 SLO
错误预算驱动发布预算充裕时发布,耗尽时冻结不看预算盲目发布

五、SLO 仪表盘设计#

5.1 SLO 仪表盘的核心组件#

一个好的 SLO 仪表盘应该一目了然地回答三个问题:SLO 达成了吗?错误预算还剩多少?燃烧率是多少?

graph TB subgraph DASHBOARD[" SLO 仪表盘"] STATUS["/ SLO 状态<br/>当前 SLI 值 vs 目标"] BUDGET[" 错误预算<br/>剩余百分比 + 趋势图"] BURN[" 燃烧率<br/>当前燃烧率 + 历史趋势"] EVENTS[" 重大事件<br/>部署/事故/变更时间线"] end STATUS --> BUDGET BUDGET --> BURN BURN --> EVENTS style DASHBOARD fill:#e8f5e9,stroke:#2e7d32 style STATUS fill:#c8e6c9,stroke:#2e7d32 style BUDGET fill:#fff3e0,stroke:#e65100 style BURN fill:#ffcdd2,stroke:#c62828 style EVENTS fill:#e3f2fd,stroke:#1565c0

5.2 SLO 仪表盘的 PromQL 查询#

# 1. 当前 SLI 值
1 - (
sum(rate(http_requests_total{status=~"5.."}[30d]))
/
sum(rate(http_requests_total[30d]))
)
# 2. 剩余错误预算
1 - (
(1 - sum(rate(http_requests_total{status=~"5.."}[30d])) / sum(rate(http_requests_total[30d])))
/
0.999 # SLO 目标
)
# 3. 燃烧率
(
sum(rate(http_requests_total{status=~"5.."}[1h]))
/
sum(rate(http_requests_total[1h]))
)
/
(1 - 0.999)
# 4. 错误预算消耗趋势(30 天窗口)
1 - (
sum_over_time((1 - (sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))))[30d:])
/
sum_over_time((1)[30d:])
)

5.3 SLO 仪表盘布局建议#

面板类型说明
1SLO 状态概览Stat Panel大字体显示 SLI 值和 SLO 目标
1错误预算剩余Gauge0-100%,颜色随预算变化
2SLI 趋势Time Series30 天 SLI 趋势 + SLO 目标线
2错误预算趋势Time Series30 天预算消耗趋势
3燃烧率Time Series当前燃烧率 + 告警阈值线
3事件时间线Annotations部署/事故/变更标记

六、事件响应工作流#

6.1 SLO 驱动的事件响应#

sequenceDiagram participant SLO as SLO 告警 participant ONCALL as 值班工程师 participant DIAG as 诊断 participant FIX as 修复 participant REVIEW as 复盘 Note over SLO: 燃烧率 > 14.4x<br/>Page 告警触发 SLO->>ONCALL: 通知值班工程师 ONCALL->>DIAG: 查看 SLO 面板<br/>确认错误预算消耗 DIAG->>DIAG: 通过信号关联<br/>定位根因 DIAG->>FIX: 实施修复 FIX->>SLO: 验证 SLO 恢复 FIX->>REVIEW: 48 小时内复盘 REVIEW->>SLO: 更新 SLO/告警规则

6.2 事件响应流程#

阶段时间目标行动产出
响应< 5 分钟确认告警、加入 oncall 频道响应确认
评估< 15 分钟评估影响范围、确认 SLO 违规程度影响评估
缓解< 30 分钟实施缓解措施(回滚/限流/扩容)缓解确认
修复视问题而定修复根因修复确认
复盘48 小时内无指责复盘、更新 SLO/告警复盘报告

6.3 复盘模板#

## 事件复盘
### 基本信息
- 事件时间:YYYY-MM-DD HH:MM - HH:MM
- 影响时长:X 分钟
- SLO 影响:可用性 SLO 从 99.9% 降至 99.X%
- 错误预算消耗:X%
### 时间线
- HH:MM - SLO 告警触发
- HH:MM - 值班工程师响应
- HH:MM - 定位根因
- HH:MM - 实施缓解
- HH:MM - SLO 恢复
### 根因分析
- 直接原因:
- 贡献因素:
- 根本原因:
### 行动项
- [ ] 修复根因(负责人,截止日期)
- [ ] 更新 SLO 告警规则(负责人,截止日期)
- [ ] 增加防御性检测(负责人,截止日期)

七、Grafana SLO 平台#

7.1 Grafana SLO 功能#

Grafana 提供了 SLO 管理界面,支持:

  • SLO 定义和可视化
  • 错误预算追踪
  • 燃烧率告警
  • SLO 报告

7.2 Sloth 工具#

Sloth 是一个 SLO 生成器,将 SLO 定义转换为 Prometheus recording rules 和告警规则:

# 安装 Sloth
go install github.com/slok/sloth/cmd/sloth@latest
# 生成 Prometheus 规则
sloth generate -i slo.yaml -o prometheus-rules.yaml
# 应用规则
kubectl apply -f prometheus-rules.yaml

7.3 Sloth 生成的 Recording Rules#

Sloth 生成的 Recording Rules 大幅简化了 SLO 查询的复杂度:

# Sloth 自动生成的 Recording Rules
groups:
- name: sloth-slo-rules-order-service-availability
rules:
# SLI 当前值
- record: slo:sli_error:ratio_rate5m
expr: |
sum(rate(http_requests_total{service="order-service",status=~"5.."}[5m]))
/
sum(rate(http_requests_total{service="order-service"}[5m]))
# 30 天错误预算剩余
- record: slo:error_budget:remaining
expr: |
1 - (
slo:sli_error:ratio_rate30d
/
(1 - 0.999)
)
# 燃烧率
- record: slo:burn_rate:rate1h
expr: |
slo:sli_error:ratio_rate1h
/
(1 - 0.999)

八、从阈值告警到 SLO 告警#

8.1 迁移路径#

阶段告警类型告警数量误报率
阶段 1纯阈值告警500+90%
阶段 2阈值 + 核心 SLO300+60%
阶段 3SLO 为主 + 少量阈值50+20%
阶段 4纯 SLO 告警20+< 5%

8.2 保留的阈值告警#

即使迁移到 SLO 告警,以下阈值告警仍需保留:

告警原因严重级别
服务不可达SLO 无法度量死掉的服务Page
磁盘满系统级问题Page
证书过期安全问题Ticket
副本数不足可用性风险Ticket

8.3 迁移步骤#

graph LR S1["阶段1<br/>纯阈值告警<br/>500+ 告警"] --> S2["阶段2<br/>+核心SLO<br/>300+ 告警"] S2 --> S3["阶段3<br/>SLO为主<br/>50+ 告警"] S3 --> S4["阶段4<br/>纯SLO告警<br/>20+ 告警"] style S1 fill:#ffcdd2,stroke:#c62828 style S2 fill:#fff3e0,stroke:#e65100 style S3 fill:#e8f5e9,stroke:#2e7d32 style S4 fill:#c8e6c9,stroke:#2e7d32
迁移步骤行动预期效果
1. 选择核心服务挑选 3-5 个核心服务聚焦高价值
2. 定义 SLO为核心服务定义可用性+延迟 SLO建立 SLO 基线
3. 配置 SLO 告警燃烧率告警(Page + Ticket)SLO 告警上线
4. 并行运行SLO 告警和阈值告警并行运行对比效果
5. 逐步移除阈值移除被 SLO 告警覆盖的阈值告警减少告警噪音
6. 扩展到更多服务将 SLO 推广到更多服务全面覆盖

九、动手实践#

9.1 定义 SLO#

# slo.yaml — 订单服务 SLO
spec:
service: order-service
slo:
- name: availability
objective: 99.9
sli:
events:
error_query: sum(rate(http_requests_total{service="order-service",status=~"5.."}[{{.window}}]))
total_query: sum(rate(http_requests_total{service="order-service"}[{{.window}}]))

9.2 生成并应用规则#

# 生成 Prometheus 规则
sloth generate -i slo.yaml -o rules.yaml
# 应用规则
# 将 rules.yaml 添加到 Prometheus 配置

9.3 模拟 SLO 违规#

# 注入错误,模拟 SLO 违规
for i in $(seq 1 100); do
curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/api/v1/error
done
# 观察燃烧率告警是否触发
curl http://localhost:9090/api/v1/alerts

9.4 验证清单#

检查项验证方式预期结果
SLO 指标可查询PromQL 查询返回 SLI 值
错误预算可视化Grafana 面板显示剩余预算
燃烧率告警模拟错误触发告警
多窗口检测持续错误快速/慢速告警分别触发
SLO 仪表盘查看 Dashboard所有面板有数据

十、本章小结#

上一章剖析了信号关联与 Exemplar。 这一章覆盖了SLO 驱动的可观测性的关键设计。

主题核心要点关键词
SLI/SLO/SLASLI 是度量指标,SLO 是目标值,SLA 是商业后果。SLI 必须从用户视角度量,可计算且可行动。SLI/SLO/SLA
错误预算SLO 的反面,是创新的燃料——充裕时可以实验,耗尽时必须专注稳定性。计算要基于实际请求量,低流量服务需要特别关注。错误预算
燃烧率错误预算消耗速度的度量,是 SLO 告警的核心。14.4x 燃烧率意味着 2 天耗尽 30 天预算,需要立即处理。燃烧率
多窗口告警快速燃烧(14.4x, Page)+ 慢速燃烧(6x, Ticket),平衡灵敏度和误报率。两个数字来自数学推导,不是随意选择。多窗口告警
SLO 仪表盘一目了然地回答”SLO 达成了吗?预算还剩多少?燃烧率是多少?“SLO 仪表盘
事件响应SLO 驱动的事件响应流程,48 小时内完成无指责复盘。事件响应
迁移路径从阈值告警渐进式迁移到 SLO 告警,保留少量系统级阈值告警。迁移路径

支持与分享

如果这篇文章对你有帮助,欢迎支持作者或分享给更多人

SLO 驱动的可观测性
https://blog.souloss.com/posts/observability/slo-and-alerting/
作者
Souloss
发布于
2025-10-18
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时