漫谈SLA
作者：互联网
纵观运维的各项技能，了解各种各样的中间件，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等。这两个的失败是完全不一样的，用户的功能出了问题，那么就是故障了，但是管控服务出现问题，只要及时修好就行了，这种一般使用的评率很少，所以请求数量也不多。
云平台。。。服务太多，几百个几千个微服务，谁知道哪个是管控的功能，谁又知道哪个是会影响用户的共。。。傻傻分不清楚。。。说不清，道不明。。。
在定义SLA的时候，顺便可以定义出监控的主要指标，例如请求的延迟，吞吐量等。
停机外的时间，一般由几种原因引起，大部分都是由于新版本的发布，升级，变更导致，从而。。。开发和运维之战也就把这个作为导火索了。。。
关注SLA，从开发和运维做起，这样可以统一两者之间的目标，不会再为此开战，根据SLA计算出每年或者每个季度的计划外停机时间，当时间充足的时候，开发可以快速的发布新版本，发布新功能，当时间不足的时候，那么开发就应该进行大量的测试，例如各种金丝雀测试，回归测试等保障程序的可靠性。。。
SLA定的太高，那么就要考虑各种因素，假如一个指标是延迟，那么就要考虑分配的资源的地理位置，越近越好。。。DNS？GSLB？
想起DNS和GSLB，有一种故障叫做连锁故障。。。就近原则，为了延迟，当请求来临时，一个机器出现问题，导致整个集群故障，一个集群故障，导致一个机房跪掉。。。修复一个挂一个，呵呵哒。。。贼好玩了。。。一粒老鼠屎弄坏一锅粥
风言风语
话说。。。书中自有颜如玉，书中自有黄金屋，但是，你看的越多，你会发现。。。
看的越多，你会发现越来越渺小。。。说好的读万卷书呢。。。
所谓的成功，天时，地利，人和，缺一不可。。。更多的时候，只是一个机遇问题。。。
标签：例如,服务,请求,运维,漫谈,停机,SLA 来源： https://blog.51cto.com/15060545/2653058