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