做SRE这些年我有个特别深的体会很多人把SLO和SLA当成一回事觉得“反正都是服务质量嘛”。但真正在线上跑过业务、经历过事故善后谈判的人都会告诉你这两者完全是两码事。搞混了轻则团队内部目标混乱重则公司要真金白银地赔钱。SLOService Level Objective服务等级目标是技术团队给自己定的靶子SLAService Level Agreement服务等级协议是公司对外部客户写的保证书。一个是内功一个是承诺。这篇文章我就想用自己踩过的坑、调过的参数、算过的账把这两个概念彻底拆开讲清楚顺带把从SLI定义到SLA落地的完整路径走一遍。1. SLO与SLA的本质差异为什么不能用同一个指标管两件事1.1 一句话先区分两者的定位拿考试打个比方你就明白了。SLO是你自己定的目标分数线比如“期末考试数学要上90分”——这是内部标准你可以根据自己状态调整错了就反思改进。SLA则是你和家长签的协议“如果数学低于60分就取消暑假游戏时间”——这是外部承诺达不到就有惩罚后果。SLO是技术指标面向研发和运维团队用来指导工作SLA是商业条款面向客户和法务用来界定责任。SLO没达到最多是团队复盘写报告SLA没达到那是要触发赔偿流程的财务要掏钱商务要去安抚客户法务要准备应对可能的纠纷。所以你可以看到SLO的管理粒度是分钟级、小时级的它的时间窗口通常很短比如“过去30天可用性达到99.9%”而SLA的管理粒度是月级、季度级的它的话语权掌握在产品和商务手里很少会按小时去考核。1.2 混用SLO和SLA会引发的真实问题我见过一家做B2B SaaS的公司把给客户承诺的SLA写了99.99%可用性但技术团队内部的SLO定的是99.95%。结果某个月线上出了一个多小时的事故技术团队一看——SLO守住了觉得没大事就正常下班了。结果月底商务一看账单当月可用性只有99.98%离承诺的99.99%差了那么一丢丢按合同要赔掉当月服务费的10%。这就是典型的“用SLO的视角去管理SLA”。技术团队觉得自己干得还行但商业层面上已经违约了。反过来如果直接用SLA当SLO用天天用“99.99%”这种高压线去要求内部系统团队会被逼得不敢发布新功能为了指标好看而牺牲迭代速度最后反而拖垮业务。这两个指标服务的对象不同、时间粒度不同、惩罚机制不同硬要混用必然出问题。2. 三兄弟的底层关系SLI、SLO、SLA各管哪一段想要真正用起来光知道SLO和SLA的区别还不够还得引入SLIService Level Indicator服务等级指标。这三者是一套链条没搞清楚SLI就想定SLO基本等于在沙滩上盖楼。2.1 SLI把主观体验翻译成可量化数字SLI是最底层的数据它回答的问题是“我们的服务到底有多好”。好的SLI必须满足两个条件可测量、能反映用户体验。常见的有这么几类可用性请求成功数除以总请求数。比如“99.9%的请求成功返回”。延迟一定比例如95%、99%的请求在多少毫秒内完成。吞吐量每秒能处理的请求数或事务数。数据正确性比如搜索结果返回了非空结果的比例、推荐内容的点击率。这里有个关键原则SLI要选用户真正能感知到的不要选技术细节。比如你监控的是数据库连接池的可用性但用户感知到的却是页面加载超时。数据库连接池满了HTTP请求同样超时用户根本分不清是数据库问题还是网络问题。所以SLI要尽量贴近用户视角把底层多个技术组件的健康度转换为“端到端请求的成功率和延迟”。我当年踩过最深的坑是拿一条“支付成功率”SLI去衡量整个支付链路结果数据波动大得离谱因为没有拆开“收银台请求成功率”和“支付渠道回调成功率”。用户页面都跳到银行那边去了结果银行返回失败收银台这边算成功指标自然失真。2.2 SLO给指标加上目标和时间窗口SLO是SLI的目标值它回答“我们希望服务好到什么程度”。一个完整的SLO由三个要素构成SLI监控用哪个指标目标值SLI要大于或小于哪个数时间窗口这个目标在哪个周期内衡量举两个不同维度的SLO实例“过去30天首页API的可用性要≥99.9%”可用性SLO“过去7天登录接口P95延迟要≤500ms”延迟SLO注意时间窗口这个点不同的窗口适合不同的场景。30天窗口适合看整体稳定性7天窗口适合捕捉近期趋势更短的窗口适合告警。SRE圈公认的做法是把窗口拉长因为短窗口波动太大很容易因一次小抖动触发误判。2.3 SLA把目标升级成合同条款SLA在SLO之上再加上商业属性明确适用范围、统计口径、赔偿规则、例外情况。SLA回答的是“如果服务没达到承诺怎么承担责任”。一个完整的SLA条款通常包含以下内容承诺的服务水平就是定好SLO中的目标值可以直接引用如果达不到的赔偿方案服务费折抵、优惠券等哪些情况不算违约计划内维护、客户自身原因等计算方式按月度可用性还是按年度可用性来算比较清晰的对比我整理了个表维度SLISLOSLA本质测量指标目标阈值合同承诺对象内部技术团队内部技术团队外部客户粒度分钟/小时天/月/季度月/季度/年未达标的后果无团队复盘改进赔偿、法律风险话语权归属工程师工程师/技术管理者商务/法务/产品典型例子请求成功率99.95%30天可用性≥99.9%月度可用性≤99.9%否则赔10%费用3. 目标怎么定才靠谱SLO数值设计与错误预算原理3.1 为什么99.9%不是拍脑袋拍出来的很多团队定SLO第一反应是“人家都写99.9%那我们也写99.9%吧”。这完全搞反了。SLO的目标值应该由业务需求推导出来不是对标行业参数。推导过程通常是这样的先确认用户的核心旅程是什么。比如电商的“搜索→浏览→下单→支付”链路。估算每一步的SLO。如果支付这一步SLO是99.95%搜索可以放宽到99.9%浏览页可以再降到99.5%因为浏览偶发失败对用户影响不大。把链路SLO层层分解到每个组件。比如支付SLO 99.95%可以分解为收银台API 99.98%、支付渠道回调99.97%。一个非常关键的计算细节多个组件合成后整体SLO不会比最差的组件更好。假如支付依赖3个组件每个组件可用性都是99.9%理论上整条链路可用性是99.9% × 99.9% × 99.9% ≈ 99.7%比你预期的99.9%低不少。所以定下游组件SLO时必须考虑这种乘法叠加效应。我一般会把链路上最关键的两个依赖设成99.99%甚至更高把边缘组件放宽到99.5%用“保关键、放边缘”的思路来控制整体风险。3.2 错误预算把可靠性当成本来管理Google SRE团队提出的错误预算Error Budget概念是解决SLO与迭代速度矛盾的利器。思路非常简单粗暴承诺可用性99.9%等于允许不可用时间占0.1%一个月30天的0.1% 43.2分钟这43.2分钟就是本月的“错误预算”预算花完了线上发生的事故再严重本月的发布就得冻结转去专门做稳定性建设这个机制精妙在哪里它把抽象的“可靠性”变成了可见的资金池。错误预算既给了研发团队快速试错的空间又给了稳定性工作一个明确的优先级信号。当预算余额不足时就算新功能再重要也得为稳定性让路而不是某个人拍脑袋说“这周不能发布”“这周可以发”。实操中我常用的是按周做预算消耗跟踪。如果第2周就花掉了80%的预算那团队必然是哪里出了大问题得立刻排查如果到月底还剩50%预算没用说明SLO定的太保守了可以调高目标或者放开发布节奏。3.3 从SLO倒推告警阈值很多团队的监控告警是“凭感觉设阈值”——把告警阈值定在90%、80%结果天天响只能“告警免疫”。SLO框架下的告警逻辑其实很清晰围绕错误预算消耗来告警而不是围绕某个瞬时指标。具体做法是设置两个级别的告警预警错误预算消耗速率超过预期。比如月初就花了15%的预算按此速度月底必超立即排查。告警错误预算已经耗尽或短时间内消耗速率异常飙升。立即响应。这里我自己常用的一个方法是“多窗口法”用1小时窗口和6小时窗口同时看错误率。1小时窗口内的错误率超过SLO允许的瞬时峰值触发高优告警6小时窗口累积的错误率超了也触发告警但优先级可以低一些。多窗口的好处是既能捕捉突然爆发的故障又不会因为瞬时毛刺频繁打扰值班人。另外提一句很多人以为告警阈值就是SLO目标值这不对。假如SLO是99.9%出现持续几分钟0.5%的错误率怎么看单看这个值没超0.1%失败率但累积起来就可能吃掉大量预算。所以要用SLO的倒数最大允许失败率和当前窗口实际失败率做比较而不是拿瞬时值和目标值硬比。4. SLA设计实战条款、赔偿与例外条款4.1 服务窗口与赔偿阶梯SLA里的“可用性”定义必须写清楚统计窗口。业界最常见的做法是按月计算公式大致是当月可用性 当月总时间 – 不可用时间 / 当月总时间但这里面有个隐蔽的坑对“不可用时间”的定义。到底是“所有用户都不可用”才算还是“超过一定比例用户不可用”就算一般建议在SLA里定义清楚“超过5%的用户或请求受影响才记为不可用”。否则一次只影响0.1%用户的故障就可能被客户按条款索赔公司会很亏。赔偿阶梯一般这样设计可用性低于99.9%、高于99.5%返还当月费用5%可用性低于99.5%、高于99%返还当月费用10%可用性低于99%返还当月费用20%或支持无条件解约赔偿阶梯的设计原则是“赔偿力度要真实但不要让公司亏到无法承受”。SLA不是越严越好它是商业上的一种平衡既给客户信任感又控制极端情况下企业的损失边界。4.2 除外条款不能抄模板我见过太多公司的SLA除外条款直接抄AWS或者阿里云的模板结果一用就出问题。最常见的除外条款包括计划内维护窗口客户自身原因导致的故障源站被攻击、客户代码问题第三方不可抗力机房断电、光纤被挖断、极端天气客户未按约定支付费用的时期抄模板的问题在于模板里的“计划内维护窗口”可能写的是“提前48小时邮件通知”而你们的客户可能根本不看邮件需要短信电话双重通知。又比如“客户自身原因”B2B场景里如果不登记清楚客户的具体操作边界到时候对方可以赖账说“不是我们的问题”。我自己的建议是除外条款必须结合业务形态挨条过一遍。比如你们做的是数据库托管那“客户自身原因”必须明确到“客户慢查询导致实例负载异常”这样的级别如果做的是CDN就得把“源站故障”单列出来写清楚。4.3 与合作方SLA对接的坑做B端或SaaS业务服务链上往往有第三方依赖你依赖云计算服务商你的客户又依赖你。这类上下游SLA对接是坑最多的领域。举个例子客户对外承诺SLA 99.99%但他的系统依赖你们提供的一个API而你们的SLA只有99.9%。理论上客户的SLA就不应该对外写99.99%除非通过多活架构、本地缓存等手段绕开单点依赖。但实际上很多商务去谈合同时根本不管这些销售为了赢单先承诺了再说。等出了问题技术和商务一碰双输。我的建议是销售出合同前内部必须有一套“SLA可行性评审”。技术团队给出当前最薄弱的依赖环节和SLO数据商务根据这个数据反向决定能承诺多少。这一步虽然繁琐但能替公司挡掉大量不可控的赔偿风险。5. 从零落地SLO体系五步实操流程5.1 第一步挑核心用户旅程SLO落地的第一步不是翻监控系统拉一堆指标而是确定“哪个用户旅程最重要”。你会为所有功能都设SLO吗不建议SLO如果设了太多团队注意力会被摊薄反而哪个都守不住。建议挑1~3条核心用户旅程。比如电商首页加载→搜索→进入商品详情→加购浏览购物车→提交订单→支付→支付成功回调登录→个人中心→查询历史订单每条旅程选一个主SLI最多两个。比如“首页加载”主SLI用“页面加载成功率3G/4G网络下P90延迟”“支付”主SLI用“支付成功率”。5.2 第二步定义SLI和采集方案确定旅程后就得为每个SLI定义精确的计算公式和数据来源。这一步最容易被技术团队拖很久因为很多人想在“完美的数据平台”上再做SLO结果永远做不出来。我的经验是“先用已有监控数据起步再逐步迭代”。哪怕你只有负载均衡日志算请求成功率也能先把毛坯搭起来。SLI要从日志、监控系统、网关指标中提取不必等全链路追踪系统建好。定一个SLI清单模板指标名首页请求成功率计算公式HTTP状态码500的请求数 / 总请求数数据来源负载均衡日志或API网关判断成功的定义2xx和3xx都算成功4xx不算服务端故障采集频率1分钟聚合这里有个关键点4xx算不算失败答案是不算。用户请求的参数错误、权限不足这是用户侧问题不反映服务健康度。计算SLI时要把4xx从分母中排除或者标记为用户错误否则一个小爬虫疯狂发404会把成功率瞬间拉低。5.3 第三步定SLO目标这一步要开会邀请业务、产品、技术代表共同拍板。我常用的方法是“先算账、后拍板”先算出当前系统的实际SLI表现比如过去90天每天的成功率均值是99.8%。再结合业务预期客户投诉率、销售承诺、竞品参数。给出建议值比如SLO定99.9%这意味着当前系统水平还不够需要额外投入改进或定99.5%留有充分预算。SLO定出来不是用来看的而是要成为团队绩效的一部分。我的做法是把它写进研发团队的季度OKR里跟发布节奏、值班轮换绑定。5.4 第四步搭建错误预算告警告警是保证SLO有效落地的手段。建议用现成的SLO监控工具或者自建一个简单系统每天凌晨计算一次“过去30天滚动错误率”并推送到群。推荐Prometheus Grafana的组合来搭建重点就是定义好两个指标slo_error_budget:burn_rate预算消耗速率slo_error_budget_remaining剩余预算如果剩余预算低于5%立刻触发热线告警低于20%触发一般告警。如果消耗速率连续2小时超过预测速率的2倍也要触发告警哪怕预算还很多——因为这说明正在发生持续故障不及时处理很容易失控。5.5 第五步回填SLA与流程SLO落地后把表现稳定、团队有信心守住的目标值整理成对外SLA的候选条款。这里要注意SLO能改SLA不能随便改。SLA一旦写进合同变更要法务和商务走流程所以SLA里的数值要留一定余量。我运营时有个习惯动作每季度末把本季度SLO达标情况和SLA触发情况一起拉出来对比一次。如果连续3个月SLO都是99.99%而对外SLA只承诺了99.9%说明SLO定的太保守可以上调如果SLO达标靠的是“冻结发布换来的”就得反思业务是不是被稳定性绑架了该考虑调低SLO以换取迭代速度。6. 常见问题与排查技巧实录6.1 典型的误用场景速查现象根因正确处理SLA三天两头触发赔偿SLA数值由商务拍板没跟技术对过建立SLA发布前的技术评审会团队天天围着失败率告警转新功能没法发SLO定的太紧没有错误预算概念引入错误预算机制允许适当消耗监控系统告警太多值班人免疫了瞬时指标阈值设太低改用错误预算消耗速率做告警指标显示正常用户频繁投诉SLI选错了没贴近用户体验用核心用户旅程重新定义SLI月度可用性达标但季度赔偿不断时间窗口定义不清被客户按指定区间索赔SLA里写清楚统计时段和统计口径6.2 几个实操中容易翻车的细节细节一百分位延迟的采样率。很多人用P99延迟做SLO但数据采样率不够比如只取了1%的样本P99根本算不准。要保证采样覆盖率最好的办法是让网关层对每个请求都记录延迟或者用直方图聚合避免丢失长尾请求。细节二全局SLO vs 分模块SLO。只设一个全局SLO出了问题往往不知道是哪个模块拖后腿。建议至少拆两层全局层用户端整体可用性和模块层登录、订单、支付等关键模块。全局SLO用于对外模块SLO用于内部排查。细节三SLO变更流程。SLO不能今天改一下、明天改一下否则就失去了衡量基线的作用。至少以季度为周期做SLO调整每次调整要记录原因并重新校准告警阈值。6.3 当SLO守住但SLA赔钱时的通用排查思路这种情况说明对外承诺的口径和内部目标的定义不一致。按这个顺序排查先核对统计口径SLA里的“不可用时间”是怎么定义的SLO里的“失败率”是怎么算的。两种口径下同一个故障可能一个算失败、一个不算。再核对时间窗口SLA是按自然月算SLO可能是滚动30天。滚动窗口会把上个月的故障顺延到本月导致SLO显示正常但月SLA被击穿。最后核对计算粒度SLA判断的是整个账号粒度还是全局粒度。有的客户是独占集群而内部SLO是按整个系统算的客户层面自然容易出现单点偏差。排查完这几步基本就能定位“报表正常、合同违约”的病根。7. 写在最后一些真实的心得做稳定性这么多年我越来越认同一个观点SLO和SLA不是监控系统里的两个标签而是商业和技术的翻译层。SLO把复杂的系统状态翻译成工程团队能执行的目标SLA再把工程目标翻译成客户能信任的商业承诺。翻译不到位两边就会各说各话最后背着锅的永远是值班工程师和售后团队。如果你所在的团队还停留在“写个SLA挂在官网”的阶段我建议从最小闭环开始挑一条核心链路定一个SLI设一个SLO配一个错误预算告警。哪怕只是做到了这三步半年之后你回头看会发现团队对待故障的态度、发布节奏的把握、跨部门协作的效率都会有一个质的提升。我自己的团队就是靠这个“最小闭环”从天天救火的状态逐步走到了有事按预算决策的状态。这个转变不是靠某个神器实现的就是靠把度量、目标、预算这三个词落到实处。