在我們日常的生活中，可用性是衡量一個東西好壞的標準。舉個例子，一輛車，動力很足，內飾奢華，空間夠大，安全性好，但是每半個小時就會熄火一次，這是個好車么?同樣的道理，你設計一個APP，操作流暢，但是每半個小時就會Crash一次，顯然也不是什么好APP。對于程序員來說，特別是對于后端開發來說，系統的可用性非常地重要，那么怎么衡量一個系統的可用性呢?

[[284626]]

我們有兩個重要的標準，一個是故障間隔時間，顧名思義，就是兩次故障之間，相隔了多長的時間，很明顯，故障間隔時間越長，說明系統越穩定。另一個是故障恢復時間，人非圣賢，孰能無過。故障總是會發生的，那么從故障開始，到發現問題，解決問題的時間，我們稱之為故障解決時間，很明顯，故障解決時間越短，說明解決問題的速度越快，系統越穩定。

我們把故障間隔時間/(故障間隔時間+故障恢復時間)稱之為系統的可用率，很顯然，這是個小于等于100%的數。我們把系統可用率99%以上的稱之為2個9，把系統可用率99.9%以上的稱之為3個9，很顯然，越接近1，說明可用性越高。但是每當我們把可用性提高1個9，有多難么?

當系統的可用性為2個9的時候，我們的系統有3.65天是故障不可用的，這個看起來難度并不是很大，但是當我們把標準提高到4個9的時候，我們一年只有52分鐘的時間允許故障，這是非常困難的，因為從故障的發生，到收到反饋，到定位，再修復，往往需要不少的時間。對于一個大公司來說，特別是一個有著千萬甚至上億月活的項目來說，故障的時間越長，影響的用戶越多，那么就會造成越大的損失。

那么，為了提高系統的可用性，我們有哪些簡單又行之有效的方法呢?

首先是規范好流程，代碼的開發到發布上線，需要進行技術評審、代碼審查、測試驗證，不能夠那么的隨意，把線上環境當成測試環境使用。

其次是做好監控，自己發現用戶而不是等用戶發現問題，很多程序員，對處理異常、錯誤碼非常地不屑，這是個非常不好的習慣，一般來說，好的代碼，幾乎60%都是用來處理異常跟邊界情況地，如果不去做好這些，就很難從監控中去發現異常。

然后是，自動化的運維，人總是會犯錯誤的，并且還常犯，相信每個運維都重啟錯應用，或者部署錯機器。而且人不可能24小時都盯著機器看，所以，我們需要自動化的運維，在某些機器故障的時候，快速進行響應。

最后則是定時的演練，在阿里巴巴，每年雙十一前的3個月，都是進行壓測跟演練，從而形成一套說明書，某某系統壓力過高，降級停用了，其他系統該如何表現，讓技術人員又心理準備，才能在故障真正發生地時候臨危不亂。

好了，今天我們學習了高可用的系統標準還有一些方法論。關注我，讓我們一起學習，共同進步!