如何有效的评估服务可用性？服务可用性的核心组成要素

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 于深圳

【尊重版权：转载之前请先联系我】