78 lines
3.4 KiB
Markdown
78 lines
3.4 KiB
Markdown
|
---
|
|||
|
|
tags: [sre, slo, sli, sla, service-level]
|
|||
|
|
create time: 2026-05-18 00:50
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# SLI / SLO / SLA 详解 — 可靠性量化基础
|
|||
|
|
|
|||
|
|
## 概述
|
|||
|
|
|
|||
|
|
站点可靠性工程 (SRE) 把运维问题看作**软件工程问题**。它的核心理念是用 SLI/SLO/SLA 来量化服务质量，避免"我觉得系统很慢"这类模糊描述。本文将详细拆解三层模型和实际应用方法。
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
flowchart LR
|
|||
|
|
User["用户体验"] --> SLI{"实际测量"}
|
|||
|
|
SLI -->|"达标"| SLO_OK["✅ SLO 达成"]
|
|||
|
|
SLI -->|"不达标"| Budget["消耗错误预算"]
|
|||
|
|
|
|||
|
|
Budget --> Left{"预算剩余?"}
|
|||
|
|
Left -- "> 50%" --> Ship["快速迭代 🚀"]
|
|||
|
|
Left -- "< 10%" --> Stabilize["稳定优先 ❄️"]
|
|||
|
|
|
|||
|
|
style User fill:#e3f2fd
|
|||
|
|
style SLO_OK fill:#e8f5e9
|
|||
|
|
style Ship fill:#fff3e0
|
|||
|
|
style Stabilize fill:#ffebee
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## SLI / SLO / SLA 三层模型
|
|||
|
|
|
|||
|
|
| 术语 | 全称 | 定义 | 谁制定 | 变更频率 |
|
|||
|
|
|------|------|------|--------|---------|
|
|||
|
|
| **SLI** | Service Level Indicator | 实际度量：用户请求的成功率是多少？ | 观测系统自动产出 | 持续更新 |
|
|||
|
|
| **SLO** | Service Level Objective | 内部目标：我们承诺达到 99.9% 可用性 | SRE + 研发 | 季度回顾 |
|
|||
|
|
| **SLA** | Service Level Agreement | 对外契约：达不到就赔钱 | 法务 + 商务 | 按合同约定 |
|
|||
|
|
|
|||
|
|
> [!question] 三者有什么区别？
|
|||
|
|
>
|
|||
|
|
> - **SLI** = 仪表盘上的真实数字（"今天成功率 99.87%"）
|
|||
|
|
> - **SLO** = 内部团队的目标线（"我们要 ≥ 99.9%"）
|
|||
|
|
> - **SLA** = 给客户的承诺条款（"达不到赔偿 10% 月费"）
|
|||
|
|
>
|
|||
|
|
> SLI < SLO → 团队内部关注；SLI < SLA → 客户开始投诉。
|
|||
|
|
|
|||
|
|
### 实用的类比
|
|||
|
|
|
|||
|
|
| 层级 | 生活类比 | 技术场景 |
|
|||
|
|
|------|---------|---------|
|
|||
|
|
| SLI | "我体重秤显示 72kg" | Prometheus 返回的 P99 延迟 230ms |
|
|||
|
|
| SLO | "我要保持 70kg 以下" | 研发团队内部追求 P99 < 200ms |
|
|||
|
|
| SLA | "健身合约：每周少于 3 次到店扣费" | 对客户提供 99.9% 可用性，否则退款 |
|
|||
|
|
|
|||
|
|
## 实用性比例对照表
|
|||
|
|
|
|||
|
|
| SLO | 每年停机时间 | 每月停机时间 | 适用级别 |
|
|||
|
|
|-----|-------------|-------------|---------|
|
|||
|
|
| **99%** | ~87.6 小时 | ~7.2 小时 | 内部工具（几乎无意义） |
|
|||
|
|
| **99.9% ("三个九")** | ~8.76 小时 | ~43 分钟 | 大多数后端服务 ✅ |
|
|||
|
|
| **99.95%** | ~4.38 小时 | ~21 分钟 | 核心交易链路 |
|
|||
|
|
| **99.99% ("四个九")** | ~52.6 分钟 | ~4.3 分钟 | 金融级 / 支付系统 |
|
|||
|
|
| **99.999%** | ~5.26 分钟 | ~26 秒 | 电信级，极难实现 |
|
|||
|
|
|
|||
|
|
> [!warning] "三个九"是底线
|
|||
|
|
>
|
|||
|
|
> 如果团队宣称 SLO = 99%，这意味着每月可以容忍近 **7 小时的不可用**——这在生产环境中基本等于没有可用性目标。
|
|||
|
|
|
|||
|
|
## 补充：如何为你的服务设定合适的 SLO
|
|||
|
|
|
|||
|
|
1. **从用户视角出发** — 不是"API P99 < 200ms"，而是"用户在正常网络下加载页面 < 2s"
|
|||
|
|
2. **参考行业标准** — 内部工具 99.9%，用户-facing 服务 99.95%+
|
|||
|
|
3. **考虑成本收益** — 从 99.9% 到 99.99% 可能需要 5~10 倍的基础设施投入
|
|||
|
|
4. **先设定保守目标再逐步提升** — 一个达不到的 SLO 比没有 SLO 更有害（团队会习惯打破它）
|
|||
|
|
5. **绑定到具体指标** — 每个 SLO 必须有对应的 SLI 自动采集数据支撑
|
|||
|
|
|
|||
|
|
## 关联笔记
|
|||
|
|
|
|||
|
|
- [[../02-错误预算深度解析]] — Error Budget 的计算与应用
|
|||
|
|
- [[../hhs/MS/05-部署运维/04-SRE实践]] — SRE 总体概览
|