漫谈SLA

SRE运维实践

发布于 2019-07-08 13:24:01

2.5K0

发布于 2019-07-08 13:24:01

文章被收录于专栏：SRE运维实践SRE运维实践

序言

纵观运维的各项技能，了解各种各样的中间件，tomcat，redis，mongo，nginx等等等，但是又有什么意思？

看看各种各样的算法，其实也就那样，看看各种运行，参数，配置，问题解决。。。嗬，狗上狗也行（表示无论什么样的人都可以做，替代性太强），那又有什么意思？

看看在进行运维的时候，别人在吹嘘什么。要么吹嘘创建了一个自动化运维系统，实现了某某功能；要么就是创建了一个新的系统，构建了高可用，高可靠的服务。。。运维的核心在哪儿？开发是写程序，测试是看性能，DBA是围绕着DB，那么运维干啥？广而不深。。。Emmm，这不科学，运维的核心只能是SRE或者利用各种开源组件构建高性能，高可用，高扩展，成本更低的系统。

风言风语

是什么限制了你的思维？知识框架？底层结构？数据流向？

SLA服务质量协议，在常规的领域中，总是设定所谓的三个9，四个9来进行表示，当没有达到这种水平的时候，就会有一些列的惩罚措施，而运维，最主要的目标就是达成这种服务水平。

SLA的计算方式，是使用正常运行时间/（正常运行时间+故障时间），当指标为99.99的时候，每年的停机时间只有52.26分钟。。。停机时间又分为两种，一种是计划内停机时间，一种是计划外停机时间，而运维则主要关注计划外停机时间。

在分布式系统中，哼。。。用时间指标来衡量系统的可用性，简直就是无效的。。。分布式系统中，部分可用的情况太多了，例如后端有两个rs，而一个rs坏了，那么就会有百分之五十的请求失败。。。这种情况SLA怎么来计算？扣时间还是不扣呢？

在分布式系统中，一般使用请求的成功率来计算SLA，也就是SLA=请求成功/（请求成功+请求失败），在使用这种计算方式的时候，无论你是前端的web服务，还是后端的存储服务，还是离线服务，都是可以很好的计算。。。毕竟是一个可以量化的数据。

在进行定义这些关键性指标的时候，也就是定义哪些请求成功，哪些请求失败，是有很大关系的，例如支付宝的核心功能是支付，如果支付功能可以，那么就满足了大多数的高可用，而所谓的其他的一些附加功能，例如城市服务，也影响不了多少人，当然。。。也要看基数。

在提供服务的时候，服务可以分为两种类型，一种类型是面对消费者的服务，一种是基础设施服务，例如微信就是面对消费者的服务，而各种云平台则是基础设施服务。

当面对消费者服务的时候，一般会有对应的产品经理，那么可以由产品经理定义各种关键性的指标来衡量一个服务的可用性，例如微信在定义的时候，可以使用发送消息的成功率；消费者服务，可以参考竞争对手的可用性水平；免费的还是收费的；有没有替代产品可以使用。。。在这个时候，其实还可以定义服务降级，例如微信最常用的功能是发送消息和朋友圈，这两个服务的可用性可以定义为四个9，而对于所谓的摇一摇，附近的狗等服务，可以定义低等级的可用性，例如两个9，这种构建方式，可以很大程度上节省成本，毕竟物理服务器冗余才是提高可用性的唯一方式。。。

在消费者服务类型中，还需要注意每个请求的成败后果是不一样的，例如系统注册，或者是一个信息发送失败，系统注册失败，可能就不用这个系统了，而一个信息发送失败，用户可能认为是自己的网络有问题。。。

在提供基础设施服务的时候，一般分为两个部分，一个部分是直接提供给用户使用的功能，例如提供VM访问服务；一个部分是平台的管控功能，例如云平台里面创建虚拟机，创建SLB等。这两个的失败是完全不一样的，用户的功能出了问题，那么就是故障了，但是管控服务出现问题，只要及时修好就行了，这种一般使用的评率很少，所以请求数量也不多。