想象你住在小区门口，新开了一家“火箭披萨店”，老板小明最头疼的问题就一句话：到底送得快不快？ 他给每辆电动车装了计时器，每接一单就掐表记录送餐时间——这就是他店里最初的“数字化”。攒了三个月数据，小明给自己立了条规矩：95% 的订单要在 30 分钟内送到；再后来，外卖平台找他签深度合作合同，要求把“准时”写进白纸黑字：若 45 分钟内没送到，平台需赔钱。 从“计时器读数”到“自家店规”再到“对外的合同”，恰好就是今天的主角——SLI、SLO、SLA——三兄弟的完整故事。SLI 是那个秒表记录下来的指标，SLO 是写给自己的内部目标，SLA 是签给客户的法律契约。理解了这三层关系，你就理解了互联网公司天天挂在嘴边的“三个 9”“误差预算”“告警烧毁率”到底在说什么。

岗位关联

对 AI 从业者的价值：掌握了 SLI/SLO/SLA，你就能把“系统稳不稳定”从模糊感觉变成可量化数字、再变成商业合同，这是 AI 服务从实验室走向生产环境的必修课。

目录
  1. 可视化演示
  2. 1. 核心概念定义
  3. 2. 三者层级关系
  4. 3. SLI指标设计
  5. 4. SLO目标制定
  6. 5. SLA协议细则
  7. 6. 告警体系构建
  8. 7. 落地实践步骤
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示SLI/SLO/SLA三层体系结构、错误预算燃尽曲线和多维度实时监控告警的可观测性体系。

本节配有交互动效（进入视口后自动加载，约 3KB）。

SLI/SLO/SLA三层体系 SLA是对外契约，违约有商业后果 SLO是内部目标，SLI是量化度量指标 Error Budget = 1 - SLO_target 错误预算驱动发布节奏与可靠性投入

1. 核心概念定义

小明在小区门口开了一家“火箭披萨店”，最头疼的问题是“到底送得快不快”。他给每辆电动车装了计时器，接一单就记录一次送达时间——这就是他店里最初的“计量”。三个月后，小明从记录里总结出一条店规：95% 的订单要在 30 分钟内送到。再往后，外卖平台要跟他签合作协议，要求把“准时”写进合同，否则赔钱。从“秒表记录”到“自家店规”再到“白纸黑字的合同”，三样东西逐步升级，正是 SLI、SLO、SLA 的完整故事。

把故事翻译成技术术语：SLI（Service Level Indicator，服务等级指标） 是秒表读数，比如“本次请求耗时 300 毫秒”“这一单用了 28 分钟”；SLO（Service Level Objective，服务等级目标） 是写给自己的店规，比如“ 95% 的请求要在 30 分钟内完成”；SLA（Service Level Agreement，服务等级协议） 是签给外部客户或合作伙伴的合同，白纸黑字写明“若做不到就要赔偿”。三者共同回答了同一个问题：我们的服务到底有多可靠？

技术圈里给它们起了个顺口溜：“指标是测量，目标是标准，协议是合同。”SLI 回答“现在怎么样”，SLO 回答“我们想做到什么样”，SLA 回答“我们承诺做到什么样、做不到怎么办”。三者缺一不可：没有 SLI，目标和合同都无从谈起；没有 SLO，指标只是一堆无意义的数字；没有 SLA，目标就只是自我安慰。还记得店里的秒表吗？它什么都没承诺，只是忠实地记录每一单的快慢——这就是 SLI 的本分。

SLI⏟指标:秒表读数→聚合SLO⏟目标:内部店规→契约化SLA⏟协议:对外合同\underbrace{\text{SLI}}_{\text{指标:秒表读数}} \xrightarrow{\text{聚合}} \underbrace{\text{SLO}}_{\text{目标:内部店规}} \xrightarrow{\text{契约化}} \underbrace{\text{SLA}}_{\text{协议:对外合同}}
公式说了什么：大量原始测量值（SLI）汇总成一个内部目标（SLO），内部目标再固化成对外合同（SLA）。箭头代表层层升级：从数据到标准，从标准到法律。
  1. SLI 是底层的记录对每一次请求或订单做原始测量，比如“这单耗时 28 分钟”，只记录事实，不做任何承诺。
    SLI⏟指标:秒表读数\underbrace{\text{SLI}}_{\text{指标:秒表读数}}
  2. SLO 把记录聚合成标准把成千上万条记录汇总，挑一个分位数或比例作为内部目标，比如“95% 的订单 30 分钟内送达”。
    →聚合SLO⏟目标:内部店规\xrightarrow{\text{聚合}} \underbrace{\text{SLO}}_{\text{目标:内部店规}}
  3. SLA 把标准固化成契约把内部目标写成对外的合同条款，配上赔偿细则，违约就要付出真金白银的代价。
    →契约化SLA⏟协议:对外合同\xrightarrow{\text{契约化}} \underbrace{\text{SLA}}_{\text{协议:对外合同}}

2. 三者层级关系

小明店里那三样东西，“约束力”完全不同。秒表没有嘴巴，不会抱怨；店规贴在墙上，违反最多影响口碑；合同锁在抽屉里，一旦违反，小明就要真金白银地赔钱。同样一件事——“送得快不快”——从测量、自律到契约，承诺强度一级比一级高。SLI、SLO、SLA 并不是三个独立的概念，而是同一条可靠性价值链上的三个环节，环环相扣。

环节之间如何衔接？SLI 是地基，负责把用户体验翻译成可量化的数字；SLO 是墙体，基于地基选一个“我们认为够好”的分数线；SLA 是屋顶，把分数线中最保守、最能守住的那条写进合同。一条铁律是：对外承诺必须比对内目标更容易达成。假如店规是“30 分钟内送达率达 95%”，合同就不能写“30 分钟内送达率达 96%”，否则小明每天都在违约边缘走钢丝。聪明的做法是：对内定一个激进目标逼自己进步，对外定一个保守承诺保证不赔钱。

这套层级关系在 AI 系统中同样成立。比如大模型推理服务：SLI 可以是“每次请求的响应延迟、token 生成成功率”；SLO 定成“p95 延迟小于 2 秒，成功率 99.9%”；SLA 则对客户承诺“月度可用性不低于 99.5%，否则按比例退款”。你会发现，越往上层，数字越保守，惩罚越明确。这也解释了为什么面试官总爱问“SLA 能不能等于 SLO”——答案是不能，因为一旦等于，任何内部抖动都可能直接变成商业违约。

约束力: SLI⏟仅记录<SLO⏟自我要求<SLA⏟法律合同\text{约束力}:\ \underbrace{\text{SLI}}_{\text{仅记录}} < \underbrace{\text{SLO}}_{\text{自我要求}} < \underbrace{\text{SLA}}_{\text{法律合同}}
公式说了什么：三者的约束力逐级增强。SLI 只是测量没有立场，SLO 是对自己的要求，SLA 是带有赔偿条款的法律文件。
  1. SLI 是最弱的约束秒表只负责记录事实，无论读数好坏都不产生任何后果。
    SLI⏟仅记录\underbrace{\text{SLI}}_{\text{仅记录}}
  2. SLO 是中等的自律店规写给自己看，违反了可以靠改进弥补，没有外部惩罚。
    SLO⏟自我要求\underbrace{\text{SLO}}_{\text{自我要求}}
  3. SLA 是最强的契约合同签给外部对象，违约触发赔偿，约束力来自法律与商业信誉。
    SLA⏟法律合同\underbrace{\text{SLA}}_{\text{法律合同}}

3. SLI指标设计

秒表要量什么？这看似简单，其实是整个可靠性工程的起点。小明最初让后厨记“出餐速度”，结果顾客还是不停地投诉“太慢了”——因为出餐快不等于送达快，路上堵车、骑手绕路都会让顾客饿肚子。这个教训告诉我们：SLI 必须从用户视角选择，度量用户真正感知到的体验，而不是度量我们自己觉得方便的指标。对披萨店，SLI 是“顾客下单到收到披萨的总时长”；对 AI 服务，SLI 则是“用户发出请求到拿到完整响应”的时间与成功率。

选好指标后，如何把它变成一个可计算的数字？最常见的就是“比率类 SLI”，公式很简单：拿成功次数除以总次数。比如“准时率”就是按时送达的订单数除以全部订单数；“可用性”就是成功响应的请求数除以全部请求数。这里的关键在于明确“成功”的判定标准：什么样的行为算成功？对披萨店，“30 分钟内送到”算准时；对在线支付，“3 秒内返回成功且金额正确”才算成功。判定标准不写清楚，SLI 就像一把刻度模糊的尺子，测出来的数字毫无意义。

判定和计数还有两个容易被忽略的细节。其一是“谁来说失败”：站在用户角度，超时、连接中断、返回乱码都算失败，不能只统计 HTTP 500 错误码。其二是采样与窗口：不能用“抽几个样本”代替全量统计，也不能只看一天的平均值，要按分钟、小时、月分窗口统计，才能支撑后面的告警与考核。采集到的大量原始读数，最终汇聚成一个百分比——这就是披萨店秒表记录的数字化升华，也是整个可靠性大厦的地基。

可用性 SLI=成功请求数成功请求数+失败请求数×100%=99,900100,000=99.9%\text{可用性 SLI}=\frac{\text{成功请求数}}{\text{成功请求数}+\text{失败请求数}}\times 100\%=\frac{99{,}900}{100{,}000}=99.9\%
公式说了什么：可用性等于“成功的请求”占“所有请求”的比例。十万次请求中成功九万九千九百次，可用性就是 99.9%。
  1. 分子是成功的请求只有满足“成功判定标准”（如超时阈值内返回正确结果）的请求才计入分子。
    成功请求数\text{成功请求数}
  2. 分母是全部请求成功与失败都要计入分母，失败的请求包括超时、报错、断连等所有用户可感知的异常。
    成功请求数+失败请求数\text{成功请求数}+\text{失败请求数}
  3. 乘以 100% 转成百分比把比值放大成百分数，方便与 SLO 目标直接对照，如 0.999 写作 99.9%。
    ×100%\times 100\%
  4. 代入具体算例九万九千九百除以十万恰好等于 0.999，即 99.9%，对应每年约 8.76 小时的停机时间。
    99,900100,000=99.9%\frac{99{,}900}{100{,}000}=99.9\%

4. SLO目标制定

知道秒表怎么用了，接下来定目标。小明一开始拍脑袋：“必须 100% 准时！”结果骑手们天天焦虑，雨天依旧超时，数据反而更难看。后来他翻出三个月记录，发现实际准时率是 94%，于是把店规定成“95% 的订单 30 分钟内送达”——比现状高一点点，跳一跳够得着。SLO 不是越高越好，而是基于现状、留有呼吸空间的目标。目标定得太高，团队疲于奔命还总失败，挫败感爆棚；定得太低，服务没有竞争力，顾客早晚流失。

SLO 的另一个灵魂概念叫误差预算（Error Budget），翻译成披萨店语言就是“允许迟到的单数”。既然店规允许 5% 的订单迟到，那这 5% 就是小明的“迟到额度”。这个额度不是用来浪费的，而是用来投资的：小明可以把某个雨天集中“消耗”好几单额度，去试新菜品、给骑手培训；额度用完了就必须暂停一切实验，全力恢复准时率。这个机制解决了团队最大的内耗——稳定与创新不再打架，因为创新有明确的“预算”边界。

制定 SLO 时还要确定统计周期与评估窗口。是在滚动 28 天的时间窗内统计，还是按自然月结算？按月结算意味着月初就把预算全花光、月末躺平，聪明的团队往往用“滚动窗口”来防止这种投机。误差预算的计算极其简单——1 减去 SLO 目标值——但它把一句口号变成了可花可省的资源。记住：SLO 是给自己贴的“紧箍咒”，是逼团队进步又不至于崩溃的那条平衡线。

误差预算=1−SLO=1−95%=5%\text{误差预算}=1-\text{SLO}=1-95\%=5\%
公式说了什么：误差预算等于“1 减去 SLO 目标值”。SLO 是 95%，就允许 5% 的订单失败，这 5% 就是团队的迟到额度。
  1. 把全部可能性看作 11 代表 100% 的请求或订单，是最完整的集合。
    11
  2. 减去 SLO 目标值扣除必须达标的部分，剩下的就是允许失败的比例。SLO 越高，误差预算越少。
    1−SLO1-\text{SLO}
  3. 代入具体数字SLO 定 95% 时，误差预算是 5%，即每 100 单允许 5 单迟到，其余 95 单必须准时。
    1−95%=5%1-95\%=5\%

5. SLA协议细则

店规贴在自己墙上，合同却要签给甲方。小明跟外卖平台签协议时，条款写得密密麻麻：月度准时率（45 分钟内送达）不低于 99%，每低 0.1 个百分点，退还当月佣金的 5%。这就是 SLA 与 SLO 最本质的分野——SLO 是内部自律，SLA 是外部契约。SLO 违反了自己关起门来改进，SLA 一旦违反就要真金白银地赔偿，还会上征信、丢口碑、影响后续合作。

写 SLA 时最忌讳“拍脑袋承诺”。小明的聪明之处在于：对外承诺用的是 45 分钟、99% 的宽松组合，比内部店规（30 分钟、95%）留出了充足安全垫。现实中很多公司栽跟头，就是因为销售为了拿单把 SLA 承诺得比 SLO 还激进，结果技术团队天天背锅。正确做法是：先有扎实的 SLI 数据，再定可完成的 SLO，最终推导出保守的 SLA。三者数据同源、层层留量，合同才是可执行的。

SLA 另一个容易忽略的价值是“保护双方”。对客户，它是维权依据，服务不行就能索赔；对服务商，它划定了责任的上限——月度可用性做到 99.5%，剩下的 0.5% 不可用时间是合同允许的，客户不能无限追责。这也解释了为什么合同里要精确约定统计口径：是按自然月还是滚动窗口？维护窗口算不算不可用？“失败”如何定义？口径不清晰，赔偿纠纷就没完没了。披萨店的合同同样如此——雨天豁免、平台系统故障免责，这些条款都是甲乙双方共同的保护伞。

月度准时率=30×24×60−违约分钟30×24×60×100%\text{月度准时率}=\frac{30\times24\times60-\text{违约分钟}}{30\times24\times60}\times100\%
公式说了什么：把一个月按 30 天折算成 43200 分钟，用“总分钟数减去违约分钟数”再除以总分钟数，就得到月度准时率的百分比。
  1. 分母是当月总分钟数一个月按 30 天、每天 24 小时、每小时 60 分钟折算，共 43200 分钟。
    30×24×6030\times24\times60
  2. 分子是达标分钟数总分钟减去违约分钟，剩下的就是服务正常、符合合同约定的时间。
    30×24×60−违约分钟30\times24\times60-\text{违约分钟}
  3. 乘以 100% 与合同对照把比值转为百分比，和 SLA 中约定的 99% 直接对比，低于承诺即触发赔偿条款。
    ×100%\times100\%

6. 告警体系构建

店规和合同都有了，小明总不能等月底算账时才发现违约吧？他需要一个“实时监工”：只要迟到趋势不对，就立刻拉响警报。很多团队的告警逻辑是“可用性低于 95% 就报警”，但这是事后诸葛——等指标跌破 SLO 再报警，误差预算已经烧光，做什么都晚了。正确的告警要盯着一个更灵敏的指标：烧毁率（Burn Rate），它衡量的是“误差预算被烧掉的速度”，而不是“还剩多少”。

烧毁率的计算十分直观：拿当前的实际错误率除以误差预算。小明现在实际迟到率是 10%，而误差预算只有 5%，烧毁率等于 2，意思是预算正在以两倍速度燃烧。如果维持这个速度，只需半个统计周期就会把整季度的迟到额度烧光，必须立刻处理。业界常做的“多窗口告警”就是基于烧毁率：比如设定 1 小时窗口内烧毁率达 14.4 倍就发紧急页面告警（快通道），24 小时窗口烧毁率达 2 倍则发普通工单（慢通道）。快通道求快，防止急性故障；慢通道求稳，防止慢性劣化被忽略。

多层告警的意义在于给响应留出时间余量。急性故障像披萨店后厨着火，必须立刻打电话（页面告警、值班电话）；慢性劣化像骑手普遍变慢，可以慢慢排查（工单、周报）；偶尔一次超时则连告警都不必发（记录归档）。告警不是越多越好，而是越准越好——把工程师从告警疲劳中解放出来，让他们把精力留给真正的“火情”。小明的监工盯的不是“今天有没有迟到”，而是“这个速度烧下去，月底会不会赔钱”——这就是烧毁率告警的哲学。

烧毁率=实际错误率误差预算=10%5%=2\text{烧毁率}=\frac{\text{实际错误率}}{\text{误差预算}}=\frac{10\%}{5\%}=2
公式说了什么：烧毁率等于实际错误率除以误差预算。比值大于 1 说明预算烧得太快，等于 2 意味着以当前速度，预算只够撑半个周期。
  1. 分子是实际错误率当前统计窗口内真实发生的失败比例，比如最近一小时内 10% 的订单迟到。
    实际错误率\text{实际错误率}
  2. 分母是误差预算误差预算由 SLO 决定，即允许失败的最大比例，这里为 5%。
    误差预算=1−SLO\text{误差预算}=1-\text{SLO}
  3. 两者相除得倍数关系10% 除以 5% 等于 2，代表预算以两倍速度消耗，触发告警级别也应该相应提高。
    10%5%=2\frac{10\%}{5\%}=2

7. 落地实践步骤

道理都懂了，怎么在自己的 AI 服务里落地？把披萨店的创业经验整理成一套“六步法”：一看二定三签四算五告六复盘。第一步，“看”：梳理用户链路，定义真正影响体验的 SLI；第二步，“定”：基于历史数据定一个跳一跳够得着的 SLO；第三步，“签”：把最保守的承诺写进对外的 SLA；第四步，“算”：算出误差预算，明确每周期可以用于创新的额度；第五步，“告”：按烧毁率搭好多窗口告警；第六步，“复盘”：每个周期结束，复盘预算使用情况，动态调整 SLO。

六步法里最容易翻车的是“第一步”，因为很多团队把内部技术指标直接当 SLI 用，比如“CPU 使用率低于 80%”。可用户根本不在乎你的 CPU，他们在乎的是响应快不快、结果对不对。AI 系统的 SLI 更应该贴近用户感受：请求的端到端延迟、首 token 返回时间、推理结果的成功率与准确性。另外，SLO 的制定绝不能是 SRE 单方面的决定，而要让研发、算法、产品、销售坐在一起对齐——销售承诺的 SLA 不能超过研发能完成的 SLO，算法的灰度发布要花误差预算也必须提前申报。

最后用一组数字感受一下“每提升一个 9”的代价：99.9% 可用性允许每年停机约 8.76 小时，99.99% 则只允许 52.6 分钟。多一个 9，意味着要多做冗余、多写容错、多花成本。靠谱的团队不会一上来就承诺四个 9，而是把目标定在“比现状好一点，比客户期待高一点”，然后靠误差预算驱动的告警和复盘机制，一个季度一个季度地稳步逼近更高的可用性。披萨店如此，AI 服务亦如此——可靠性不是喊出来的，是量出来、定出来、签出来、守出来的。

年累计停机时间=365×24×60×(1−SLO)=525,600×0.001=525.6 分钟≈8.76 小时\text{年累计停机时间}=365\times24\times60\times(1-\text{SLO})=525{,}600\times0.001=525.6\ \text{分钟}\approx8.76\ \text{小时}
公式说了什么：把一年的总分钟数乘上允许失败的比例，就能把"99.9%“翻译成”每年最多停机约 8.76 小时"，让所有人直观感受目标的严苛程度。
  1. 先算一年的总分钟数365 天乘以每天 24 小时，再乘以每小时 60 分钟，得到每年的总分钟数。
    365×24×60365\times24\times60
  2. 乘上允许失败的比例用 1 减去 SLO 目标值，得到允许不达标的时间比例，比如 99.9% 对应 0.1%。
    ×(1−SLO)\times(1-\text{SLO})
  3. 代入数值算出实际分钟数525600 分钟乘以 0.001 等于 525.6 分钟，约等于 8.76 小时，这就是 99.9% 目标下一年最多可接受的停机时间。
    525,600×0.001=525.6 分钟≈8.76 小时525{,}600\times0.001=525.6\ \text{分钟}\approx8.76\ \text{小时}

AI 应用场景

大模型推理 API 的可用性承诺

阶段：服务可靠性度量与目标制定

解决的问题：传统监控只看 CPU、内存、GPU 利用率，机器一切正常，用户却在抱怨“AI 回复太慢”；用 SLI/SLO/SLA 体系后，从用户视角定义“首 token 延迟 p95 小于 2 秒、每次请求的完成成功率大于 99.9%”，把用户体验翻译成可考核、可签约的数字。

具体案例：某对话机器人 API 服务商与银行客户签约：月度可用性承诺 99.5%，违约责任为按未达标比例减免当月服务费。技术团队内部则定下 SLO 为 99.8%——比 SLA 高 0.3 个百分点作为安全垫，任何内部抖动都不至于直接演变成合同违约。

误差预算驱动的模型灰度发布

阶段：告警体系与变更风险管理

解决的问题：算法团队每次发新版模型都心惊胆战，怕灰度引发线上事故；基于误差预算后，团队约定“每月误差预算 0.5%，模型灰度最多消耗其中 0.2%”，预算不足就自动熔断回滚，稳定与迭代不再互相伤害。

具体案例：某推荐系统团队把“推荐接口可用性 99.5%”设为 SLO 基线，新排序模型灰度期间若烧毁率超过 2 倍并持续 30 分钟，平台自动把流量切回旧模型，同时给算法团队发出告警工单。灰度失败不再是人肉决策，而是预算自动刹车。

面向客户的 AI 服务合同谈判

阶段：SLA 商务条款设计

解决的问题：销售签单时随口承诺“可用性 99.99%”，技术团队根本达不到，合同成了定时炸弹；通过 SLI 历史数据推导，销售知道哪些承诺能签、哪些不能签，SLA 成为商务与技术的共同语言。

具体案例：某 AI 翻译 SaaS 公司整理过去 6 个月的 SLI 数据，发现月可用性稳定在 99.2% ~ 99.4%，于是把对外 SLA 定为 99%，对内 SLO 定为 99.5%。销售谈判时只承诺 99%，但实际服务水平超出预期，客户满意度反而提升。

Python 演示

python48 行
"""A tiny SLI/SLO/SLA calculator with error budget monitor.""" import random  class PizzaDelivery:    """模拟一家披萨店的配送服务."""     SLO = 0.95          # 内部目标: 95% 的订单 30 分钟内送到    SLA = 0.99          # 对平台合同: 45 分钟内送达率不低于 99%    TIMEOUT = 30        # 认定"准时"的分钟阈值     def __init__(self):        self.good_count = 0    # 准时的订单数        self.bad_count = 0     # 迟到的订单数     def record(self, minutes):        if minutes <= self.TIMEOUT:            self.good_count += 1        else:            self.bad_count += 1     def sli(self):        total = self.good_count + self.bad_count        if total == 0:            return 0.0        return self.good_count / total     def error_budget_left(self):        consumed = 1.0 - self.sli()        budget = 1.0 - self.SLO        return max(0.0, 1.0 - consumed / budget)  def main():    shop = PizzaDelivery()    random.seed(42)    for _ in range(1000):        minutes = random.gauss(20, 8)   # 平均 20 分钟送达, 标准差 8 分钟        shop.record(max(1, round(minutes)))    print("SLI(on-time rate): %.2f%%" % (shop.sli() * 100))    print("SLO(internal goal): %.2f%%" % (shop.SLO * 100))    print("Error budget left: %.2f%%" % (shop.error_budget_left() * 100))    print("SLA satisfied: %s" % (shop.sli() >= shop.SLA))  if __name__ == "__main__":    main()
目的：用 1000 个模拟配送订单，演示如何从原始记录算出 SLI、对比 SLO、检查是否满足 SLA，并计算误差预算剩余量。
  1. SLO = 0.95定义内部目标：95% 的订单要在 30 分钟内送达，这是店规。
  2. SLA = 0.99定义对外合同：45 分钟内送达率不低于 99%，否则要赔偿。
  3. self.good_count = 0初始化“准时订单”计数器，用于累计分子。
  4. def record(self, minutes):每来一个订单就记录一次耗时，相当于秒表读数。
  5. def sli(self):用“准时数除以总数”计算当前 SLI，即实测准时率。
  6. budget = 1.0 - self.SLO误差预算等于 1 减去 SLO，即允许失败的最大比例。
  7. max(0.0, 1.0 - consumed / budget)用消费比例反推剩余预算，耗尽则归零。
  8. random.gauss(20, 8)模拟真实配送耗时分布，大部分订单在均值附近，少量超时。
  9. if __name__ == "__main__":保证只有直接运行时才执行主流程，方便被其他模块导入。

常见误区

误区开会时经常听到“我们的 SLA 这个月达到了 99.9%”“这个 SLA 指标要盯一下”，好像三个词可以随便替换，说的都是“服务稳不稳定”。

正解三者的角色完全不同。SLI 是“事实”（这次请求用了多久），SLO 是“目标”（我们要求 95% 的请求在 2 秒内），SLA 是“合同”（做不到就赔钱）。混用的后果很严重：把 SLA 当内部指标，会导致对外承诺无人负责；把 SLI 当合同条款，则会让客户拿原始数据来索赔。记住秒表、店规、合同三件套，角色就清晰了。

为何常见：三者都围绕“可靠性”展开，数值又都是百分比，日常口头交流时很容易偷懒省略，时间久了概念就模糊了。

误区既然目标是“可靠”，那定 99.999% 甚至 100% 不是最稳妥吗？客户看了也放心，团队也有面子。

正解目标越高，误差预算越少，团队为达成目标付出的成本呈指数上升。从 99.9% 提升到 99.99%，每年允许停机时间从 8.76 小时压缩到 52.6 分钟，意味着要多做跨机房冗余、自动故障转移、混沌工程演练，成本可能翻几倍。而且误差预算是创新的“口粮”，预算被压到零，灰度发布和模型迭代全都寸步难行。SLO 应当定在“比现状好一点、跳一跳够得着”的位置，而不是数学上的最大值。

为何常见：人们习惯用“越高越好”的直觉评价目标，忽略了可靠性目标的本质是“成本与体验的平衡”，而不是单一方向的追逐。

误区老板说“这个季度我们的 SLA 要达到 99.9%，各部门背指标”，把 SLA 当成内部 KPI 层层下压。

正解SLA 是对外的法律文件，对象是客户、合作伙伴或监管方，包含明确的赔偿条款和统计口径；内部考核用的应该是 SLO。如果把 SLA 当内部指标，就会出现两种荒谬场景：要么内部根本没签过对外合同，却用“合同标准”给自己加戏；要么销售签了 SLA，技术团队却全然不知。正确的姿势是：SLO 对内咬紧牙关，SLA 对外留足余量，两者通过误差预算联动，而不是互相替代。

为何常见：很多人只记得“SLA 是大厂都在提的概念”，却不知道它的法律属性，于是顺手把它当成了内部管理工具。

误区SLO 定的是 95%，那就让监控系统在“准时率低于 95%”时报警，简单直接，一点不多余。

正解等指标跌破 SLO 再报警，误差预算已经烧完了，团队只剩“事后补救”的份儿。正确做法是盯烧毁率：当“当前错误率 ÷ 误差预算”超过某个倍数（如 1 小时窗口 14.4 倍、24 小时窗口 2 倍）就告警，让团队在预算烧光之前介入。这就像小明的监工不能等月底账本红了才喊人，而要看到“按这个速度烧下去月底必赔”就提前拉响警报。

为何常见：把“阈值告警”这种最简单的监控思维带入了 SRE 场景，忽略了误差预算本身具备的“时间维度”——不只关心还剩多少，更关心烧得多快。

面试题

Q1. SLI 的中文含义是什么？

单选题 · easy

  • A.服务等级协议指标
  • B.服务等级目标规范
  • C.服务等级指标度量← 正确答案
  • D.服务等级问题记录

答案：C。SLI 是 Service Level Indicator，即“服务等级指标”，对应披萨店的秒表读数。选项 A 的“协议”对应 SLA，B 的“目标”对应 SLO，D 的“问题记录”是干扰项，都不是 SLI 的准确定义。

Q2. 披萨店秒表记录的每一单送达时间，对应哪个概念？

单选题 · easy

  • A.服务等级协议 SLA 承诺
  • B.服务等级目标 SLO 标准
  • C.服务等级指标 SLI 度量← 正确答案
  • D.服务等级误差预算额度

答案：C。秒表记录的是每次服务的原始测量值，这正是 SLI 的定义——只记录事实，不做承诺。SLO 是在大量 SLI 基础上聚合出的内部目标，SLA 是对外的合同条款，误差预算则是由 SLO 推导出的允许失败比例，三者都不是“单次记录”本身。

Q3. SLO 与 SLA 的关键区别是什么？

单选题 · mid

  • A.SLO内部目标SLA对外契约← 正确答案
  • B.SLO对外契约SLA内部目标
  • C.两者均为对外正式合同文本
  • D.两者均为内部考核标准文本

答案：A。SLO 是写给团队自己的内部目标，违反后关起门改进即可；SLA 是签给客户或合作伙伴的合同，违反要触发赔偿。选项 B 把两者说反了，C 和 D 都错误地认为两者属于同一类对象。这也是面试中最常考的辨析点。

Q4. 计算可用性类 SLI 的正确公式是？

单选题 · mid

  • A.失败请求数除以总请求数
  • B.成功请求数除以总请求数← 正确答案
  • C.成功请求数减去失败请求数
  • D.总请求数除以失败请求数

答案：B。可用性 = 成功请求数 ÷ 总请求数，相当于披萨店的“准时单数 ÷ 总单数”。A 算的是失败率而非可用性，C 得出的是绝对差值而不是比率，D 的分子分母颠倒，数值越大反而代表服务质量越差。

Q5. “误差预算”的正确理解是什么？

单选题 · mid

  • A.允许失败的服务请求比例← 正确答案
  • B.必须成功的服务请求比例
  • C.承诺给客户的最低可用性
  • D.需要预留的服务器资源量

答案：A。误差预算 = 1 − SLO，表示一个统计周期内允许失败的最大比例，比如 SLO 为 95% 时误差预算是 5%，每 100 单允许 5 单迟到。选项 B 描述的是 SLO 本身，C 描述的是 SLA 承诺值，D 描述的是容量规划，都与误差预算无关。

Q6. 烧毁率的计算公式是什么？

单选题 · hard

  • A.实际错误率乘以误差预算
  • B.实际错误率除以误差预算← 正确答案
  • C.误差预算除以实际错误率
  • D.误差预算减去实际错误率

答案：B。烧毁率 = 实际错误率 ÷ 误差预算，衡量误差预算被消耗的速度。若实际错误率 10%、误差预算 5%，烧毁率为 2，意味着预算以两倍速度燃烧、只够撑半个周期。C 是倒数，A 和 D 的运算结果都没有“速率”含义。

Q7. 可用性为 99.9% 时，每年累计停机时间约为多少？

单选题 · easy

  • A.每年约 8.76 个小时← 正确答案
  • B.每年约 87.6 个小时
  • C.每周约 8.76 个小时
  • D.每月约 8.76 个小时

答案：A。一年按 365 天计算共 525600 分钟，99.9% 可用性对应 0.1% 的不可用时间：525600 × 0.001 = 525.6 分钟，约 8.76 小时。B 多了一位小数点，C、D 则混淆了统计周期的量级。

Q8. 以下哪些是设计良好 SLI 应该具备的特征？

多选题 · mid

  • A.从用户视角定义和采集← 正确答案
  • B.可测量且能被持续监控← 正确答案
  • C.指标数量越多效果越好
  • D.只关注服务器内部状态

答案：AB。好的 SLI 必须贴近用户体验（如用户感知的延迟而非 CPU 使用率），并且可测量、可采集、可持续监控。选项 C 错误，指标贵精不贵多；选项 D 错误，只看服务器内部状态会重蹈“机器正常但用户投诉”的覆辙。

Q9. 基于误差预算的告警设计，正确的做法包括哪些？

多选题 · hard

  • A.用烧毁率触发快速告警← 正确答案
  • B.多窗口结合避免抖动误报← 正确答案
  • C.等到目标被击穿再告警
  • D.告警级别设置越多越好

答案：AB。烧毁率告警能在预算烧光之前提前介入，快通道（短窗口高倍数）处理急性故障、慢通道（长窗口低倍数）发现慢性劣化，多窗口组合还能过滤偶发抖动。选项 C 是典型的事后诸葛，选项 D 会导致告警疲劳，都不可取。

Q10. SLA 协议中通常包含哪些内容？

多选题 · easy

  • A.月度可用性承诺数值← 正确答案
  • B.违约时的赔偿细则← 正确答案
  • C.内部告警阈值设定
  • D.详细误差预算计算方法

答案：AB。SLA 是对外合同，核心要素是“承诺值 + 违约赔偿”，如月度可用性 99% 及未达标时的退款比例。内部告警阈值和误差预算属于团队自己掌握的工程细节，写在内部文档里即可，不需要也不会写进对外合同。