l

2012年2月8日 星期三

Quality Attribute Scenarios(3):Availability

February 07 18:16~19:10

在這系列第一集的時候Teddy提到Software Architecture in Practice, 2nd 這本書介紹availability、modifiability、performance、security、testability、usability這六種QAS,今天先介紹一下availability的定義,下一集在介紹availability QAS。

Availability中文翻作可用性,這是一個經常可以聽到的非功能需求,尤其是現在網路與雲端計算很熱門,一個雲端應用的availability就變得很重要。那麼到底什麼是availability?如果用簡單的白話文來說明,availability就是某樣東西或是服務,當你想要用它的時候,是否立即就可以使用。例如,當Teddy想用Facebook、Gmail、或是Dropbox的時候,這些服務是否還活得好好的。如果這些服務三不五時就當機,使得使用者想用的時候卻無法使用,我們就說這個服務的availability很低。

從軟體架構的設計面來看,要設計一個availability很高的系統,所必須考量的因素有兩點:

  • System failure types:有哪些情況會導致system failure。當一個系統無法依據它的規格書所規範的條件來提供服務的時候,我們就說這個系統失效(system failure)。這邊有一個很重要的「眉角」要注意,那就是系統是否發生failure是要依據他的規格書所記載的服務條件來判斷。舉一個大家都知道的例子,如果鄉民們跑去搭台灣高鐵,今天高鐵誤點59分鐘,請問可否退票?答案是不行,因為人家的規格書寫了,誤點超過60分鐘才可以退票,所以就算是「只」誤點59分59秒也不算system failure,因此無法退票。
  • The consequences of a system failure :當一個系統失效所造成的後果有多麼嚴重,是只要重開機一下耽誤個使用者幾分鐘而已,還是會造成幾百萬…美元的損失,或是會 毆傷運將 搞出人命。

在談到availability還有一個觀念要弄清楚,那就是failure和fault的差別。Fault就是系統的缺陷或是可以簡單想成bug,當系統中有缺陷的時候,就有可能造成系統失效導致無法提供服務。但是fault只要被妥善處理之後,就不會造成failure。換句話說,從使用者的角度來看,使用者只觀察的到failure但看不到fault。當一個fault可以被使用者所觀察到,那麼就表示這個fault變成了failure,也就是說這個fault造成系統失效。

鄉民們可能會問,幹嘛區分這些有的沒的觀念?因為要提升系統的availability,就是要降低系統失效的機會;要降低系統失效的機會,就要想辦法讓系統不會有fault,或是退而求其次,當fault發生的時候,要想辦法去處理它使其不會造成系統失效,這樣系統才可以繼續運作下去,availability才會高。

最後談到如何評量一個系統的availability,公式如下:

availability = mean time to failure / (mean tim to failure + mean time to repair)

假設一個系統的mean time to failure (MTTF) 是2年(兩年當機一次)而mean time to repair (MTTR) 是一小時,那麼:

MTTF in hours = 2 * 365 * 24 = 17520 (系統跑了17520個小時才會當機一次)

Availability= MTTF/(MTTF+MTTR) = 17520/17521=99.99429%

Unavailability = 0.00571%

一年當中有多少小時無法使用該系統

U= 0.00571% * 365 * 24 = 0.62195 小時/年

最後的最後還有一個觀念,叫做scheduled downtime,排定的停機時間,這個時間一般來講是不算入一個系統的availability之內。例如,一個系統每半年要停機2小時來備份資料。在這段停機的時間中,由於系統已經對外公告「暫停營業」,所以不會算入availability的計算之中。

先有這樣的觀念之後,之後談availability QAS才會有fu…XD。

***

友藏內心獨白:mean time to failure要怎麼算啊?

沒有留言:

張貼留言