架構風險分析概述#

每個架構都帶有風險，無論是 availability、scalability 或 data integrity 相關的風險。持續分析架構風險是架構師的核心職責之一。透過主動分析風險，架構師可以發現架構中的缺陷並採取修正措施來降低風險。本章介紹量化風險的 risk matrix、建立 risk assessment 報告，以及透過協作活動 risk storming 來識別風險。

Risk Matrix#

評估架構風險時，第一個問題是如何將風險分類為低、中、高。過多的主觀性會導致混淆 — 到底什麼是高風險？什麼是中風險？

Risk matrix 使用兩個維度來量化風險：

• Overall impact of risk（風險的整體影響）— 低 (1)、中 (2)、高 (3)
• Likelihood of risk occurring（風險發生的可能性）— 低 (1)、中 (2)、高 (3)

將兩個維度的值相乘，得出客觀的風險數值：

風險等級判定：

• 1-2：低風險（綠色）
• 3-4：中風險（黃色）
• 6-9：高風險（紅色）

範例#

假設有一個集中式資料庫的 availability 問題：

• Impact：如果資料庫掛了，影響是高的 → 3
• Likelihood：資料庫部署在高可用的叢集配置上，掛掉的可能性低 → 1
• Risk = 3 x 1 = 3（中風險）

使用 risk matrix 時，建議先考慮 impact 維度，再考慮 likelihood 維度。影響程度通常比較容易判斷。

Risk Assessments#

Risk matrix 可用來建立 risk assessment（風險評估報告），這是一份架構整體風險的總結報告。Risk assessment 根據 assessment criteria（評估準則，如 scalability、availability、performance、security、data integrity 等）來評估各個服務或領域。

標準風險評估報告#

風險評估以表格呈現，行是評估準則，列是服務/領域。每個格子中的數字來自 risk matrix：

• 每個 risk criteria 的橫向加總顯示哪個準則的風險最高
• 每個 domain area 的縱向加總顯示哪個領域的風險最高

例如，一份評估可能顯示 data integrity 的累計風險最高 (17)，而 availability 最低 (10)。縱向來看，customer registration 的風險最高 (24)，而 order fulfillment 最低 (8)。

過濾呈現#

風險評估通常不會一次展示所有結果。根據場景進行過濾 (filtering) 是很重要的：

• 在向管理層報告時，可以只顯示高風險區域
• 過濾可以提升訊號與雜訊的比例，清楚呈現系統的狀態

風險方向#

標準的風險評估只是時間快照 — 無法看出風險是在改善還是惡化。有幾種方式可以顯示風險的方向趨勢：

• 正負號 — 在風險數值旁加上 +（改善）或 -（惡化），無符號表示穩定
• 箭頭加數字 — 用箭頭顯示趨勢方向，同時顯示趨向的目標數值（如紅色箭頭表示惡化，綠色箭頭表示改善）

風險方向可以透過 fitness functions 的持續量測來客觀判定。透過分析每個 risk criteria 的趨勢，可以觀察到風險是否在改善或惡化。

Risk Storming#

沒有任何一個架構師能獨自判定系統的整體風險。原因有二：

• 單一架構師可能遺漏或忽視某些風險區域
• 很少有架構師對系統的每個部分都有完整了解

Risk storming 是一種協作練習，用來在特定維度 (dimension) 內判定架構風險。常見的風險維度包括：

• 未經驗證的技術 (unproven technology)
• Performance
• Scalability
• Availability（包含 transitive dependencies）
• Data loss
• Single points of failure
• Security

Risk storming 應邀請多位架構師參與，也建議包含資深開發者和 tech lead，因為他們不僅能提供實作層面的風險觀點，參與過程本身也能幫助他們更深入了解架構。

Risk Storming 的三個活動#

Risk storming 分為三個主要活動：

1. Identification（識別）#

個人、非協作的活動。每位參與者獨立進行：

• 架構師提前 1-2 天寄出邀請，包含架構圖、風險維度、會議時間與地點
• 每位參與者使用 risk matrix 獨立分析架構，將風險分類為低 (1-2)、中 (3-4) 或高 (6-9)
• 準備對應顏色的便利貼（綠色=低、黃色=中、紅色=高），寫上風險數值

盡可能將 risk storming 限制在單一維度（如只分析 performance）。這能讓參與者集中注意力，避免在同一架構區域識別出多個不同維度的風險時產生混淆。

2. Consensus（共識）#

協作活動。所有參與者一起進行：

• 將大型架構圖列印或投影出來
• 每位參與者將便利貼放在架構圖上他們識別出風險的區域
• 針對意見分歧的區域進行討論，達成共識

共識過程的關鍵在於討論差異：

• 如果所有人都對某個區域標記相同的風險等級，則不需要討論
• 如果有人標記高風險而其他人標記中風險，需要討論原因
• 如果只有一個人識別出某個區域的風險，而其他人完全沒有標記，更需要深入了解

這正是 risk storming 的價值所在。例如，某位開發者可能因為不熟悉某項技術（如 Redis cache）而標記高風險 (9)，其他參與者因此才得知團隊中有人不了解該技術 — 這本身就是一個重要的風險資訊。

3. Mitigation（緩解）#

協作活動。在所有人對風險達成共識後進行：

• 討論如何降低或消除已識別的風險
• 風險緩解通常涉及架構的變更或強化
• 變更通常會帶來額外成本，因此需要與業務利害關係人協商

緩解的結果可能包括：

• 完全重新設計架構的某個部分
• 簡單的架構重構（如增加 message queue 來提供 back-pressure）
• 接受風險（如果成本超過收益）
• 與利害關係人協商替代方案以降低成本

Agile Story Risk Analysis#

Risk storming 不僅適用於架構層面，也可應用於 Agile 開發中的 user story 風險分析。在 sprint planning / story grooming 時，可以使用相同的 risk matrix 來評估 user story 的風險：

• Impact 維度 — 如果 story 沒有在迭代內完成的整體影響
• Likelihood 維度 — story 無法完成的可能性

透過這種方式，團隊可以識別高風險的 stories，對其進行追蹤和優先排序。

Risk Storming 範例#

本章以一個護理診斷系統 (nurse diagnostics call center system) 為例，展示 risk storming 如何在三個維度上逐步改善架構：

Availability Risk Storming#

• 識別出集中式資料庫為高風險 (6)：高影響 + 中可能性
• 識別出第三方診斷引擎為高風險 (9)：高影響 + 未知可能性
• 緩解方式：將單一資料庫拆分為兩個獨立資料庫（護理師 profile 用叢集資料庫、case notes 用單一實例資料庫），並調查外部系統的 SLA

Elasticity Risk Storming#

• 識別出診斷引擎介面為高風險 (9)：外部引擎每秒只能處理 500 請求，在流感季或疫情爆發時會成為瓶頸
• 緩解方式：在 API gateway 和診斷引擎之間加入非同步 message queue（護理師和自助服務各一個 channel），並新增 Diagnostics Outbreak Cache Server 來快取常見疫情相關的診斷問題

Security Risk Storming#

• 識別出單一 API gateway 為高安全性風險 (6)：所有使用者（管理員、護理師、自助服務患者）都經過同一個 gateway，存在安全隱患
• 緩解方式：將單一 API gateway 拆分為三個獨立的 gateway（Admin、Nurse、Diagnostics），確保管理介面和自助服務介面無法觸及醫療記錄交換介面

比較 risk storming 前後的架構圖，可以看到顯著的差異。這些變更分別解決了 availability、elasticity 和 security 的問題。沒有 risk storming，這些風險可能直到上線後才會被發現。

Risk storming 不是一次性的活動。它是一個持續的過程，應在每個主要功能上線後或每個迭代結束時定期進行，以持續追蹤和緩解架構中的風險。