错误预算和SLO管理

1）为什么SLO和错误预算

SLO（服务级别目标）是用户感知的目标质量级别；SLI是可测量的度量；Error Budget-每个窗口的偏差入场（通常为30/90天）。
错误预算将可靠性从"抽象"转换为可管理的资源：当预算迅速燃烧时-冻结菲奇和奇尼姆；当预算正常时-您可以加快发布速度。

2）SLI选择： 什么算是"好"

标准："从用户的角度来看是成功的"。

2.1经典SLI

可用性：成功请求的百分比（不包括客户端取消的请求）。
'success=http_status ∈ {2xx，3xx，404}和没有时间表'（如果是期望的语义，则404可能被认为是读取API的成功）。
Latency：请求的百分比快于阈值（例如p95 ≤ 300 ms）。

`good_latency = duration_ms ≤ 300`.

Freshness/Staleness："数据不超过X分钟"（缓存、目录、系数）。
质量：结果正确（通过业务验证器/后端不变量）。

2.2边界和段

SLI必须从重要的部分中考虑："route"，"tenant/brand"，"region/jurisdiction"，"payment_provider"。因此，您不会"侵蚀"整个系统中单个关键手柄的故障。

3）公式和预算

3.1基于Request（最好用于API）


SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3.2个基于时间的（用于后台服务/流媒体）


SLO_uptime = good_minutes / total_minutes

3.3目标示例

API通用： 99。30天内可用性的9％ →预算=0。1%.

关键支付笔： 99。95%;目录/搜索：99。5%.

潜伏期：p95 ≤ 300毫秒对'/v1/payments'，p99 ≤ 800毫秒。

4）SLI指导

4.1项原则

Logi/Traces →带有显式桶的RED （Rate/Errors/Duration）度量标准。
请务必提供"tenant"、"region"、"route_class"（没有PII）。
考虑两个指标："成功"和"一切"，对于后坐力-"快速"和"一切"。

4.2 Prometheus示例（5m的价格）

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5） Alerta按燃烧率计算（多窗口、多燃烧）

5.1个想法

我们正在研究预算相对于目标的燃烧速度。如果在短窗口和长窗口上速度很高-信号。

5.2阈值配置文件（适用于SLO 99.9%)

分页：burn rate ≥ 14。4 × （1小时预算的10%，6小时预算的5%）。
Tiket：燃烧率≥ 6 ×（6小时2%，24小时1%）。

5.3规则示例（Prometheus，pseudo）

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

同样，tiket在6h/24 h。

6）预算办公室： 程序

6.1个发布门户

如果预算余额为<25％，趋势为负值-fici上的"冻结代码"，则SRE/可持续性的优先级。

金丝雀发行版必须具有单独的SLO剪辑（'部署。environment="canary"`).

6.2 beclog优先级

按燃烧速度和收入影响比例分配团队容量。

用指标证明技术债务是合理的： "fix X将使燃烧率降低Y％。"

6.3事后事件

每个事件都是RCA和"无法回滚的假人"（动作），控制权"是否已返回SLO"。

7） SLO作为代码

7.1 SLO清单（YAML）示例)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7.2规则生成

使用生成器（slo-generator, pyrra, sloth）自动生成规则、行车记录和报告。

8）SLO降解和保护

Load shedder：在高峰时给出没有"昂贵"依赖性的快速答桉。

Cache & stale: `stale-while-revalidate` для read.

Rate/Concurrency限制：保护后端；重要路线是优先级。
电路/时间表：快速时间表和"倒退"分支。
功能闪光灯：一键关闭重型幻灯片。

9） SLO的可观察性

Dashbords：SLO actual vs target，预算余额，burn rate，路线/提供商捐款。
相关：从SLO的"漏洞"→ →特定的跟踪→ 逻辑/profile。
报告：每周-趋势，预算消费，退化的最高原因。

10）反模式

一个"全球"SLO适用于所有→掩盖了问题。分段。
«99.99%全部"不考虑成本和现实。从用户体验中选择目标。
根据CPU/heap代替burn rate/SLO。
忽略破坏UX的4 x/长重复。
不透明窗口（滚动vs日历）-比较"苹果与橙子"。

11） iGaming/财务细节

货币路径（存款/结算）：单独的SLO高于总体水平（例如，99。95%的可用性；p95 ≤ 250毫秒）。
PSP/KYC提供商：每个提供商+Alerta的SLO对燃烧的贡献；自动路由切换（智能路由）。
司法管辖区/特南特：SLO和"区域/司法/品牌"预算，以使本地问题不会"淹没"全球度量标准。
负责任的游戏：SLO应用限制/自我体验（compliance formulation）的时间。
审计/监管：保存SLO和事件报告；内部审计的透明度。

12）准备就绪支票清单

由SLI （可用性/latency/quality/freshness）和路段（route/tenant/region）定义。
目标（SLO）是现实的，与业务一致；有30/90天的滚动窗口。
Alerta的燃烧率与多窗口（分页/滴答声）。
SLO作为代码（规则/dashbord生成器）；预算报告。
释放门与预算余额挂钩；金丝雀切片。
已实施并测试了降解机制（shedder、cache stale、circuit、limits）。
指标↔跟踪的相关性（exemplars）,清晰的运行手册。
财务/司法途径-单独的SLO/Alertes；PSP/KYC分类。
定期复古事件和基于燃烧的可靠性投资。

13) TL;DR

通过用户价值定义SLI,设置逼真的SLO,并通过多窗口通过Error Budget和burn rate进行控制。按计划启用SLO代码、发布门和降级。按路线/特南特/地区细分；对于金钱的路径，保持更严格的目标和单独的差。

错误预算和SLO管理

联系我们

快速联系

视频即将更新

我们目前正忙于各项项目