SLO/SLI/SLA体系：把可靠性承诺变成工程预算

可视化演示

展示SLI、SLO、SLA三层可靠性体系，错误预算的消耗与分配机制，以及燃尽率监控告警与超支判断。

三层体系总览

你是一名信奉“科学健身”的工程师。手腕上的手环每天记录静息心率、睡眠深度、步数，体脂秤每周给出体脂率和肌肉量。这些数字本身不会让你变强壮，但它们是所有训练计划的起点——没有它们，“今天状态不错”只是一句感觉。在服务可靠性领域，这些原始数字就是 SLI（Service Level Indicator，服务水平指标），它是整座大厦的地基。

有了数字，你得给自己定目标：每周跑 3 次、每次 30 分钟、心率保持 130-150。这个目标只约束你自己，叫 SLO（Service Level Objective，服务水平目标）。而年初你对家人承诺的“5 公里赛完赛否则包一年奶茶”，是带有外部后果的契约，叫 SLA（Service Level Agreement，服务水平协议）。SRE 体系的精髓，就是把“感觉挺稳”翻译成这三层结构。

三层各有分工：SLI 是度量层，回答“我们测什么”；SLO 是目标层，回答“我们希望达到多少”；SLA 是契约层，回答“我们对外担保多少”。一个重要的工程原则是：SLA 的数值必须比 SLO 更宽松。比如内部 SLO 定 99.95%，对外 SLA 只承诺 99.9%，中间的 0.05% 是给意外留的缓冲垫，避免内部一次小失误就直接触发外部赔偿。

这就像你对外只承诺“35 分钟跑完 5 公里”，但训练时按“30 分钟完赛”准备。真到了比赛日，就算脚踝有点小伤、天气闷热，你也大概率能守住对家人的承诺——因为你的真实能力线，永远比对外承诺高出一截。

SLI指标选择

健身新手最容易犯的错是什么都记：体重、BMI、体脂率、臂围、腿围、最大摄氧量……记了两个月，哪个也没坚持下来。真正有效的做法，是围绕目标选 1-2 个强相关指标：想减脂就盯腰围和体脂率，想提升心肺就盯静息心率和配速。

选 SLI 也是同样的道理。一台微服务每秒吐出成千上万个观测信号：CPU、内存、QPS、错误数、延迟、GC 次数、连接池占用……但并不是每个信号都配当 SLI。SLI 必须是“用户能感知、业务能对齐”的指标——CPU 飙升但接口响应正常，用户毫无感觉，它就不该进入 SLO 的考核范围。

最经典的 SLI 是两类：比例型与分位型。比例型的代表是可用性，即成功请求占总请求的比例；分位型的代表是延迟，如 P99 延迟小于 200 毫秒，描述长尾体验而非平均体验。选择的原则有三条：与用户体验强相关、可精确采集、数量少而精——一个核心服务通常 3 到 5 个 SLI 足够。

就像健身房里真正的高手不会拿 20 个指标轰炸自己，而是盯住“静息心率”和“腰围”两个关键数字。服务的 SLI 也应该是这样一个“精简仪表盘”：成功率和 P99 延迟，往往比一整面墙的监控大屏更能说明问题。

SLO目标设定

设定健身目标不能拍脑袋。你上周只能连续跑 3 公里，这周定 3.5 公里是合理挑战；直接定 10 公里，大概率是第一天就把腿拉伤，然后整个计划报废。好的目标，是“踮踮脚能够到”的水平。

SLO 的设定同理。它不是一个拿来炫耀的数字，而是一个“基于证据”的工程决策。团队通常回看过去 3-6 个月的 SLI 数据，找出系统在正常情况下的稳定水平，再在这个水平上留出余量，而不是凭空喊一个 99.999%。

具体做法上，可以取历史 SLI 的分位数作为候选目标。比如过去半年可用性的 P90 是 99.95%，那就把 SLO 定在 99.9% 或 99.95% 之间。这里有个硬约束必须明白：每多一个"9"，错误预算就缩小一个量级，而实现和维护成本近乎翻倍。99.9% 允许每月故障 43 分钟，99.99% 只有 4.3 分钟——后者对发布、变更、容灾的要求都苛刻得多。

目标定得越狠，你的“偷懒额度”就越少。一个月只能偷懒 4 分钟，意味着几乎每天都不能出错；而 43 分钟的额度，好歹允许你偶尔熬夜看场球。SLO 不是在比谁的数字漂亮，而是在为团队争取“可持续的喘息空间”。

错误预算机制

你给自己定了“每周跑 4 次”的目标。但生活总有意外：出差、加班、暴雨、感冒。所以你在心里设了一个“偷懒额度”：一个月最多允许 3 次不跑。额度用完，剩下的日子哪怕下雨也要在家练核心。这个偷懒额度，就是服务界的“错误预算”（Error Budget）。

错误预算的概念简单到让人怀疑：它是 1 减去 SLO。SLO 是 99.9%，错误预算就是 0.1% 的时间——一个月 43.2 分钟。整个窗口期内，所有故障、发布事故、性能劣化造成的不可用时间，都得从这 43.2 分钟里扣。

关键在“消耗”二字。系统每天都在消耗预算：某天可用性 99.98%，说明当天消耗了 0.02% 的预算；一次 20 分钟的 P0 故障，直接烧掉接近一半。因此团队必须持续追踪两个量：剩余预算（存量）和消耗速率（流量）。如果月初就烧掉了 40 分钟，月底几乎必然破线——这时候 SLO 已经名存实亡。

偷懒额度本质上是风险管理的仪表盘。它不评判“熬夜看球”是对是错，只是冷冰冰地告诉你：额度还剩多少，还能不能浪。服务也一样——错误预算不阻止你发布，但它会诚实记录每一次冒险的代价。

预算驱动决策

当偷懒额度只剩一次时，你的行为会自动改变：推掉晚上的火锅局，取消下周的爬山计划，把时间留给必要的训练。额度余额，成了你安排生活的“总开关”。

错误预算的最大价值，不是“算出来看”，而是“驱动决策”。它把可靠性从一句口号变成一把客观标尺，让发布、救火、扩容这些日常动作都有了统一的依据。

最典型的是三个场景。一是发布门禁：CI/CD 流水线在发布前查询剩余预算，若预算不足或已耗尽，自动拦截版本上线，防止在脆弱的系统上再叠加变更风险。二是故障优先级：多个告警同时爆发时，不再“谁叫得响先救谁”，而是按预算消耗速率排序，优先处理即将击穿 SLO 的故障。三是容量规划：大促前通过压测估算活动会消耗多少预算，反推需要预留多少冗余容量，让“加多少机器”有了数学依据。

这就像游戏里的体力条：体力充足，你可以放心推图、挑战 BOSS；体力见底，系统自动切到“挂机回血”模式。错误预算驱动的服务，也拥有了这样的“体力值”——它让整个团队在同一套规则下行动，而不是每次都由某个人拍脑袋。

工程实践落地

光有健身计划和偷懒额度还不够。你还需要手环、体脂秤、训练 App，以及每周日晚上雷打不动的复盘。工具决定数据，数据决定坚持。SLO 体系要真正跑起来，同样需要一套“可观测装备”。

落地可以拆成四件事：埋点采集、实时聚合、告警策略、定期复盘。缺了任何一环，SLO 都只是文档里的一行字。

第一，埋点采集：在服务入口和出口埋下 SLI 相关计数，如请求总数、成功数、耗时分布、错误码，注意用统一协议透传，避免多语言、多团队各搞一套。第二，实时聚合：用 Prometheus 这类系统按滑动窗口计算可用性和延迟分位数，窗口要“滚动”而不是每天重置，才能真实反映累积消耗。第三，告警策略：不要等预算耗尽才告警，而是跟踪消耗速率——例如“按当前速率将在 7 天内耗尽预算”时就触发预警，多窗口配合（短窗口捕捉突变、长窗口判断趋势）减少误报。第四，月度复盘：回顾 SLO 达成率，把预算消耗大的变更和故障拎出来分析，动态调整 SLO 和容量。

手环一周不充电，顶多是少几天数据；可观测系统一旦失灵，架构师就像蒙眼开车。装备齐全之后，“上个月偷懒了几天、哪次熬夜最伤身”就一目了然——服务也一样，数据越完整，决策越清醒。

生产案例复盘

年底的体检报告是最好的老师。去年体脂超标，今年就重点练力量；去年跑量不足，今年就把跑量写进周计划。生产案例复盘，就是服务团队的“年度体检”。

案例一：电商大促的预算预留与大促保护。某电商平台在双 11 前将核心交易链路的 SLO 定为 99.95%，并预留出 50% 的错误预算给大促当天。压测发现商品详情页 P99 延迟超过目标，团队在大促前一周完成缓存优化；活动当天监控显示预算消耗速率逼近预警线，团队果断降级了“个性化推荐”等非核心模块，确保下单主链路没有击穿 SLO。

案例二：支付链路的外部依赖熔断。某支付系统大量依赖第三方结算渠道，渠道抖动直接让可用性 SLI 波动。团队为外部依赖设置了熔断阈值：当依赖失败率超过 SLO 容忍范围时，快速熔断并返回降级提示，避免第三方故障持续消耗错误预算。上线后，因外部原因导致的预算消耗下降了 60%。

用数据说话：假设某服务当月发生两次故障，分别持续 20 和 15 分钟，当月实际可用性可以精确算出。

体检报告不会因为你“感觉身体挺好”就放过你。错误预算同样忠实记录每一次故障、每一次决策失误。复盘的真正价值，是让下一次大促不再踩同一个坑——把经验沉淀成新的 SLO、新的告警、新的容量基线，这才是三层体系持续进化的闭环。

AI 应用场景

Python 演示

"""SLO/SLI/SLA 落地演示: 可用性计算 + 错误预算消耗跟踪"""  def calc_sli(success_count: int, total_count: int) -> float:    """计算可用性 SLI: 成功请求数 / 总请求数"""    if total_count == 0:        return 1.0    return success_count / total_count  def calc_error_budget(slo: float, window_days: int) -> float:    """计算错误预算: 窗口期内允许的最长故障时长(分钟)"""    total_minutes = window_days * 24 * 60    return total_minutes * (1 - slo)  def track_budget(budget_minutes: float, daily_failure_minutes: list) -> None:    """按日扣减错误预算, 输出每日剩余"""    remaining = budget_minutes    for day, fail_min in enumerate(daily_failure_minutes, 1):        remaining -= fail_min        print(f"第{day:>2}天 故障{fail_min:>6.1f}分钟 剩余{remaining:>7.2f}分钟")        if remaining <= 0:            print(f"  >>> 预算耗尽, 冻结发布并优先修复可靠性!")  if __name__ == "__main__":    slo = 0.999    window_days = 30    budget = calc_error_budget(slo, window_days)    print(f"SLO={slo:.1%}, {window_days}天窗口错误预算={budget:.2f}分钟")     total_per_day = 10_000_000    fail_counts = [        420, 380, 505, 460, 610, 355, 7520, 430, 480, 410,        505, 620, 470, 390, 520, 680, 455, 520, 9100, 610,        480, 430, 380, 590, 1500, 760, 980, 470, 410, 380,    ]     print("\n前 7 天可用性 SLI:")    for day in range(7):        fail_count = fail_counts[day]        sli = calc_sli(total_per_day - fail_count, total_per_day)        print(f"  第{day + 1}天 SLI={sli:.6%}")     # 折算每日故障分钟数: 假设高峰期每秒处理 5000 个核心请求    daily_failure_minutes = [fail_count / 5000 for fail_count in fail_counts]     print("\n错误预算消耗跟踪:")    track_budget(budget, daily_failure_minutes)

1. def calc_sli(success_count: int, total_count: int) -> float:定义可用性 SLI 的计算函数，输入成功数和总数
2. return success_count / total_count返回成功比例，即当天可用性 SLI
3. total_minutes = window_days * 24 * 60把窗口天数换算成总分钟数，为预算计算做准备
4. return total_minutes * (1 - slo)错误预算等于总分钟数乘以允许失败占比
5. remaining -= fail_min每天把故障分钟数从预算中扣掉，模拟实际消耗
6. if remaining <= 0:判断预算是否耗尽，触发冻结发布的决策信号
7. budget = calc_error_budget(slo, window_days)实例化 30 天 99.9% SLO 的总预算（43.2 分钟）
8. daily_failure_minutes = [fail_count / 5000 for fail_count in fail_counts]把失败请求数折算为故障分钟数，便于预算扣减
9. sli = calc_sli(total_per_day - fail_count, total_per_day)计算当天可用性百分比，展示 SLI 的日常形态

常见误区

面试题