SLA是什么?

写在前面

本文隶属于专栏《100个问题搞定大数据理论体系》,该专栏为笔者原创,引用请注明来源,不足和错误之处请在评论区帮忙指出,谢谢!

本专栏目录结构和文献引用请见100个问题搞定大数据理论体系

解答

SLA( Service- Level Agreement),也就是服务等级协议,指的是系統服务提供者( Provider)对客户( Customer)的一个服务承诺。
这是衡量一个大型分布式系统是否“健康”的常见方法。

最常见的 4 个 SLA 指标:
1.可用性(Availabilty)
2.准确性(Accuracy)
3.系统容量(Capacity)
4.延退(Latency)

补充

SLA

可用性(Availability)

可用性指的是系统服务能正常运行所占的时间百分比。

对于许多系统而言,四个9的可用性(99.99% Availability,或每年约50分钟的系统中断时间)即可以被认为是高可用性( High availability)。

“99.9% Availability”指的是一天当中系统服务将会有大约86秒的服务间断期。

服务间断也许是因为系统维护,也有可能是因为系统在更新升级系统服务。

86秒这个数字是怎么算出来的呢?

99.9%意味着有0.1%的可能性系统服务会被中断,而一天中有24小时x60分钟x60秒,也就是有(24×60×60×0.001)=86.4秒的可能系统服务被中断了。
而上面所说的四个9的高可用性服务就是承诺可以将一天当中的服务中断时间缩短到只有(24×60×60x0.0001)=8.64秒。

准确性( Accuracy)

准确性指的是我们所设计的系统服务中,是否允许某些数据是不准确的或者是丢失了的。

如果允许这样的情况发生,用户可以接受的概率(百分比)是多少? 这该怎么衡量呢?

不同的系统平台可能会用不同的指标去定义准确性。很多时候,系统架构会以错误率(Error Rate)来定义这一项SLA。

怎么计算错误率呢?

可以用导致系统产生内部错误(Internal Error)的有效请求数,除以这期间的有效请求总数。

例如,我们在一分钟内发送100个有效请求到系统中,其中有5个请求导致系统返回内部错误,那我们可以说这一分钟系统的错误率是5/100=5%。

系统容量(Capacity)

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

我们常常可以看见,某个系统的架构可以处理的QPS(Queries Per Second)是多少又或者RPS(Requests Per Second)是多少。

这里的QPS或者是RPS就是指系统每秒可以响应多少请求数。

延迟(Latency)

延迟指的是系统在收到用户的请求到响应这个请求之间的时间间隔。

在定义延迟的SLA时,我们常常看到系统的SLA会有p95或者是p99这样的延迟声明。

这里的p指的是percentile,也就是百分位的意思。

如果说一个系统的p95延迟是1秒的话,那就表示在100个请求里面有95个请求的响应时间会少于1秒,而剩下的5个请求响应时间会大于1秒。

<think>好的,我需要回答用户关于SLA全称及定义的问题。首先,根据提供的引用,引用[1]和引用[3]都提到了SLA。引用[3]明确给出了全称是service level agreement,即服务等级协议,并解释了它是在一定开销下保障服务性能和可用性的协议。接下来需要确认定义部分,引用[1]提到SLA定义时涉及监控指标如延迟、吞吐量,引用[3]补充了可用性如几个9的标准。需要将这些信息整合,用中文清晰表达。另外,用户要求回答结构清晰,分步说明,所以可能需要分点列出全称和定义要点。同时,根据系统级指令,需要生成相关问题,参考示例中的问题类型,提出与SLA相关的问题,如组成要素、指标、应用场景等。最后,检查是否符合格式要求,如数学表达式是否正确,引用标识是否正确添加。确保所有内容符合用户要求,没有使用Markdown,语言口语化,自然流畅。</think>SLA的全称是**服务等级协议**(Service Level Agreement),在IT服务管理中指服务提供商与用户之间达成的正式协定,用于明确双方认可的服务质量标准和责任范围[^3]。 **核心定义包含三个要素**: 1. **量化指标**:通过具体数值定义服务性能要求,例如系统可用性需达到$99.99\%$(即全年停机不超过52分钟),接口响应时间需满足$P99 \leq 200ms$ 2. **责任边界**:规定服务覆盖范围、故障响应时效(如故障修复时间$MTTR \leq 1小时$)及赔偿条款 3. **监控机制**:要求服务方提供实时监控数据,例如引用[1]中提到的请求延迟、吞吐量等关键指标,并通过类似Micrometer[^3]的工具实现指标采集 典型应用场景包括云服务商承诺的虚拟机可用性、企业IT部门对内部系统的稳定性保障等。例如当可用性从$99.9\%$提升到$99.99\%$时,年允许停机时间将从8.76小时大幅缩减至52分钟[^3]。
评论 25
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值