Skip to main content

Ch20: 分析架構風險

分析架構風險​

風險矩陣與評估​

  • 將系統中的顧慮，依照風險發生的可能性及發生時的影響程度依序評估
    • 先考慮「影響」再考慮「可能性」
  • 風險評估的作法差異很大
    • 有時很主觀
影響\可能性低中高
低1🟢2🟡3🟠
中2🟡4🟠6🔴
高3🟠6🔴9🟣

風險矩陣範例​

  • 評估報告是時間上的一個「快照」
  • 隨著系統演進，對整體的風險有視覺化的評估
影響\可能性 客戶註冊 前臺結帳 訂單屢行 訂單出貨 風險總值
可擴展性🟡🔴🟢🟡11
可用性🟠🟠🟡🟢10
效能🟠🟡🟠🔴15
安全性🔴🟠🟢🟢11
資料完整性🔴🔴🟢🟢 17
風險總值2421811

風險激盪 (Risk Storming)​

  • 沒有架構師能單獨決定整體風險

    • 透過一群人合作激盪出架構的風險

  • Storming：一群人一起合作激盪火花

    • Event Storming: 事件風暴，DDD的分析工具
    • Model Storming: Agile Modeling的Just-in-time塑模方法

  • 是符合Agile Modeling的5項價值觀的作法

    • Communication 有效溝通
    • Simplicity 最小有價值解法(MVP)
    • Feedback 儘早取得回饋
    • Courage 嘗試的勇氣
    • Humility 謙卑地接受意見

1. 確認 Identification​

  • 會議前發出架構圖給所有與會者
  • 參與者先各自(不一起合作)指定架構的風險值為1~10的何者
    • 避免彼此互相影響
  • 將注意力從特定區域離開；但要盡可能在同一個維度上
    • 維度：效能、可擴展性...etc.
    • 區域：資料庫、附載平衡器、快取...etc.
    • ✅ 在可擴展性上進行風險風暴，尋找架構組件的可擴展性具有風險的區域
    • ⛔ 在網站伺服器上進行事件風暴，尋找網站伺服器具有風險的維度

Architecture

2. 共識 Consensus​

  • 將大家的結果合起來，努力在風險區域上取得共識
    • 例如：給出最高風險跟最低風險的人，解釋自己的想法..etc.

Architecture

3. 減緩 Mitigation​

  • 針對架構中，原本認為沒有問題的區域，進行修改或加強

Architecture

風險激盪範例​

可用性 Availability​

Origin

彈性 Elasticity​

Origin

安全性 Security​

Origin