我們生活在一個用戶依賴于對服務的一致訪問的可靠性時代。在相互競爭的服務之間進行選擇時，對用戶來說，沒有比可靠性更重要的特性了。但是可靠性是什么意思呢？
為了回答這個問題，我們將根據可靠性工程中的其他度量來分解可靠性：可用性和可維護性。區分這些術語并不是語義問題。了解這些差異可以幫助您更好地將開發工作的優先級放在客戶的滿意度上。
可用性
可用性是可靠性最簡單的組成部分。此度量描述服務運行的時間百分比，這也被稱為服務的“正常運行時間”。可用性可以通過連續查詢服務并以預期的速度和準確性確認返回的響應來監控。
服務的可用性是用戶感知可靠性的主要因素。考慮到這一點，設定一個100%正常運行時間的目標是很誘人的。但是SRE告訴我們失敗是不可避免的；導致停機的事故總是發生在工程預期之外。可用性通常用“9”表示，表示正常運行時間的百分比可以達到多少位小數。一些主要的軟件公司會吹噓自己的“5個9”或者99.99%的正常運行時間，但永遠不會有可確保的100%的正常運行時間。
此外，用戶是可以容忍甚至無法注意到服務的某些領域出現宕機。致力于改善超出預期的可用性的開發資源并不會增加客戶的滿意度，把這些資源用在可維護性上會更好。
可維護性
可靠性的另一個主要組成部分是可維護性。通過描述停機時間的產生和解決方式，將可維護性因素考慮到可用性中。當發生導致停機的事件時，可維護服務可以快速修復。事件越早得到解決，服務就越快恢復可用。
可維護性有兩個主要組成部分：主動式可維護性和反應式可維護性。
主動式可維護性包括構建易于理解和更改的代碼庫。隨著開發的進行，會出現與現有代碼不兼容的問題。如果工程師寫的是面條式代碼，而不是優先考慮可維護性，就容易出問題，并且很難發現和解決問題。主動維護還包括質量保證和測試等程序。
反應式可維護性描述了服務在事故發生后被修復的能力。這受服務的事故響應過程的影響。大型事故的反應和防范是必要的，如果事故響應程序可靠，團隊將迅速解決事件。適當的事故反應也有助于減少復發。高度可維護的服務允許工程師有效地汲取這些經驗教訓。
可維護性反映在可用性指標中。縮短停機時間或停機頻率可以提高可用性。但是，可維護性不是實現可用性的唯一手段。采取這種方法可能導致發展資源分配不當。在可維護性方面的投資可能不會立即帶來更好的正常運行時間。當您重構舊代碼以解決技術債務時，服務的功能將與以前相同，并具有相同的可用性。直到事件發生，您才會看到這種高可維護性的好處。可維護性應該被看作是可靠性方面的投資，而不僅僅是可用性的一個組成部分。
可靠性
可靠性可以定義為當用戶訪問服務時，服務按預期運行的可能性。這似乎與我們定義可用性的方式相同，但有關鍵的區別。可用性檢查服務是否工作，用戶是否正在訪問它。如果用戶在所有時間、所有功能上統一訪問服務，可用性將決定可靠性。一般情況下，這不可能發生。
以兩種情形為例：
服務A：
用戶登錄頁面的可用性為97%
目錄搜索的可用性為97%
站點設置頁面的可用性為97%
服務B:
用戶登錄頁面具有可用性為99%
目錄搜索的可用性為98%
網站設置頁面的可用性為90%
僅從可用性度量來看，服務A勝出。但是如果登錄頁面被100%的用戶使用，目錄搜索被90%的用戶使用，而站點設置頁面只有30%的用戶使用，那么服務B就會被認為更可靠。可靠性需要考慮實際使用情況，將可用性指標轉化為客戶滿意度的度量指標。
通過理解系統的可靠性，開發人員可以避免浪費時間來改進超出客戶預期的可用性。服務級別指標將延遲和可用性等指標捆綁到更有效的度量中。然后將服務水平目標設定在顧客不滿意的閾值。這種方法從客戶的角度來看可靠性，因為對他們來說，服務的可靠性比它的可用性更重要。
可維護性也可以通過這種標準來評估。響應事件所花費的時間耗盡了服務正常運行時間的錯誤預算……SLI和SLO可以幫助分配開發工作，以改進可維護性和最影響客戶滿意度的事件響應過程。
可靠性不僅僅是度量的集合或代碼庫的質量。這是一個全局概念，包含了用戶的觀點、變化和增長的必然性以及開發代碼的人員。這種整體方法是SRE的基礎，是實踐的集合，也是提高服務可靠性的文化課程。
