Service Level objectives (SLO)
要管理好一个IT服务,除了要了解用户之外,还需要了解用户最关心服务的哪个要点,从而可以应用相关指标进行度量、评估。这类指标就是ITSM中定义的服务水平指标。服务水平指标一般包含SLI (Service Level Indicators)、SLO (Service Level Objectives)、SLA (Service Level Agreements),这三种的关系如下图所示:
可用性指标
在服务水平指标中,使用的最多的便是可用性指标。从理论上来说,可用性指标的计算比较简单,具体为:
组成要素
在实际的应用过程中,为了计算可用性指标,一般会定义以下要素:
- 时间块:用于评估服务可用性的最小单位。
- 服务总时间块:周期内,服务的期望运行总时长。例如:一个服务周期为一个星期,服务周期按每周七(7)天每天二十四(24)小时每小时六十(60)分钟计算,即10080分钟。
- 不可用时间块:为服务周期中的最小时间单位。通过服务不可用的标准,定义某一时间单位是否为不可用的时间块。
基于上述三个主要要素,服务可用性的算法为:
这种算法的特点是可以放大或者缩小最终的可用性,关键的操作点是不可用时间块的判断标准。如例子中所示,若不可用的标准是:5分钟内超过20%的请求失败则认为时间块不可用,这将缩小最终的可用性;若不可用的标准是:5分钟内超过100%的请求失败才认为时间块不可用,这将放大最终的可用性。
为了更精确的计算可用性指标,业界使用了一种精确的可用性计算方法,其主要要素如下:
- 时间块:用于评估服务可用性的最小单位。
- 服务总时间块:周期内,服务的期望运行总时长。例如:一个服务周期为一个星期,服务周期按每周七(7)天每天二十四(24)小时每小时六十(60)分钟计算,即10080分钟。
- 时间块内可用性:定义了时间块内的可用性计算方法。
这种算法更加精确的评估了服务的可用性,同时也避免不可用指标在大数情况下被淹没的情况(如上图,若将总成功请求数处以总请求数,其可用性为99.756%)。
总结
总体来说,服务可用性指标有两种基本方式:普通可用性、精确可用性。普通可用性比较适用于粗粒度的评估服务运行的情况(例如:数据库连接的可用性),可用于放大、缩小可用性;精确可用性比较适用于尽量精确的评估服务运行情况(例如:开放接口调用的可用性评估)。具体使用,可视不同场景而选择。
Reference
- Google SRE > Embracing Risk - https://landing.google.com/sre/book/chapters/embracing-risk.html
- Google SRE > Service Level Objectives - https://landing.google.com/sre/book/chapters/service-level-objectives.html
- Amazon RDS Service Level Agreement - https://aws.amazon.com/cn/rds/sla/
- Amazon DynamoDB Service Level Agreement - https://aws.amazon.com/cn/dynamodb/sla/
- HybridDB for PostgreSQL > 服务条款 > 服务等级协议 - https://help.aliyun.com/document_detail/47984.html?spm=a2c4g.11186623.6.647.387ab0351JVLud
- 云数据库 RDS 版 > 相关协议 > 服务等级协议 - https://help.aliyun.com/document_detail/58806.html?spm=a2c4g.11174283.6.963.7dea4c224ux0c5
- Google Cloud Datastore Service Level Agreement (SLA) - https://cloud.google.com/datastore/sla
- Cloud Bigtable Service Level Agreement (SLA) - https://cloud.google.com/bigtable/sla
pstrike 2018.09.10 于深圳
【尊重版权:转载之前请先联系我】
网友评论