可用性、可维护性、可靠性有什么区别？ - DevOps干货

摘要：区分这些术语并不是语义问题。了解这些差异可以帮助您更好地将开发工作的优先级放在客户的满意度上。

我们生活在一个用户依赖于对服务的一致访问的可靠性时代。在相互竞争的服务之间进行选择时，对用户来说，没有比可靠性更重要的特性了。但是可靠性是什么意思呢？

为了回答这个问题，我们将根据可靠性工程中的其他度量来分解可靠性：可用性和可维护性。区分这些术语并不是语义问题。了解这些差异可以帮助您更好地将开发工作的优先级放在客户的满意度上。

可用性

可用性是可靠性最简单的组成部分。此度量描述服务运行的时间百分比，这也被称为服务的“正常运行时间”。可用性可以通过连续查询服务并以预期的速度和准确性确认返回的响应来监控。

服务的可用性是用户感知可靠性的主要因素。考虑到这一点，设定一个100%正常运行时间的目标是很诱人的。但是SRE告诉我们失败是不可避免的；导致停机的事故总是发生在工程预期之外。可用性通常用“9”表示，表示正常运行时间的百分比可以达到多少位小数。一些主要的软件公司会吹嘘自己的“5个9”或者99.99%的正常运行时间，但永远不会有可确保的100%的正常运行时间。

此外，用户是可以容忍甚至无法注意到服务的某些领域出现宕机。致力于改善超出预期的可用性的开发资源并不会增加客户的满意度，把这些资源用在可维护性上会更好。

可维护性

可靠性的另一个主要组成部分是可维护性。通过描述停机时间的产生和解决方式，将可维护性因素考虑到可用性中。当发生导致停机的事件时，可维护服务可以快速修复。事件越早得到解决，服务就越快恢复可用。

可维护性有两个主要组成部分：主动式可维护性和反应式可维护性。

主动式可维护性包括构建易于理解和更改的代码库。随着开发的进行，会出现与现有代码不兼容的问题。如果工程师写的是面条式代码，而不是优先考虑可维护性，就容易出问题，并且很难发现和解决问题。主动维护还包括质量保证和测试等程序。

反应式可维护性描述了服务在事故发生后被修复的能力。这受服务的事故响应过程的影响。大型事故的反应和防范是必要的，如果事故响应程序可靠，团队将迅速解决事件。适当的事故反应也有助于减少复发。高度可维护的服务允许工程师有效地汲取这些经验教训。

可维护性反映在可用性指标中。缩短停机时间或停机频率可以提高可用性。但是，可维护性不是实现可用性的唯一手段。采取这种方法可能导致发展资源分配不当。在可维护性方面的投资可能不会立即带来更好的正常运行时间。当您重构旧代码以解决技术债务时，服务的功能将与以前相同，并具有相同的可用性。直到事件发生，您才会看到这种高可维护性的好处。可维护性应该被看作是可靠性方面的投资，而不仅仅是可用性的一个组成部分。

可靠性

可靠性可以定义为当用户访问服务时，服务按预期运行的可能性。这似乎与我们定义可用性的方式相同，但有关键的区别。可用性检查服务是否工作，用户是否正在访问它。如果用户在所有时间、所有功能上统一访问服务，可用性将决定可靠性。一般情况下，这不可能发生。
以两种情形为例：
服务A：
用户登录页面的可用性为97%
目录搜索的可用性为97%
站点设置页面的可用性为97%

服务B:
用户登录页面具有可用性为99%
目录搜索的可用性为98%
网站设置页面的可用性为90%

仅从可用性度量来看，服务A胜出。但是如果登录页面被100%的用户使用，目录搜索被90%的用户使用，而站点设置页面只有30%的用户使用，那么服务B就会被认为更可靠。 可靠性需要考虑实际使用情况，将可用性指标转化为客户满意度的度量指标。

通过理解系统的可靠性，开发人员可以避免浪费时间来改进超出客户预期的可用性。服务级别指标将延迟和可用性等指标捆绑到更有效的度量中。然后将服务水平目标设定在顾客不满意的阈值。这种方法从客户的角度来看可靠性，因为对他们来说，服务的可靠性比它的可用性更重要。

可维护性也可以通过这种标准来评估。响应事件所花费的时间耗尽了服务正常运行时间的错误预算……SLI和SLO可以帮助分配开发工作，以改进可维护性和最影响客户满意度的事件响应过程。

可靠性不仅仅是度量的集合或代码库的质量。这是一个全局概念，包含了用户的观点、变化和增长的必然性以及开发代码的人员。这种整体方法是SRE的基础，是实践的集合，也是提高服务可靠性的文化课程。