在一個陽光明媚的週二下午，我正在公司裡面看著即將釋出的Java 12的新特性，這時候女朋友打來電話。
晚上下班後，女朋友回到家裡面和我說，發現淘寶無法訪問的十幾分鍾後又可以了。
系統的可用性，英文名字為System Usability，即系統服務不中斷執行時間佔實際執行時間的比例。所以，可用性其實是一個百分比，如99.9%。
我們通常會聽說一個詞：高可用，其實指的就是高可用性。高可用指的就是系統服務不中斷執行時間佔實際執行時間的佔比更大。
要了解可用性，躲不開的三個體現系統可用性的重要指標：MTTR、MTTF、MTBF
MTTF 即 Mean Time To Failure，中文為：平均無故障時間。指系統無故障執行的平均時間，取所有從系統開始正常執行到發生故障之間的時間段的平均值。
MTTR 即 Mean Time To Repair，中文為：平均修復時間，指系統從發生故障到維修結束之間的時間段的平均值。
MTBF 即 Mean Time Between Failure，中文為：平均失效間隔，指系統兩次故障發生時間之間的時間段的平均值。
MTBF = MTTF + MTTR
複製程式碼按照以上概念，那麼系統的可用性指的其實就是： MTTF / MTBR * 100% 即 MTTF / ( MTTF + MTTR ) * 100%
在實際的情況中，很多系統都是由若干個子系統組成的，那麼整個系統的可用性到底該如何計算呢？我們接著來了解下系統結構。
對於串聯絡統：
衡量系統的高可用性，一般通過SLA，全稱Service Level Agrement，也就是有幾個9的高可用性。我們經常可以看到很多公司會宣稱自己的系統可以達到99.99%、99.999%等。
工業界通常通過統計故障發生到恢復的時間的方法來測量SLA。一般以年度為單位，統計一年內的系統不可用總時長。具體對應關係如下表：
對於 SLA 指標來說，9 的數字越多可用性越高，當機時間越少，系統就可以在給定的時刻內高比例地正常工作。然而對系統的挑戰就越大，投入的成本也會越高。 比如 5 個 9 要求系統每年只當機 5 分鐘左右，而 4 個 9 要求每年當機時間不超過一個小時。這就使得系統需要在設計、基礎設施、資料備份等不同層面採取多種方式，甚至增加基礎設施投資來保證可用性。
“當你的裝置處理人命關天的事情，或業務中斷一分鐘就會損失百萬美刀，那麼你可以考慮 99.99% 的可靠性。” Robertson（Linux 高可用專案開發者）
不同系統的可用性要求也是不同的，比如：淘寶、京東等這些電商系統使用者量很多，不同區不同時刻都有大量的使用者在使用系統，這必然對系統的可用性要求很高。
據以往這些系統的故障統計和不準確地測試資料推測，它們目前的可用性是在 3 個 9 到 4 個 9 左右。相對而言，企業類的工作軟體因為通常只在工作時間被使用，或只在某些特定的地區使用，或只給某部分人某一特定時間使用，可用性的需求就會低一些。
影響可用性的因素有很多，包括系統故障、基礎設施故障、資料故障、安全攻擊、系統壓力等等。
可用性的保障涉及到很多層面，其中包括但不限於了：
軟體的設計、編碼、測試、上線和軟體配置管理的水平
工程師的人員技能水平
運維的管理和技術水平
資料中心的運營管理水平
依賴於第三方服務的管理水平
對待技術的態度
一個公司的工程文化
領導者對工程的尊重
下面的表格裡，列出了高可用常見的問題和應對措施。