作者:捕风的默小墨 | 来源:互联网 | 2023-08-17 12:23
1,SLA
SLA是Service-Level Agreement的缩写,意思是服务等级协议,一般是协议双方做的彼此承诺,放在运维的领域,很重要的一个结果指标就是系统的SLA,这个是技术向业务做的一个承诺。
系统SLA的定制方法一般有两种,一种是通过时间维度进行测算,另外一种是通过用户请求状态进行测算。
-
时间维度测算
公式:
PS:如果年度SLA,则n=365
这种计算方式比较常规,通用,但真正较真起来,还是比较麻烦的,麻烦的地方主要有以下几点:
1),业务中断怎么判断,须知一个业务完全中断的场景并不多见,往往是出现部分业务受到影响。
2),复杂组织场景下,如何做责任划分,比如A部门引发的问题,但B部门的容错性做的也不好,这种情况A,B的各自SLA是多少?
3),时间分片并不是完全等价的,业务高峰时的一个小时要比业务低谷值钱的多,如果按照同样的时间去计算,其实是有失公允的。
鉴于以上种种原因,在公司SLA实际计算中,计算公式会变得非常复杂,比较常见的一种就是根据业务进行时间换算,公式为:
PS:如果年度SLA,则n=365
举例:
如果一天的业务量是一万单,业务时出现故障高峰,持续一个小时,影响1000单,那么时间业务影响时间换算为:1000 / 10000 * 24 = 2.4个小时,当天的SLA为 90%,而非95.8%
这种算法的优点是:
直观,计算简单,业务部门容易理解
缺点是:
这是个结果指标,改进指向不明确。
- 用户请求状态测算
公式:
举例:
如果一个系统,用户一天请求量为10000,其中5XX的请求为1000,那么当天的SLA为90%
优点:
可以有针对性的改进,只要增加访问成功率即可
缺点:
业务不容易理解,在什么事请求成功上容易产生分歧
2,支撑SLA的运维指标
SLA一般我们定义为结果指标,也就是到最后一刻才知道是否正常,所以一般需要有一些过程指标进行跟踪,这里着重介绍一下运维侧指标,开发侧比较简单,不做详细介绍
- 一级指标
一级指标直接承载SLA,指标好坏,会对SLA有直接影响
1),故障次数,这个比较理解,就是有业务影响的异常次数
2),故障的平均恢复时间,为了避免某几个故障处理时间过长,导致指标不能反映真实情况,一般会采用P90,P95的故障平均恢复时间
3),N分钟内的异常恢复比例,N的取值和公司的技术能力和实际情况定,以故障为例,一般是30分钟能恢复就已经很不错了 - 二级指标
二级指标间接承载SLA,指标好坏会对一级指标有直接影响
1),用户报障比,有多少故障是用户发现的,而非监控系统发现的
2),自动化变更占比,数字证明,自动化的变更质量要更好一些
3),问题及时解决率,问题单尤其是故障产生的问题单解决效率
4),事件及时解决率,事件单及时处理效率
5),告警及时处理率,这个是把故障控制在萌芽中的很有效手段
6),监控覆盖率,生产重要的应用和组件的监控覆盖程度
这些指标计算公式比较简单,这里不赘述。