你今日預咗風險未？
每次與項目成員溝通後，應該都會預感項目有風險吧。
大概都會遇到這些問題：進度風險、技術難點、需求變動、資源分配問題等等。
別和我說，基本沒啥風險，項目很穩定。真有這樣沒風險的項目，那就不須要架構師了。畢竟這樣的項目確定會有成熟的「輪子」，直接借鑑就行了。
實際上，沒風險的項目不多，須要開發的軟件項目總有風險的，由於實際需求都是隨時間變化的。
咱們平常生活不少事情都是看風險來作決定的，最明顯莫過於股票、基金等投資行爲，在本身能接受的風險範圍內進行決策。這是由於風險能夠反映出真實世界的不肯定性，並且是一個很好的決策指示器，它能幫助咱們看清障礙，作出合理的選擇。
所以，風險是能夠指導咱們進行優秀的架構設計，也就是說咱們能夠採用風險驅動模型進行架構設計。
風險驅動設計
風險驅動模型就是以風險爲中心，根據合乎邏輯的理由進行決策權衡的模型。web
採用風險驅動的話，必需要能回答如下這些問題：安全
- 項目的主要失敗風險有哪些？
- 應對失敗風險的技術有哪些？
- 什麼時候結束和恢復架構設計？
爲了解答以上問題，主要的對策有：網絡
- 識別風險、描述風險
- 選擇技術下降風險
- 設定風險閾值，權衡架構設計
下面就將詳細講解以上的問題和對策。架構
風險
風險是指一個事件產生咱們所不但願的後果的可能性。對於已經發生的，應該稱之爲事故。
以上對風險的定義沒法直觀衡量，咱們借鑑下在工程領域對風險的定義，即：
風險 = 失敗的機率 x 失敗帶來的影響
但定義中失敗的機率和影響大部分的時候是難以精確度量的，除非咱們能覺察到風險，也就是說只能在已知的條件下去定義風險。所以，風險的定義就變爲：
當前已知條件下的風險 = 覺察到的失敗的機率 x 覺察到的影響
此定義是讓咱們接受現實，盡力去下降覺察到風險，使架構設計達到已知的最優。
有了定義，首先咱們要識別風險，而後就能夠去描述風險，更深刻地理解風險。框架
識別風險
識別風險的方法主要有：性能
- 肯定難以實現的需求。例如，複雜難以理解的業務問題，就須要開需求會議來評估風險。
- 識別不完整或難以理解的質量屬性（非功能屬性）需求。例如，「保證可靠性」這種不可測試的質量屬性，就須要開發質量屬性研討會來識別風險。
- 借鑑典型風險來識別。例如，web項目必需要關注安全性。
- 風險分類排序。以利益相關方需求的優先級和開發者覺察到的難度來進行風險分類排序。
描述風險
根據風險的定義，描述風險至少須要三個部分：條件、後果、優先級。條件是當前風險可能發生的實際狀況，後果（覺察到的影響）是由條件引起的未來可能出現的不良情況，優先級（覺察到的失敗的機率和影響等來肯定）是已知條件下風險的重要程度。
然而，這樣的描述方式缺少項目交叉引用的能力，所以爲了標識風險以及便於溝通理解，咱們還須要加入四個部分：名稱、編號、類型、來源。
咱們能夠採用表格的形式記錄風險。例如，能夠用表1做爲示例來描述風險。
表1 描述風險學習
| 風險名稱 | 風險編號 | 風險類型 | 條件 | 後果 | 優先級 | 來源 |
|---|---|---|---|---|---|---|
| 數據處理風險 | R1.1 | 數據風險 | 業務系統CPU、磁盤和網絡帶寬已佔有80%，數據處理將消耗大量的時間和資源 | 可能沒法順利完成任務 | 高 | 數據需求D1.1:必須1小時內處理完數據 |
經過描述理解了風險後，咱們能夠經過如下方式去下降或消除風險：測試
- 下降機率。減小業務系統的資源佔有。
- 減小影響。優化數據處理的能力，提高資源的利用率。
- 減少風險發生的時間窗口。在業務系統空閒時，進行數據處理。
- 移除條件。增長CPU、磁盤和網絡帶等資源，或需求來源方溝通，下降質量屬性的要求
- 接受現狀，等接近不可接受的程度再着手處理。優先級不高，數據處理超時和資源不夠用的狀況較少出現，等解決完優先級高的風險後或風險優先級上升後再處理。
風險指導架構設計
一旦能清楚地識別和描述所面臨的風險，就能夠藉助風險來指導架構設計，進而運用合適的技術去下降或消除風。
能夠把風險理解爲架構設計的GPS，它幫助咱們進行架構設計的定位，告知咱們目前在何地距離要去的目的地還有多遠。優化
技術選擇
根據風險選擇技術是最敏捷高效的，這樣就不會把時間和資源浪費在那些低效的技術上，也不會忽略那些危及項目的風險，主動地推進咱們進行最優的技術選型。
藉助風險選擇技術的方法主要有：url
- 分析風險的條件、影響、機率、時間窗口，肯定能夠解決的部分，進而選擇解決問題的技術。
- 借鑑業界成熟解決方案。
- 研究密切相關的技術，尋找解決風險的技術
爲了實現架構設計的可重複性，咱們還能夠總結經驗，作出風險指導架構設計的指南。例如：
| 面臨的風險 | 解決的技術 | 時間和成本預計 |
|---|---|---|
| 數據處理沒法順利完成 | 增長硬件資源、引入數據處理框架 | 硬件資源每一年花費XX元，引入XX框架學習成本是x我的天 |
設定風險閾值
風險的閾值究竟是多少？
咱們參考下《恰如其分的軟件架構》對風險閾值的定義：風險下降到再也不是系統中最大風險源的地步。固然這是主觀的判斷，但只要能保證所設計的架構能克服所面臨的失敗便可。
若是架構再也不是系統中最大的風險源，就能夠從主動設計轉爲被動設計，不然從被動設計轉爲主動設計。主動設計是指主動設法下降或消除風險。被動設計是指在需求變動、出現未知的性能問題等須要及時糾正的狀況。
須要注意的是，架構還能夠隨時從新變回重大的風險源，這多是由於現實環境的變化、重大的需求變動、不可控的項目管理風險等等。當這些狀況出現時，確定要切換回主動設計模型。
總結
運用風險驅動設計的方法，能夠識別和描述風險，並選擇一套架構和設計技術來下降或消除這些風險，還能夠根據風險的重要程度和閾值，把握住架構設計的度，進行最高效敏捷的設計。