前言

本文为扫盲文章
扫除未知概念，培养服务保证意识

一.SLA是什么

sla是量化软件服务质量的协定

SLA

服务品质协议（简称：SLA，全称：service level agreement）是在一定开销下为保障服务的性能和可用性，服务提供商与用户间定义的一种双方认可的协定。SLA包含SLI和SLO。

SLI

服务等级关键量化指标（简称：SLI，全称：service level indicator）
在这里插入图片描述

指标	含义	适用场景
HA: 高可用（High Availability）	服务可用情况	通用，通常所说的99.9% 99.99%
QPS: 每秒并发量 (Queries Per Second)	查询返回能力（每秒）	适合并发查询服务
RPS:每秒处理量 (Response Per Second)	操作返回能力（每秒）	适合接口多任务服务
TPS: 每秒吞吐量 (Transactions Per Second)	事务处理能力（每秒）	适合异步多任务服务
RT: 响应时间 (Response Time)	请求响应时间（每秒）	适合所有接口服务通常关注90%请求算数平均
并发量	接口用户请求数（每秒）	并不准确与QPS相互估算
MTBF: 平均出错间隔（Mean Time Between Fail）	MTBF = MTTF + MTTR	服务稳定性衡量,越大越好
MTTR: 平均修复时间 (Mean Time To Repair)		服务稳定性衡量,越小越好
MTTF: 平均无间隔 (Mean time to Failure)		服务稳定性衡量,越大越好

其中一些指标量化

HA = 计划可用时间/(计划可用时间+故障时间)*100 
HA = 请求成功/(请求成功+请求失败)*100    # 分布式系统 通常使用此计算公式简化复杂情况

99%  故障时间不超过432分钟/月 7.2小时/月
99.9%  故障时间不超过43.2分钟/月
99.99% 故障时间不超过4.32分钟/月

# 以下指标通常为HA条件下的细项,亦可以界定故障时间或请求失败数
QPS = 请求成功总数/单位时间
TPS = 任务总数/单位时间
RT = 单位时间总请求响应时间和/总请求数
并发量 ～= QPS * RT

稳定性量化
在这里插入图片描述

上图 
N:两次故障
T1:无故障时间
T2:故障等待修复时间
T3:故障修复时间
T21:故障发现时间
T22:故障发现到定位时间
T23:故障定位到处理时间
T31:故障处理时间

MTTF =∑T1/ N         #指系统无故障运行的平均时间，所有系统开始正常运行到发生故障之间的时间段的平均值
MTTR =∑(T2+T3)/ N    #指系统从发生故障到维修结束之间的时间段的平均值
MTBF =∑(T2+T3+T1)/ N #指系统两次故障发生时间之间的时间段的平均值

SLO

服务等级目标（简称：SLO，全称：service level Object）指定了服务所提供功能的一种期望状态，包含所有能够描述服务应该提供什么样功能的信息。
一般描述为：

每分钟平均QPS > 100k/s
99% RT < 500ms
99% IO > 200MB/s
MTTR<30min
MTTF<1次/周
故障发生-发现<5min
故障发现-定位<5min
故障发现-处理<10min
故障处理-消除<15min

下图是一个故障复盘的图例
在这里插入图片描述

二.为什么需要SLA？

SLA让模糊的质量问题定性且量化,推进双方的沟通和合作

商用合同定义服务内容的量化索赔和免责条款。

某个saas服务平台的sla协议
服务依赖约定服务稳定性/稳定性量化,规范服务间规范和整体链路可靠。

通常服务提供方与需求提供方对话

	需求方: 需要使用xxxxapi,查询相关文档定位可使用你的服务,请评估一下能否承接
		   目的:xxxx,
		   输入参数:xxxx,
		   返回参数:xxxx,
		   响应RT<500ms,
	       使用频率 <1000/天,
	       峰值QPS<10/s,
	       预期SLA>99.9%
	         
	服务方: 经过api模拟调用测试,满足RT/QPS要求,约消耗20%服务容量,能够承接服务。
	       将会创建服务token作为访问标识
	       token授权接口访问,
	       token做QPS峰值拒绝 错误码xxxx,
	       token做每日上限拒绝 错误码xxxx。
	       若存在SLA内正常维护会通知各位,
	       若存在SLA内异常问题会处理并通知各位。
	       本服务保障方案如下 xxxxxxx
	
	需求方: 五星好评！
	       将严格按照规定使用接口,
	       保障方案中将会对服务接口故障预案,及时沟通。

三.怎么保障服务SLA？

什么会影响SLA？

不可抗力
基础设施故障
基础服务
人为过失
a. 软件升级
b. 配置变更
c, 数据变更

在这里插入图片描述

如何提高SLA？

0.重视sla

重视和敬畏代码能减少大部分人为引起的故障。及时做好检查和反馈，早就职业素养和形象。

在这里插入图片描述

1.架构设计

高可用架构:多活、双主同步、灾备、弹性服务。服务内部熔断、削峰限流、降级等。

需求来了
A同学: 根据需求实现了功能，并部署了单体服务在a机房。
B同学: 根据需求实现了功能和与之评估的可能存在的风险设计整体架构，采用lvs+ha+keepalive+多活服务在ab机房。
某天晚上a机房断电
A同学: 连夜起床部署b机房
B同学: 呼噜噜...
某天业务上涨，服务警报发起
A同学: 连夜起床分析a机房服务监控
B同学: 呼噜噜...
某天三方依赖服务跟a机房网络出现问题
A同学: 连夜起床部署b机房
B同学: 起床看了下时间,呼噜噜...

AB同学都很优秀，但是懂得保障SLA而设计的B同学好像轻松的多。

2.代码设计与测试

90%的故障率来自于未对外部异常做积极处理。例如: 参数格式发送变化/参数超出边界值/依赖基础服务队列/缓存/存储变慢了。

除了处理高内聚低耦合，还要关注代码的鲁棒性。
注重单测和性能测试。有兴趣的可以了解一下TDD。

	需求来了
	A同学: A是上游服务。
	B同学: B是下游服务，B对A的所有参数做了单元测试覆盖。根据实效性做了结果缓存。
	某天A同学服务升级修改了参数
	B同学: 收到A同学升级后改了参数导致的异常报警，第一时间告诉A代码变动影响了。
	A同学: 赶紧回退代码
	某天A同学服务挂了
	B同学: 收到A同学服务的异常报警,因为缓存有效,没有影响服务，给A留言后，呼噜噜...
	A同学: 连夜起床恢复服务,并通知B同学,发现B同学的留言...
	某天服务量级徒增一倍
	A同学: 担心受怕度过
	B同学: 根据性能测试，发现可以轻松hold住，呼噜噜...

AB同学都很优秀，但是懂得代码设计的B同学不用每时每刻提心吊胆。

3.监控异常报警

SLA最重要的是尽早发现故障。所以相关报警异常重要！
在这里插入图片描述

4.应急预案

第一步感知故障
可预见故障，例如断网、断电、设备迁移等可以提前通知
不可预见故障，例如网络问题、人为过失、恶意攻击等可以做探针服务尽早发现。
依赖探针服务+监控系统来感知发现故障。
对感知的故障。明确影响面，处理优先级，消除故障步骤。

第二步故障转移
第一时间，第一时间，第一时间减小故障的影响，不要，不要，不要只顾分析原因。
升级故障则回退升级
配置故障则回退配置
主故障就通知切备机等

第三步故障演练
通常演练是由基础设施、基础服务建设做一些常规故障预案和演练。
各个服务根据自己的故障预案处理情况，完善应急预案。

第四步及时更新完善
随着环境变迁或者软件服务升级，相应的故障感知影响面优先级处理步骤都会变化,需要及时更新。
不断精简故障处理方式,降低MTTR

四.总结

对数据敏感培养开发人员的职业灵敏度，所有开发和优化有了数据反馈能促进个人成长。
sla是一种量化服务质量好坏的协议,做好sla能提升服务质量以及提升个人对服务的设计掌控力。
监控是sla路上的基石，没有监控各种量化指标没法采集并且无法主动感知异常。
工欲善其事，必须利其器。机遇也是挑战，因为难所以做到了就变强了。

SLA服务保障初识

目录

前言