这些指标是不是都很熟悉？那该怎么选呢？好像每一个指标都很重要啊！
你好，我是赵成，欢迎回来。
还是先来复习下上节课讲的“系统可用性”的两种计算方式，一种是从故障角度出发，以时长维度对系统进行稳定性评估；另一种是从成功请求占比角度出发，以请求维度对系统进行稳定性评估。同时，我们还讲到，在SRE实践中，通常会选择第二种，也就是根据成功请求的比例来衡量稳定性：
Availability = Successful request / Total request
SRE强调的稳定性，一般不是看单次请求的成功与否，而是看整体情况，所以我们会把成功请求的占比设定为一个可以接受的目标，也就是我们常说的“3个9”或“4个9”这样的可量化的数字。
那么，这个“确定成功请求条件，设定达成占比目标”的过程，在SRE中就是设定稳定性衡量标准的SLI和SLO的过程。
具体来看下这两个概念。SLI，Service Level Indicator，服务等级指标，其实就是我们选择哪些指标来衡量我们的稳定性。而SLO，Service Level Objective，服务等级目标，指的就是我们设定的稳定性目标，比如“几个9”这样的目标。
SLI和SLO这两个概念你一定要牢牢记住，接下来我们会反复讲到它们，因为落地SRE的第一步其实就是“选择合适的SLI，设定对应的SLO”。
好，那我们就正式开始今天的内容。我会带你彻底理解SLI和SLO这两个概念，并掌握识别SLI、设定SLO的具体方法。
SLI和SLO这两个概念比较有意思，看字面意思好像就已经很明白了，但是呢，仔细一想，你会发现它们很抽象。SLI和SLO指的到底是啥呢？
接下来我给你讲一个具体的例子，讲完后，你肯定就能理解了。
我们以电商交易系统中的一个核心应用“购物车”为例，给它取名叫做trade_cart。trade_cart是以请求维度来衡量稳定性的，也就是说单次请求如果返回的是非5xx的状态码，我们认为该次请求是成功的；如果返回的是5xx状态码，如我们常见的502或503，我们就判断这次请求是失败的。
但是，这个状态码只能标识单次请求的场景。我们之前讲过，单次的异常与否并不能代表这个应用是否稳定，所以，我们就要看在一个周期内，所有调用次数的成功率是多少，以此来确定它是否稳定。比如我们给这个“状态码返回为非5xx的比例”设定一个目标，如果大于等于99.95%，我们就认为这个应用是稳定的。
在SRE实践中，我们用SLI和SLO来描述。“状态码为非5xx的比例”就是SLI，“大于等于99.95%”就是SLO。说得更直接一点，SLO是SLI要达成的目标。
通过这个例子，你现在是不是已经理解了这两个概念呢。SLI就是我们要监控的指标，SLO就是这个指标对应的目标。
好，那接下来我们要解决的问题就很具体了。我们应该选择哪些指标来监控系统的稳定性？指标选好后，对应地怎么定它的目标呢？下面咱们就一一来探索。
我们先来讨论怎么选择SLI。要回答怎么选择这个问题，我们得先来看看都有哪些可供选择的指标。
在下面这张图中，我列举了系统中常见的监控指标。
这些指标是不是都很熟悉？那该怎么选呢？好像每一个指标都很重要啊！
确实，这些指标都很重要。我们可以通过问自己两个问题来选择。
第一个问题：我要衡量谁的稳定性？ 也就是先找到稳定性的主体。主体确定后，我们继续问第二问题：这个指标能够标识这个实例是否稳定吗？ 一般来说，这两个问题解决了，SLI指标也就确认了。
从我的经验来看，给指标分层非常关键。就像上图那样分层后，再看稳定性主体是属于哪一层的，就可以在这一层里选择适合的指标。但是，你要注意，即便都是应用层的，针对具体的主体，这一层的指标也不是每一个都适合。
根据这几年的实践经验，我总结了选择SLI指标的两大原则。
原则一：选择能够标识一个主体是否稳定的指标，如果不是这个主体本身的指标，或者不能标识主体稳定性的，就要排除在外。
原则二：针对电商这类有用户界面的业务系统，优先选择与用户体验强相关或用户可以明显感知的指标。
还拿我们上面trade_cart的例子来说，主体确定了，就是trade_cart，应用层面的，请求返回状态码和时延就是很好的指标，再来检查下它们能否标识的trade_cart稳定性，毫无疑问，这两个指标都可以，那么请求返回状态码和时延就可以作为trade_cart稳定性的SLI指标。
我们换一个指标，CPU的使用率这个指标适合吗？根据我们刚才说的原则，既然我们关注的是trade_cart的运行状况，而CPU是系统层的指标，所以，在选择应用层SLI的指标时，自然会把CPU排除掉。
你可能会说，这样是不是太武断了呀？
我们简单来分析下。假设CPU使用率达到了95%，但是只要CPU处理能力足够，状态码成功率可能还是保持在4个9，时延还是在80ms以内，用户体验没有受到影响。另外一种情况，假设CPU使用率只有10%，但是可能因为网络超时或中断，导致大量的请求失败，甚至是时延飙升，购物车这个应用的运行状态也不一定是正常的。所以结论就是，CPU使用率不管是10%还是95%，都不能直接反映trade_cart运行是正常还是异常，不适合作为trade_cart这样的应用运行稳定性的SLI指标。
讲到这里，你可能会问，哎呀，你说的这两个原则我理解了，分层也大概能做到，但是我还是需要做很多详细的分析才能选择出SLI指标，有没有什么更便捷、更快速的方法来帮助我选择啊？
嗯，不要着急，还真有这样一套方法。怎么选SLI，我们可以直接借鉴Google的方法：VALET。
VALET是5个单词的首字母，分别是Volume、Availability、Latency、Error和Ticket。这5个单词就是我们选择SLI指标的5个维度。我们还是结合trade_cart这个例子，一起看一下每个维度具体是什么。
Volume-容量
Volume（容量）是指服务承诺的最大容量是多少。比如，一个应用集群的QPS、TPS、会话数以及连接数等等，如果我们对日常设定一个目标，就是日常的容量SLO，对双11这样的大促设定一个目标，就是大促SLO。对于数据平台，我们要看它的吞吐能力，比如每小时能处理的记录数或任务数。
Availablity-可用性
Availablity（可用性）代表服务是否正常。比如，我们前面介绍到的请求调用的非5xx状态码成功率，就可以归于可用性。对于数据平台，我们就看任务的执行成功情况，这个也可以根据不同的任务执行状态码来归类。
Latency-时延
Latency（时延）是说响应是否足够快。这是一个会直接影响用户访问体验的指标。对于任务类的作业，我们会看每个任务是否在规定时间内完成了。
讲到这里，我要延伸下，因为通常对于时延这个指标，我们不会直接做所有请求时延的平均，因为整个时延的分布也符合正态分布，所以通常会以类似“90%请求的时延 <= 80ms，或者95%请求的时延 <=120ms ”这样的方式来设定时延SLO，熟悉数理统计的同学应该知道，这个90%或95%我们称之为置信区间。
因为不排除很多请求从业务逻辑层面是不成功的，这时业务逻辑的处理时长就会非常短（可能10ms），或者出现404这样的状态码（可能就1ms）。从可用性来讲，这些请求也算成功，但是这样的请求会拉低整个均值。
同时，也会出现另一种极端情况，就是某几次请求因为各种原因，导致时延高了，到了500ms，但是因为次数所占比例较低，数据被平均掉了，单纯从平均值来看是没有异常的。但是从实际情况看，有少部分用户的体验其实已经非常糟糕了。所以，为了识别出这种情况，我们就要设定不同的置信区间来找出这样的用户占比，有针对性地解决。
Errors-错误率
错误率有多少？这里除了5xx之外，我们还可以把4xx列进来，因为前面我们的服务可用性不错，但是从业务和体验角度，4xx太多，用户也是不能接受的。
或者可以增加一些自定义的状态码，看哪些状态是对业务有损的，比如某些热门商品总是缺货，用户登录验证码总是输入错误，这些虽不是系统错误，但从业务角度来看，对用户的体验影响还是比较大的。
Tickets-人工介入
是否需要人工介入？如果一项工作或任务需要人工介入，那说明一定是低效或有问题的。举一个我们常见的场景，数据任务跑失败了，但是无法自动恢复，这时就要人工介入恢复；或者超时了，也需要人工介入，来中断任务、重启拉起来跑等等。
Tickets的SLO可以想象成它的中文含义：门票。一个周期内，门票数量是固定的，比如每月20张，每次人工介入，就消耗一张，如果消耗完了，还需要人工介入，那就是不达标了。
这里我给出一个Google提供的，针对类似于我们trade_cart的一个应用服务，基于VALET设计出来的SLO的Dashboard样例，结合上面我们介绍的部分，就一目了然了。
好，VALET我们就讲完了，怎么选SLI指标，你是不是一下子就清楚了。可以说，这是一个我们可以直接复用的工具。上面Google的这张SLO样例图，建议你多看几遍，看到时候，对比思考下自己系统的情况。
到这里，我们已经能够根据自己想要保障稳定性的主体，来选择合适的SLI指标了，也知道SLO就是对应SLI要实现的目标，比如“几个9”。
但是，我们前面讲到了系统可用性：
Availability = Successful request / Total request
然后又深入到了提炼具体的SLI，以及设定对应的SLO，那这两者之间是什么关系呢？也就是通过SLO应该怎么去计算我们的系统可用性的呢？这就涉及到系统整体可用性的两种计算方式。
第一种，直接根据成功的定义来计算。
也就是我们前面定义一个请求的返回状态码必须是非5xx才算成功，同时时延还要低于80ms，同时满足这两个条件，我们才算是成功的，也就是纳入上述公式中Successful request的统计中，用公式来表示：
Successful = （状态码非5xx） & （时延 <= 80ms）
如果还有其它条件，直接在后面增加做综合判定。
但是，这种计算方式存在的问题就是，对单次请求的成功与否的判定太过死板，容易错杀误判。比如我们前面讲对于时延，我们一般会设定置信区间，比如90%时延小于等于200ms这样的场景，用这种方式就很难体现出来。而且，对于状态码成功率和时延成功率的容忍度，通常也是也不一样的，通过这种方式就不够准确。所以，我们就会采取第二种方式。
第二种方式，SLO方式计算。
我们前面讲时延时讲过以下几个SLO，这时我们设定稳定性的时候，就需要把公式计算方式灵活调整定义一下了。
直接用公式表示：
Availability = SLO1 & SLO2 & SLO3
只有当这个三个SLO同时达标时，整个系统的稳定性才算达标，有一个不达标就不算达标，这样就可以很好地将SLO设定的合理性与最终可用性结合了起来。所以，通常在SRE实践中，我们通常会采用这种设定方式。
如果是这样，第一种方式是不是就没有用途了呢？当然不是。第一种计算方式也会有它特有的应用场景，它通常会被利用在第三方提供的服务承诺中，也就是SLA（ Service Level Agreement）。因为对于第三方提供商来说，比如云厂商，它们要面对的客户群体是非常大的，所以很难跟每一家客户都去制定像SLO这么细粒度稳定性目标，而且每家客户对稳定性的要求和感知也不同，就没法统一。
这种情况下，反而是第一种计算方式是相对简单直接的，但是这样也决定了SLA的承诺相比SLO肯定也相对比较宽松，因为SLA是商业服务承诺，如果达不成是要进行赔偿的。关于SLA，最直接的参考资料，就是各个公有云厂商在官网公开的信息资料，你可以找到这些资料，作为自己的一个补充学习。
讲到这里，怎么选择SLI指标、如何制定SLO目标，我们就介绍完了。你需要掌握下面三个重点。
最后，给你留一个思考题。
下面我给出一个Google的SLI和SLO设定标准示例，内容很直观，需要你认真研究一下这个文档，结合今天我们所讲的内容，请你尝试按照Google提供的规范格式，制定一个自己所负责系统的SLO。
Google的SLI和SLO设定模板链接：https://landing.google.com/sre/workbook/chapters/slo-document
另外，对今天的内容如果你还有什么疑惑，都可以在留言区提问，也欢迎你把今天的内容分享给身边的朋友，和他一起学习讨论。
我是赵成，我们下节课见。
评论