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要怎麼算啊？