SLO/SLI/SLA三要素在DevOps中的落地实践

可视化演示

动态演示SLO/SLI/SLA三要素的核心机制，通过总览/传输/转换/输出四种模式展示关键概念与交互流程。

三要素定义

老张的“准时面馆”贴出告示：“30分钟内上齐菜品，超时整桌免单。”这张告示就是SLA——对顾客白纸黑字的承诺。后厨出菜口装了计时器，每道菜从下单到上桌都记录秒数，这是SLI。但老张心里还有一本账：“100桌里至少95桌要在30分钟内上齐”，这是他给厨房定的红线，也就是SLO。三样东西各有分工：SLA管“赔多少”，SLI管“怎么量”，SLO管“底线在哪”。

AI服务上线后，只说“系统好像挺稳定”是不够的。SLA、SLO、SLI三层结构把“稳定”拆成三个可回答的问题：对用户承诺什么？用什么数据衡量？内部要守住的底线是多少？在DevOps语境里，SLA通常写进服务合同，包含可用性百分比（如99.9%）和赔偿说明；SLO是工程团队自己定义的量化目标，例如“过去30天，P99推理延迟不超过200毫秒”；SLI则是真实采集的测量值，比如成功率、延迟分位数。三者构成一条从测量到承诺的链条。

所以面馆真正赚钱的秘诀，不是把告示贴得多响，而是秒表、红线和告示三层咬合。把顾客挡在赔偿之外的，不是嘴上的承诺，而是厨房里那根更紧的红线。

SLI选取法则

老张一开始让厨师自己报“感觉上菜挺快”，结果顾客投诉不断。后来他在每张桌上放沙漏，从顾客落座到菜齐，量的是“全程体验”而不是“灶上时间”。选SLI的第一原则就是回到用户视角：用户感知不到GPU利用率，只感知“点了推荐按钮多久出结果”。一个SLI如果用户感受不到变化，它对服务质量就没有发言权。

具体到AI工程，常见SLI有四类。第一类是可服务性：请求总数里成功的比例；第二类是延迟：用P50、P95、P99分位数描述“大多数人多快、最慢的1%多慢”；第三类是吞吐量：单位时间处理多少请求；第四类是事件驱动指标：批处理任务成功率、训练作业是否按时完成。特别注意，延迟必须用分位数而不能用平均值，因为平均延迟会被少数快请求“拉平”，掩盖大量慢请求。

就像沙漏只记“菜齐没齐”这一件事，好SLI只回答一个用户能感知的问题，而不是把一堆系统内部指标搅成一大锅粥。

SLO制定方法

告示承诺30分钟免单，厨房内部红线定多少？老张的答案是28分钟——比承诺更紧。如果红线也定30分钟，那厨房天天在悬崖边走路，一忙起来必然翻车。定SLO的核心思想就是“从SLA反推，再往回收一点”。

制定SLO通常走四步。第一步，确定统计窗口：是滚动30天、自然月，还是周维度。窗口不同，抖动被吸收的程度就不同。第二步，基于SLI历史数据评估可达基线：面馆要看过去三个月平均上菜时长，而不是拍脑袋。第三步，按SLA反推并留缓冲：外部承诺99.9%可用性，内部SLO通常定99.95%，错误率几乎砍半。第四步，与业务方对齐优先级：有些服务追求极致延迟，有些服务更看重吞吐，SLO不能一刀切。标准的SLO表述长这样：“过去30天，99.9%的请求延迟低于200毫秒”。

SLO就是那根28分钟的线：比30分钟承诺紧，又比“每桌20分钟”的死命令更可达成。它把“诚信”翻译成一串能考核的数字，让厨房知道今天到底干得怎么样。

错误预算管理

红线不是用来罚厨师的，而是用来管理“搞砸的额度”。100桌允许5桌超时，这5%就是老张给厨房的容错额度。预算没用完，可以让厨师尝试新菜式、调整流程；预算快烧光了，立刻停止新品研发，全员修流程。这就是错误预算的核心思想：把可靠性风险换算成一张可以消费和补充的“信用卡”。

错误预算的计算非常简单：1减去SLO。SLO=99.9%，月度错误预算大约43.2分钟；SLO=99%，月度预算约432分钟，也就是7.2小时。预算的补充周期通常与统计窗口一致——每个新窗口开始，预算自动回满。但真正有价值的是“消耗速度”，也就是燃烧率：实际错误率除以允许错误率。燃烧率等于1，表示按当前速度正好30天烧完；燃烧率等于14.4，意味着2天就会爆表。团队应该用错误预算做发布决策：预算充足时允许更大胆的发布，预算耗尽时冻结非必要变更。

错误预算让“允许失败”变得可管理：预算没花完，新菜随便试；预算见底，厨房立刻停止研发，全员修流程——这就是用容错额度做发布决策的DevOps智慧。

告警策略设计

老张不可能等打烊才发现今晚超时了30桌。他需要火候警报器：连续几分钟“出菜太慢”就立刻喊人。传统监控是等阈值突破才告警，比如“错误率超过5%就报警”，但等这个数字出现，预算往往已经烧掉一大半。Google SRE推荐的“多窗口多燃烧率”告警，用快慢两个窗口同时观察燃烧率，兼顾及时性和准确性。

以月度SLO=99.9%（错误预算0.1%）为例，有三条经典规则：1小时窗口燃烧率≥14.4，说明预算约2天内耗尽，属于紧急告警，需要立刻响应；6小时窗口燃烧率≥6，说明预算约5天内耗尽，属于严重告警；3天窗口燃烧率≥1，说明按当前速度正好30天耗尽，需要开工单跟进。快窗口负责第一时间抓住异常，慢窗口负责过滤偶发抖动，避免误报。这样既不会惊弓之鸟，也不会亡羊补牢。

快慢窗口就像灶台边的两个铃铛：一个一响就扑上去看，一个慢慢摇提醒你今晚整体节奏偏慢。两个铃铛配合，才能既不草木皆兵，也不等到顾客掀桌才反应。

落地实践流程

老张给面馆上了三件套：POS机自动记录每单时间、后厨大屏实时滚动达标率、每周一复盘上周数据。AI工程里的SLO落地同样是这条流水线：从埋点采集，到计算呈现，再到告警决策，缺一不可。

落地包含四个环节。第一，指标采集管道：通过日志、分布式追踪、API网关埋点获取原始数据，AI服务还要额外记录推理耗时、token数等特征。第二，服务端点监控：SLO必须定义在“用户请求的完整生命周期”上，从客户端发起请求到拿到响应，而不是只测某一个内部模块。第三，数据质量控制：处理缺失值、异常时间戳、重复上报，脏数据会直接污染SLO计算，让告警失灵。第四，持续改进：周期性复盘SLO达成情况，与容量规划联动，发现基线漂移就及时调整目标。

没有管道的数据是死数据。面馆的大屏若没人看，和没有大屏没有区别；DevOps的最后一公里，是把SLO数字变成每周例会上的行动项，而不是躺在监控系统里的装饰品。

SLA保障体系

免单告示背后，老张设了三道保险：赔偿规则白纸黑字写清楚，后厨目标比告示更严，高峰期多备一口灶。SLA不仅是技术指标，更是商业合同的延伸。一套完整的保障体系要回答三个问题：做不到怎么赔，怎么尽量做到，出了问题谁负责。

落地时通常抓四个方面。第一，赔偿条款设计：按违约时长或次数计算服务额度返还，条款必须和SLO联动，不能只写在销售PPT里。第二，内部SLO支撑：内部红线始终严于外部承诺，留出缓冲垫，避免一次流量尖峰就直接触发赔偿。第三，容量规划联动：错误预算不足时提前扩容、限流或降级非核心功能，用技术手段兜住商业承诺。第四，多方问责机制：on-call轮值、事故复盘、改进项跟踪，确保每一次SLA险情都有人负责闭环。

对外承诺是“面子”，内部SLO是“里子”，容量与问责是“底子”。三子齐备，老张的免单告示才敢贴得理直气壮。AI平台的SLA也同理：只有背后有一套完整的技术保障体系，白纸黑字的承诺才不会变成一纸空文。

AI 应用场景

Python 演示

import mathimport random  class LatencyRecorder:    """记录每次请求的延迟, 并评估SLO与错误预算状态."""     def __init__(self, slo_ratio=0.95, slo_line=30.0):        self.slo_ratio = slo_ratio          # SLO目标: 达标比例        self.slo_line = slo_line            # SLO红线: 最长可接受延迟        self.samples = []                   # 存放每单延迟        self.total_count = 0                # 总请求数        self.bad_count = 0                  # 超时请求数     def record(self, latency):        self.samples.append(latency)        self.total_count += 1        if latency > self.slo_line:            self.bad_count += 1     def percentile(self, p):        ordered = sorted(self.samples)        idx = int(math.ceil(p / 100.0 * len(ordered))) - 1        return ordered[max(idx, 0)]     def summarize(self):        if self.total_count == 0:            return {}        ok = self.total_count - self.bad_count        sli = ok / self.total_count        error_rate = self.bad_count / self.total_count        allowed_error = 1.0 - self.slo_ratio        burn_rate = error_rate / allowed_error if allowed_error else 0.0        return {            "total": self.total_count,            "sli": sli,            "p95": self.percentile(95),            "p99": self.percentile(99),            "error_rate": error_rate,            "burn_rate": burn_rate,            "budget_left": max(0.0, 1.0 - burn_rate),        }  def simulate_diner():    rng = random.Random(42)    rec = LatencyRecorder(slo_ratio=0.95, slo_line=30.0)    for _ in range(2000):        latency = rng.lognormvariate(2.6, 0.55)        rec.record(latency)    report = rec.summarize()    print("总单量:", report["total"])    print("SLI(达标率): {:.2%}".format(report["sli"]))    print("P95延迟: {:.1f} 分钟".format(report["p95"]))    print("P99延迟: {:.1f} 分钟".format(report["p99"]))    print("燃烧率: {:.2f}".format(report["burn_rate"]))    if report["burn_rate"] > 1.0:        print("错误预算超支, 应冻结发布, 优先修复流程")    elif report["burn_rate"] > 0.5:        print("燃烧速度偏快, 建议暂停非必要发布")    else:        print("预算消耗正常, 可继续迭代")  if __name__ == "__main__":    simulate_diner()

1. LatencyRecorder(slo_ratio=0.95, slo_line=30.0)创建一个“面馆记录器”：要求95%的订单在30分钟内送达，这两者就是SLO。
2. if latency > self.slo_line: self.bad_count += 1每单延迟超过红线就记一次超时，这是SLI的原始采集。
3. idx = int(math.ceil(p / 100.0 * len(ordered))) - 1把延迟排序后定位第p百分位，用来算P95和P99。
4. error_rate = self.bad_count / self.total_count实际超时率，对应面馆打烊后统计的“搞砸比例”。
5. burn_rate = error_rate / allowed_error实际超时率除以允许超时率得到燃烧率，超过1说明预算亮红灯。

常见误区

面试题