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

當系統(tǒng)的可用性為2個9的時候,我們的系統(tǒng)有3.65天是故障不可用的,這個看起來難度并不是很大,但是當我們把標準提高到4個9的時候,我們一年只有52分鐘的時間允許故障,這是非常困難的,因為從故障的發(fā)生,到收到反饋,到定位,再修復,往往需要不少的時間。對于一個大公司來說,特別是一個有著千萬甚至上億月活的項目來說,故障的時間越長,影響的用戶越多,那么就會造成越大的損失。
那么,為了提高系統(tǒng)的可用性,我們有哪些簡單又行之有效的方法呢?
首先是規(guī)范好流程,代碼的開發(fā)到發(fā)布上線,需要進行技術評審、代碼審查、測試驗證,不能夠那么的隨意,把線上環(huán)境當成測試環(huán)境使用。
其次是做好監(jiān)控,自己發(fā)現(xiàn)用戶而不是等用戶發(fā)現(xiàn)問題,很多程序員,對處理異常、錯誤碼非常地不屑,這是個非常不好的習慣,一般來說,好的代碼,幾乎60%都是用來處理異常跟邊界情況地,如果不去做好這些,就很難從監(jiān)控中去發(fā)現(xiàn)異常。
然后是,自動化的運維,人總是會犯錯誤的,并且還常犯,相信每個運維都重啟錯應用,或者部署錯機器。而且人不可能24小時都盯著機器看,所以,我們需要自動化的運維,在某些機器故障的時候,快速進行響應。
最后則是定時的演練,在阿里巴巴,每年雙十一前的3個月,都是進行壓測跟演練,從而形成一套說明書,某某系統(tǒng)壓力過高,降級停用了,其他系統(tǒng)該如何表現(xiàn),讓技術人員又心理準備,才能在故障真正發(fā)生地時候臨危不亂。
好了,今天我們學習了高可用的系統(tǒng)標準還有一些方法論。關注我,讓我們一起學習,共同進步!