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