all-in-kingsoft/hhs/MS/05-部署运维/04-SRE实践/01-SLI-SLO-SLA详解.md

tags, create time

tags	create time
sre slo sli sla service-level	2026-05-18 00:50

SLI / SLO / SLA 详解 — 可靠性量化基础

概述

站点可靠性工程 (SRE) 把运维问题看作软件工程问题。它的核心理念是用 SLI/SLO/SLA 来量化服务质量，避免"我觉得系统很慢"这类模糊描述。本文将详细拆解三层模型和实际应用方法。

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 总体概览