目录
前言
本文为扫盲文章
扫除未知概念,培养服务保证意识
一.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让模糊的质量问题定性且量化,推进双方的沟通和合作
![](/qrcode.jpg)
-
商用合同定义 服务内容的量化索赔和免责条款。
-
服务依赖约定 服务稳定性/稳定性量化,规范服务间规范和整体链路可靠。
通常服务提供方与需求提供方对话
需求方: 需要使用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路上的基石,没有监控各种量化指标没法采集并且无法主动感知异常。
- 工欲善其事,必须利其器。机遇也是挑战,因为难所以做到了就变强了。