想象你是一家“云端餐厅”的老板，餐厅每天接待成千上万的客人——这些客人可能是搜索一句“帮我画只猫”的 AI 用户，也可能是刷着短视频的普通访客。你的后厨出菜太慢，客人会走；把菜烧糊了，客人会投诉；更惨的是，如果三天两头停业整顿，老主顾全跑光。但问题是：你怎么知道餐厅今天运转得好不好？凭什么向客人打包票“我们 15 分钟一定上菜”？万一真没做到，又该怎么赔？ 这就是可靠性工程（SRE）要回答的问题。SRE 团队发明了一套“经营仪表盘”：用 SLI 测量服务到底好不好（像用计时器量上菜速度），用 SLO 定下自己要做到的标准（像后厨规定 95% 的菜 15 分钟内上桌），再用 SLA 把承诺写进合同（像对客人承诺超时就免单）。这套方法在 AI 时代尤其重要——大模型推理服务的 GPU 资源昂贵、流量波动剧烈，没有 SLO/SLI/SLA 这套“餐厅经营法”，你根本不知道自己的 AI 服务是日进斗金还是在悄悄亏本。

岗位关联

学会 SLO/SLI/SLA 实践，你将拥有量化服务健康度、驱动容量规划、保证 AI 业务 SLA 的核心能力——这是 SRE 工程师晋升技术专家、主导可靠性架构设计的必备技能。

目录
  1. 可视化演示
  2. 核心概念：SLI/SLO/SLA 三兄弟
  3. SLI 设计：选对测量仪表
  4. SLO 目标制定：定个聪明目标
  5. 错误预算：犯错零花钱
  6. AI 容量规划：节假日备料数学
  7. 负载测试：模拟客流高峰
  8. 告警策略：燃烧率模型
  9. 生产实践：SLA 分级与优化闭环
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

演示SRE可靠性工程中SLI度量、SLO目标与SLA承诺的关系，通过请求链路展示指标采集，并模拟错误预算在滚动窗口内的消耗与告警触发。

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

SRE 可靠性闭环 SLI：度量可用性指标 SLO：设定目标阈值 SLA：对外承诺协议 预算=1-SLO 超支触发告警

核心概念：SLI/SLO/SLA 三兄弟

云端餐厅开业第一天，你发现自己面临三个问题：怎么测量服务好不好？怎么定义“好”？怎么承诺客人？于是你给团队立了三条规矩：厨房里挂上计时器和温度计（这是 SLI）；后厨白板上写着“95% 的菜 15 分钟内上桌”（这是 SLO）；菜单上印着“超时 30 分钟免单”（这是 SLA）。三者分工明确：SLI 是数据，SLO 是目标，SLA 是契约。

在 SRE 术语里，SLI（Service Level Indicator）是量化服务质量的指标，比如请求成功率、响应时间、吞吐量。SLO（Service Level Objective）是团队承诺要达到的目标值，例如“月度可用性不低于 99.9%”。SLA（Service Level Agreement）是与客户签署的服务协议，包含 SLO、违约责任、赔偿条款等。AI 推理服务最常见的 SLI 是“请求成功率”——用户发来一张图片让模型识别，服务器返回真确结果就算成功。

可用性是最经典的 SLI，它的计算公式如下：

把 SLI 当温度计、SLO 后厨标准、SLA 对客合同，SRE 的一切工作就围绕这三兄弟展开。记住顺序：先有数据（SLI），再有目标（SLO），最后才是对外承诺（SLA）。

SLI可用性=成功请求数总请求数×100%\displaystyle \text{SLI}_{\text{可用性}} = \frac{\text{成功请求数}}{\text{总请求数}} \times 100\%
通俗地说：100 个客人点菜，成功端上来 99 道，可用性就是 99%。
  1. 分子——成功请求数在统计窗口（如 1 分钟）内，服务器返回 2xx 状态码且数据完整的请求数量。AI 场景下，“成功”还要包含模型正常推理、没有超时、没有返回乱码。
    成功请求数=∑请求 i1[返回正常]\text{成功请求数} = \sum_{\text{请求 } i} \mathbb{1}[\text{返回正常}]
  2. 分母——总请求数窗口内所有到达系统的请求，包括失败的和被限流拒绝的。分母必须覆盖全部流量，漏掉被拒请求会虚高可用性。
    总请求数=成功请求数+失败请求数+被拒绝请求数\text{总请求数} = \text{成功请求数} + \text{失败请求数} + \text{被拒绝请求数}
  3. 比值与百分比分子除以分母后乘以 100%，得到 0~100% 的百分比。99.9% 意味着每 1000 次请求最多允许失败 1 次。
    9991000×100%=99.9%\frac{999}{1000} \times 100\% = 99.9\%

SLI 设计：选对测量仪表

给厨房装仪表，不能只装一个温度计。AI 服务也一样：如果用户在乎响应快不快，你却只测请求成功率，就像客人抱怨上菜慢，你却说“菜都做熟了呀”。选择 SLI 的核心原则是站在用户体验角度挑选最能反映“好不好”的测量维度。

Google 提出好指标四原则：可测量（能持续采集）、贴近体验（直接反映用户感受）、能区分好坏（正常时高、故障时低）、可行动（出问题时团队知道该怎么办）。AI 推理服务的 SLI 通常有三类：可用性（请求成功率）、时延（P50/P95/P99 响应时间）、吞吐量（QPS/TPM）。另外还要区分“所有请求”与“有效请求”——被客户端主动取消的请求不应计入分母。

时间维度上的可用性公式，等价于请求维度的成功率：

选 SLI 就像选体温计和血压计：别盯着无关紧要的指标，要测那些“一坏用户就能感受到”的东西。给 AI 服务配好 SLI 仪表盘，后续所有 SLO 和容量规划才有的放矢。

可用性=总时间−不可用时间总时间×100%\displaystyle \text{可用性} = \frac{\text{总时间} - \text{不可用时间}}{\text{总时间}} \times 100\%
餐厅一个月营业 720 小时，停业维修了 2 小时，可用性就是 99.72%。
  1. 总时间SLO 申报的统计周期总时长，比如一个月 720 小时、一天 1440 分钟。AI 服务常以自然月为窗口，与账单周期对齐。
    总时间=30×24×60=43200 分钟\text{总时间} = 30 \times 24 \times 60 = 43200 \ \text{分钟}
  2. 不可用时间服务连续失败或返回错误的时间段，包括宕机、网络分区、模型加载失败导致的拒绝服务。注意：单次偶发超时不算“不可用”，只有达到“错误率阈值”的时间段才累计。
    不可用时间=∑故障持续时长\text{不可用时间} = \sum \text{故障持续时长}
  3. 除法与百分比用可用时间占比衡量服务稳定性。乘以 100% 后，99.9% 的 SLO 对应每个月最多 43.2 分钟不可用——就像餐厅一个月最多允许 43 分钟停业。
    43200−43.243200×100%≈99.9%\frac{43200 - 43.2}{43200} \times 100\% \approx 99.9\%

SLO 目标制定：定个聪明目标

定了测量仪表，接下来要写后厨白板。聪明的老板不会写“永远不许迟到”，因为那既不现实也没法考核；他会写“95% 的菜 15 分钟内上桌，一个月内达标率不低于 99%”——这就是 SLO 的雏形。

制定 SLO 有三个关键决策：目标值（定多少）、时间窗口（统计多久）、达成率（允许多少次不达标）。AI 服务常见的 SLO 是“月度可用性 ≥ 99.9%、P95 时延 ≤ 2 秒”——比对外 SLA 更严格，留出缓冲。窗口常用 30 天滚动，避免月初清零导致月末松懈。达成率指窗口内满足 SLO 的时间占比，SRE 团队通常要求“30 天内 99% 的时间达标”。

达成率计算的本质是“好的时段占总时段的比重”：

SLO 是后厨自己的“及格线”，不是对客承诺。把目标定得比 SLA 略严格，就像考试给自己定“保 95 冲 100”，真到期末（对客结算）时才不会翻车。

达成率=满足 SLO 的时段数总时段数×100%\displaystyle \text{达成率} = \frac{\text{满足 SLO 的时段数}}{\text{总时段数}} \times 100\%
一个月 30 天，其中 29 天都达标，达成率就是 96.7%——如果目标是 99%，这月不达标。
  1. 划分时段将时间窗口切成等长的评估单元，比如一天一个时段、或 5 分钟一个桶。AI 服务建议用 5 分钟粒度，太粗会掩盖瞬时故障。
    时段总数=窗口时长评估粒度=30 天5 分钟=8640\text{时段总数} = \frac{\text{窗口时长}}{\text{评估粒度}} = \frac{30\ \text{天}}{5\ \text{分钟}} = 8640
  2. 判定达标计算每个时段内的 SLI 值（如请求成功率、P95 时延），与该时段 SLO 阈值比较，达标记 1，否则记 0。
    达标i=1[SLIi≥SLO 阈值]\text{达标}_i = \mathbb{1}[\text{SLI}_i \geq \text{SLO 阈值}]
  3. 求占比达标时段数除以总时段数，得到达成率。达成率低于 100% 是常态，关键看是否低于自己设定的红线（如 99%）。
    达成率=∑达标i8640\text{达成率} = \frac{\sum \text{达标}_i}{8640}

错误预算：犯错零花钱

后厨白板上写着 99.9% 可用性，这意味着什么？意味着一个月里你有 43.2 分钟的“犯错额度”。如果你提前把额度花完了，这月剩下的时间就“不许再出任何错”——这就是错误预算（Error Budget）的核心思想：把“允许失败”变成一种可管理的资源。

错误预算 = 1 − SLO。SLO 99.9% 对应预算 0.1%，即一个月 43.2 分钟。SRE 用“消耗速率”监控预算花销：如果月末预算还剩很多，说明系统过度冗余，可以大胆发布新功能；如果月中预算就见底了，必须冻结上线、全力治理稳定性。这把“要不要发布”的争论变成了“还有没有钱”的数学题。

错误预算的直接计算式：

错误预算就像孩子的零花钱：给太多会乱花（过度发布导致故障），给太少会叛逆（团队畏手畏脚不敢迭代）。每月初“充值”43.2 分钟，花完就收紧开支——SRE 团队靠它既保证稳定性，又不扼杀创新速度。

错误预算=1−SLO\displaystyle \text{错误预算} = 1 - \text{SLO}
一杯柠檬水标着“含 99.9% 纯水”，那“杂质”最多占 0.1%。这 0.1% 就是错误预算。
  1. SLO 的小数形式把 99.9% 写成 0.999。数学上习惯用 0~1 的小数参与计算，避免百分号带来的歧义。
    0.999=99910000.999 = \frac{999}{1000}
  2. 减法求余1 减去 SLO，得到“允许失败的比例”。SLO 越接近 1，预算越小，系统越“娇贵”。
    1−0.999=0.0011 - 0.999 = 0.001
  3. 换算成绝对时间用预算比例乘以窗口总时长，得到可容忍的停机分钟数。30 天窗口对应 43.2 分钟。
    0.001×43200 分钟=43.2 分钟0.001 \times 43200 \ \text{分钟} = 43.2 \ \text{分钟}

AI 容量规划：节假日备料数学

周末或节假日，云端餐厅的客流会翻好几倍。备料太少，客人来了没菜；GPU 资源太少，AI 请求来了排队超时。容量规划就是提前算好：“高峰期需要几口锅、几个厨师、多少斤食材”。

AI 服务的容量规划核心是根据峰值 QPS 估算 GPU 数量。公式如下：

容量规划的产出是“要租多少 GPU、何时扩缩容”。配合 Kubernetes 的 HPA，让 GPU 数量跟随 QPS 曲线自动伸缩——客流高峰前备足料，深夜客流少时把 GPU 让给离线训练任务。

GPU 数=QPS峰值×单请求推理耗时(秒)单卡最大并发×冗余系数\displaystyle \text{GPU 数} = \frac{\text{QPS}_{\text{峰值}} \times \text{单请求推理耗时(秒)}}{\text{单卡最大并发}} \times \text{冗余系数}
每分钟来 600 个客人，每位客人要吃 6 分钟，一张桌子能同时坐 6 人——你需要 600÷60×6÷6 = 10 张桌子。
  1. 峰值 QPS（每秒请求数）历史流量峰值的 1.5~2 倍，或从业务预测得到。AI 功能上线、大促活动都会推高 QPS，取“最挤的那天”做基准。
    QPS峰值=max⁡(历史峰值×1.5, 业务预测)\text{QPS}_{\text{峰值}} = \max(\text{历史峰值} \times 1.5, \ \text{业务预测})
  2. 单请求推理耗时一次模型推理的平均延迟，通常取 P50 或 P95。LLM 流式生成的耗时会长达数秒，这是 AI 容量规划与普通 Web 最大的不同。
    耗时=P95 推理延迟 (如 2.5 秒)\text{耗时} = \text{P95 推理延迟} \ (\text{如 } 2.5\ \text{秒})
  3. 单卡最大并发一张 GPU 卡能同时处理的请求数，由显存大小和批处理（batching）能力决定。例如 A100 可并发 16 个推理请求。
    并发=单卡显存单请求显存占用\text{并发} = \frac{\text{单卡显存}}{\text{单请求显存占用}}
  4. 冗余系数乘以 1.2~1.5，应对突发流量和单卡故障。冗余不是浪费，是给“厨房着火”留的备用锅。
    最终 GPU 数=理论值×1.3\text{最终 GPU 数} = \text{理论值} \times 1.3

负载测试：模拟客流高峰

菜好不好吃不能光靠脑补，得在试营业时请一批“模拟客人”来点菜。负载测试就是对 AI 服务做同样的事：用压测工具模拟海量请求，看看系统在 50%、100%、200% 预期负载下的表现。

压测设计三要素：场景真实（请求内容、并发模型贴近线上）、指标明确（P95 延迟、错误率、GPU 利用率）、渐进加压（从低到高找出拐点）。AI 服务压测尤其要注意：模型推理的显存占用和 Token 吞吐，不仅要测 QPS，还要测 TPM（每分钟 Token 数）。P95 延迟是核心验收指标：

压测发现瓶颈后，常见的“堵点”有：GPU 算力不足、显存溢出、API 网关连接数打满、数据库连接池耗尽。定位到瓶颈后扩容或调优，再复测——这就是 SRE 的“试菜-改进-再试菜”循环。

P95 延迟≤延迟 SLO 阈值\displaystyle \text{P95 延迟} \leq \text{延迟 SLO 阈值}
100 道菜的上菜时间从快到慢排队，第 95 道菜端上桌用了 18 秒——只要这 18 秒不超过你的承诺线，就达标。
  1. 采集排序压测中记录每次请求的响应时间，从快到慢排序。排在第 95% 位置的值就是 P95。P95 比平均值更真实——平均值会被“超快请求”拉低，掩盖尾部慢请求。
    排序: t1≤t2≤⋯≤tn,P95=t⌈0.95n⌉\text{排序}: \ t_1 \leq t_2 \leq \cdots \leq t_n, \quad P95 = t_{\lceil 0.95n \rceil}
  2. SLO 阈值业务方定义的可接受延迟，如“AI 首 Token 时延 ≤ 1 秒”、“完整回复 ≤ 3 秒”。这个阈值来自用户体验预期，不是技术指标。
    SLO延迟=3 秒\text{SLO}_{\text{延迟}} = 3\ \text{秒}
  3. 比较判定P95 小于等于阈值则通过。若 P95 超标，说明系统还有瓶颈——要么扩容，要么优化推理引擎（如 TensorRT 加速、vLLM 批处理）。
    P95=2.8 秒≤3 秒 ⇒ 通过P95 = 2.8\ \text{秒} \leq 3\ \text{秒} \ \Rightarrow \ \text{通过}

告警策略：燃烧率模型

厨师长不能盯着每一道菜，他需要一套报警铃：出菜慢了铃响，温度不够了铃响。SRE 的报警铃就是基于 SLO 的告警，核心机制叫燃烧率（Burn Rate）——错误预算被烧掉的速度。

燃烧率 = 实际错误率 ÷ 可容忍错误率。例如 99.9% SLO 的可容忍错误率是 0.1%，如果最近 1 小时实际错误率是 1%，燃烧率就是 10——相当于把 1 小时的错误预算额度（0.6 分钟）按 10 倍速度烧掉了。燃烧率越高，预算耗尽越快，告警越紧急：

多窗口组合告警能避免误报：短窗口（1 小时高燃烧率）捕捉突发故障，长窗口（6 小时、3 天低燃烧率）捕捉缓慢劣化。告警分级后，P0 立即拉群电话、P1 十分钟内响应、P2 工作时间处理——就像厨房的火警铃、门铃、定时器，声音不同，紧急程度也不同。

燃烧率=当前错误率1−SLO\displaystyle \text{燃烧率} = \frac{\text{当前错误率}}{1 - \text{SLO}}
每月零花钱 1000 元，照现在的花法两周就烧完——这花法就是“高燃烧率”，得赶紧记账提醒自己。
  1. 当前错误率最近一个时间窗口内（如 1 小时、6 小时）的实际失败比例。AI 服务可以按请求数算，也可以按推理错误数算。
    错误率=失败请求数总请求数\text{错误率} = \frac{\text{失败请求数}}{\text{总请求数}}
  2. 可容忍错误率SLO 隐含的失败上限，等于 1 − SLO。99.9% 的 SLO 对应可容忍错误率 0.1%。
    可容忍错误率=1−0.999=0.001=0.1%\text{可容忍错误率} = 1 - 0.999 = 0.001 = 0.1\%
  3. 比值与判定燃烧率 > 1 意味着超速消耗预算。SRE 实践推荐：燃烧率 14.4 持续 1 小时 → 紧急告警；燃烧率 6 持续 6 小时 → 严重告警；燃烧率 1 持续 3 天 → 关注。
    燃烧率=0.1%0.1%=1 (临界),1%0.1%=10 (危险)\text{燃烧率} = \frac{0.1\%}{0.1\%} = 1 \ (\text{临界}), \quad \frac{1\%}{0.1\%} = 10 \ (\text{危险})

生产实践：SLA 分级与优化闭环

餐厅经营满一年，你开始给不同客人不同承诺：普通客人“30 分钟上菜”，VIP 客人“15 分钟上菜，超时免单还送甜点”。这就是 SLA 分级：不同用户级别对应不同服务承诺与赔偿标准。

SLA 的赔偿机制本质是“违约金计算公式”：

生产实践最终要形成 SRE 工作流闭环：定义 SLI → 制定 SLO → 分配错误预算 → 监控告警 → 故障应急 → 复盘改进 → 重新评估 SLO。每次大故障后都要问：“SLO 定得合理吗？SLI 真的反映用户体验吗？容量预测哪里偏了？” 用数据驱动持续迭代，让这家云端餐厅从“凭感觉经营”走向“看仪表盘经营”。

赔偿额=月度费用×赔偿系数(未达标程度)\displaystyle \text{赔偿额} = \text{月度费用} \times \text{赔偿系数}(\text{未达标程度})
承诺 99.9% 可用性，结果做到 99.0%，按合同赔当月费用的 10%——相当于餐厅给客人送代金券。
  1. 月度费用客户当月实际支付的账单金额，是赔偿基数。AI 服务按 Token 计费或按 API 调用量计费，账单额可直接作为基数。
    月度费用=Token 单价×月度 Token 消耗量\text{月度费用} = \text{Token 单价} \times \text{月度 Token 消耗量}
  2. 赔偿系数根据可用性未达标等级查表得到。例如可用性 99.0%~99.9% 赔 10%，98%~99.0% 赔 30%，低于 98% 赔 50%。
    赔偿系数={10%,99.0%≤可用性<99.9%30%,98.0%≤可用性<99.0%50%,可用性<98.0%\text{赔偿系数} = \begin{cases} 10\%, & 99.0\% \leq \text{可用性} < 99.9\% \\ 30\%, & 98.0\% \leq \text{可用性} < 99.0\% \\ 50\%, & \text{可用性} < 98.0\% \end{cases}
  3. 求赔偿额基数乘以系数，得到应退金额。SLA 赔偿不仅补偿客户损失，更是给自己“每个月不能破产”的外部约束。
    赔偿额=10000×10%=1000 元\text{赔偿额} = 10000 \times 10\% = 1000 \ \text{元}

AI 应用场景

场景一：大模型推理服务的容量预估

阶段：容量规划与成本优化

解决的问题：一家 AI 初创公司上线 ChatGPT 类应用前，只知道“用户会很多”，但不知道要租多少 GPU。传统做法是拍脑袋买卡，结果要么 GPU 闲置浪费巨额成本，要么高峰期打满导致 P95 延迟飙到 10 秒、用户流失。

具体案例：SRE 团队用历史 Beta 数据预估峰值 QPS 约 200，单次推理 P95 延迟 2.5 秒，单卡 A100 并发 16 路，代入 GPU 数 = 200×2.5÷16×1.3 ≈ 41 张卡。上线后再结合 HPA 自动扩缩容，成本节省 35%，P95 延迟稳定在 1.8 秒以内。

场景二：SLO 驱动的发布闸门

阶段：变更管理与发布控制

解决的问题：AI 模型的版本更新很频繁，但新模型可能出现“回答质量下降”或“推理变慢”等隐性回归。传统做法是人工抽检，覆盖不全且效率低。

具体案例：某推荐系统将“月度可用性 99.9%”设为 SLO，错误预算每月 43.2 分钟。团队建立“预算闸门”：若本月已消耗 60% 预算，新模型灰度发布必须暂停；若预算剩余超 80%，可放行高风险优化。上线三个月，重大故障数量下降 50%。

场景三：AI 客服的时延告警

阶段：可观测性与告警

解决的问题：AI 客服系统对延迟极其敏感，3 秒没回复用户就挂断。传统监控只盯着 CPU/内存这些“后厨仪表”，对“菜没端上桌”毫无感知。

具体案例：SRE 团队设置燃烧率告警：P95 延迟超过 2 秒（错误率 20%）持续 5 分钟即触发 P1 告警。某次对话模型升级导致推理排队，告警在 3 分钟内拉响，团队 10 分钟完成回滚，将故障影响控制在预算范围内。

Python 演示

python50 行
# -*- coding: utf-8 -*-"""30 天滚动窗口错误预算监控器"""import random class ErrorBudgetMonitor:    def __init__(self, slo=0.999, window_days=30):        self.slo = slo        self.window_days = window_days        self.total_budget = 1.0 - slo        self.records = []        self._count = 0     def record_day(self, good, total):        self.records.append((good, total))        if len(self.records) > self.window_days:            self.records.pop(0)        self._count += 1     def availability(self):        good = sum(g for g, _ in self.records)        total = sum(t for _, t in self.records)        return good / total if total > 0 else 1.0     def budget_left(self):        avail = self.availability()        consumed = max(0.0, avail - self.slo)        return max(0.0, 1.0 - consumed / self.total_budget)     def alert_level(self):        left = self.budget_left()        if left < 0.2:            return "critical"        if left < 0.5:            return "warning"        return "ok"  if __name__ == "__main__":    random.seed(42)    monitor = ErrorBudgetMonitor(slo=0.999, window_days=30)    for day in range(30):        if day < 20:            bad = random.randint(1, 3)        else:            bad = random.randint(15, 30)        total = 10000        monitor.record_day(total - bad, total)        print("day {:2d} | 可用性 {:.4%} | 预算剩余 {:.1%} | {}".format(            day + 1, monitor.availability(),            monitor.budget_left(), monitor.alert_level()))
目的：模拟一个 30 天滚动窗口内的 AI 服务错误预算监控过程——前 20 天正常，后 10 天故障恶化，观察预算消耗与告警等级变化。
  1. class ErrorBudgetMonitor:定义监控器类，对应 SRE 团队里的“看仪表盘的人”。
  2. self.total_budget = 1.0 - slo关键一行：SLO 99.9% 时错误预算只有 0.1%，是后续所有计算的基准线。
  3. self.records.append((good, total))每天记录“成功数/总数”到滚动列表，窗口超过 30 天自动挤掉最老的数据。
  4. budget_left = 1.0 - consumed / self.total_budget把已消耗的错误预算比例换算成剩余比例，归零即告警。
  5. if left < 0.2: return "critical"预算剩余不足 20% 触发严重告警，对应“零花钱快花光了要停发”。
  6. random.seed(42)固定随机种子让结果可复现，方便团队对齐压测和演练场景。

常见误区

误区SLO 和 SLA 不是一回事吗？反正都是承诺可用性 99.9%，写进合同的就是 SLO，客户认可就行。

正解SLO 是内部的、可单方面调整的目标；SLA 是对外的、有法律约束的契约。SLO 应该比 SLA 更严格——好比后厨自定“15 分钟上菜”，对客承诺却是“30 分钟超时免单”，中间留足缓冲。如果把 SLA 当 SLO 用，每次技术改进都牵动合同变更，业务上寸步难行。

为何常见：两者数值常常相同，文档里又经常混写，初学者容易想当然地认为“SLA 就是对外版本的 SLO”。

误区SLO 定得越高越好，最好写上四个九五个九，这样客户肯定满意、老板肯定放心。

正解可用性每多一个九，成本翻倍：99.99% 需要双活数据中心、复杂故障转移，而 0.01% 的收益对普通用户几乎无感。错误预算哲学恰恰承认“失败是不可避免的”，与其烧钱追完美，不如用预算指导团队把精力花在高性价比的改进上。SLO 是产品决策，不是技术指标。

为何常见：工程师天然的完美主义倾向，加上“质量越高越安全”的直觉，让人忽视了背后的巨大成本。

误区只要平均响应时间是 800ms，系统就很健康，不用看那些复杂的百分位数。

正解平均值会掩盖尾部灾难——1000 个请求里 990 个 100ms 完成，10 个等了 10 秒，平均值只有 199ms，但那 10 个用户已经骂娘了。SLI 必须用 P95/P99 这类高百分位数，或者用“超过阈值请求占比”，才能真实反映绝大多数用户体验的“后厨出菜速度”。

为何常见：平均值计算简单、监控面板默认展示，而百分位数需要额外配置和理解门槛。

误区多设几条告警，每 5 分钟检查一次错误率，任何风吹草动都拉群，这样肯定万无一失。

正解告警过多会导致“告警疲劳”，值班人员对铃声麻木，真正的 P0 故障反而被淹没。Google 推荐用燃烧率做“少而准”的告警：只有错误预算消耗速度异常才告警。每月几十条有意义的告警，比每天几百条噪声有价值得多。

为何常见：人本能地觉得“监控覆盖越全越安全”，没意识到监控本身也有信噪比问题。

面试题

Q1. 关于 SLO、SLI、SLA 的关系，下列说法正确的是？

单选题 · easy

  • A.SLI 是目标，SLO 是指标，SLA 是合同
  • B.SLI 是指标，SLO 是目标，SLA 是合同← 正确答案
  • C.SLO 是指标，SLA 是目标，SLI 是合同
  • D.SLA 是指标，SLI 是目标，SLO 是合同

答案：B。SLI 是测量服务质量的指标（如请求成功率），SLO 是基于 SLI 制定的目标（如月度可用性 99.9%），SLA 是对外签署的协议合同。选项 B 准确对应“测量-目标-承诺”三层关系，其余选项均混淆了三者的定义。

Q2. 一个 AI 服务 SLO 为 99.9%，30 天内最多允许多少分钟不可用？

单选题 · easy

  • A.4.32 分钟
  • B.43.2 分钟← 正确答案
  • C.432 分钟
  • D.4320 分钟

答案：B。30 天总时长 = 30×24×60 = 43200 分钟，错误预算 = 1−99.9% = 0.1%，43200×0.001 = 43.2 分钟。类似算房租按天折算：月租里允许“损耗”的额度就是总时长乘以损耗比例。

Q3. 燃烧率（Burn Rate）的计算公式是？

单选题 · mid

  • A.当前错误率除以可容忍错误率← 正确答案
  • B.可容忍错误率除以当前错误率
  • C.当前错误率乘以可用性
  • D.错误预算乘以当前错误率

答案：A。燃烧率 = 当前错误率 ÷ 可容忍错误率，可容忍错误率 = 1 − SLO。它衡量错误预算的消耗速度，等于“按现在的花法，零花钱能撑几天”。

Q4. 为什么 AI 服务容量规划要重点参考 P95 延迟而非平均延迟？

单选题 · mid

  • A.P95 一定比平均值小，更容易达标
  • B.平均延迟掩盖尾部慢请求，P95 反映多数用户实际体验← 正确答案
  • C.P95 是模型推理准确率的指标
  • D.平均延迟无法用工具测量

答案：B。平均值被少数超快请求拉低，100 个请求 99 个 100ms、1 个 10s，平均约 200ms，但 P95 已接近 10s。做容量规划要保证“绝大多数请求都够快”，所以看高百分位数更贴近用户体验。

Q5. SLO 目标值通常应该比对外 SLA 的承诺值？

单选题 · mid

  • A.更宽松
  • B.更严格← 正确答案
  • C.完全一样
  • D.无所谓

答案：B。SLO 是内部自定目标，SLA 是对外承诺。SLO 设置更严格是为了预留缓冲，避免内部目标擦边时对外违约——好比考试目标定 95 分，实际考了 93 分也没跌破“及格线”。

Q6. 以下哪项是衡量 AI 推理服务“上菜速度”的最佳 SLI？

单选题 · easy

  • A.GPU 温度
  • B.服务端 P95 响应时延← 正确答案
  • C.模型参数数量
  • D.磁盘剩余空间

答案：B。SLI 要贴近用户体验。GPU 温度、参数量、磁盘空间都是内部资源指标，用户感知不到；P95 响应时延直接反映“等多久才能看到 AI 回复”，才是有效的服务质量指标。

Q7. 错误预算剩余 60% 时，SRE 团队最合理的决策是？

单选题 · mid

  • A.冻结所有发布直到月末
  • B.可以择机发布低风险功能← 正确答案
  • C.立即终止所有在线服务
  • D.忽略预算直接发布高风险变更

答案：B。剩余 60% 说明预算充足，可以支持正常迭代。错误预算机制的意义就是在预算充足时放行发布、预算紧张时收紧变更——像零花钱还剩大半时允许买点零食。

Q8. 一个“好 SLI”应该满足哪些标准？

多选题 · mid

  • A.能够持续自动化采集← 正确答案
  • B.直接反映用户体验← 正确答案
  • C.故障时数值明显恶化← 正确答案
  • D.数值越复杂越专业

答案：ABC。好指标四原则是可测量、贴近体验、能区分好坏、可行动。A、B、C 分别对应这三条；D 是迷惑项——SLI 重在简单可靠地反映质量，复杂不等于有效。

Q9. AI 服务负载测试的设计要点包括？

多选题 · hard

  • A.压测请求贴近真实业务分布← 正确答案
  • B.只测平均 QPS 不测峰值
  • C.验证 P95 延迟是否满足 SLO← 正确答案
  • D.渐进加压定位性能拐点← 正确答案

答案：ACD。压测要场景真实（A）、验收到位（C）、渐进找瓶颈（D）。只测平均 QPS 会掩盖高峰期的排队和超时，所以 B 错误。压测的核心是模拟“客流最高峰的那顿饭”。

Q10. 关于错误预算驱动决策，以下说法正确的有？

多选题 · extreme

  • A.预算充足时可加速功能发布← 正确答案
  • B.预算耗尽后应立即冻结高风险变更← 正确答案
  • C.错误预算等于允许用户感受到的失败总量← 正确答案
  • D.错误预算只能用于发布决策不能用于容量规划

答案：ABC。错误预算本质是“允许失败的量”，预算充足说明系统健康、可承受变更风险（A 对）；耗尽则收紧变更（B 对）；它源自 SLO 的失败容忍度，可从用户体验角度理解为允许的失败总量（C 对）。D 错误，预算还用于指导容量规划、告警阈值设计等场景。