在我們?nèi)粘５纳钪?，可用性是衡量一個(gè)東西好壞的標(biāo)準(zhǔn)。舉個(gè)例子，一輛車，動(dòng)力很足，內(nèi)飾奢華，空間夠大，安全性好，但是每半個(gè)小時(shí)就會(huì)熄火一次，這是個(gè)好車么?同樣的道理，你設(shè)計(jì)一個(gè)APP，操作流暢，但是每半個(gè)小時(shí)就會(huì)Crash一次，顯然也不是什么好APP。對(duì)于程序員來說，特別是對(duì)于后端開發(fā)來說，系統(tǒng)的可用性非常地重要，那么怎么衡量一個(gè)系統(tǒng)的可用性呢?

[[284626]]

我們有兩個(gè)重要的標(biāo)準(zhǔn)，一個(gè)是故障間隔時(shí)間，顧名思義，就是兩次故障之間，相隔了多長(zhǎng)的時(shí)間，很明顯，故障間隔時(shí)間越長(zhǎng)，說明系統(tǒng)越穩(wěn)定。另一個(gè)是故障恢復(fù)時(shí)間，人非圣賢，孰能無過。故障總是會(huì)發(fā)生的，那么從故障開始，到發(fā)現(xiàn)問題，解決問題的時(shí)間，我們稱之為故障解決時(shí)間，很明顯，故障解決時(shí)間越短，說明解決問題的速度越快，系統(tǒng)越穩(wěn)定。

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

當(dāng)系統(tǒng)的可用性為2個(gè)9的時(shí)候，我們的系統(tǒng)有3.65天是故障不可用的，這個(gè)看起來難度并不是很大，但是當(dāng)我們把標(biāo)準(zhǔn)提高到4個(gè)9的時(shí)候，我們一年只有52分鐘的時(shí)間允許故障，這是非常困難的，因?yàn)閺墓收系陌l(fā)生，到收到反饋，到定位，再修復(fù)，往往需要不少的時(shí)間。對(duì)于一個(gè)大公司來說，特別是一個(gè)有著千萬甚至上億月活的項(xiàng)目來說，故障的時(shí)間越長(zhǎng)，影響的用戶越多，那么就會(huì)造成越大的損失。

那么，為了提高系統(tǒng)的可用性，我們有哪些簡(jiǎn)單又行之有效的方法呢?

首先是規(guī)范好流程，代碼的開發(fā)到發(fā)布上線，需要進(jìn)行技術(shù)評(píng)審、代碼審查、測(cè)試驗(yàn)證，不能夠那么的隨意，把線上環(huán)境當(dāng)成測(cè)試環(huán)境使用。

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

然后是，自動(dòng)化的運(yùn)維，人總是會(huì)犯錯(cuò)誤的，并且還常犯，相信每個(gè)運(yùn)維都重啟錯(cuò)應(yīng)用，或者部署錯(cuò)機(jī)器。而且人不可能24小時(shí)都盯著機(jī)器看，所以，我們需要自動(dòng)化的運(yùn)維，在某些機(jī)器故障的時(shí)候，快速進(jìn)行響應(yīng)。

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

好了，今天我們學(xué)習(xí)了高可用的系統(tǒng)標(biāo)準(zhǔn)還有一些方法論。關(guān)注我，讓我們一起學(xué)習(xí)，共同進(jìn)步!