可用性、可維護性、可靠性有什麽區別？
原創
最后编辑：李晓琳 于 2020-11-10 17:03:19
1292次查看
本篇目錄
我們生活在一個用戶依賴于對服務的一致訪問的可靠性時代。在相互競爭的服務之間進行選擇時，對用戶來說，沒有比可靠性更重要的特性了。但是可靠性是什麽意思呢？
为了回答这个问题，我们将根据可靠性工程中的其他度量来分解可靠性：可用性和可維護性。区分这些术语并不是语义问题。了解这些差异可以帮助您更好地将开发工作的优先级放在客户的满意度上。
服務的可用性是用戶感知可靠性的主要因素。考慮到這一點，設定一個100%正常運行時間的目標是很誘人的。但是SRE告訴我們失敗是不可避免的；導致停機的事故總是發生在工程預期之外。可用性通常用“9”表示，表示正常運行時間的百分比可以達到多少位小數。一些主要的軟件公司會吹噓自己的“5個9”或者99.99%的正常運行時間，但永遠不會有可確保的100%的正常運行時間。
可維護性有两个主要组成部分：主动式可維護性和反应式可維護性。
主动式可維護性包括构建易于理解和更改的代码库。随着开发的进行，会出现与现有代码不兼容的问题。如果工程师写的是面条式代码，而不是优先考虑可維護性，就容易出问题，并且很难发现和解决问题。主动维护还包括质量保证和测试等程序。
反应式可維護性描述了服务在事故发生后被修复的能力。这受服务的事故响应过程的影响。大型事故的反应和防范是必要的，如果事故响应程序可靠，团队将迅速解决事件。适当的事故反应也有助于减少复发。高度可维护的服务允许工程师有效地汲取这些经验教训。
可維護性反映在可用性指标中。缩短停机时间或停机频率可以提高可用性。但是，可維護性不是实现可用性的唯一手段。采取这种方法可能导致发展资源分配不当。在可維護性方面的投资可能不会立即带来更好的正常运行时间。当您重构旧代码以解决技术债务时，服务的功能将与以前相同，并具有相同的可用性。直到事件发生，您才会看到这种高可維護性的好处。可維護性应该被看作是可靠性方面的投资，而不仅仅是可用性的一个组成部分。
以兩種情形爲例：
服務A：
用戶登錄頁面的可用性爲97%
目錄搜索的可用性爲97%
站點設置頁面的可用性爲97%
服務B:
用戶登錄頁面具有可用性爲99%
目錄搜索的可用性爲98%
網站設置頁面的可用性爲90%
僅從可用性度量來看，服務A勝出。但是如果登錄頁面被100%的用戶使用，目錄搜索被90%的用戶使用，而站點設置頁面只有30%的用戶使用，那麽服務B就會被認爲更可靠。可靠性需要考慮實際使用情況，將可用性指標轉化爲客戶滿意度的度量指標。
通過理解系統的可靠性，開發人員可以避免浪費時間來改進超出客戶預期的可用性。服務級別指標將延遲和可用性等指標捆綁到更有效的度量中。然後將服務水平目標設定在顧客不滿意的阈值。這種方法從客戶的角度來看可靠性，因爲對他們來說，服務的可靠性比它的可用性更重要。
可維護性也可以通过这种标准来评估。响应事件所花费的时间耗尽了服务正常运行时间的错误预算……SLI和SLO可以帮助分配开发工作，以改进可維護性和最影响客户满意度的事件响应过程。
可靠性不僅僅是度量的集合或代碼庫的質量。這是一個全局概念，包含了用戶的觀點、變化和增長的必然性以及開發代碼的人員。這種整體方法是SRE的基礎，是實踐的集合，也是提高服務可靠性的文化課程。
为了回答这个问题，我们将根据可靠性工程中的其他度量来分解可靠性：可用性和可維護性。区分这些术语并不是语义问题。了解这些差异可以帮助您更好地将开发工作的优先级放在客户的满意度上。
可用性
可用性是可靠性最簡單的組成部分。此度量描述服務運行的時間百分比，這也被稱爲服務的“正常運行時間”。可用性可以通過連續查詢服務並以預期的速度和准確性確認返回的響應來監控。服務的可用性是用戶感知可靠性的主要因素。考慮到這一點，設定一個100%正常運行時間的目標是很誘人的。但是SRE告訴我們失敗是不可避免的；導致停機的事故總是發生在工程預期之外。可用性通常用“9”表示，表示正常運行時間的百分比可以達到多少位小數。一些主要的軟件公司會吹噓自己的“5個9”或者99.99%的正常運行時間，但永遠不會有可確保的100%的正常運行時間。
此外，用户是可以容忍甚至无法注意到服务的某些领域出现宕机。致力于改善超出预期的可用性的开发资源并不会增加客户的满意度，把这些资源用在可維護性上会更好。
可維護性
可靠性的另一个主要组成部分是可維護性。通过描述停机时间的产生和解决方式，将可維護性因素考虑到可用性中。当发生导致停机的事件时，可维护服务可以快速修复。事件越早得到解决，服务就越快恢复可用。可維護性有两个主要组成部分：主动式可維護性和反应式可維護性。
主动式可維護性包括构建易于理解和更改的代码库。随着开发的进行，会出现与现有代码不兼容的问题。如果工程师写的是面条式代码，而不是优先考虑可維護性，就容易出问题，并且很难发现和解决问题。主动维护还包括质量保证和测试等程序。
反应式可維護性描述了服务在事故发生后被修复的能力。这受服务的事故响应过程的影响。大型事故的反应和防范是必要的，如果事故响应程序可靠，团队将迅速解决事件。适当的事故反应也有助于减少复发。高度可维护的服务允许工程师有效地汲取这些经验教训。
可維護性反映在可用性指标中。缩短停机时间或停机频率可以提高可用性。但是，可維護性不是实现可用性的唯一手段。采取这种方法可能导致发展资源分配不当。在可維護性方面的投资可能不会立即带来更好的正常运行时间。当您重构旧代码以解决技术债务时，服务的功能将与以前相同，并具有相同的可用性。直到事件发生，您才会看到这种高可維護性的好处。可維護性应该被看作是可靠性方面的投资，而不仅仅是可用性的一个组成部分。
可靠性
可靠性可以定義爲當用戶訪問服務時，服務按預期運行的可能性。這似乎與我們定義可用性的方式相同，但有關鍵的區別。可用性檢查服務是否工作，用戶是否正在訪問它。如果用戶在所有時間、所有功能上統一訪問服務，可用性將決定可靠性。一般情況下，這不可能發生。以兩種情形爲例：
服務A：
用戶登錄頁面的可用性爲97%
目錄搜索的可用性爲97%
站點設置頁面的可用性爲97%
服務B:
用戶登錄頁面具有可用性爲99%
目錄搜索的可用性爲98%
網站設置頁面的可用性爲90%
僅從可用性度量來看，服務A勝出。但是如果登錄頁面被100%的用戶使用，目錄搜索被90%的用戶使用，而站點設置頁面只有30%的用戶使用，那麽服務B就會被認爲更可靠。可靠性需要考慮實際使用情況，將可用性指標轉化爲客戶滿意度的度量指標。
通過理解系統的可靠性，開發人員可以避免浪費時間來改進超出客戶預期的可用性。服務級別指標將延遲和可用性等指標捆綁到更有效的度量中。然後將服務水平目標設定在顧客不滿意的阈值。這種方法從客戶的角度來看可靠性，因爲對他們來說，服務的可靠性比它的可用性更重要。
可維護性也可以通过这种标准来评估。响应事件所花费的时间耗尽了服务正常运行时间的错误预算……SLI和SLO可以帮助分配开发工作，以改进可維護性和最影响客户满意度的事件响应过程。
可靠性不僅僅是度量的集合或代碼庫的質量。這是一個全局概念，包含了用戶的觀點、變化和增長的必然性以及開發代碼的人員。這種整體方法是SRE的基礎，是實踐的集合，也是提高服務可靠性的文化課程。
DevOps幹貨
