Quality Attribute Scenarios（4）：Availability General Scenarios

February 07 22:40~23:44

為了幫助使用者寫出QAS，書中針對六種quality attributes個別訂定了一個所謂的「general scenario」，開發人員可以把這個general scenario看成是用來產生QAS的範本。今天先看一下availability general scenario（課本80-81頁），各位鄉民還記得一個QAS包含那六個元素嗎？

元素	可能的內容
Source	系統內部或系統外部
Stimulus	Fault的種類：omission, crash, timing, response
Artifact	系統處裡器，通訊通道，永久儲存體，行程（process）
Environment	正常操作或降級模式
Response	系統要能夠增測到fault發生，並且執行以下一種或多種動作：(1)通知相關人等或是其他系統；(2)將產生fault來源的元件或系統關閉，隔離或移除；(3)暫時停止系統服務一小段時間；(4)在正常或是降級模式中繼續提供服務
Response Measure	(1)系統需要花多少時間從fault中復原；(2)系統可得性；(3)系統從降級模式到正常模式所需花費的時間；(4)修復時間

有了上面這個表格，鄉民們就可以替自己的軟體架構定義出很多個availability QAS（非功能需求）。再舉例子之前先說明一下上面這個表格中的內容：

• Source：Stimulus的來源可能來自系統內部或是系統外部，例如，一個資料庫應用系統，source可能是系統的使用者介面元件（系統內部），或是來自於外部的資料庫系統。
• Stimulus：fault的種類一共有四大類，
  • omission：忽略，系統無法回應一個要求
  • crash：系統持續遭遇到ommission這種fault（翻成白話文，系統持續無法回應要求，就等於當機啊）
  • timing：系統太早或太晚回應需求（timing不對）
  • response：系統回應會應錯誤的答案
• Artiface：需要高度可得性的系統或元件
• Environment：當fault發生時系統的狀態，這個狀態很可能會影響到系統處理fault的策略，例如當系統已經是處於降級模式時，又不斷的遇到很多fault（可能是遭受攻擊），那麼此時系統可能會決定暫停服務一小段時間。
• Response measure：用來評量這個availability QAS是否合格的標準，例如當fault發生時系統必須要在0.1ms回復正常，或是當系統當機時，平均修復時間必須少於五分鐘。

***

接下來舉兩個簡單的例子

Quality Attribute	Source	Stimulus	Artifact	Environment	Response	Response Measure
Availability	Database (external system)	connection closed (omission)	Application (process)	Normal operation	create a new connection and continue to operate	No downtime
Availability	Database (external system)	no response (crash)	Application (process)	Normal operation	switch to the replicated database, inform DBA, and continue to operate	No downtime

參考上表依樣畫葫蘆，花點時間腦力激盪一下就可以訂出很多的availability QAS。

看到這邊鄉民們是不是在想，這樣不是很麻煩嗎？沒錯，是很麻煩，但是誰叫你要開發high availability的系統呢，想 賺錢 做出好東西就不要怕麻煩啊…XD 。

***

友藏內心獨白：好多細節Teddy也都忘了，邊寫邊複習。