系統中的故障場景建模(2)

　　在下一節中，我們將介紹解決方案的一些特性。我們需要將這些特性整合到解決方案的架構中，并且需要在創建故障模型時考慮這些屬性。
　　第二步. 建立運作指標
　　在識別出解決方案的各種場景以及它們所依賴的不同系統/服務后，我們需要明白系統的正常運作模式是什么。只有這樣，我們才能夠識別出系統是否存在異常的情況，并可以及時采取主動的應對措施。在這一節中，我們將檢查系統的資源約束并通過對解決方案的質量特性進行建模，從而概括出正常的運作模型。
　　解決方案特性可以被劃分為兩個高層次的分類：解決方案的功能特性和解決方案的運作特性。解決方案的功能特性描述的是該方案提供的實實在在的功能。而解決方案的運作特性有時被稱為非功能性需求，它只是確定了該系統會如何運作。
　　這些質量特性包括系統的可擴展性范圍，系統在正?；蝈e誤條件下的響應時間，系統的可用性等。雖然對最終用戶是不可見的，但是解決方案的質量需求將決定系統在業務中的長期價值。
　　我們通常將解決方案質量的一個子集歸為解決方案服務品質協議(SLAs)。通常的SLAs包括但不限于：響應時間，可用性，系統支持的并發用戶數。
　　你的系統需要滿足的SLAs通常取決于業務需要和市場需求。有的時候，達成SLA的期望過早，而在后期對依賴系統的分析中會發現，預先達成的SLAs其實是不可行的。
　　在這一節中，我們將考察從SLAs中挑選出最常見的三項。展示我們如何通過著眼于它們的依賴，從而使我們的解決方案可以支持的SLAs更加清晰合理。
　　系統可用性模型
　　對于指定的解決方案來說，可用性往往是SLA列表里排在首位的。當然，所有的軟件解決方案都努力的希望達到100%的可用性。但不幸的是，在復雜的解決方案中，系統的功能實現都由一系列其他系統集成而成，這使得要達到100%的可用性極其困難。
　　取決于不同的功能依賴，要計算整個系統的可用性數值非常復雜。然而，我們可以使用以下的公式，來粗略地計算計劃中解決方案的可用性。
　　總可用性 = 依賴系統1的可用性*依賴系統2的可用性*依賴系統N的可用性 (譯者注：這里原文中可能漏掉了一個省略號，個人感覺應該是如下公式, 總可用性 = 依賴系統1的可用性*依賴系統2的可用性*…*依賴系統N的可用性) 為了能更真實的理解解決方案的功能可用性，并為依賴系統的響應制定計劃?？梢允褂萌缦聢D所示的模型來計算基于依賴服務可用性的場景可用性。

場景/服務	訂單執行服務	庫存服務	客戶數據庫	商品目錄	客戶評論服務	系統響應時間
搜索商品				99.50%		99.50%
閱讀客戶評論					98.00%	98.00%
添加商品到購物車		99.90%		99.50%		99.40%
結賬	99.00%	99.90%	99.99%			98.89%

　　我們注意到，上面的例子中，依賴服務各自的可用性將通過應用/服務所屬的分組獲取到。在大多數的企業場景中，直接從運維團隊獲取到數據是最精確最理想的方法。
　　系統響應時間模型
　　隨著復雜軟件解決方案中依賴項數目的增長，系統的響應時間將被串聯起來。其中系統響應時間的波動將對整個開發中的解決方案的總體響應時間產生負面影響。
　　最常見的一種容易被忽視的情況是具有父子處理關系的一些場景。當接收到一個包含了很多子項需要被進一步處理的請求時，做出的響應往往有很多的情況。盡管這個問題看起來很瑣碎，但是在理解每個調用鏈的總體響應時間之前，有很多的數據依賴問題需要去解答。
　　為了簡便起見，我們將只集中精力于所有參與服務的調用鏈依賴而不是數據依賴。
　　為了對期望的響應時間建模，我們將重新使用服務依賴項矩陣。這一次，我們不再簡單的展示依賴關系，而是清算出每個服務的調用次數。如果再加上各自服務響應時間的指標，表格將如下所示：

原文轉自：http://www.anti-gravitydesign.com