在我們日常的生活中，可用性是衡量一個東西好壞的標準。舉個例子，一輛車，動力很足，內飾奢華，空間夠大，安全性好，但是每半個小時就會熄火一次，這是個好車麼？同樣的道理，你設計一個APP，操作流暢，但是每半個小時就會Crash一次，顯然也不是什麼好APP。對於程式設計師來說，特別是對於後端開發來說，系統的可用性非常地重要，那麼怎麼衡量一個系統的可用性呢？我們有兩個重要的標準，一個是故障間隔時間，顧名思義，就是兩次故障之間，相隔了多長的時間，很明顯，故障間隔時間越長，說明系統越穩定。另一個是故障恢復時間，人非聖賢，孰能無過。故障總是會發生的，那麼從故障開始，到發現問題，解決問題的時間，我們稱之為故障解決時間，很明顯，故障解決時間越短，說明解決問題的速度越快，系統越穩定。我們把故障間隔時間/（故障間隔時間+故障恢復時間）稱之為系統的可用率，很顯然，這是個小於等於100%的數。我們把系統可用率99%以上的稱之為2個9，把系統可用率99.9%以上的稱之為3個9，很顯然，越接近1，說明可用性越高。但是每當我們把可用性提高1個9，有多難麼？

當系統的可用性為2個9的時候，我們的系統有3.65天是故障不可用的，這個看起來難度並不是很大，但是當我們把標準提高到4個9的時候，我們一年只有52分鐘的時間允許故障，這是非常困難的，因為從故障的發生，到收到反饋，到定位，再修復，往往需要不少的時間。對於一個大公司來說，特別是一個有著千萬甚至上億月活的專案來說，故障的時間越長，影響的使用者越多，那麼就會造成越大的損失。那麼，為了提高系統的可用性，我們有哪些簡單又行之有效的方法呢？首先是規範好流程，程式碼的開發到釋出上線，需要進行技術評審、程式碼審查、測試驗證，不能夠那麼的隨意，把線上環境當成測試環境使用。

其次是做好監控，自己發現使用者而不是等使用者發現問題，很多程式設計師，對處理異常、錯誤碼非常地不屑，這是個非常不好的習慣，一般來說，好的程式碼，幾乎60%都是用來處理異常跟邊界情況地，如果不去做好這些，就很難從監控中去發現異常。然後是，自動化的運維，人總是會犯錯誤的，並且還常犯，相信每個運維都重啟錯應用，或者部署錯機器。而且人不可能24小時都盯著機器看，所以，我們需要自動化的運維，在某些機器故障的時候，快速進行響應。最後則是定時的演練，在阿里巴巴，每年雙十一前的3個月，都是進行壓測跟演練，從而形成一套說明書，某某系統壓力過高，降級停用了，其他系統該如何表現，讓技術人員又心理準備，才能在故障真正發生地時候臨危不亂。