每種架構(gòu)都有與之相關(guān)的風(fēng)險(xiǎn)，無(wú)論是涉及可用性、可擴(kuò)展性還是數(shù)據(jù)完整性的風(fēng)險(xiǎn)。架構(gòu)風(fēng)險(xiǎn)分析是架構(gòu)的關(guān)鍵活動(dòng)之一。通過(guò)不斷分析風(fēng)險(xiǎn)，架構(gòu)師可以解決架構(gòu)中的缺陷，并采取糾正措施來(lái)降低風(fēng)險(xiǎn)。在本章中，我們將介紹一些關(guān)鍵技術(shù)和實(shí)踐，這些技術(shù)和實(shí)踐可用于確認(rèn)風(fēng)險(xiǎn)、創(chuàng)建風(fēng)險(xiǎn)評(píng)估，以及通過(guò)一項(xiàng)名為“風(fēng)險(xiǎn)風(fēng)暴”的活動(dòng)來(lái)識(shí)別風(fēng)險(xiǎn)。
風(fēng)險(xiǎn)矩陣
評(píng)估架構(gòu)風(fēng)險(xiǎn)時(shí)出現(xiàn)的第一個(gè)問(wèn)題是確定風(fēng)險(xiǎn)應(yīng)歸類為低、中還是高。在這種歸類中通常會(huì)引入過(guò)多的主觀性，從而造成對(duì)架構(gòu)中哪些部分是真正的高風(fēng)險(xiǎn)還是中等風(fēng)險(xiǎn)的混淆。幸運(yùn)的是，架構(gòu)師可以利用一個(gè)風(fēng)險(xiǎn)矩陣來(lái)幫助降低主觀性的水平，并量化與架構(gòu)的特定領(lǐng)域相關(guān)的風(fēng)險(xiǎn)。
架構(gòu)風(fēng)險(xiǎn)矩陣（如圖20-1所示）使用兩個(gè)維度來(lái)量化風(fēng)險(xiǎn)：風(fēng)險(xiǎn)的總體影響和風(fēng)險(xiǎn)發(fā)生的可能性。每個(gè)維度都有一個(gè)低（1）、中（2）和高（3）等級(jí)。這些數(shù)字在矩陣的每個(gè)網(wǎng)格內(nèi)相乘，提供表示該風(fēng)險(xiǎn)的客觀數(shù)字。數(shù)字1和2被認(rèn)為是低風(fēng)險(xiǎn)（綠色），數(shù)字3和4被認(rèn)為是中等風(fēng)險(xiǎn)（黃色），數(shù)字6到9被認(rèn)為是高風(fēng)險(xiǎn)（紅色）。
為了了解如何使用風(fēng)險(xiǎn)矩陣，假設(shè)需要考慮應(yīng)用中使用的主中央數(shù)據(jù)庫(kù)的可用性。首先，考慮影響維度：如果數(shù)據(jù)庫(kù)關(guān)閉或變得不可用，總體影響是什么？在這里，架構(gòu)師可能會(huì)認(rèn)為風(fēng)險(xiǎn)很高，將該風(fēng)險(xiǎn)設(shè)為3（中等）、6（高）或9（高）。然而，在應(yīng)用第二個(gè)維度（風(fēng)險(xiǎn)發(fā)生的可能性）之后，架構(gòu)師意識(shí)到數(shù)據(jù)庫(kù)位于集群配置中的高可用服務(wù)器上，因此數(shù)據(jù)庫(kù)變得不可用的可能性很低。因此，高影響和低可能性之間的交叉點(diǎn)給出的總體風(fēng)險(xiǎn)評(píng)級(jí)為3（中等風(fēng)險(xiǎn)）。
提示
當(dāng)利用風(fēng)險(xiǎn)矩陣來(lái)確定風(fēng)險(xiǎn)時(shí)，首先考慮影響維度，其次考慮可能性維度。
風(fēng)險(xiǎn)評(píng)估
上一節(jié)中描述的風(fēng)險(xiǎn)矩陣可用于構(gòu)建所謂的風(fēng)險(xiǎn)評(píng)估。風(fēng)險(xiǎn)評(píng)估是關(guān)于某種上下文和有意義的評(píng)估標(biāo)準(zhǔn)的架構(gòu)總體風(fēng)險(xiǎn)的總結(jié)報(bào)告。
風(fēng)險(xiǎn)評(píng)估的形式可以各式各樣，但一般來(lái)說(shuō)，它們包含基于應(yīng)用的服務(wù)或領(lǐng)域的某些評(píng)估標(biāo)準(zhǔn)的風(fēng)險(xiǎn)（從風(fēng)險(xiǎn)矩陣中量化）?；镜娘L(fēng)險(xiǎn)評(píng)估報(bào)告格式如圖20-2所示，其中淺灰色（1-2）表示低風(fēng)險(xiǎn)，中灰色（3-4）表示中等風(fēng)險(xiǎn)，深灰色（6-9）表示高風(fēng)險(xiǎn)。通常這些顏色編碼為綠色（低）、黃色（中）和紅色（高），但采用陰影對(duì)于黑白渲染和色盲非常有用。
風(fēng)險(xiǎn)矩陣中的量化風(fēng)險(xiǎn)可以通過(guò)風(fēng)險(xiǎn)標(biāo)準(zhǔn)以及服務(wù)或領(lǐng)域來(lái)累加。例如，請(qǐng)注意，在圖20-2中，數(shù)據(jù)完整性的累加風(fēng)險(xiǎn)是最高的風(fēng)險(xiǎn)區(qū)域，總共是17，而可用性的累積風(fēng)險(xiǎn)只有10（風(fēng)險(xiǎn)最?。?。每個(gè)領(lǐng)域的相關(guān)風(fēng)險(xiǎn)也可以通過(guò)例子中的風(fēng)險(xiǎn)評(píng)估來(lái)確定。在這里，客戶注冊(cè)服務(wù)的風(fēng)險(xiǎn)最高，而訂單履行服務(wù)的風(fēng)險(xiǎn)最低。可以跟蹤這些相關(guān)數(shù)字，以證明特定風(fēng)險(xiǎn)類別或領(lǐng)域內(nèi)風(fēng)險(xiǎn)的改善或降低。
盡管圖20-2中的風(fēng)險(xiǎn)評(píng)估示例包含了所有的風(fēng)險(xiǎn)分析結(jié)果，但很少會(huì)這樣呈現(xiàn)。過(guò)濾對(duì)于在給定上下文中直觀地指示特定消息是必不可少的。例如，假設(shè)一個(gè)架構(gòu)師正在開(kāi)會(huì)，目的是展示系統(tǒng)中高風(fēng)險(xiǎn)的區(qū)域。除了展示圖20-2所示的風(fēng)險(xiǎn)評(píng)估，過(guò)濾可以用于只顯示高風(fēng)險(xiǎn)區(qū)域（如圖20-3所示），提高整體信噪比，并呈現(xiàn)系統(tǒng)狀態(tài)的清晰圖像（好或壞）。
圖20-2的另一個(gè)問(wèn)題是，該評(píng)估報(bào)告僅顯示了一個(gè)時(shí)間快照；它并不能顯示情況是在好轉(zhuǎn)還是在惡化。換句話說(shuō)，圖20-2沒(méi)有顯示風(fēng)險(xiǎn)的趨勢(shì)。呈現(xiàn)風(fēng)險(xiǎn)方向在某種程度上是一個(gè)問(wèn)題。如果用向上或向下箭頭來(lái)表示方向，向上箭頭是什么意思？情況是好轉(zhuǎn)還是惡化？我們花了數(shù)年時(shí)間詢問(wèn)人們向上箭頭是否意味著事情變得更好或更糟，近50%的人說(shuō)向上箭頭意味著事情逐漸變得更糟，而近50%的人說(shuō)向上箭頭表示事情正在變得更好。左右箭頭也是如此。因此，當(dāng)使用箭頭指示方向時(shí)，必須使用關(guān)鍵字。然而，我們也發(fā)現(xiàn)這也不起作用。一旦用戶滾動(dòng)到關(guān)鍵字之外，疑惑就會(huì)再次發(fā)生。
我們通常在風(fēng)險(xiǎn)評(píng)級(jí)旁邊使用加號(hào)（+）和減號(hào)（-）的通用方向符號(hào)來(lái)表示方向，如圖20-4所示。請(qǐng)注意，在圖20-4中，盡管客戶注冊(cè)服務(wù)的性能風(fēng)險(xiǎn)為中等（4），但方向?yàn)樨?fù)號(hào)（紅色），表明它正在逐漸惡化并走向高風(fēng)險(xiǎn)。另一方面，請(qǐng)注意目錄簽出服務(wù)的可擴(kuò)展性風(fēng)險(xiǎn)很高（6），帶有一個(gè)加號(hào)（綠色），表明它正在改善。沒(méi)有加號(hào)或減號(hào)的風(fēng)險(xiǎn)評(píng)級(jí)表明風(fēng)險(xiǎn)是穩(wěn)定的，沒(méi)有好轉(zhuǎn)也沒(méi)有惡化。
有時(shí)，甚至加號(hào)和減號(hào)也會(huì)讓一些人感到迷惑。指示方向的另一個(gè)技巧是利用箭頭和它所趨向的風(fēng)險(xiǎn)評(píng)級(jí)數(shù)字。如圖20-5所示，這種技術(shù)不需要關(guān)鍵字，因?yàn)榉较蚝芮宄?。此外，顏色的使用（紅色箭頭表示惡化，綠色箭頭表示改善）使風(fēng)險(xiǎn)的趨勢(shì)方向更加清晰。
通過(guò)使用本書前面描述的適應(yīng)性函數(shù)的連續(xù)測(cè)量，可以確定風(fēng)險(xiǎn)的趨勢(shì)方向。通過(guò)客觀分析每個(gè)風(fēng)險(xiǎn)標(biāo)準(zhǔn)，可以觀察到趨勢(shì)走向，從而為每個(gè)風(fēng)險(xiǎn)標(biāo)準(zhǔn)提供方向。
風(fēng)險(xiǎn)風(fēng)暴
沒(méi)有一個(gè)架構(gòu)師能夠單槍匹馬地確定系統(tǒng)的總體風(fēng)險(xiǎn)。原因有兩個(gè)方面。首先，一個(gè)架構(gòu)師可能會(huì)錯(cuò)過(guò)或忽略一個(gè)風(fēng)險(xiǎn)區(qū)域，很少有架構(gòu)師對(duì)系統(tǒng)的每個(gè)部分都有充分的了解。這就是風(fēng)險(xiǎn)風(fēng)暴可以提供幫助的地方。
風(fēng)險(xiǎn)風(fēng)暴是一種協(xié)作活動(dòng)，用于確定特定維度內(nèi)的架構(gòu)風(fēng)險(xiǎn)。常見(jiàn)維度（風(fēng)險(xiǎn)領(lǐng)域）包括未經(jīng)驗(yàn)證的技術(shù)、性能、可擴(kuò)展性、可用性（包括可傳遞的依賴關(guān)系）、數(shù)據(jù)丟失、單點(diǎn)故障和安全性。盡管大多數(shù)風(fēng)險(xiǎn)風(fēng)暴涉及到多個(gè)架構(gòu)師，但明智的做法是也把高級(jí)開(kāi)發(fā)人員和技術(shù)負(fù)責(zé)人包含進(jìn)來(lái)。他們不僅可以提供架構(gòu)風(fēng)險(xiǎn)的實(shí)施層面的觀點(diǎn)，而且讓開(kāi)發(fā)人員參與進(jìn)來(lái)有助于他們更好地理解架構(gòu)。
風(fēng)險(xiǎn)風(fēng)暴的工作既包括個(gè)人部分，也包括協(xié)作部分。在個(gè)人的部分中，所有參與者使用上一節(jié)中描述的風(fēng)險(xiǎn)矩陣將風(fēng)險(xiǎn)單獨(dú)（無(wú)需協(xié)作）分配給架構(gòu)的各個(gè)區(qū)域。風(fēng)險(xiǎn)風(fēng)暴的這一非協(xié)作部分非常重要，這樣參與者就不會(huì)影響或直接將注意力從架構(gòu)的特定區(qū)域引開(kāi)。在風(fēng)險(xiǎn)風(fēng)暴的協(xié)作部分，所有參與者共同努力，就風(fēng)險(xiǎn)區(qū)域達(dá)成共識(shí)，討論風(fēng)險(xiǎn)，并形成減輕風(fēng)險(xiǎn)的解決方案。
架構(gòu)圖用于風(fēng)險(xiǎn)風(fēng)暴工作的兩個(gè)部分。對(duì)于整體風(fēng)險(xiǎn)評(píng)估，通常使用綜合架構(gòu)圖，而應(yīng)用程序特定區(qū)域內(nèi)的風(fēng)險(xiǎn)風(fēng)暴將使用上下文架構(gòu)圖。進(jìn)行風(fēng)險(xiǎn)應(yīng)對(duì)工作的架構(gòu)師有責(zé)任確保這些圖表是最新的，并可供所有參與者使用。
圖20-6顯示了我們將用于說(shuō)明風(fēng)險(xiǎn)風(fēng)暴過(guò)程的示例架構(gòu)。在這個(gè)架構(gòu)中，彈性負(fù)載平衡器在每個(gè)都包含web服務(wù)器（Nginx）和應(yīng)用服務(wù)的EC2實(shí)例之前。應(yīng)用服務(wù)調(diào)用MySQL數(shù)據(jù)庫(kù)、Redis緩存和MongoDB數(shù)據(jù)庫(kù)進(jìn)行日志記錄。他們還調(diào)用推送擴(kuò)展服務(wù)器。擴(kuò)展服務(wù)器依次與MySQL數(shù)據(jù)庫(kù)、Redis緩存和MongoDB日志記錄工具進(jìn)行連接。
風(fēng)險(xiǎn)風(fēng)暴分為三個(gè)主要活動(dòng)：
1、識(shí)別風(fēng)險(xiǎn)
2、達(dá)成共識(shí)
3、減輕風(fēng)險(xiǎn)
識(shí)別風(fēng)險(xiǎn)始終是一種個(gè)人的、非協(xié)作的活動(dòng)，而達(dá)成共識(shí)和緩解風(fēng)險(xiǎn)則始終是協(xié)作的，所有參與者都在同一個(gè)房間（至少是虛擬的）一起工作。以下各節(jié)將詳細(xì)討論這些主要活動(dòng)。
識(shí)別風(fēng)險(xiǎn)
風(fēng)險(xiǎn)風(fēng)暴的識(shí)別風(fēng)險(xiǎn)活動(dòng)涉及每個(gè)參與者分別識(shí)別架構(gòu)內(nèi)的風(fēng)險(xiǎn)區(qū)域。以下步驟描述了風(fēng)險(xiǎn)風(fēng)暴的識(shí)別風(fēng)險(xiǎn)工作：
1、進(jìn)行風(fēng)險(xiǎn)風(fēng)暴的架構(gòu)師在協(xié)作部分工作開(kāi)始前一到兩天向所有參與者發(fā)出邀請(qǐng)。邀請(qǐng)包含架構(gòu)圖（或找到它的位置）、風(fēng)險(xiǎn)風(fēng)暴維度（針對(duì)特定風(fēng)險(xiǎn)風(fēng)暴工作分析的風(fēng)險(xiǎn)區(qū)域）、風(fēng)險(xiǎn)風(fēng)暴協(xié)作部分的日期和地點(diǎn)。
2、使用本章第一節(jié)中描述的風(fēng)險(xiǎn)矩陣，參與者分別分析架構(gòu)，并將風(fēng)險(xiǎn)分為低（1-2）、中（3-4）或高（6-9）。
3、參與者準(zhǔn)備帶有相應(yīng)顏色（綠色、黃色和紅色）的小便箋，并記下相應(yīng)的風(fēng)險(xiǎn)編號(hào)（見(jiàn)風(fēng)險(xiǎn)矩陣）。
大多數(shù)風(fēng)險(xiǎn)風(fēng)暴工作只涉及分析一個(gè)特定維度（如性能），但由于人員空閑或時(shí)間安排問(wèn)題，有時(shí)可能會(huì)在單個(gè)風(fēng)險(xiǎn)風(fēng)暴工作中分析多個(gè)維度（如性能、可擴(kuò)展性和數(shù)據(jù)丟失）。當(dāng)在一次風(fēng)險(xiǎn)風(fēng)暴中分析多個(gè)維度時(shí)，參與者將維度寫在便箋上的風(fēng)險(xiǎn)編號(hào)旁邊，以便每個(gè)人都知道具體的維度。例如，假設(shè)三個(gè)參與者在中央數(shù)據(jù)庫(kù)中發(fā)現(xiàn)了風(fēng)險(xiǎn)。三個(gè)參與者都認(rèn)為風(fēng)險(xiǎn)很高（6），但一個(gè)參與者發(fā)現(xiàn)了可用性方面的風(fēng)險(xiǎn)，而兩個(gè)參與者發(fā)現(xiàn)了性能方面的風(fēng)險(xiǎn)。這兩個(gè)維度將分別討論。
提示
只要有可能，將風(fēng)險(xiǎn)風(fēng)暴的努力限制在一個(gè)維度上。這使參與者能夠?qū)⒆⒁饬械皆撎囟ňS度上，并避免對(duì)為架構(gòu)的同一區(qū)域確定的多個(gè)風(fēng)險(xiǎn)區(qū)域的混淆。
達(dá)成共識(shí)
風(fēng)險(xiǎn)風(fēng)暴工作中的達(dá)成共識(shí)活動(dòng)是高度協(xié)作的，目的是在所有參與者之間就架構(gòu)內(nèi)的風(fēng)險(xiǎn)達(dá)成共識(shí)。當(dāng)一個(gè)大的，印刷版的架構(gòu)圖就緒并張貼在墻上時(shí)，這個(gè)活動(dòng)是最有效的。作為印刷版本替代，電子版本可以顯示在大屏幕上。
到達(dá)風(fēng)險(xiǎn)風(fēng)暴會(huì)議后，參與者開(kāi)始在架構(gòu)圖上他們各自發(fā)現(xiàn)風(fēng)險(xiǎn)的區(qū)域放置他們的便利貼記錄。如果使用電子版本，組織風(fēng)險(xiǎn)風(fēng)暴會(huì)議的架構(gòu)師會(huì)詢問(wèn)每個(gè)參與者，并以電子方式將風(fēng)險(xiǎn)放在架構(gòu)圖中識(shí)別風(fēng)險(xiǎn)的區(qū)域上（見(jiàn)圖20-7）。
一旦所有的便利貼都準(zhǔn)備好了，風(fēng)險(xiǎn)風(fēng)暴的協(xié)作部分就可以開(kāi)始了。這項(xiàng)風(fēng)險(xiǎn)風(fēng)暴活動(dòng)的目標(biāo)是作為一個(gè)團(tuán)隊(duì)分析風(fēng)險(xiǎn)領(lǐng)域，并就風(fēng)險(xiǎn)鑒定達(dá)成共識(shí)。請(qǐng)注意，架構(gòu)中確定了幾個(gè)風(fēng)險(xiǎn)區(qū)域，如圖20-7所示：
1、兩名參與者分別將彈性負(fù)載均衡器確定為中等風(fēng)險(xiǎn)（3），而一名參與者將其確定為高風(fēng)險(xiǎn)（6）。
2、一位參與者將推送擴(kuò)展服務(wù)器單獨(dú)標(biāo)識(shí)為高風(fēng)險(xiǎn)（9）。
3、三位參與者分別將MySQL數(shù)據(jù)庫(kù)標(biāo)識(shí)為中等風(fēng)險(xiǎn)（3）。
4、一位參與者將Redis緩存單獨(dú)標(biāo)識(shí)為高風(fēng)險(xiǎn)（9）。
5、三名參與者認(rèn)為MongoDB日志記錄為低風(fēng)險(xiǎn)（2）。
6、架構(gòu)的所有其他區(qū)域均未被視為具有任何風(fēng)險(xiǎn)，因此架構(gòu)的任何其他區(qū)域均無(wú)便利貼記錄。
上面列表中的第3項(xiàng)和第5項(xiàng)不需要在本活動(dòng)中進(jìn)一步討論，因?yàn)樗袇⑴c者都同意風(fēng)險(xiǎn)的級(jí)別和資格。但是，請(qǐng)注意，列表中的第1項(xiàng)存在意見(jiàn)分歧，第2項(xiàng)和第4項(xiàng)只有一個(gè)參與者確定了風(fēng)險(xiǎn)。這些項(xiàng)目需要在活動(dòng)期間進(jìn)行討論。
列表中的第1項(xiàng)顯示，兩名參與者分別將彈性負(fù)載均衡器識(shí)別為中等風(fēng)險(xiǎn)（3），而一名參與者將其識(shí)別為高風(fēng)險(xiǎn)（6）。在這種情況下，其他兩個(gè)參與者問(wèn)第三個(gè)參與者為什么他認(rèn)為風(fēng)險(xiǎn)很高。假設(shè)第三個(gè)參與者說(shuō)，他們將風(fēng)險(xiǎn)識(shí)別為高風(fēng)險(xiǎn)，因?yàn)槿绻麖椥载?fù)載均衡器發(fā)生故障，則無(wú)法訪問(wèn)整個(gè)系統(tǒng)。雖然這是真的，事實(shí)上確實(shí)使整體影響評(píng)級(jí)變高，其他兩名參與者說(shuō)服第三名參與者，這種情況發(fā)生的風(fēng)險(xiǎn)很低。經(jīng)過(guò)多次討論，第三位參與者同意了，將風(fēng)險(xiǎn)水平降低到中等（3）。然而，第一個(gè)和第二個(gè)參與者可能沒(méi)有像第三個(gè)參與者那樣在彈性負(fù)載均衡器中看到風(fēng)險(xiǎn)的特定方面，因此需要在這個(gè)風(fēng)險(xiǎn)風(fēng)暴活動(dòng)中進(jìn)行協(xié)作。
舉個(gè)例子，考慮前面列表中的第2項(xiàng)，其中一個(gè)參與者將推送擴(kuò)展服務(wù)器單獨(dú)標(biāo)識(shí)為高風(fēng)險(xiǎn)（9），而沒(méi)有其他參與者將其標(biāo)識(shí)為任何風(fēng)險(xiǎn)。在這種情況下，所有其他參與者都會(huì)詢問(wèn)識(shí)別出風(fēng)險(xiǎn)的參與者為什么將其評(píng)為高風(fēng)險(xiǎn)。那個(gè)參與者接著說(shuō)，他們有過(guò)推送擴(kuò)展服務(wù)器在高負(fù)載下持續(xù)宕機(jī)的糟糕經(jīng)歷，這個(gè)是特定架構(gòu)所具有的問(wèn)題。這個(gè)例子展示了風(fēng)險(xiǎn)風(fēng)暴的價(jià)值，如果沒(méi)有這個(gè)參與者的介入，沒(méi)有人會(huì)看到高風(fēng)險(xiǎn)（當(dāng)然，在投入生產(chǎn)之前！）。
清單中的第4項(xiàng)是一個(gè)有趣的例子。一位參與者將Redis緩存識(shí)別為高風(fēng)險(xiǎn)（9），而沒(méi)有其他參與者將該緩存視為架構(gòu)中的任何風(fēng)險(xiǎn)。其他參與者詢問(wèn)該區(qū)域?yàn)楦唢L(fēng)險(xiǎn)的原因是什么，那個(gè)參與者回答說(shuō)，“什么是Redis緩存？”在這種情況下，參與者不知道Redis是什么，因此該區(qū)域的風(fēng)險(xiǎn)很高。
提示
對(duì)于未經(jīng)證實(shí)或未知的技術(shù)，始終指定最高風(fēng)險(xiǎn)評(píng)級(jí)（9），因?yàn)轱L(fēng)險(xiǎn)矩陣不能用于此維度。
清單中第4項(xiàng)的例子說(shuō)明了為什么讓開(kāi)發(fā)人員參加風(fēng)險(xiǎn)風(fēng)暴會(huì)議是明智的（而且是重要的）。開(kāi)發(fā)人員不僅可以更多地了解架構(gòu)，而且一個(gè)參與者（在本例中是團(tuán)隊(duì)中的開(kāi)發(fā)人員）不知道給定的技術(shù)這一事實(shí)為架構(gòu)師提供了關(guān)于總體風(fēng)險(xiǎn)的有價(jià)值的信息。
這一過(guò)程一直持續(xù)到所有參與者就確定的風(fēng)險(xiǎn)領(lǐng)域達(dá)成一致為止。一旦所有的便利貼記錄都被合并，這個(gè)活動(dòng)就結(jié)束了，下一個(gè)活動(dòng)就可以開(kāi)始了。該活動(dòng)的最終結(jié)果如圖20-8所示。
減輕風(fēng)險(xiǎn)
一旦所有參與者就架構(gòu)的風(fēng)險(xiǎn)區(qū)域的量化達(dá)成一致，最后也是最重要的活動(dòng)就是減輕風(fēng)險(xiǎn)。減輕架構(gòu)中的風(fēng)險(xiǎn)通常涉及對(duì)架構(gòu)的某些區(qū)域進(jìn)行更改或增強(qiáng)，否則這些區(qū)域可能被認(rèn)為是完美的。
這項(xiàng)活動(dòng)通常也是協(xié)作性的，尋求減少或消除第一項(xiàng)活動(dòng)中確定的風(fēng)險(xiǎn)的方法。在某些情況下，可能需要根據(jù)風(fēng)險(xiǎn)識(shí)別對(duì)原始架構(gòu)進(jìn)行完全更改，而其他情況可能是直接的架構(gòu)重構(gòu)，例如添加一個(gè)用于背壓的隊(duì)列以減少吞吐量瓶頸問(wèn)題。
不管架構(gòu)中需要做什么更改，這項(xiàng)活動(dòng)通常都會(huì)產(chǎn)生額外的成本。因此，關(guān)鍵利益相關(guān)者通常決定成本是否大于風(fēng)險(xiǎn)。例如，假設(shè)通過(guò)一個(gè)風(fēng)險(xiǎn)風(fēng)暴會(huì)議，中央數(shù)據(jù)庫(kù)在總體系統(tǒng)可用性方面被確定為中等風(fēng)險(xiǎn)（4）。在這種情況下，與會(huì)者一致認(rèn)為，將單個(gè)數(shù)據(jù)庫(kù)拆分為單獨(dú)的物理數(shù)據(jù)庫(kù)進(jìn)行集群，將減輕這種風(fēng)險(xiǎn)。然而，雖然風(fēng)險(xiǎn)將大大降低，但這一解決方案將花費(fèi)20000美元。然后，架構(gòu)師將與關(guān)鍵業(yè)務(wù)干系人舉行一次會(huì)議，討論這項(xiàng)利益權(quán)衡關(guān)系。在這次協(xié)商中，業(yè)務(wù)負(fù)責(zé)人認(rèn)為價(jià)格太高，投入成本沒(méi)有超過(guò)減輕風(fēng)險(xiǎn)所獲得的好處。架構(gòu)師并沒(méi)有放棄，而是提出了一種不同的方法——跳過(guò)集群并將數(shù)據(jù)庫(kù)分成兩部分怎么樣？在這種情況下，成本降低到8000美元，同時(shí)仍然減輕了大部分風(fēng)險(xiǎn)。在這種情況下，利益相關(guān)者同意了該解決方案。
前面的場(chǎng)景顯示了風(fēng)險(xiǎn)風(fēng)暴不僅會(huì)對(duì)整個(gè)架構(gòu)產(chǎn)生影響，還會(huì)對(duì)架構(gòu)師和業(yè)務(wù)涉眾之間的協(xié)商產(chǎn)生影響。風(fēng)險(xiǎn)風(fēng)暴與本章開(kāi)頭描述的風(fēng)險(xiǎn)評(píng)估相結(jié)合，為識(shí)別和跟蹤風(fēng)險(xiǎn)、改進(jìn)架構(gòu)和處理關(guān)鍵利益相關(guān)者之間的協(xié)商提供了一個(gè)極好的工具。
敏捷故事風(fēng)險(xiǎn)分析
風(fēng)險(xiǎn)風(fēng)暴可以用于軟件開(kāi)發(fā)的其他方面，而不僅僅是架構(gòu)上。例如，在故事梳理期間，我們利用風(fēng)險(xiǎn)風(fēng)暴來(lái)確定給定敏捷迭代中用戶故事完成的總體風(fēng)險(xiǎn)（以及該迭代的總體風(fēng)險(xiǎn)評(píng)估）。使用風(fēng)險(xiǎn)矩陣，用戶故事風(fēng)險(xiǎn)可以通過(guò)第一個(gè)維度（如果故事沒(méi)有在迭代中完成的總體影響）和第二個(gè)維度（故事沒(méi)有完成的可能性）來(lái)識(shí)別。通過(guò)對(duì)故事使用與架構(gòu)相同的風(fēng)險(xiǎn)矩陣，團(tuán)隊(duì)可以識(shí)別高風(fēng)險(xiǎn)的故事，仔細(xì)跟蹤這些故事，并對(duì)它們進(jìn)行優(yōu)先級(jí)排序。
風(fēng)險(xiǎn)風(fēng)暴示例
為了說(shuō)明風(fēng)險(xiǎn)風(fēng)暴的威力以及它如何改進(jìn)系統(tǒng)的整體架構(gòu)，請(qǐng)考慮一個(gè)呼叫中心系統(tǒng)的示例，以支持護(hù)士就各種健康狀況向患者提供建議。此類系統(tǒng)的需求如下：
- 該系統(tǒng)將使用第三方診斷引擎，提供問(wèn)題并指導(dǎo)護(hù)士或患者有關(guān)他們的醫(yī)療問(wèn)題。
- 患者可以使用呼叫中心呼叫護(hù)士，也可以選擇使用自助服務(wù)網(wǎng)站繞過(guò)護(hù)士而直接訪問(wèn)診斷引擎。
- 該系統(tǒng)必須支持全國(guó)250名護(hù)士和全國(guó)數(shù)十萬(wàn)名自助病人并發(fā)訪問(wèn)。
- 護(hù)士可以通過(guò)病歷交換訪問(wèn)患者的病歷，但患者不能訪問(wèn)自己的病歷。
- 對(duì)于醫(yī)療記錄，系統(tǒng)必須符合HIPAA規(guī)定。這意味著，除了護(hù)士以外，任何人都不能查閱病歷。
- 在感冒和流感季節(jié)爆發(fā)和大面積感染的情況需要在系統(tǒng)中解決。
- 呼叫護(hù)士的路由是基于護(hù)士的檔案資料（如雙語(yǔ)需求）。
- 第三方診斷引擎每秒可以處理大約500個(gè)請(qǐng)求。
系統(tǒng)架構(gòu)師創(chuàng)建了如圖20-9所示的高層次的架構(gòu)。在這個(gè)架構(gòu)中，有三個(gè)獨(dú)立的基于web的用戶界面：一個(gè)用于自助服務(wù)，一個(gè)用于護(hù)士接聽(tīng)電話，另一個(gè)用于管理人員添加和維護(hù)護(hù)士檔案信息和配置設(shè)置。系統(tǒng)的呼叫中心部分包括一個(gè)接收呼叫的呼叫接受器和一個(gè)呼叫路由器，呼叫路由器根據(jù)其配置文件將呼叫路由到下一個(gè)有空的護(hù)士（注意呼叫路由器如何訪問(wèn)中央數(shù)據(jù)庫(kù)以獲取護(hù)士檔案信息）。此架構(gòu)的中心是診斷系統(tǒng)API網(wǎng)關(guān)，它執(zhí)行安全檢查并將請(qǐng)求定向到適當(dāng)?shù)暮蠖朔?wù)。
該系統(tǒng)有四個(gè)主要服務(wù)：病例管理服務(wù)、護(hù)士檔案管理服務(wù)、病歷交換接口和外部第三方診斷引擎。除了外部系統(tǒng)和呼叫中心服務(wù)的專有協(xié)議外，所有通信都使用REST。
架構(gòu)師已經(jīng)多次審核了這個(gè)架構(gòu)，并相信它已經(jīng)準(zhǔn)備好實(shí)現(xiàn)了。作為自我評(píng)估，研究圖20-9中的需求和架構(gòu)圖，并嘗試確定該架構(gòu)中可用性、彈性和安全性方面的風(fēng)險(xiǎn)級(jí)別。在確定風(fēng)險(xiǎn)級(jí)別之后，需要再確定在架構(gòu)中進(jìn)行哪些更改來(lái)減輕風(fēng)險(xiǎn)。下面的部分包含可以用作對(duì)比的場(chǎng)景。
可用性
在第一次風(fēng)險(xiǎn)風(fēng)暴演習(xí)中，架構(gòu)師選擇首先關(guān)注可用性，因?yàn)橄到y(tǒng)可用性對(duì)于該系統(tǒng)的成功至關(guān)重要。在風(fēng)險(xiǎn)風(fēng)暴識(shí)別和協(xié)作活動(dòng)之后，參與者利用風(fēng)險(xiǎn)矩陣提出了以下風(fēng)險(xiǎn)區(qū)域（如圖20-10所示）：
- 使用中央數(shù)據(jù)庫(kù)被確定為高風(fēng)險(xiǎn)（6），因?yàn)槠溆绊懛秶鸀楦撸?）和發(fā)生可能性為中等（2）。
- 由于影響范圍為高（3）和發(fā)生的可能性為未知（3），診斷引擎可用性被確定為高風(fēng)險(xiǎn)（9）。
- 醫(yī)療記錄交換可用性被確定為低風(fēng)險(xiǎn)（2），因?yàn)樗皇窍到y(tǒng)運(yùn)行所必需的組件。
- 由于每個(gè)服務(wù)有多個(gè)實(shí)例和API網(wǎng)關(guān)集群化，系統(tǒng)的其他部分不被視為具有可用性風(fēng)險(xiǎn)。
在風(fēng)險(xiǎn)風(fēng)暴環(huán)節(jié)中，所有參與者都同意，如果數(shù)據(jù)庫(kù)宕機(jī)了，護(hù)士可以手動(dòng)寫下病例筆記，但是如果數(shù)據(jù)庫(kù)不可用，呼叫路由器就不能工作。為了降低數(shù)據(jù)庫(kù)風(fēng)險(xiǎn)，參與者選擇將單個(gè)物理數(shù)據(jù)庫(kù)拆分為兩個(gè)獨(dú)立的數(shù)據(jù)庫(kù)：一個(gè)包含護(hù)士檔案信息的集群數(shù)據(jù)庫(kù)和一個(gè)用于病例記錄的單實(shí)例數(shù)據(jù)庫(kù)。這種架構(gòu)的更改不僅解決了對(duì)數(shù)據(jù)庫(kù)可用性的擔(dān)憂，而且有助于從管理員訪問(wèn)中保護(hù)病例記錄。另一種減輕這種風(fēng)險(xiǎn)的方法是在呼叫路由器中緩存護(hù)士檔案信息。然而，由于呼叫路由器的實(shí)現(xiàn)是未知的，而且可能是第三方產(chǎn)品，參與者采用了數(shù)據(jù)庫(kù)方案。
由于缺乏對(duì)這些系統(tǒng)的控制，減輕外部系統(tǒng)（診斷引擎和病歷交換）可用性的風(fēng)險(xiǎn)更難于管理。減輕這種可用性風(fēng)險(xiǎn)的一種方法是研究是否為這些系統(tǒng)中的每一個(gè)都發(fā)布服務(wù)級(jí)別協(xié)議（SLA）或服務(wù)級(jí)別目標(biāo)（SLO）。SLA通常是合同協(xié)議和具有法律約束力，而SLO通常不具有法律約束力。根據(jù)研究，架構(gòu)師發(fā)現(xiàn)診斷引擎的SLA保證99.99%的可用性（即每年52.60分鐘的停機(jī)時(shí)間），醫(yī)療記錄交換保證99.9%的可用性（即每年8.77小時(shí)的停機(jī)時(shí)間）?；谙鄬?duì)風(fēng)險(xiǎn)，這些信息足以消除已識(shí)別的風(fēng)險(xiǎn)。
圖20-11說(shuō)明了風(fēng)險(xiǎn)風(fēng)暴會(huì)議后架構(gòu)的相應(yīng)變化。注意，現(xiàn)在使用了兩個(gè)數(shù)據(jù)庫(kù)，SLA也發(fā)布在架構(gòu)圖上。
可伸縮性
在第二個(gè)風(fēng)險(xiǎn)風(fēng)暴練習(xí)中，架構(gòu)師選擇關(guān)注用戶負(fù)載的彈性峰值（也稱為可變可伸縮性）。雖然只有250名護(hù)士（為大多數(shù)服務(wù)提供自動(dòng)調(diào)節(jié)器），但系統(tǒng)的自助服務(wù)部分可以訪問(wèn)診斷引擎和護(hù)士，這大大增加了對(duì)診斷接口的請(qǐng)求數(shù)量。參與者擔(dān)心流感爆發(fā)和流感季節(jié)，屆時(shí)系統(tǒng)的預(yù)期負(fù)荷將顯著增加。
在風(fēng)險(xiǎn)風(fēng)暴會(huì)議期間，所有參與者都將診斷引擎界面確定為高風(fēng)險(xiǎn)（9）。在每秒只有500個(gè)請(qǐng)求的情況下，參與者計(jì)算出診斷引擎接口無(wú)法跟上預(yù)期的吞吐量，特別是在當(dāng)前使用REST作為接口協(xié)議的架構(gòu)下。減輕此風(fēng)險(xiǎn)的一種方法是利用API網(wǎng)關(guān)和診斷引擎接口之間的異步隊(duì)列（消息傳遞），以便支持對(duì)診斷引擎的調(diào)用時(shí)提供背壓點(diǎn)。雖然這是一個(gè)很好的做法，但仍然不能降低風(fēng)險(xiǎn)，因?yàn)樽o(hù)士（以及自助服務(wù)患者）等待診斷引擎響應(yīng)的時(shí)間太長(zhǎng)，而且這些請(qǐng)求可能會(huì)超時(shí)。利用所謂的救護(hù)車模式將使護(hù)士獲得比自助服務(wù)更高的優(yōu)先級(jí)。因此需要兩個(gè)消息通道。雖然這種技術(shù)有助于降低風(fēng)險(xiǎn)，但它仍然不能解決等待時(shí)間問(wèn)題。參與者決定，除了提供背壓的消息隊(duì)列技術(shù)之外，緩存與爆發(fā)相關(guān)的特定診斷問(wèn)題將使爆發(fā)和流感調(diào)用不再需要到達(dá)診斷引擎接口。
相應(yīng)的架構(gòu)變更如圖20-12所示。請(qǐng)注意，除了兩個(gè)隊(duì)列通道（一個(gè)用于護(hù)士，一個(gè)用于自助服務(wù)患者）之外，還有一個(gè)新的服務(wù)，名為Diagnostics Explosion Cache Server，用于處理與特定爆發(fā)或流感相關(guān)問(wèn)題的所有請(qǐng)求。有了這個(gè)架構(gòu)，限制因素就消除了（對(duì)診斷引擎的調(diào)用），從而允許成千上萬(wàn)的并發(fā)請(qǐng)求。如果沒(méi)有風(fēng)險(xiǎn)風(fēng)暴的努力，這種風(fēng)險(xiǎn)可能無(wú)法確定，直到爆發(fā)或流感季節(jié)發(fā)生。
安全性
受前兩個(gè)風(fēng)險(xiǎn)風(fēng)暴工作的結(jié)果和成功的鼓舞，架構(gòu)師決定就系統(tǒng)中必須支持的另一個(gè)重要架構(gòu)特性舉行最后的風(fēng)險(xiǎn)風(fēng)暴會(huì)議，以確保其成功，就是安全性。由于HIPAA法規(guī)要求，通過(guò)病歷交換接口訪問(wèn)病歷必須是安全的，僅允許護(hù)士在需要時(shí)訪問(wèn)病歷。由于API網(wǎng)關(guān)中的安全檢查（身份驗(yàn)證和授權(quán)），架構(gòu)師認(rèn)為這并不是問(wèn)題，但很好奇參與者是否發(fā)現(xiàn)了任何其他安全風(fēng)險(xiǎn)元素。
在風(fēng)險(xiǎn)風(fēng)暴期間，參與者都將診斷系統(tǒng)API網(wǎng)關(guān)確定為高安全風(fēng)險(xiǎn)（6）。這一高評(píng)級(jí)的理由是管理人員或自助服務(wù)患者訪問(wèn)醫(yī)療記錄的高影響（3）與中等發(fā)生可能性（2）相結(jié)合。由于對(duì)每個(gè)API調(diào)用進(jìn)行了安全檢查，因此發(fā)生風(fēng)險(xiǎn)的可能性沒(méi)有被評(píng)為高，但仍然被評(píng)為中等，因?yàn)樗姓{(diào)用（自助服務(wù)、管理員和護(hù)士）都要通過(guò)相同的API網(wǎng)關(guān)。僅將風(fēng)險(xiǎn)評(píng)級(jí)為低（2）的架構(gòu)師在風(fēng)險(xiǎn)風(fēng)暴共識(shí)活動(dòng)期間，他被說(shuō)服實(shí)際風(fēng)險(xiǎn)很高，需要進(jìn)行緩解。
參與者一致認(rèn)為，為每種類型的用戶（管理員、自助服務(wù)/診斷和護(hù)士）設(shè)置單獨(dú)的API網(wǎng)關(guān)將阻止來(lái)自管理員web用戶界面或自助服務(wù)web用戶界面的調(diào)用到達(dá)病歷交換界面。架構(gòu)師同意并創(chuàng)建了最終的架構(gòu)，如圖20-13所示。
前面的場(chǎng)景說(shuō)明了風(fēng)險(xiǎn)風(fēng)暴的威力。通過(guò)與其他架構(gòu)師、開(kāi)發(fā)人員和關(guān)鍵利益相關(guān)者就對(duì)系統(tǒng)的成功至關(guān)重要的風(fēng)險(xiǎn)維度進(jìn)行協(xié)作，可以識(shí)別出原本不被關(guān)注的風(fēng)險(xiǎn)區(qū)域。對(duì)比圖20-9和圖20-13，可以注意到風(fēng)險(xiǎn)風(fēng)暴之前和之后架構(gòu)的顯著差異。這些重大的變化解決了架構(gòu)中的可用性、可伸縮性和安全性問(wèn)題。
風(fēng)險(xiǎn)風(fēng)暴不是一次性的過(guò)程。相反，在任何系統(tǒng)的生命周期中都是一個(gè)連續(xù)的過(guò)程，以便在風(fēng)險(xiǎn)區(qū)域在生產(chǎn)環(huán)境發(fā)生之前捕獲并減輕它們。風(fēng)險(xiǎn)風(fēng)暴的舉辦頻率取決于許多因素，包括變更頻率、架構(gòu)重構(gòu)工作和架構(gòu)的增量開(kāi)發(fā)。通常在添加一個(gè)主要特性之后或在每次迭代結(jié)束時(shí)，會(huì)在某個(gè)特定維度上進(jìn)行一次風(fēng)險(xiǎn)風(fēng)暴。
