云原生SRE实践：从SLI/SLO到可观测性落地

CH-22-06-008·约 21 分钟·现代软件架构与云原生·更新 2026-08-12

想象你经营一家叫「云味楼」的餐厅，每天接待上千桌客人。客人最在意的一件事是：菜能不能在承诺时间内上桌。为此你给后厨立了一条规矩——「95% 的菜要在下单后 15 分钟内上桌」。跑堂的每接一单就按一下计时器，后厨每出一道菜都在出菜记录本上登记，传菜员则把「下单 → 切配 → 炒制 → 上桌」的每个环节记在一张追踪单上。可有一天蒸箱坏了，出菜时间从 15 分钟飙升到 40 分钟。计时器数据告诉你「出大事了」，记录本告诉你「蒸菜压单」，追踪单告诉你「问题出在蒸箱这一环」——三份记录拼在一起，几分钟就找到了病灶。这个场景就是云原生 SRE 的全部骨架：计时器是「指标」，记录本是「日志」，那张环节追踪单就是「链路追踪」；「95% 的菜 15 分钟内上桌」是 SLO，每天实测的达标率是 SLI，一个月里允许偶尔慢几桌的额度叫「错误预算」，慢菜比例连续超标时摇响的铃声就是「燃烧率告警」。云原生系统里跑着的每一行日志、每一个数字，都和这家餐厅一一对应。这篇文章，就用「云味楼」做向导，带你走一遍从 SLI/SLO 设计、可观测性三支柱，到告警治理、故障定位的完整落地流程。

岗位关联

对 AI 从业者而言，这套方法论让你知道系统何时在「带病运行」、哪里在「漏气」，是把模型和业务的可靠性从玄学变成科学的底层能力。

可视化演示
度量体系
三支柱协同
落地四步法
采样降噪
告警管理
故障排查
SRE文化
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示SRE核心实践：SLI/SLO指标体系与错误预算管理（可用性/延迟/吞吐+预算决策）、可观测性三支柱（日志/指标/链路追踪+采集流程+工具链）、多窗口多燃烧率告警策略（短窗+长窗+2x/6x/14x），交互切换核心维度。

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

SLI/SLO与错误预算 SLI量化服务质量：可用性（成功率）、延迟(P99)、吞吐量(QPS) SLO设定目标值（如99.9%），28天评估窗口，错误预算=43.8分钟有预算激进发布，无预算保守维护，超预算冻结变更 error_budget = (1 - SLO) * window_duration SLI度量+SLO目标+预算驱动决策

度量体系

餐厅说要「承诺上菜时间」，第一步不是改菜谱，而是先量。体温计、血压计上岗，才能知道后厨此刻是健康还是发烧。在 SRE 体系里，SLI（服务等级指标）就是这个体温计——它是系统行为的客观读数，比如「请求成功率」「平均响应延迟」；SLO（服务等级目标）则是你写在门口招牌上的承诺——「95% 的菜 15 分钟内上桌」。两者一字之差，一个是测量结果，一个是目标承诺。

从比喻过渡到技术世界：一个线上服务每天收到海量请求，不可能凭感觉判断「今天还行」。于是我们定义 SLI 为「好事件占总事件的比例」，SLO 则基于 SLI 设定一个可接受的下限。更进一步，把「允许失败」变成一笔可管理的额度，这就是错误预算：既然承诺了 99% 可用，那 1% 的失败就是被允许的「喘息空间」。当同时开着多起故障时，火警的速度用燃烧率衡量——实际错误率相对预算错误率的倍数。燃烧率越高，预算烧得越快。

有了 SLI，再立 SLO 就容易了：错误预算 = 1 − SLO。好比餐厅承诺 95% 准时，那么 5% 的慢菜就是本月的「挨骂额度」。额度用完了，不是硬着头皮继续接客，而是立刻停掉新品试菜，先专心稳定后厨。这就是错误预算给团队的宝贵节奏感——不是靠吼来控制质量，而是靠数字来刹车。

\displaystyle \text{SLI} = \frac{\text{成功请求数}}{\text{总请求数}} \times 100\%

SLI 就是「好菜占总菜的比例」：一晚上出了 1000 道菜，其中 985 道准时上桌，SLI 就是 98.5%。

累计成功请求只有服务端正常处理并返回的请求才算作「好事件」。
$\text{成功请求数}$
统计总请求数所有进入系统的请求，无论成败都要计入分母。
$\text{总请求数}$
计算比值两者相除得到成功率，这是最核心的度量。
$\frac{\text{成功请求数}}{\text{总请求数}}$
化为百分比乘以 100 得到更直观的百分数读数。
$\times 100\%$

三支柱协同

「云味楼」的后厨有三本必不可少的台账：出菜记录本记下每一件具体的事，比如「12:01 蒸箱报警」「12:05 编号 1024 号菜出锅」；墙上的温度计、计时器持续画出曲线，告诉你「蒸箱温度最近 10 分钟在下降」；而那张环节追踪单，则把一道菜从下单到上桌经过的每个窗口完整串起来。这三本账，就是可观测性领域常说的三支柱：日志、指标、链路追踪。

在云原生系统里，日志是离散的事件记录，回答「发生了什么」，适合事后翻账、查异常细节；指标是连续的数值序列，回答「趋势如何」，适合画大盘、做告警；链路追踪则还原一次请求穿过多服务的完整路径，回答「到底哪一跳出了问题」。它们不是三选一，而是要配合使用：指标发现异常，日志补充现场，链路定位环节。一次请求从网关到认证服务、再到数据库，会产生一串带相同 traceId 的记录，把它们头尾相接，就像把散落的拼图重新拼回完整画面。

回到餐厅：如果没有追踪单，蒸箱坏了你只能满后厨乱转；有了它，看一眼「哪一环耗时暴增」就直奔目标。三本台账合在一起，才是真正的「可观测」——不是数据越多越好，而是能回答任意时刻「系统怎么了、为什么、在哪坏」这三个问题。

\displaystyle \text{trace} = \bigcup_{i=1}^{n} \text{span}_i

一条链路 trace 由 n 个操作单元 span 首尾组合而成，就像一道菜的下单、切配、炒制、传菜四个环节串成一张追踪单。

分解操作单元每个服务处理请求的一段工作叫 span，例如「鉴权服务校验 token」。
$\text{span}_i$
按序拼接所有 span 按调用顺序合并，形成完整调用链。
$\bigcup_{i=1}^{n}\text{span}_i$
还原调用链合并结果就是一条完整链路，可逐段查看耗时与状态。
$\text{trace}$

落地四步法

「云味楼」要正式把承诺挂上墙，不能拍脑袋写个 15 分钟。老板的做法是：先定关键指标（上菜时长），测一周摸清现状（平均 12 分钟、95 分位 18 分钟），再根据实测定承诺（95% 在 15 分钟内），最后每月复盘慢菜原因。这就是 SLO 落地的四步法：定义 → 测量 → 设定 → 复盘，一步都不能跳。

这套方法论在服务里同样适用。第一步，定义 SLI，从用户可感知的维度里挑一个，比如下单接口的成功率或 P95 延迟；第二步，持续采集测量，上报到监控系统，先跑一两周看基线；第三步，根据基线设定 SLO 目标，目标要够得着且能保护用户体验；第四步，用错误预算驱动复盘——预算消耗过快就冻结发布、优先修复，预算充足则允许研发大胆迭代。四步循环往复，SLO 就成为团队内部沟通的语言，而不是挂在墙上的口号。

回想餐厅的例子：如果第一周实测 95 分位就要 18 分钟，你却硬写 15 分钟，等于给后厨下了不可能的任务；如果实测只要 8 分钟，写 15 分钟又太宽松，用户早就流失了。SLO 落地不是一纸公文，而是拿着数据说话、按节奏调整的治理循环——这也是 SRE 实践和传统「拍脑袋运维」的分水岭。

\displaystyle \text{落地循环} = \text{定义} \rightarrow \text{测量} \rightarrow \text{设定} \rightarrow \text{复盘}

四步不断循环，就像餐厅每月根据上菜数据微调承诺和流程，让标准随真实运营动态进化。

定义 SLI确定要守护的用户关键路径和度量维度。
$\text{定义（SLI 选择）}$
持续测量埋点采集、上报到监控系统，形成历史基线。
$\text{测量（数据采集）}$
设定 SLO依据基线数据确定一个合理且有挑战的目标。
$\text{设定（SLO 目标）}$
复盘改进根据错误预算消耗情况决定发布策略与改进项。
$\text{复盘（review）}$

采样降噪

给每锅菜都配一台高清摄像机，食材成本会翻倍；但完全不拍，出了问题又没证据。聪明的后厨做法是：普通时段按比例抽拍，饭点高峰自动降低抽样，一旦发现某批菜疑似有问题就整批全拍。这就是链路追踪里的「采样降噪」——用少量的数据换取足够的可观测性。

链路追踪是成本大户：一个高并发服务每天产生数十亿条 span，全量存储的账单让人肉疼。于是有了三种经典策略。优先级采样：按业务重要性区分，核心交易链路全量保留，普通查询按低比例抽取；自适应采样：根据当前流量动态调整比例，低峰多存、高峰少存，保持存储水位平稳；尾部采样：平时只保留「慢请求」和「异常请求」的链路，因为这些尾部数据恰恰是故障分析最需要的素材。它们共同的目标，是在数据完整性和存储成本之间找平衡点。

回到餐厅：抽样的牺牲是「没被拍到的菜出了问题没法回放」，但换来的是账本不爆、查询不卡。选策略时要想清楚——哪些环节必须「全程留证」，哪些环节「抽样看看就行」。尾部采样尤其像「只留慢菜的照片」，平时鸡毛蒜皮不值得存，但每次上菜慢的现场必须完整存档，这是排查故障最值钱的素材。

\displaystyle C_{\text{实际}} = C_{\text{全量}} \times p, \qquad p = \frac{n_{\text{抽样}}}{N_{\text{总量}}}

实际成本约等于全量成本乘以采样比例 p：请求总量 100 万条，只抽 1 万条，成本就降到 1%。

全量成本全部链路都存下来需要的存储与计算开销。
$C_{\text{全量}}$
采样比例抽样数除以总请求数，p 越小省钱越多。
$p = \frac{n_{\text{抽样}}}{N_{\text{总量}}}$
折算实际成本两者相乘得到抽样后的真实开销。
$C_{\text{全量}} \times p$

告警管理

「云味楼」灶台上挂着一排气哨和铃铛。如果每口锅都配一个高音警笛，一冒热气全后厨铃声大作，反而没人听得清哪儿出事。老板重新设计了铃声体系：蒸箱故障拉 P0 主警笛，某口锅温度偏高响 P1 中铃，备料不足只是 P2 小叮当。同样的逻辑，线上告警也必须分级、收敛，否则就会变成「狼来了」的告警风暴。

告警管理的核心动作是「把多条告警变成一个事件」。指标监控发现下单成功率下跌，日志平台同时出现超时堆栈，链路追踪定位到某个依赖服务 503——这三条孤立通知，如果分别发给三个群，值班的人会疯掉。正确的做法是：用 traceId、服务名、时间段做多源关联，合并成一个「支付链路故障」事件，指定唯一负责人。再配合抑制去重：同一故障窗口内重复触发的规则不再重复通知，根因告警恢复后下游告警自动关闭。而告警阈值本身，也不该拍脑袋——用燃烧率来定：错误预算剩余越多，可以容忍的告警窗口越长；剩余越少，风吹草动都要立刻响铃。

餐厅里最好的铃声设计，是「该响的时候一定响，不该响的绝不乱响」。告警管理不是把阈值调高让告警变少，而是让每一条告警都带着上下文、分好优先级、自动收敛成可处理的工单。值班的人被从噪音里解放出来，才能真正把精力留给那些决定生死的 P0。

\displaystyle T_{\text{耗尽}} = \frac{E_{\text{剩余}}}{B_{\text{燃烧}}} \times T_{\text{SLO周期}}

预算还剩 30%、燃烧率为 6，意味着按当前速度大约 0.3 ÷ 6 = 5% 的 SLO 周期后预算就会烧光，这时候必须立即响 P0 告警。

剩余预算比例错误预算还剩多少，E 越大越从容。
$E_{\text{剩余}}$
燃烧率实际错误率相对预算错误率的倍数，B 越大烧得越快。
$B_{\text{燃烧}}$
推算耗尽时间两者相除再乘上 SLO 统计周期，算出还能撑多久。
$\frac{E_{\text{剩余}}}{B_{\text{燃烧}}} \times T_{\text{SLO周期}}$

故障排查

上菜慢的消息从大厅传到后厨，优秀的指挥不会立刻怪罪切菜师傅，而是先同时翻开三本台账：计时器曲线显示「近 10 分钟出菜时长翻倍」，记录本显示「蒸菜窗口压单 30 份」，追踪单显示「卡在蒸箱环节」。三张纸一对，结论指向同一处：蒸箱坏了。这就是故障排查的标准动作：先触发信号，再关联分析，最后定位根因。

线上故障的排查流程可以拆成四步。信号触发：燃烧率告警或 SLO 被击穿，告诉你「出事了」；关联分析：把同一 traceId 的日志、该时间段的指标、链路各 span 耗时拼在一张时间轴上；根因定位：找到链路中第一个报错的服务，而不是被下游的雪崩效应带偏——数据库变慢会让所有上游服务都超时，但根因只有数据库一处；恢复验证：修复后确认错误率回落到 SLO 以内、错误预算停止消耗、链路恢复绿色，才算真正闭环。整个过程追求的指标，就是 MTTR（平均修复时间）。

试想餐厅没装计时器、不写记录、没有追踪单，蒸箱坏掉后可能要打烊后大扫除才发现。工具的意义不是「出故障时炫技」，而是把「找原因」的时间从几小时压缩到几分钟。链路追踪负责指路，日志负责还原现场，指标负责确认边界——三者合力，让 MTTR 的每一段都肉眼可见地缩短。

\displaystyle \text{MTTR} = T_{\text{发现}} + T_{\text{定位}} + T_{\text{恢复}}

MTTR 是从故障发生到系统恢复的总时长，等于发现故障、定位根因、完成恢复三段时间之和，每一段都可以被可观测性工具缩短。

发现时间从故障发生到告警触发、值班人员确认的耗时。
$T_{\text{发现}}$
定位时间通过三支柱关联分析锁定根因服务的耗时。
$T_{\text{定位}}$
恢复时间执行修复动作并验证系统状态正常的耗时。
$T_{\text{恢复}}$
总时长三段累加得到完整修复周期。
$\text{MTTR}$

SRE文化

「云味楼」能长期维持 95% 准时率，靠的不是某天大扫除，而是把「量一量、记一记、跟一跟」变成每天的习惯：数据自动进账本、值班员每天扫一眼大盘、每周例会花十分钟复盘慢菜原因。SRE 文化的内核，就是把可靠性变成一种组织习惯，而不是某个人的英雄主义。

落到工程实践，SRE 文化需要四块基石。工具链整合：Prometheus 采集指标、APM 系统收录链路、日志平台聚合日志，三套数据在同一入口查询，避免来回切系统。动态大盘：把 SLI 实时绘成仪表盘，值班人员一眼看到整体健康度，而不必看几十张割裂的图表。值班机制：明确 on-call 轮值、响应时限和升级路径，让每次告警都有人负责到底。跨团队协作：错误预算不是 SRE 团队的私产，而是研发、运维、产品共享的安全边界——预算耗尽时，所有人都同意暂停新功能、优先补稳定性。可用性与停机时间之间存在直白的换算关系，能让每个角色都直观理解「几个 9」意味着什么。

餐厅的招牌承诺不是一次性的营销噱头，而是每天打烊后对照数据问自己「明天哪里能更好」的持续修炼。SRE 也一样——工具会迭代、系统会重构，但「用数据说话、为可靠性负责、让每个角色都看得懂代价」的文化，才是云原生时代最稀缺的资产。

\displaystyle \text{年度停机时长} = (1 - A) \times 365 \times 24 \times 60

可用性 A = 99% 时，一年允许停机约 87.6 小时；A = 99.99% 时，只有约 52.6 分钟。这就是「多一个 9」带来的真实代价。

不可用比例1 减去可用性，得到允许失败的时间占比。
$1 - A$
换算成分钟乘上一年的总分钟数，得到直观的停机时长。
$\times 365 \times 24 \times 60$
结果解读99% 允许约 3.65 天停机，99.9% 允许约 8.76 小时。
$\text{年度停机时长}$

AI 应用场景

电商大促的 SLO 护航

阶段：监控与告警

解决的问题：大促流量是平日的数十倍，靠人工盯仪表盘根本来不及反应。传统做法是堆机器、堆告警，结果既烧钱又淹没在告警风暴里。用 SLI/SLO 体系后，团队只守护「下单成功率」这一核心 SLI，设定大促期 SLO，并用燃烧率告警替代一堆零散阈值，错误预算消耗过快时自动拉高响应级别。

具体案例：某电商平台在双 11 当天，下单链路错误率从 0.1% 爬升到 0.8%，燃烧率达到 8 倍，系统在 2 分钟内自动触发 P0 告警并拉起扩容流程，同时冻结非核心的营销推送发版，15 分钟内错误率回到 SLO 以内。

微服务故障定位的「三支柱联合作战」

阶段：故障诊断

解决的问题：一次支付超时可能涉及网关、用户服务、支付服务、数据库四个环节，传统排查要逐个服务翻日志，平均耗时 40 分钟。用 traceId 将链路、日志、指标三份数据对齐到同一时间轴后，能一眼锁定首个异常节点。

具体案例：某支付服务出现大面积超时，链路追踪显示耗时集中在「调用风控服务」这一跳，日志显示该服务抛出连接池耗尽异常，指标确认其 CPU 使用率冲到 95%。三份证据指向同一根因，运维在 5 分钟内完成了重启与扩容，MTTR 从 40 分钟降到 8 分钟。

成本敏感型创业公司的采样落地

阶段：成本优化

解决的问题：创业公司预算有限，全量保存链路数据每月要花数万元，但不保存又无法排查慢请求。通过「优先级采样 + 尾部采样」组合策略，核心交易链路全量保留，普通接口按 10% 抽取，所有慢请求（P99 以上）完整入库，成本直降 70%。

具体案例：某在线教育公司接入 APM 后，将每月 800 亿条 span 的存储量压缩到 200 亿条，查询响应依然在秒级，同时保证了「慢课请求」的 100% 可追溯，季度监控成本从 6 万元降到 1.8 万元。

Python 演示

python49 行

# -*- coding: utf-8 -*-"""SLO 管理小工具：计算 SLI、错误预算与燃烧率告警"""import random  class SloManager:    def __init__(self, slo_target=0.99, window_size=60):        self.slo = slo_target        self.window_size = window_size        self.samples = []        # 每分钟成功率样本        self.budget_spent = 0.0  # 已消耗错误预算比例     def add_minute(self, success_rate):        """记录新一分钟，返回 SLI 与燃烧率"""        self.samples.append(success_rate)        if len(self.samples) > self.window_size:            self.samples.pop(0)        sli = sum(self.samples) / len(self.samples)        error_rate = 1 - sli        allowed_error = 1 - self.slo        burn_rate = error_rate / allowed_error        surplus = max(0.0, error_rate - allowed_error)        self.budget_spent = max(0.0, min(1.0, self.budget_spent + surplus))        return sli, burn_rate     def should_alert(self, burn_rate, threshold=3):        return burn_rate >= threshold     def gen_sample(self, base=0.995, spike=False):        if spike:            return max(0.70, base - random.uniform(0.05, 0.25))        return max(0.90, min(1.0, base + random.uniform(-0.01, 0.01)))  def main():    manager = SloManager(slo_target=0.99)    print("min |   sli     burn  budget  status")    for minute in range(1, 61):        spike = 30 <= minute <= 45   # 模拟第 30~45 分钟故障        success = manager.gen_sample(spike=spike)        sli, burn = manager.add_minute(success)        alert = manager.should_alert(burn)        status = "ALERT" if alert else "OK"        print("%3d | %.4f | %.2f | %3.0f%% | %s" %              (minute, sli, burn, (1 - manager.budget_spent) * 100, status))  if __name__ == "__main__":    main()

目的：模拟一个线上服务连续 60 分钟的成功率数据，实时计算滚动窗口内的 SLI、燃烧率与错误预算消耗，并在燃烧率超过 3 倍阈值时输出 ALERT，直观展示 SLO 体系的运行逻辑。

self.samples.append(success_rate)把每分钟的实测成功率追加到滚动窗口，积累历史观测。
if len(self.samples) > self.window_size: self.samples.pop(0)超过 60 分钟就弹出最旧样本，保证只看最近一小时。
sli = sum(self.samples) / len(self.samples)SLI 就是窗口内的平均成功率，即“好事件占比”。
burn_rate = error_rate / allowed_error燃烧率是实际错误率与 SLO 允许错误率的倍数，用来衡量烧预算的速度。
surplus = max(0.0, error_rate - allowed_error)只有超过 SLO 允许的错误部分才消耗预算，正常波动不扣额度。
self.budget_spent = max(0.0, min(1.0, self.budget_spent + surplus))把预算消耗限制在 0~1 之间，防止越界。
alert = manager.should_alert(burn)检查燃烧率是否达到 3 倍阈值，决定是否触发告警。
spike = 30 <= minute <= 45模拟一个持续 15 分钟的故障窗口，观察 SLI 下跌、燃烧率飙升、预算被快速消耗的全过程。

常见误区

误区我觉得只要把能采集的指标全采了，日志全存了，覆盖率越高就越不容易漏掉问题，可观测性自然就强了。

正解可观测性追求的是「回答问题的能力」，而不是数据的堆砌。就像餐厅把每颗葱的重量都记录在案，对判断上菜慢毫无帮助。正确的做法是聚焦用户可感知的关键路径，挑 2~3 个核心 SLI 守护，例如下单成功率、P95 延迟。指标太多反而让大盘变成噪音，告警阈值无法聚焦，排障时不知道先看哪块表。

为何常见：刚接触可观测性的人容易把「多」等同于「全」，加上监控工具采集指标几乎零成本，自然想先捞一把数据再说，却忽视了数据只有被有效消费才有价值。

误区SLO 不写高点怎么向领导交代？直接定 99.999%，显得团队很厉害，多几个 9 更专业。

正解SLO 不是广告牌而是契约，目标越高错误预算越小，创新空间越少。99.99% 一年只允许停机约 52.6 分钟，一场数据库迁移就可能耗尽全年额度。盲目定高目标的结果是团队天天救火、不敢发布，反而拖慢迭代。合理的 SLO 要基于历史数据，定在「用户满意」和「成本可控」的交叉点上，并允许错误预算被有计划地消耗。

为何常见：人们习惯把「更高目标」等同于「更好」，却忽略了 SLO 真正的作用是定义「何时需要停下来改进」，过高的目标会让预算机制失去弹性。

误区Prometheus、Grafana、Jaeger、ELK 全给装上，工具链越全越安心，系统就“可观测”了。

正解工具只是数据的采集端，可观测性的关键在于数据能否被关联和回答疑问。日志、指标、链路要能通过 traceId 贯通，告警要能合并成事件，仪表盘要能直接映射到 SLO。装了一堆工具却各看各的，就像厨房里有温度计、有记录本、有追踪单，但三张纸对不上号，依然找不到蒸箱毛病。工具链的整合与消费方式，远比工具数量重要。

为何常见：工具落地效果直观可见，容易给人「做了事」的安全感；而数据关联和组织流程的设计是隐性的，需要更多思考，自然容易被跳过。

误区错误预算快没了，赶紧扩容、加资源，把错误率压下去，预算就回来了。

正解错误预算不是「可以随便花的钱」，而是「允许失败的时间窗口」。它耗尽的核心信号是稳定性欠账，而不是资源不足。正确动作是：暂停高风险发布、成立专项小组修复根因、补充自动化测试和混沌演习，先把可靠性债务还清。盲目扩容可能临时掩盖症状，但根因不除，预算照样会再次被烧穿，账单却先爆炸了。

为何常见：人本能地倾向于「立刻把指标救回来」，扩容是最直接的救火动作；而“暂停发布、优先改进”需要跨团队协调和更长远的判断，心理阻力更大。

面试题

Q1. 在 SRE 体系中，SLI 指的是什么？

单选题 · easy

A.服务等级目标，团队承诺的可用性数值
B.服务等级指标，对系统行为的客观度量← 正确答案
C.服务等级协议，与客户签订的法律条款
D.错误预算，允许系统出错的时间比例

答案：B。SLI 是客观测量值，比如「请求成功率 98.5%」，回答的是「系统实际表现如何」；SLO 是基于 SLI 设定的目标承诺，SLA 是与客户签订的协议，错误预算则由 SLO 推导而来。牢记四者顺序：先量（SLI）、再承诺（SLO）、立协议（SLA）、算余量（错误预算）。

Q2. 某服务 SLO 为 99.9%，一个 30 天的月份大约有多少错误预算？

单选题 · mid

A.约 43 分钟的不可用额度← 正确答案
B.约 8 小时 46 分钟的不可用额度
C.约 15 分钟的不可用额度
D.约 4 小时 18 分钟的不可用额度

答案：A。错误预算 = 1 − SLO = 0.1%，一个月 30 × 24 × 60 = 43200 分钟，乘以 0.001 得约 43.2 分钟。这意味着这个月系统累计「不达标」时间不能超过 43 分钟左右，超了就该停止发布、优先做稳定性工作。

Q3. 燃烧率为 3 表示什么含义？

单选题 · mid

A.实际错误率是 SLO 允许错误率的 3 倍← 正确答案
B.系统成功率是 SLO 目标的 3 倍
C.错误预算正好还剩 3%
D.同一时间触发了 3 条告警

答案：A。燃烧率 = 实际错误率 ÷ 预算错误率。SLO 允许 1% 错误而实际达到 3%，燃烧率就是 3，意味着错误预算以 3 倍速度被消耗。它回答的不是「现在有多糟」，而是「按这个速度多久会烧光预算」，因此常用于设计告警窗口。

Q4. 可观测性三支柱包括哪些？

单选题 · easy

A.日志记录、指标监控、链路追踪← 正确答案
B.容器编排、服务发现、负载均衡
C.持续集成、持续部署、持续监控
D.数据库、缓存、消息队列

答案：A。三支柱是日志（发生了什么）、指标（趋势如何）、链路追踪（问题在哪一环）。容器编排、CI/CD、中间件是云原生工程的其他组成部分，不属于可观测性三支柱的范畴。

Q5. 日志与指标的核心差异是什么？

单选题 · mid

A.日志定性描述事件，指标定量数值序列← 正确答案
B.日志保存成本更低，指标存储成本更高
C.指标只能看大盘，日志只能查历史
D.两者没有本质区别，可以互相替代

答案：A。日志是离散、有上下文的事件描述，比如「12:01 用户下单成功」；指标是连续、可聚合的数值序列，比如 QPS、延迟。二者形态不同、回答的问题不同，无法互相替代，只能互相补充——指标告诉你出事了，日志告诉你细节。

Q6. 错误预算耗尽后，SRE 团队的正确做法是？

单选题 · mid

A.立即恢复发布，用新功能弥补损失
B.暂停高风险发布，优先做稳定性改进← 正确答案
C.增加更多告警规则来加强监控
D.降低 SLO 目标以缓解预算压力

答案：B。错误预算耗尽代表「这个周期的稳定性欠账已经还不上」，继续发布只会让风险叠加。正确动作是冻结高风险变更、专攻根因修复，把可靠性债务还清后再恢复迭代。增加告警只是让噪音更多，降低 SLO 则是逃避问题，都不解决根本。

Q7. 关于链路追踪的采样策略，以下哪种描述是正确的？

单选题 · hard

A.尾部采样只保留慢请求和异常请求的链路← 正确答案
B.优先级采样对所有请求一视同仁地随机抽取
C.自适应采样在低峰期降低采集比例以节省成本
D.全量采样成本低，适合所有生产环境

答案：A。尾部采样专门保留下行链路（慢请求、错误请求），因为故障分析最需要这些样本。优先级采样按业务重要性差异化抽取；自适应采样是低峰多存、高峰少存来平滑存储；全量采样的成本极高，通常只有核心链路才值得全量保留。

Q8. 治理告警风暴最有效的手段是？

单选题 · mid

A.把相关告警合并成一个事件并抑制重复通知← 正确答案
B.提高所有告警阈值让告警少触发
C.减少监控指标的数量
D.把告警直接转给研发团队处理

答案：A。告警风暴的根源是「多条孤立告警对应同一根因」，所以关键是多源关联合并成事件 + 抑制去重。一刀切提高阈值会漏报真实故障；减少指标是自欺欺人；转给研发不解决噪音问题，只会把压力转移。

Q9. 链路追踪最核心的价值是什么？

单选题 · easy

A.还原一次请求跨多个服务的完整调用链← 正确答案
B.替代日志系统记录详细错误堆栈
C.替代指标系统提供聚合监控数据
D.自动修复故障服务节点

答案：A。链路追踪通过 traceId 把散落在各服务的 span 串联起来，回答「请求到底走了哪些服务、哪一跳最慢」。它不替代日志和指标，也不具备自动修复能力，而是三支柱中负责「定位环节」的那一位。

Q10. 可用性为 99% 的服务，一年大约允许停机多久？

单选题 · mid

A.约 3 天 15 小时← 正确答案
B.约 8 小时 46 分钟
C.约 52 分 36 秒
D.约 5 分 15 秒

答案：A。停机时长 = (1 − 99%) × 365 × 24 ≈ 87.6 小时，约合 3 天 15 小时。对比来看，99.9% 约 8.76 小时，99.99% 约 52.6 分钟——每多一个 9，可靠性要求指数级上升，这也是 SLO 不能盲目追高的原因。