SLO/SLA和指标

1）术语和层次结构

SLI（服务级别指标）-可衡量的指标"用户如何看待我们"：成功查询的比例，p95潜伏率，数据新鲜度，成功处理的战斗的比例等。

SLO（服务级别目标）是监视间隔（28/30/90天）上的SLI目标值。示例： "99。9%的请求/付款在400毫秒≤完成。"

Error budget — 1 − SLO.在SLO 99下。9％的错误预算=0。1%的时间/请求。
SLA（协议）-具有法律意义的服务级别：包括SLO，测量，例外，赔偿/罚款。

2）设计原则

症状>内部指标。SLI必须反映真实的用户体验。
少量关键SLI。每项服务有2-5项主要服务：成功，潜伏期，吞吐量/新鲜度，正确性。
覆盖关键路径。对于每个业务脚本（checkout、login、webhook、ETL下载）,均为自己的SLI/SLO集。
严格的"成功"语义。不是"代码200"，而是"用户按时收到响应，结果验证"。
外部SLO和内部SLO的分离。内部-严格；外部SLA ≤在下面的1-2 9。

3） SLI目录（参考）

3.1个API/在线服务

成功： 'SLI_success=1 −（5xx+timeout+business_error）/all_requests'

潜伏期： p95/p99 'http_server_duration_seconds'沿路由/方法/租户

吞吐量： "RPS"/限制/配额

正确性： 有效响应的比例（签名、电路、不变量）

3.2 Webhooks/异步交付

交付： T秒和 N ≤中确认的事件百分比

客户： 订户比例无长时间延误（主订户）

3.3 数据/ETL/DWH

新鲜（freshness）： 'now − last_successful_ingest_ts'

完整性： 'ingested_rows/ expected_rows'

正确性： 经过质量检查的记录比例

Piplines： 截止日期前完成的乔布斯比例

3.4移动/客户端SDK

客户成功： 会议比例无致命错误

round-trip潜伏期： p95从查询到渲染

快取热门： 快取服务的比例（作为表现症状）

4）公式和目标示例

可用性（按请求）：

`SLI_req_avail = 1 − (failed_requests / total_requests)`
`SLO_req_avail = 99.95%在30天内→ error budget=0。50%的请求。

可用性（按时间）：

`uptime = (obs_window − downtime) / obs_window`

潜伏期：

"SLO_latency=p95 （route="/pay"） ≤ 400 ms在7天的切片中，缓存预热除外（1%）

数据更新：

"SLO_freshness（dataset="orders"）在24小时内≤ 10 min'p99。

5）错误预算和变更管理

预算（B）："B=1 − SLO"。
预算支出（burn）：实际错误与允许的比率。

政客：

超支（burn> 1） → fichfries,专注于可靠性。
在burn rate> X中,在短窗口中是事件和引脚。措施。
计划：冲刺对可靠性的比例与过去的燃烧有关。

6） Alerting： 燃烧率和多窗口规则

想法：捕捉快速泄漏和缓慢漂移。

示例（SLO 99。9％，预算0。1%):

关键："1小时预算的2%"（快速火灾）。
警告："6小时预算的5%"（爬行退化）。

规则：

快速事件的短窗口（一分钟至一小时）。
趋势的长窗口（6-24小时）。
潜伏期：p99>阈值≥5分钟，带有悬浮抑制以及与步道外胚层的关系。

表达式示例（逻辑）：


error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7）多范围（multi-tenant）和细分

SLI/SLO按租户/计划/地区计算，否则中位数将"吸引"失败。
统计意义的最小事件数（guard-rails）。

SLA的票价可能会有所不同（例如"Pro 99。9%, Free 99.5%»).

8）与可观察性和跟踪的关系

SLI度量标准是从直方图/计数器到exemplars →过渡到"不良"轨迹。
Logi是原因的来源：时间限制，业务错误代码，限制。

对于数据-链接到线程： "哪个乔巴延迟了新鲜度量。"

9）合同和SLA

SLA的内容：

SLI/测量方法/窗口定义。
例外（计划工作，不可抗力）。
事件和通信程序（状态页面，RFO/RCA）。
赔偿（服务信贷）和请求顺序。
管辖权，有效期，审查条件。

建议：

永远不要公开承诺SLO比架构和操作实践所允许的更严格。
分离内部SLO和外部SLA。

10）成本和优先级

九个的价格没有线性增长。«99.9% → 99.99％"=不同的体系结构类别（N+1，multizon，资产-资产）。
将SLO置于最有价值的用户操作上。
控制遥测的成本：按类分解、配额、复制副本和存储。

11）程序和报告

每周报告：按服务/租户执行SLO，预算支出，最高原因，改进计划。
发育后的RCA：与预算相关联；我们的任务是解决根本原因。
Fichfries：包含/删除标准。

12）模板（快速启动）

12.1 SLO卡（示例）


Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12.2 "SLO成熟度"表"

级别	特点
0	没有SLI，CPU/Memory上的变量
1	有SLI，简单的阈值
2	SLO与burn-rate alerts,报告
3	多Arand SLO、Fichfries、Capversion按计划
4	端到端SLO （kliyent→bekend→dannyye）、自动还原、金丝雀SLO

13）规则示例（片段）

PromQL-成功/错误/潜在性：

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

Alerta burn-rate（规则的想法）：

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

数据更新：

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14）数据和ML SLO（功能）

端到端数据SLO： p99的新鲜度、p99的完整性、故障发生后的"重新设计"时间。
数据合同：预期的方案，数量，截止日期；违反→数据事件。
ML：地狱潜伏期的SLO，相机可用性的SLA，漂移监测（模型质量是一个单独的主题，在SLA之外）。

15）与安全和隐私的整合

没有PII/秘密的 SLI标志；令牌/掩码。
审核未更改日志中的SLO/SLA更改和报告出版物。
对于监管途径（付款/PII），是单独的，更严格的SLO。

16）支票单

启动服务/fichi之前

SLI定义为"成功/潜在/吞吐量/新鲜度"。
设置了SLO和窗口；计算出错误预算。
设置了burn-rate alerta（短+长）。
RED+exemplars →轨道；Runibook事件。
多方切口和重要性阈值。
fichfriz和报告程序。

运营

SLO/burn的每周报告，强硬计划。
在体系结构/负载更改时重新评估SLO。
偶尔的"事件演习"和更新runibook。
控制遥测成本和SLI数量。

17) Runbook’и

Runbook： 快速增长p99/pay

1.Alert r 99>阈值→打开行车记录板→通过exemplar进入步道。
2.查找狭窄的CLIENT/SERVER-span并比较区域/版本。
3.启用降级（缓存/限制/后退）,通知依赖命令。
4.稳定后-RCA，优化问题，SLO测量更新。

Runbook： 每周预算支出>50%

1.冷冻菲奇，提高可靠性的优先级。
2.错误集群：路线/租户/依存关系。
3.推出修复程序→确认趋势恢复。
4.回顾和调整标量/阈值。

18) FAQ

Q：需要多少个SLO?

答：关键用户场景的最低限度：成功+潜伏。其他一切-根据需要。

Q：什么是最好的-按时间或按请求提供?

答：根据请求,是更定制的指标。对于网络组件/infra，时间方便。

问：为什么p95而不是平均水平？
答：中间隐藏尾巴；用户感觉到p95/p99。

问：怎么不把螺母扭得太厉害？
答：从现实的目标（历史数据）开始，然后随着成熟而收紧。

SLO/SLA和指标

SLO/SLA和指标

运营

联系我们

快速联系

视频即将更新

我们目前正忙于各项项目