SRE与可靠性工程：SLI/SLO/SLA定义与监控

可视化演示

展示延迟流量错误饱和度四大黄金信号、SLO目标与错误预算的滚动窗口消耗、以及SLI到SLO到SLA三层指标契约关系。

SLI指标分类：面包店的每日体检

小李打烊后有一个固定习惯：翻开账本，数一数今天烤出了多少面包、卖出了多少、有几炉因为火候太大烤糊了、顾客高峰期平均排了多久的队。这四笔账各有各的意义——卖出的面包代表“能正常买到”，排队时长代表“等待是否可接受”，烤糊的数量代表“做错的比例”，而高峰接待量代表“店面能扛多大客流”。在 SRE 领域，这些数字被统称为 SLI（Service Level Indicator，服务等级指标），它是衡量系统“到底好不好”的第一手证据。

SLI 是可靠性的“体温计”，没有它，一切可靠性讨论都是空谈。在技术系统中，SLI 通常分为四类：可用性，指成功响应占全部请求的比例；延迟，指从发出请求到收到响应的时间；吞吐量，指单位时间内系统能处理的请求数；错误率，指返回错误状态（如 HTTP 5xx）的请求占比。这四个维度并非互相排斥，一个核心服务往往同时追踪多项 SLI，比如一个电商首页既要看可用性、延迟，也要看错误率。

以可用性为例，它的计算方式非常直观：

小李的账本其实就是面包店的 SLI 记录册：卖出数除以烘烤总数是“出杯成功率”，排队平均时长是“延迟指标”，烤糊占比是“错误率”。下次你听到 SRE 说“这个接口的 SLI 掉了”，脑海里浮现的就是小李皱眉看着烤糊面包的样子。

SLI采集方法：给面包店装上仪表

账本靠人写在纸上总有遗漏。小李决定给面包店装一套“自动记录系统”：收银机每扫一单自动记一笔，门口的摄像头统计进店人数，烤炉内置温度芯片记录每一次烘烤曲线。这样一来，数据不再靠人回忆，而是由设备自动产生。技术系统的 SLI 采集也是同样的逻辑——数据必须来源于系统运行时的真实痕迹。

常见的采集方法有三类。客户端埋点是在用户端（App、浏览器）主动打点，记录请求发出、响应返回的时间戳和状态码，它最贴近用户真实体感，但可能受网络环境干扰。服务端日志是服务器在处理请求时输出的访问日志和错误日志，通过日志采集器（如 Filebeat、Fluentd）汇聚到分析平台，可靠且成本低，但缺少端到端的用户视角。链路追踪则是在一次请求穿越多个微服务时，为每个服务打上统一的 Trace ID，把散落各处的调用片段串成一条完整链路，从而定位“延迟到底耗在哪个环节”。

单日 SLI 的汇总公式很简单：

对小李而言，收银机的小票就是“客户端埋点”，摄像头人流是“服务端日志”，而烤炉温度曲线则是“链路追踪”——三者互相对账，才能确认到底是排队慢、出单慢还是烤炉本身的问题。SLI 采集的价值就在于此：数据越全，越能还原真相。

SLO滚动窗口：老板给自己定的目标

有了账本，小李开始给自己定规矩：过去 30 天里，平均要有 95% 的顾客能在 10 分钟内买到面包。注意“过去 30 天”这个说法——它不是从每月 1 号到 30 号的固定日历月，而是今天往前推 30 天，明天窗口就顺势往前挪一天，始终只盯着最近的 30 天。这种设计叫 滚动窗口（rolling window），在 SRE 中称为 SLO（Service Level Objective，服务等级目标）的核心机制。

SLO 的本质是“给 SLI 定一个可验收的分数线”。一个完整的 SLO 由三部分组成：SLI 指标、目标阈值、统计窗口。例如“过去 30 天（窗口），可用性（指标）≥ 99.95%（阈值）”。与固定窗口相比，滚动窗口的最大优势是它永远反映“最近的系统状态”，不会因为月初的糟糕表现被 30 天后的大好表现长期掩盖，也不会因为一个自然月刚结束就立刻“洗白”。窗口设计通常取 30 天，既平滑了偶发抖动，又不会迟钝到无法感知近期恶化。

SLO 达成率的计算如下：

与 SLO 形影不离的是 错误预算（error budget）：错误预算 = 1 − SLO 目标值。SLO 为 95% 时，错误预算是 5%，相当于老板允许自己一个月最多搞砸 5% 的生意。只要实际坏样本比例还在这 5% 以内，团队就可以放心发布新功能；一旦超出，就说明“信用额度”透支了。这就像小李给自己留了 3 次烤糊面包的“免死金牌”，只要没超，就不必过度紧张。

SLA违约建模：与游乐场的供货合同

面包店越做越大，小李与游乐场签了一份长期供货合同：每天早晨 8 点前送达 500 个面包，如果一周内超过 3 次迟到，每次赔偿 500 元，遇到极端天气等不可抗力免责。这份合同把“目标”上升为“契约”。在 SRE 体系中，它被称作 SLA（Service Level Agreement，服务等级协议）：一份具有商业约束力的合同，明确规定服务方必须达到的等级，以及达不到时承担的后果。

SLA 的建模包括三个关键要素。违约条件：什么情况算违约？通常以多个 SLO 作为共同门槛，比如“月度可用性低于 99.9% 或 P95 延迟超过 800ms”。赔偿条款：违约后怎么赔？常见形式是服务时长减免、现金赔偿或积分补偿，赔偿金通常与业务影响挂钩。责任划分：哪些情况不算违约？如客户侧配置错误、不可抗力、计划内维护窗口，这些需要在合同中写明免责条款，避免“背锅”。

SLA 赔偿金额可建模为：

对技术团队来说，SLA 是把“技术指标”翻译成“商业语言”的关键桥梁。每一条赔偿条款背后，都需要 SLO 监控数据作为裁判依据——没有可靠的 SLI 采集和 SLO 统计，合同里的数字就是一纸空文。小李深知：敢签这份合同，是因为店里的账本和温度计让他心里有底。

监控与告警：烤炉上的报警铃

小李给烤炉装了一个报警铃：温度超过设定上限，铃声立刻响起；烤制时间超过 10 分钟，定时器也会“叮”一声提醒。但他也发现，警报不能太灵敏——偶尔开门散热导致的短暂高温，不值得兴师动众。于是他设了规则：只有温度连续 5 分钟超限才算“真出事了”。这正是监控告警系统的设计哲学。

告警规则是告警系统的核心，它规定“什么情况要响铃”。与直觉相反，好的告警规则绝不追求“有异常就告警”，而是要求同时满足“指标越界”和“持续一定时长”两个条件，才能排除瞬时抖动。分级响应将告警按紧急程度分成 P0（系统不可用，立即拉群，15 分钟内响应）、P1（核心功能受损，30 分钟内响应）、P2（非核心问题，工作时间处理）三级。告警抑制则负责防止告警风暴——当某条告警已经被确认，或上游故障必然导致下游大量告警时，自动屏蔽重复或衍生告警，让信息真正“少而准”。

告警触发判断可表示为：

小李的报警铃把“烤糊风险”控制在可控范围内，而生产系统的告警体系则是 SRE 的神经末梢——它把 SLI 的每一次恶化都及时转化为响应动作。记住：告警不是越多越好，而是“值钱”才好；每一次响铃都应该对应一个明确的、可执行的处理动作。

仪表盘配置：店门口的智慧屏

小李在店门口挂了一块智慧屏：左边是“今日销量”的大数字，中间是最近 30 天“10 分钟出杯率”的折线图，右下角是烤炉实时温度，一旦哪个数值异常，模块会立刻变成红色并可点击下钻到明细。这块屏幕不仅是给顾客看的，更是让店员在忙乱中一眼掌握全局。在 SRE 领域，这块屏幕就是 仪表盘（dashboard）。

仪表盘配置有三大原则。核心指标优先：首屏必须是决策者最关心的几个大数字——当前 SLO 达成率、错误预算剩余、每秒请求量、错误率，而不是几十个图表堆成“满汉全席”。趋势视图辅助：单个数字没有意义，必须配合时间维度的趋势曲线，例如 30 天滚动 SLO 曲线、延迟分位数变化趋势，让“变好还是变坏”一目了然。故障定位路径：仪表盘不仅是展示台，更是排查入口。点击一个异常指标，能逐级下钻到具体的服务、实例、依赖项，形成“总览 → 下钻 → 根因”的排查链路。

仪表盘上最核心的一个数字是 错误预算剩余量：

小李的智慧屏让“经营状况”变得透明可见，生产环境的仪表盘则让整个技术团队对系统健康拥有共同认知。设计仪表盘时，要克制“什么都想放上去”的冲动——好的仪表盘像驾驶舱，只放对飞行安全至关重要的仪表；其余数据放进二级详情页，需要时才查阅。可视化演示中的绿色柱状图和红色窗口，正是这块屏幕的简化版。

定期评审流程：周一晨会与季度复盘

每周一小李都会召集店员开晨会：看一眼智慧屏上的上周数据，讨论“为什么周三排队时间特别长”“周五的烤糊率为什么升高”；每月底再复盘一次，定下个月要不要调整进货量；每季度还会重新评估：顾客对 10 分钟出杯的耐心是否变了？外卖单变多后，是不是该把 SLO 拆成“到店”和“外卖”两条？这套循环，就是 SRE 的 定期评审流程。

周度评审关注“近期风险”：检查错误预算消耗速率是否过快、上周的告警是否有效、有无濒临违约的 SLO，及时采取止损措施。月度复盘关注“趋势与质量”：分析 SLI 走势、告警的准确率和噪音率、线上问题复盘，沉淀改进项。季度调整关注“目标校准”：根据业务变化审视 SLO 目标是否仍需调整、SLI 定义是否要补充、告警阈值是否要优化。SLO 不是刻在石碑上的死数字，而是需要持续管理的活目标。

评审中一个重要分析工具是对比趋势：

小李的周一晨会看起来朴素，但正是这种“数据回顾 → 探讨归因 → 制定行动”的循环，让面包店的服务质量稳步提升。SRE 团队与研发团队共同参与定期评审，用数据说话、用目标对齐，可靠性工程才能从一个人的坚守变成一个组织的肌肉记忆。

AI 应用场景

Python 演示

import randomfrom collections import deque  class SLOMonitor:    """30天滚动窗口SLO监控器"""     def __init__(self, slo_target=0.95, window_days=30):        self.slo_target = slo_target        self.window_days = window_days        self.daily_sli = []        self.window = deque()        self.error_budget = 1.0 - slo_target     def add_daily_sample(self, success, total):        # 计算当日SLI并加入滚动窗口        sli = success / total if total > 0 else 1.0        self.daily_sli.append(sli)        self.window.append(sli)        if len(self.window) > self.window_days:            self.window.popleft()     def check_slo(self):        # 检查当前窗口是否达标        if len(self.window) < self.window_days:            return True, 1.0        achieved = sum(self.window) / len(self.window)        return achieved >= self.slo_target, achieved     def burn_rate(self):        # 计算错误预算消耗速率        if len(self.window) < self.window_days:            return 0.0        error_rate = 1.0 - sum(self.window) / len(self.window)        if self.error_budget <= 0:            return 0.0        return error_rate / self.error_budget  def main():    random.seed(42)    monitor = SLOMonitor(slo_target=0.95)     print("第几天\t当日SLI\t窗口SLO\t燃烧率\t状态")    for day in range(50):        # 前40天正常，第41天起注入故障        if day >= 40:            success = random.randint(80, 92)        else:            success = random.randint(96, 100)        total = 100        monitor.add_daily_sample(success, total)        ok, achieved = monitor.check_slo()        burn = monitor.burn_rate()        status = "达标" if ok else "预算耗尽"        if day >= 29:            print(f"{day + 1:>5}\t{success / 100:.3f}\t{achieved:.3f}\t{burn:.2f}\t{status}")  if __name__ == "__main__":    main()

1. class SLOMonitor定义一个可复用的 SLO 监控类，封装滚动窗口、错误预算、燃烧率三套核心逻辑。
2. self.window = deque()用双端队列存储窗口内的每日 SLI，新数据进、旧数据自动弹出，天然支持“窗口滑动”。
3. if len(self.window) > self.window_days: self.window.popleft()队列长度超过 30 天时弹出最旧的一天，实现滚动效果。
4. achieved = sum(self.window) / len(self.window)将窗口内所有天的 SLI 取平均，作为当前 SLO 达成率。
5. error_rate = 1.0 - sum(self.window) / len(self.window)窗口期内的实际错误率，它是消耗错误预算的“元凶”。
6. return error_rate / self.error_budget燃烧率大于 1 表示错误预算消耗速度已经超出预期，需要立即介入。

常见误区

面试题