SLA/SLO Implementation Journey at 严选

1 前言

你肯定听到过“我的服务一个季度能做到99.99%的可用率”、“我能做到3个9”、“我能做到5个9”之类的话，其背后的SLA/SLO到底是一套什么样的理论？为何在那么多国内外大型互联网公司广泛使用？严选在2年前也引入SLA/SLO并建设落地，将之用作一个线上质量和稳定性的保障手段。本文将给大家分享一下严选的SLA/SLO建设旅程，以及落地后给严选带来了哪些价值。

2 快速扫盲

SLA/SLO方法论里有好几个专业术语，老司机知道其含义，但为了照顾萌新读者，这里做一下简单扫盲（不展开详细介绍）。

2.1 SLI

Service Level Indicator，指一个可量化的服务指标，简称“指标”。常见如：Latency（请求响应的延迟时间，严选内部常用rt代称之，rt=ResponseTime）、Error（请求的错误响应率，严选内部常用5xx代称之，其实定义上还包括了各种exception）、Throughput（吞吐量）、Accuracy（准确性）、Freshness（实时性）、……

2.2 SLO

Service Level Object，指服务为某个黄金指标设置一个期望的运行状态，并指定阈值，简称“目标”。常见如“请求延迟不大于300ms”、“5xx错误率小于0.5‰”等。多条SLO规则之间是相互独立，无因果无依赖关系的，任一不满足则意味着该服务出问题。

2.3 Downtime

也叫服务宕机时间或者不可用时间，指一个服务处于不可用状态的总时长。何谓“不可用状态”？没错，就是任意一条SLO不达成。一条请求SLO不达成，处理这条请求（从接收到请求到处理结束）所花费的时间长度就是一份Downtime。Downtime就是俗称的“我的服务挂了x分钟”的时间长短，服务的Downtime越长则直接表明该服务的线上生产环境表现越差。

2.4 SLA

Service Level Agreement，一个服务对外承诺的最低可用率，由一个评定周期和一个可用率目标组成。如“每季度要达到99.99%”，其中“季度”就是所选定的评定周期（通常是月、季度、半年度、年度这四种自然周期），而“99.99%”就是所选定的可用率目标（常见有99%（2个9）、99.9%（3个9）、99.95%（3.5个9）、99.99%（4个9）、99.999%（5个9）等，5个9是互联网行业的一道坎，几乎是最高标准了，金融等特殊行业才可能会要求做到更高）。

2.5 EB

Error Budget，错误预算，指服务在一段时间内最多可容忍多长时间的Downtime。是的，你可能想到了，EB就等于1减去SLA再乘以评定周期并换算成时间单位。一旦服务挂了产生Downtime，就会开始扣减EB预算，EB扣光就等于跌破SLA。前面为什么说“5个9”几乎是互联网行业最高标准？因为99.999%意味着你的服务在一年内最多宕机不超过5分钟！平均到每个季度也只有77秒，这是很有挑战的，对一家企业的故障监控、报警响应、故障恢复等系统都有极高要求，假如不能降低MTTR时间，充分控制Downtime发生，那EB就会被耗光。当然，EB本质上是一种预算，你可以去花，但不能花光，也尽量别去花。同时，EB零损耗和EB未耗尽都是义务，不会有奖励性措施。

2.6 总结

从这些术语解释中，你应该可以隐约感受到这套SLA/SLO方法论为什么可以科学量化服务/产品的线上质量的基本原理了吧？概况地说，就是服务可以实现给自己预先设定好一个可用率承诺（SLA）并对外宣告，同时设置一些SLO作为监控规则，系统自动跟踪服务在线上环境的真实表现，一旦表现违反了某条SLO则开始计算Downtime并用于扣减EB。EB扣减越多，SLA就从100%开始往下掉，直至EB扣光，那么很遗憾，你这个周期的SLA就不达标了。

3 系统建设

SLA/SLO是一套方法论，本身只是一套理论，并没有标准实现。因此，在不同企业的实际落地会不完全一样，因为不同企业的业务模式和管理诉求会有差异。这没问题。

3.1 原始理论的本土化

在遵循SLA/SLO理论主体的前提下，严选本土化时先做了下面一些“量身定制”（可以理解为一些conventions/overwrites）：

选定最适合严选的SLI，考虑到严选（电商）核心业务的技术实现都是各式各样的Webapp在线服务（主站、活动、交易、供应链、分销、等，主要基于HTTP和RPC协议），黄金指标选定了Latency（rt）和Error（5xx）这两个。为何是这两个？rt变大就是接口响应变慢了，5xx变多就是接口功能异常了，这二者都将导致本服务的服务质量和调用方体感的直接下降，是衡量HTTP&RPC的最佳黄金指标。

SLO规则是要求每个严选微服务为服务整体和本服务1~10个核心业务接口（很多公司的SLO实践只支持针对服务整体而不支持对接口粒度配SLO的）的2个黄金指标分别都配置上去。假如一个微服务有5个核心接口，那么它将配置上1×2+5×2=12条SLO。SLO的阈值需要经过充分推演和评审，并且不能超过某条基线，如L1服务的接口响应时间不能超过2秒（否则用户体感会很差）。

EB选择宕机总时长的形式（时间预算），而不是失败请求总量（数量预算）。由系统每天凌晨自动遍历本服务前一天的全部请求（时间上覆盖365×7×24，周末/夜间/节假日亦包含），每一个请求都计算一遍SLO，任一SLO不满足则标记该请求为异常请求。待前一天全部异常请求都找出来后，将它们在一个自然天的[00:00:00.000, 23:59:59.999]时间轴上垂直去重（确保同一个请求不会被多次计算，也确保发生多个异常请求的同一时刻只被算为一份）后计算出当天一共产生了多长时间的Downtime（当天里最少0毫秒，最多24小时），用于扣减EB。

SLA的评定周期仅开放月和季度两个可选（系统实现其实是支持了周、月、季度、年等多种自然周期，但周和年不开放出来），SLA可用率目标则限定在[80%, 99.999%]区间内有限的几个离散值可选，不允许设置92.3%这种“奇奇怪怪”的SLA。要求L1服务的SLA不得低于L2，以此类推，服务等级越高，要求设置越高的SLA承诺。每个微服务必须为自己设置SLA，SLA一旦设置好了就意味着本周期的EB总预算是确定不变的了，修改SLA也是下个周期才生效。每天系统在自动扣减好EB之后，会判断其本周期SLA是否已经不能达成。

定期发送服务周报和产品月报邮件，向研发运维团队告知统计数据、达成情况和一些明显异常，定期组织复盘。SRE和服务/产品负责人也将参照这些数据作为决策依据（如服务拆分、线上扩容等）。同时，革命不能完全靠主动，需要探索SLA不达成的一些惩罚性措施（如发布增加审批人等）。

要求严选全部L1-L3 HTTP服务（都是重要服务，L1是重中之重）都设置SLA和SLO，并且必须有准出评审（研发+运维+负责人），不能随便配，随便改。

考虑到系统不成熟等阶段性原因，向服务开放EB申诉功能，如生产环境全链路摸高压测可能会导致服务线上变慢或者出现5xx报错，进而产生Downtime（因为严选是直接压线上，接口变慢变5xx是可能被真实用户感知到的，是真真切切的线上质量下降）。

在明确了上述本土化定义之后，一份《严选线上质量规范》及配套的一些子规范、接入指引和最佳实践就水到渠成，呼之欲出。

3.2 基于严选DevOps的系统实现

没有严选DevOps工具链建设，这套严选SLA/SLO理论设计将沦为空话，无从落地。在丰富的严选DevOps技术项目建设成果中，对SLA/SLO最终得以从纸面走入现实最最重要的系统是：

CMDB：明确了产品/服务定义，明确了服务编码（如yanxuan-xxx）和服务等级（L1-L3、未定级）、明确了各角色负责人、等等，大大减轻SLA/SLO规范的术语定义成本和沟通成本。

APM：提供了服务运行时的丰富指标的自动化收集，最主要就是Java应用基于javaagent所捕获的请求真实数据，如一个请求当时的路径是什么（Path可对应到接口）、哪里来怎么来（Trace）、要去调用哪个服务、发生在什么时间、rt时间多少（具体到毫秒）、响应码是多少（200/4xx/5xx）、是否有抛出异常（Exception）、等等，系统里有了这些数据，SLO的判断才有从谈起。

数仓/计算：每天的海量的APM数据和大量的严选微服务的接入，都带来了巨大的SLO计算成本，一天的计算体量大约是7+亿（一天APM请求数量） × 700+（个微服务） × 10（每个微服务平均配10条SLO），这么大的计算量必须要求APM请求数据接入数据仓库并配以大数据平台的离线计算框架，只有这样才跑得动SLO的自动化计算。

用户界面：入口放在服务治理平台SNest上，用户可在此配置SLA、配置SLO、EB速算表、查看达成情况、EB申诉、等等，主要是平台统一收口，降低接入和使用成本，并通过页面交互来确保一些规范约束点的有效落地（如L1服务SLA不得低于99.9%）。

在有了这些系统之后，SLA/SLO理论终于从纸面走入现实。

3.3 主要成果

理论建设有了规范，系统开发有了工具，现在酒酿出来了，别浪费在巷子里，接下去就是运营工作，要到严选技术部门的各个业务板块去布道推广，落地下去。

3.4 价值产出

经过1年时间，这套SLA/SLO工具在建设完成后便推广落地到了700多个webapp微服务上：

微服务做出了SLA承诺：“我这个服务每季度可以做到百分之多少的可用”，这是产品负责人对服务自己的一种要求，同时也是对调用方做出的一种承诺；

微服务设置上了一批SLO规则：“我这个服务/这个接口的rt不会大于多少毫秒”、“我这个服务/这个接口的5xx错误率不会大于万分之几”。同理，对服务来说，对内是一种要求（代码足够优化，部署上足够健壮），对外是一种承诺（调用方设置超时参数，评估降级等决策时可参照）；

微服务日常管理和运营：利用SLA和SLO报表，定期复盘，可以发现线上有哪些性能隐患，有依赖风险，有拆分需求，有扩容诉求，等等。

严选业务板块的已定级微服务在经过充分的准出评审之后，配置上SLA和SLO后就算是正式接入了，接下去就是日常的运营工作，由系统每天自动计算服务的真实表现，量化出这些服务的线上质量。

4 局限性

吹了那么多SLA/SLO的好，那么，这就是一颗银弹，无所不能了吗？不。任何一套理论和工具都有它的预设场景，在这个场景内它效率最佳，收益最高，出了这个场景圈子它的效力就大打折扣，甚至不适用而起反作用（事倍功半）。

不是监控系统。有了SLA/SLO去度量线上质量，不代表你就可以忽视基建监控（硬件/系统/网络监控）、进程监控（APM/日志监控）、业务监控（多个服务多份数据共同组成一个业务行为），弃之不用。

不是无所不能。理论上SLI全集很大，但具体到企业落地时黄金指标就只会选定有限的几个。严选只选了Latency和Error，不代表Throughput、Accuracy、Freshness等其它SLI就没用，只是在综合了技术现状、SLI指标收集成本、ROI等因素考虑之后没被选上而已。对于落选的SLI，就无法为之配置SLO规则，其对应的描述能力就无法用上。

不一定被用好。在严选我们看到很多有着极高追求的服务：有2个服务给自己设置的接口RT阈值是2毫秒（你没看错，是2毫秒，不是20毫秒，也不是2秒）、有3个服务给自己设置的接口Error阈值是万分之1、有4个服务给自己设置的SLA是5个9（嗯，99.999%极限值），对于这些服务来说，随便发生一个网络抖动或者缓存抖动就可能导致守不住，但他们依然选择做勇士，敢于对自己提出高要求。但是，可能你也想到了，这套SLA/SLO的理论和工具里有些细节其实是存在人为操作空间的，如下单接口代码很差那我就故意不给它配SLO规则（我不说你不说，这个接口就漏过去），商品查询接口调用方可以接受500毫秒超时那我就得过且过（虽然我知道经过一定投入去优化是可以提升到200毫秒的，但500阈值对我来说更安全嘛），看到少量Downtime我就视而不见（反正一天只扣一点点，又没扣光我的整个EB预算），等等，这样种种的逃避/作弊行为都会妨碍这套工具的效用发挥到极致。尽管可以通过一些管理手段和规范流程来规避，但提高每位参与者的主动积极性和自觉性，这更重要。

5 小结

当前，SLA/SLO在严选的实践方兴未艾，今年还有很多工作正在开展，譬如高危EB专项整治、重点业务域达成和问题复盘、L1服务SLO规则准出评审、等。

6 扩展阅读

Google SRE团队的经验分享： Chapter 2 - Implementing SLOs：https://sre.google/workbook/implementing-slos/ Chapter 4 - Service Level Objectives：https://sre.google/sre-book/service-level-objectives/

虎牙SRE团队的经验分享： 虎牙直播的SRE实践与思考：https://www.sohu.com/a/218480103_411876 解密SRE的六种能力及虎牙运维实践：https://blog.csdn.net/weixin_33915554/article/details/88706020

一些云厂商官网的SLA承诺： 亚马逊云主机ASW：https://aws.amazon.com/cn/compute/sla/ 阿里云主机ECS：https://help.aliyun.com/document_detail/64695.html 阿里云短信服务：https://help.aliyun.com/document_detail/63935.html 阿里云对象存储OSS：https://help.aliyun.com/document_detail/60175.html

本文由作者授权严选技术团队发布