SLI、SLO与SLA三层指标体系设计

可视化演示

三步展示服务可靠性三层指标体系：SLI/SLO/SLA从度量到承诺的分层关系、SLI核心指标选取、以及SLO目标设定与SLA约束机制。

三层定义关系

想象你是“云朵奶茶”的店长：电子屏、看板、外卖合同，这三样东西挂在店里不同的墙上，却都在回答同一个问题——“我们的服务到底靠不靠谱”。电子屏回答“现在实际表现如何”，看板回答“我们自己要求多高”，合同回答“对顾客承诺多少”。分开来看，它们是三件事；合起来看，它们是一条可靠性管理的流水线。

技术世界里，这套流水线的三个工位分别叫 SLI（Service Level Indicator，服务等级指标）、SLO（Service Level Objective，服务等级目标）、SLA（Service Level Agreement，服务等级协议）。SLI 是把服务质量翻译成数字的“尺子”；SLO 是团队内部对自己下达的“军令状”；SLA 是对外签署、违约要赔钱的“法律文书”。三者层层递进：先有 SLI 的可靠度量，才有 SLO 的合理目标；有了稳定的 SLO 表现，才敢把它包装成 SLA 承诺。

实践中，SLA 几乎总是比 SLO 更保守。内部目标可以定得激进，合同承诺却要留足缓冲，否则一次随机抖动就可能触发大面积赔偿。这就像奶茶店敢在看板上写“95% 准时”，但只敢在平台上承诺“90% 准时，超出赔券”——多出来的 5% 是给自己留的容错空间，不是给顾客的承诺。

有了这三层各司其职的“分工”，奶茶店不再凭感觉做生意：顾客看得见的是 SLA，店长日常盯的是 SLO，工程师日夜优化的是 SLI。而许多系统事故的根源，恰恰是这三者被混为一谈。

SLI指标选取

顾客不会关心你店里用了什么牌子的珍珠，他只在意外卖 App 上那行字：“预计 30 分钟送达。”所以选指标的第一步，是蹲在用户视角问自己：用户真正感受到的“好”是什么？对奶茶店来说是“按时送到”；对在线支付是“转账成功”；对视频网站是“点开就能播”。

SLI 常见的四类黄金指标包括：可用性、时延、吞吐量、错误率。它们就像奶茶店的四个仪表盘——“能不能接单、送得多快、一小时出多少杯、做错了几单”。其中可用性最常用，定义为“成功请求数占有效请求数的比例”。注意“有效”二字：爬虫、监控探针、压测流量都不算真实用户请求，混进分母会把指标搅浑。这就像店里统计准时率时，得把刷单的水军订单剔除，否则数据毫无意义。

此外还要选好聚合窗口：窗口太短，指标像心电图一样毛刺横飞；窗口太长，又像钝刀切肉，故障发生半天都看不出来。业界常用“最近 N 个请求”或“固定时间窗”两种方式聚合，奶茶店的电子屏展示的是“最近 100 单的准时率”，这就是一个典型的滑动窗口。

把“30 分钟内送达”定义成好事件后，店长扫一眼屏幕就知道“今天每 100 单有几单踩线”。SLI 的哲学浓缩成一句话：先答对“量什么”，才有资格谈“怎么管”。指标选错了，后面所有目标与合同都是空中楼阁。

SLO目标设定

SLO 就像健身教练给你定的训练量：定太高，练伤自己；定太低，练了等于没练。奶茶店这个月的目标是 95% 准时送达——这个数字不是拍脑袋拍的，而是看了上季度的数据：历史 P95 送达时间是 29 分钟，P99 是 34 分钟，所以 30 分钟/95% 是个“跳一跳够得着”的目标。

SLO 由“目标值 + 统计周期”组成，比如“30 天内 99.9% 可用”。真正让 SLO 变好用的，是它派生出的错误预算（Error Budget）概念：既然 SLO 允许一定的失败比例，那么把失败比例换算成时间，就得到“这个月可以犯错多久”的预算。预算花完了，团队这个周期就不能再发布新功能，必须回头修复可靠性。

错误预算的核心公式很简单：允许失败比例 × 周期总时长。以月度 99.9% 可用性为例，一个月 43200 分钟，只允许挂掉 43.2 分钟。这 43 分钟就像奶茶店每月的“超时额度”：雨季多用一点，旺季前就少做冒险的促销活动。消耗速度快不快，则由燃烧率来刻画——它等于实际错误率除以允许错误率，将在监控告警一节重点展开。

错误预算给了团队“错的空间”——这是 SLO 体系最温柔也最强大之处：它不要求 100% 完美，而是把“出错的额度”明码标价，让团队在创新与稳定之间做出理性取舍。就像奶茶店的超时额度，花在刀刃上是成长，花在刀背上才是事故。

SLA条款设计

店长在平台挂的是“超时赔 5 元券”，而不是“超时赔 100 元”——因为刮风下雨总有意外，承诺一旦写成合同，就得有兜底。SLA 条款设计的本质，就是回答三个问题：承诺什么？违约怎么赔？什么情况不赔？

SLA（Service Level Agreement，服务等级协议）的条款通常包含四大要件：服务范围（承诺覆盖哪些功能）、指标基线（承诺达到的数值，如“月度可用性 99.5%”）、补偿机制（未达标时按比例折扣或赔偿）、例外条款（不可抗力、用户侧故障、计划内维护等免责情形）。大型云厂商还会做分级服务管理：标准版承诺 99.5%，企业版承诺 99.95%，价格相差数倍，合同条款也相应更严格。

设计条款最常犯的错，是把 SLO 直接抄进 SLA。内部目标 99.9% 看着漂亮，但随机波动、故障演练、计划内变更都可能踩线，一旦写进合同就成了“天天赔钱的自杀条款”。正确的做法是留出安全缓冲：SLO 99.9%，SLA 写 99.5%——相当于奶茶店对外只承诺“90% 准时”，实际内部却要求“95% 准时”，多出来的 5% 就是缓冲。

SLA 是一张“防护网”：SLO 是内部的自我要求，SLA 是外部的法律责任。奶茶店可以少赚一点（发券），但绝不能让合同变成天天赔钱的“死亡条款”。记住，合同里最值钱的一句话，往往是“以下情况不适用本承诺”。

监控告警配置

不能等顾客打电话投诉“怎么还没到”才行动。监控的价值在于“提前看趋势”：这一小时超时率在飙升，就该立刻加人手。SRE 监控 SLO 的核心工具是燃烧率——它回答“错误预算正在以多快的速度被消耗”。

燃烧率 = 实际错误率 ÷ 允许错误率。B=1 表示消耗速度刚好等于预算允许的速度；B>1 表示在加速透支预算，必须告警。谷歌 SRE 推荐的“多窗口多燃烧率”策略非常实用：短窗口（5 分钟/1 小时）捕捉瞬断型故障——比如机房突然断电；长窗口（6 小时/3 天）捕捉慢性恶化——比如磁盘性能缓慢下降。两种故障形态，需要两种时间尺度的“眼睛”。

告警还要分级路由：紧急告警直接触发电话响应，一般告警进工单系统，信息级通知合并到日报，避免“告警风暴”淹没真正的危险信号。同时，监控数据应自动汇成可靠性周报/月报，无需人工拼 Excel。这就像奶茶店的大屏不但显示“今日超时率”，还显示“按这个速度，本月预算还能撑几天”，让店长每天早上扫一眼就有数。

告警不是事后骂人，而是提前叫醒。多窗口燃烧率就像奶茶店的“雨天预案”：突然的暴雨（短窗口）和逐渐变慢的骑手（长窗口）都会触发不同级别的应对措施，而不是等到顾客差评满天飞才反应过来。

评审流程设计

每季度末，店长会翻出三个数字：承诺的 95%、实际的送达率、赔出去的券。然后灵魂三问：目标定得合不合理？流程哪里要改？下季度要不要调整？这套“数据驱动的季度复盘”，就是 SLO 评审流程。

评审的第一步是定期回顾：SLI 分布是否健康、错误预算消耗集中在哪些时段、是否有系统性瓶颈。第二步是变更影响评估：任何新功能、架构调整、促销活动上线前，都要评估它可能消耗多少错误预算。第三步是多方协商对齐：业务方要增长、研发要交付、运维要稳定，三方坐到一起，用数据说话，而不是比嗓门。最后是流程沉淀：把评审结论写进 Runbook，让下一季度的执行有章可循。

变更影响评估常用一个朴素的风险矩阵公式：风险 = 影响范围 × 发生概率。核心链路改动影响范围大（评分高），小概率但可能拖垮系统的变更要重点拦截。错误预算已接近耗尽时，高风险变更直接暂缓——就像预算见底的奶茶店，不会再接 500 人的团购大单。

评审不是开会走形式，而是把三层指标体系“拧成闭环”的最后一颗螺丝：度量（SLI）、目标（SLO）、合同（SLA）、监控（燃烧率）、评审（流程优化）——每一环都在为下一环提供输入。奶茶店正是靠着这个季度循环，才敢在第二季度把目标从 95% 提到 96%，因为它知道这个数字有数据撑腰。

AI 应用场景

Python 演示

import randomfrom collections import deque  class BubbleTeaShop:    """奶茶店三层指标体系模拟器"""     def __init__(self, slo_limit=30, slo_target=0.95, sla_target=0.90):        self.slo_limit = slo_limit        self.slo_target = slo_target        self.sla_target = sla_target        self.window = deque(maxlen=200)     def new_order(self):        minutes = random.gauss(26, 6)        if random.random() < 0.10:            minutes += 12        minutes = max(15, minutes)        self.window.append(minutes)        return minutes     def current_sli(self):        if not self.window:            return 1.0        ok = sum(1 for m in self.window if m <= self.slo_limit)        return ok / len(self.window)     def burn_rate(self):        actual_err = 1 - self.current_sli()        allowed_err = 1 - self.slo_target        return actual_err / allowed_err if allowed_err else 0.0     def report(self):        sli = self.current_sli() * 100        burn = self.burn_rate()        if sli < self.sla_target * 100:            status = "SLA breach risk"        elif sli < self.slo_target * 100:            status = "SLO alert"        else:            status = "healthy"        return "SLI={:.2f}% SLO={:.0f}% SLA={:.0f}% burn_rate={:.2f} status={}".format(            sli, self.slo_target * 100, self.sla_target * 100, burn, status)  shop = BubbleTeaShop()for _ in range(150):    shop.new_order()print(shop.report())

1. self.window = deque(maxlen=200)用双向队列做滑动窗口，只保留最近 200 单，模拟“最近 N 个请求”的聚合方式。
2. minutes = random.gauss(26, 6)送达时间围绕 26 分钟正态分布，模拟日常波动。
3. if random.random() < 0.10: minutes += 1210% 概率追加 12 分钟，模拟暴雨、爆单等突发状况。
4. ok = sum(1 for m in self.window if m <= self.slo_limit)SLI 分子：统计窗口内“好事件”（30 分钟内送达）的数量。
5. return ok / len(self.window)SLI = 好事件 / 有效事件，即当前滑动窗口的准时率。
6. allowed_err = 1 - self.slo_target允许错误率 = 1 − SLO，这是错误预算的比例口径。
7. return actual_err / allowed_err燃烧率 = 实际错误率 ÷ 允许错误率，数值越离 1 越远越危险。
8. if sli < self.sla_target * 100:先判断是否跌破 SLA 合同线（最严重），再判断是否跌破 SLO 内部线。

常见误区

面试题