大数据篇：SLA服务等级协议_产品运营问题等级sla

大数据篇：SLA服务等级协议
SLA（Service-Level Agreement），也就是服务等级协议，指的是系统服务提供者（Provider）对客户（Costomer）的一个服务承诺。这是一个衡量大型“分布式“系统是否健康的协议。

 

在开发设计系统服务时，无论是个人还是商业用户，还是公司内的不同业务部门，我们应该对这些服务设计好一个好的SLA。

下面是四个常见的SLA指标

1.可用性（Availability）
可用性指的是系统服务能正常运行所占的比例。

例如我们说要搭建一个”100%“的系统服务，也就意味我们要需要保证在任何时候这个系统都能运行，都说可用的，但实际这在现实中，是非常困难的，成本也是非常的高。

对于大部分的系统而言，能保证4个9的可用性（99.99%的可用性）就可以说这个系统是高可用的。

99.99%的可用性是指一天（60×60×24秒），只有8.64秒（60×60×24×0.0001秒）为不可用，一年就是大概有52.56分钟（8.64*365/60分钟）不可用。一天只有8秒左右的不可能用时间，这已经可用满足大部分系统的要求了。

2.准确性（Accuracy）
准确性指的是我们所设计的系统服务中，是否允许某些数据是不准确或丢失，如果允许那么允许的百分比是多少？

不同系统对准确率都会有一个衡量的指标，大部分系统可以 用错误率来衡量。

错误率怎么计算呢？可以用导致系统内部错误有效请求数除以总的有效请求数而求得。
错 误 率 = 导 致 系 统 内 部 错 误 有 效 请 求 数 / 总 的 有 效 请 求 数 错误率=导致系统内部错误有效请求数/总的有效请求数
错误率=导致系统内部错误有效请求数/总的有效请求数

系统一分钟内收到的总的有效请求为100个，其中有10个导致系统内部错误，则我们可以认为错误率为10%

下面我们看下大公司中对系统错误率的对比

Google Cloud Platform 的SLA中，有着这样的定义：每个月的错误率超过5%的时间要少于0.1%，以每分钟为单位来计算。

亚马逊AWS云计算平台对SLA的准确性定义为：以每5分钟为单位，错误率不会超过0.1%。

那我们可以通过哪些途径来获取系统的准确性呢？大部分情况我们可以通过软件测试或系统日志来判断。

3.系统容量（Capacity）
在数据处理中，系统容量通常指的是系统能够支持的预期负载量是多少，一般会以每秒请求数为单位来表示。

我们常常听见某个系统的架构可以处理的QPS（Queries Per Second 系统每秒查询数）是多少或者RPS（Requests Per Second系统每秒请求数）是多少。

那我们怎么准确定义系统架构的QPS呢？我认为可以用以下三种方式定义：

第一种：是使用限流的方式
如果你熟悉JAVA的话，你可能听过Google Guava库，其中RateLimiter类可用用来定义每秒最多发送多少请求到后台处理。（或者使用Hystrix框架做限流也可以，这里不多做解释，之后会推出相关文章）

假设你在RateLimiter中设置每秒最多允许1000请求，假设我们有n台服务器，在理想的状态下，我们的QPS就是1000*n

这个方案要注意的是：允许的请求不是越多越好，因为服务器的内存有限，所以可能会出现OOM(Out-Of-Memory内存溢出)的异常。

第二种：是在系统上线时提供性能测试
我们可以使用像Apache JMeter又或是LoadRunner这类性能测试工具进行性能测试。这类工具可以测出系统在峰值状态下可以应对的QPS是多少。

但是这也并不会说一定准确，比如开发者在进行测试时，使用了同一请求参数，导致在多数情况下命中缓存（Cache Hit）。这个时候的QPS就不是真实的QPS。

可以这么说，假设服务器请求的正常流程需要查询后台数据库，得到数据库结果后再返回给用户，这个过程需要1秒，但在第一次拿到数据后放入缓存中，导致结果并不是从数据库获取，这时假设只需要0.1秒，这样与正常情况相差10倍左右，这便会使我们得到的QPS并不真实，所以要而外注意这一点。

第三种：是分析系统使用时产生的日志（Log）
系统上线使用后，我们可以得到日志文件，一般日志文件会记录每时刻的请求。我们可以通过计算系统每天最繁忙的时候接收的请求数，来计算出可以承载的QPS。

但这并不一定准确，因为每天最繁忙的时候并不一定是峰值。假设一间店今天最繁忙的时候是服务10个客人，那难道可以说这间店的最多能服务的客人是10个人吗？

显然并不行，所以这里建议使用性能测试和系统日志相结合的方式来计算QPS。

4.延迟（Latency）
延迟指的是系统在收到用户的请求到响应这个请求的时间间隔。

在定义延迟的SLA时，我们常常看到系统的SLA会有p95或者是p99这样的延迟声明。这里的p指的是percentile（也就是百分比的意思），假设一个p95的系统延迟是1秒，那就表示100个请求里面有95个请求的响应时间是少于1秒的，而剩下的5个大于1秒。

下面我们通过一个例子来讲解延迟在SLA指标的重要性。

假设我们已经设计好一个电商软件一个系统架构。这个电商软件接收到用户的请求之后，需要读取数据库的内容返回给用户。

为了降低系统的延迟行，我们会将数据库的内容放进缓存（Cache）中，以此来减少从数据库的读取时间。在系统运行一段时间后我们得到一些缓存的命中率（Cache Hit Ratio）的信息。有90%的请求命中缓存，而剩下的10%的请求规则需要重新从数据库读取内容。

这时服务器给我们的p95或者p99延迟就衡量了系统的最长时间，也就是从数据库中读取内容的时间。这时我们可以通过改进缓存策略（可以进行缓存预热等）提高缓存命中率，也可以通过优化数据库的Schema或者索引（Index）来降低p95或p99的延迟。

总而言之，当p95或者p99过高（系统延迟过高）的时候，总有5%或者1%的用户抱怨产品的用户体验太差，这都是我们要优化系统来避免的。

总结
通过今天的内容，大家应该都可以了解SLA对我们系统评估的重要性。

定义好一个好的SLA，当我们以后的版本迭代时，这时我们便可以看出改进后的系统架构与上一代的差别，否与上一代SLA有所提高