在稳定性建设中，如何评价稳定性工作的好坏，可以用哪些指标来衡量？通过这些指标又如何指导我们的工作，本文为你介绍稳定性建设中几种常见的指标以及这些指标对我们的启发。

一、SLA - 服务等级协议

1、SLA概述

SLA(Service-level agreement)即服务等级协议，它描述的是服务方与客户之间达成的一个协议，即双方的一个约定。

比如说某提供云服务的IT企业，为它的客户提供99.99%的SLA，就意味着它的云服务全年最多有52分钟的不可用时间，如果系统宕机(不可用时间)超出这个时长，就意味着不满足SLA要求，需要进行相应的补偿或其他措施。

在公司内部，技术团队也会向业务侧提供SLA标准，同样的在技术团队内部，下游也需要向上游提供SLA标准，例如某个提供支付接口的基础平台团队，需要向上游业务研发团队提供SLA，等等以此类推。

SLA也就是我们通常所说的「3个9」、「4个9」，使用百分数来表示即99.9%，99.99%等。例如，如果某业务系统承诺全年可用性4个9，计算方式为 365(天) * 24(小时) * 60(分钟) * （1 - 99.99%） = 52.56分钟，即全年的不可用时间最多52.56分钟。

SLA的计算公式为: SLA = uptime / uptime + downtime。

2、SLA 与 SLO、SLI的关系

SLI(Service level indicator)即服务水平指标，一般包括包括延迟、吞吐量、可用性和错误率等。

SLO(Service-level objective)即服务水平目标，一般是指SLI需要达到的目标，可以用来消除歧义统一理解，例如接口成功率低于多少算是不稳定、接口响应时间低于多少算是慢。

SLA是构建在前面两者基础上的一个完整协议，它明确了量化标准、完成目标以及相应的责任。

很多文章会直接把SLA与指标混为一谈，实际上如果想设定好一个服务等级协议，需要双方先明确好对应的目标，然后再拆解其中的指标。例如:某个电商业务要设定SLA，需要先明确关键目标，例如商品展示页成功率不低于xx,响应时间不超过xx等，再根据这些目标拆解其中的指标，可能是某个商品API的接口成功率、接口响应时间等。

设定过程是这样的：先找到SLI(哪些是关键指标)，然后明确SLO(关键指标需要满足什么标准)，最后制定SLA(如果达不到标准，会有什么后果)。如果不谈要负的责任和惩罚措施，大多数情况下，SLA就失去了意义，就变成了SLO。

3、SLA标准给我们带来的指导意义

上面提到过，SLA依赖于SLO，SLO又依赖于SLI，因此需要先找到业务中的SLI，然后识别这些SLI所依赖的系统(以及他们的核心依赖)，这些就是我们在稳定性建设中需要重点关注的东西，比如SLI依赖的系统可以设定为核心系统，这些系统的代码、配置变更必须经过严格审核。所有的SLI指标必须配置相应的监控告警，一旦出现问题能够第一时间发现等等。

SLA有时候可以与错误时间预算一起来使用，比如说我们设定了99.99%的SLA，意味着全年有52分钟的不可用时间，出现过几次线上故障之后，预算就不足了，这个时候就要做一些针对性的错误，比如说减少变更计划等等。

3、可用时长参考表格

二、MTTR、MTBF - 故障处理过程

MTTR与MTBF是一些用来衡量故障(事件)处理相关的指标，一般可以用来评价故障处理过程。

1、MTTR和MTBF的解释

MTTR 是 Mean Time To Repair 的缩写，指的是故障修复时间的平均值。MTBF 是 Mean Time Between Failures 的缩写，指的是故障发生之间的平均时间。这两个术语最早出自于可靠性工程领域，常用来衡量设备、系统或其他产品的可靠性。

如果用一句话来描述稳定性建设的整体目标:增大MTBF(尽量不出故障)，缩短MTTR(尽量缩短故障持续时长)。

2、MTTR的进一步拆解

我们之前提出过5-5-10的概念，也就是所谓的5分钟发现、5分钟定位、10分钟修复。这个是对故障处理过程的进一步拆解，因此按照故障的处理阶段，MTTR中可以拆分为以下几个指标:

MTTR = MTTI + MTTK + MTTF + MTTV。

1、Mean Time To Identify (MTTI): 从故障开始到应急响应介入的时间，一般是考察监控告警、人员值班oncall的合理性。
2、Mean Time To Know (MTTK):从应急响应介入到故障定位的时间，主要考察根因分析、可观测性等工具的能力。
3、Mean Time To Fix (MTTF): 从故障定位到故障恢复的时间，主要考察应急预案、快恢体系的能力。
4、Mean Time To Verify (MTTV):从故障恢复之后到确认故障已经解决的时间，一般通过用户反馈、自动化测试等确认恢复。

按照以上的方式拆解之后，我们可以分别建设各个阶段的能力。

三、RPO与RTO - 灾难恢复计划

RPO和RTO是恢复点目标（Recovery Point Objective）和恢复时间目标（Recovery Time Objective）的缩写。RPO指在灾难发生后，在不影响业务运行的情况下能够接受的最长时间，在这段时间内可能会丢失的数据量。RTO指在灾难发生后，恢复正常业务运行所需的最短时间。

RPO和RTO通常用于灾难恢复计划中，以确保在灾难发生后能够尽快恢复正常业务运行，并尽量减少数据丢失。它们最早出自美国国家标准与技术研究院（National Institute of Standards and Technology）的《灾难恢复计划》(感兴趣的同学可以网上搜索 NIST SP 800-34)。

通俗地来说，RPO是指会不会丢数据，RTO是指需要多久完成恢复。一个容灾性比较好的系统，应该是RPO等于0(绝对不丢数据)，RTO接近于0(尽可能快地恢复)。

RPO与RTO经常用来评估数据中心、存储系统等容灾可靠性。在我们做一些存储引擎选型、或者建设数据中心的时候，可以拿这几个指标作为考量维度。

参考阅读

https://www.enterprisestorageforum.com/management/rpo-and-rto-understanding-the-differences/
https://en.wikipedia.org/wiki/High_availability
https://community.ibm.com/community/user/aiops/blogs/yok-han1/2019/06/12/enterprise-operations-top-3-factors-of-lengthy-mtt

ITPub博客

系统稳定性建设中的常用度量指标

二、MTTR、MTBF - 故障处理过程

三、RPO与RTO - 灾难恢复计划

参考阅读

最新文章