SLA、SLO和KPI可靠性

1）术语和区别

SLI（服务级别指标）-可测量的质量指标（例如,成功查询的比例,p95潜伏期）。
SLO（服务级别目标）是每个时间窗口（例如"成功≥ 99的目标SLI值。在28天内达到9%"）。
预算错误（Error Budget）-SLO未完成的比例允许：'1 − SLO'。
SLA（服务级别协议）是带有罚款/贷款（外部）的合同义务。
可靠性KPI-操作过程度量（MTTD/MTTA/MTTR/MTBF，％的自动联网，过滤涂层等）。

2）如何选择SLI（基于Golden Signals）

1.Latency是用于关键尾矿的p95/p99。
2.Traffic-RPS/RPM/消息流。
3.Errors是5xx/业务错误的份额（例如，不包括PSP过失的支付"决定"）。
4.饱和度-资源饱和度（CPU/RAM/IO/lag）。

• 与用户体验（user-perceived）相关。
• 技术上可用且测量稳定。
• 我们控制（可能的改进行动）。
• 收集成本低。

3）公式和示例

3.1个可用性（可用性）

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

示例：SLO 99。30天内9% →预算错误=0。1％，相当于43分钟12秒。

3.2潜伏期

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3.3付款（业务级别）

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4）有缺陷的预算和burn-rate

预算错误-用于创新的燃油箱（发布、实验）。

• 快速通道（1小时~的探测器），
• 慢频道（~ 6-12小时/24小时的趋势）。

• 如果burn-rate> 14。1小时4-SEV-1（让我们吃一天的预算~ 100分钟）。
• 如果burn-rate> 6在6小时内为SEV-2（快速降解）。

5）通过SLO进行处理（多窗口，多燃烧）

错误指示器：5xx或潜伏期违规的比例。

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6）跨域的SLI/SLO示例

6.1个API网关/边缘

SLI-Errors： 5xx <0的响应比例。1% (28d).

SLI-Latency：p95 ≤ 250毫秒（每天）。
SLO: Availability ≥ 99.95%（季度）。

6.2付款

SLI-Cuccess： 成功付款（不包括客户豁免）≥ 99。8% (28d).

SLI-Latency： 99%（一天）的授权≤ 2秒。

SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6.3个数据库（PostgreSQL）

SLI-Lag：p95 ≤ 1秒（每天）复制差。

SLI错误： 查询错误百分比≤ 0。05% (28d).

SLO： 群集可用性≥ 99。95%.

6.4队列/流媒体（Kafka）

SLI-Lag：p95 ≤ N消息的消费者脱落（小时）。

SLI-Durability： 确认记录≥ 99。99% (28d).

SLO： 经纪人的可用性≥ 99。9%.

7）可靠性过程的KPI

MTTD (Mean Time To Detect)

MTTA (…To Acknowledge)

MTTR (…To Restore)

MTBF (…Between Failures)

自动联想事件的百分比

SLO覆盖顶部交通路径（目标≥ 95%）

拥有金丝雀舞台的发行比例

使用错误的命令/犯规预算

8）如何现实地设置SLO

1.测量当前基本可靠性（3-4周）。
2.定义"敏感"用户路径（登录、存款、游戏）。
3.考虑每个偏差的成本（时间，金钱，声誉）。
4.选择一个雄心勃勃但可实现的目标（比基本目标提高10-30%）。
5.每季度审查一次。

• 立刻"五九"没有理由。
• 通过用户无法看到的度量标准（例如，与UX无关的CPU）进行SLO。
• 太多的SLO →喷涂焦点。

9） SLO和预算报告

• 每个SLO的执行：事实vs目标，趋势，confidence。
• 错误消耗摘要：多少预算"烧毁"比谁,（发布/事件）。
• 退化的五大原因，CAPA计划和任务状态。
• 业务影响：转换,ND,保留,LTV.

10）与发布政策的关系

错误预算<50% →免费版本。
50-80％→"谨慎模式"：只有低风险/金丝雀布局。

11） SLA（合同）-项目模板

负担能力义务：例如99。9%/月。
例外（Force Majeure）：DDoS在合理控制之外，第三方提供商。

测量窗口和责任区： 指标来源,计算方法.

学分/罚款：等级表（例如，60-120分钟不可用→ X%学分）。
上报和通知程序：时间表、渠道。

数据和隐私： 掩蔽,存储,法律保留.

重复预防工作计划（CAPA）在发生违规时。

12）测量工具

被动指标：Prometheus/Mimir/Thanos，出口商。
Logi： Loki/ELK用于计算业务层面的成功/错误。
合成：cron上的活性样品（登录/存款/游戏）。
跟踪：Tempo/Jaeger for"瓶颈"p99。
付款/财务：支付SLI的地面真相来源。

13）查询示例（模板）

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

14） FinOps和可靠性

最多9：添加"九"的成本呈指数增长。
收益曲线：收入增长/损失减少≥额外"9"成本的最佳状态。
SLO组合：不同路径的不同级别（关键支付"更昂贵"，报告"更便宜"）。

15）SLO/Alerts质量-支票清单

• SLI与UX和业务指标相关。
• 窗口和聚合是一致的（滚动28 d/季度）。
• Alerta多窗口,无翻转,具有角色扮演路由。
• 文件：所有者，公式，来源，运行簿。
• SLO演示面板具有错误的预算和燃烧指标。
• 定期审查目标（季度）。
• 针对关键场景的合成测试。

16）实施计划（4次迭代）

1.第一周：用户路径清单，SLI草案，基本行车记录。
2.第2周：SLO正式化，预算计算，Alerta（快速/慢烧伤）。
3.第3周：与事件/发布过程集成，freeze规则。
4.第4周+：合同SLA，季度咆哮，"每人每人9"的泡沫模型。

17）迷你常见问题

每项服务是否需要一个SLO？
优于2-3键（成功+潜在）而不是数十个次要。

如果预算用尽，该怎么办？
冻结发布，专注于稳定和CAPA，消除实验性幻想。

如何避免发布速度与可靠性之间的冲突?

计划"按预算"发布,实施金丝雀布局和功能横幅。

结果

可靠性不是由一组不同的指标驱动，而是由系统驱动：SLI → SLO →预算错误→燃烧→事件过程→ CAPA → SLA。标准化定义、数据源和报告,将目标带入用户体验和经济,并根据实际的ROI定期审查"九"级别。