讀完這章你要能回答：我的團隊現在最大的三個風險是什麼？危機發生時我會先止血還是先追因？

世界是脆弱的，持續管理風險是領導者的核心職責。

風險管理的重要性#

風險管理不是「以防萬一」的額外工作，而是日常管理的核心部分。優秀的領導者會持續思考「什麼可能會出錯」。

喬新亮在《CTO 成長復盤》中強調：

世界是脆弱的，持續管理風險非常重要。很多災難性的問題都是可以提前預見和預防的。

風險管理 vs 問題處理#

風險識別#

常見的技術風險#

mindmap
  root((技術風險))
    🖥️ 系統風險
      單點故障
      容量不足
      依賴服務不穩定
      安全漏洞
      數據丟失
    📋 專案風險
      需求不清或頻繁變更
      技術難度估計不足
      資源不足或流失
      依賴項延期
      溝通不暢
    👥 組織風險
      關鍵人員離職
      技術斷層
      知識集中
      文化問題
      協作障礙

風險識別的方法#

主動識別：

• 定期的風險評審會議
• 專案啟動時的風險分析
• 系統架構的安全審計
• 失敗模式分析（FMEA）

被動識別：

• 從過去的問題中學習
• 行業案例研究
• 監控和告警
• 使用者回饋

每個專案啟動時，花時間問「什麼可能會出錯？」並記錄下來。這個簡單的習慣能避免很多問題。

逆向思考與 Pre-mortem#

只「向前」想往往想不全——人天生樂觀，會自動跳過壞情況。換個方向，威力大很多：

• 逆向（Inversion）：不要問「怎麼成功」，改問「怎麼做才會保證失敗」，把這些做法一條條列出來，然後刻意避開。要毀掉這個專案最快的方法是什麼？那就是你的高風險清單。
• Pre-mortem（事前驗屍）：在專案還沒開始時，假設「半年後它已經慘敗了」，請團隊各自寫下「為什麼會失敗」。比起問「有什麼風險」，這個假設失敗已成定局的框架，能讓人說出平常不敢講的隱憂。

Pre-mortem 的關鍵是「假設失敗已經發生」這個語氣。問「會不會有風險」容易得到客套的「應該還好」；問「它已經死了，請說死因」才會逼出真話。

第二序思考：追問「然後呢？」#

很多決策第一層看起來很棒，代價藏在第二、第三層。**第二序思考（Second-Order Thinking）**就是對每個決定追問 2–3 層「然後呢？」：

兩個必須認得的二階陷阱：

• Goodhart 定律：「當一個指標變成目標，它就不再是好指標。」因為人會去優化指標本身，而不是它原本想代表的東西。
• 眼鏡蛇效應（Cobra Effect）：誘因反噬。殖民印度時為滅蛇而懸賞蛇屍，結果有人開始養蛇換賞金；賞金一停，蛇被放生，蛇更多了。設計任何獎懲前，先想「人會怎麼鑽這個誘因」。

風險評估#

風險評估矩陣#

根據可能性和影響來評估風險的優先級：

影響
  ↑
高│  中  │  高   │ 緊急  │
  ├──────┼───────┼───────┤
中│  低  │  中   │  高   │
  ├──────┼───────┼───────┤
低│ 接受 │  低   │  中   │
  └──────┴───────┴───────┘
     低      中      高    → 可能性

評估維度#

風險登記表#

風險ID：RISK-001
描述：支付系統第三方依賴可能不穩定
類別：系統風險
可能性：中
影響：高
優先級：高
負責人：張三
應對策略：準備備用支付通道
狀態：監控中
更新日期：2024-01-15

風險應對#

四種應對策略#

flowchart TD
    RISK[⚠️ 識別到風險] --> EVAL{評估風險}

    EVAL -->|風險極高，無法承受| AVOID[🚫 規避 Avoid]
    EVAL -->|可透過投入降低| MITIGATE[🛡️ 減輕 Mitigate]
    EVAL -->|有專業第三方| TRANSFER[🔄 轉移 Transfer]
    EVAL -->|風險很小，可承受| ACCEPT[✅ 接受 Accept]

    AVOID -.- A1["改變計劃，消除風險<br/>例：不使用不穩定的技術"]
    MITIGATE -.- M1["降低風險的可能性或影響<br/>例：增加冗餘，設置監控"]
    TRANSFER -.- T1["將風險轉移給第三方<br/>例：購買保險，使用雲服務"]
    ACCEPT -.- AC1["接受風險，準備應對<br/>例：制定應急預案"]

    style AVOID fill:#ffebee
    style MITIGATE fill:#e3f2fd
    style TRANSFER fill:#fff3e0
    style ACCEPT fill:#e8f5e9

選擇策略的考量#

危機應對#

危機的特點#

• 突發性：往往沒有預警
• 緊迫性：需要快速回應
• 高壓力：對決策能力的極大考驗
• 不確定性：資訊不完整，難以判斷

危機回應流程#

張雪峰分享了餓了麼的危機處理經驗：

flowchart TD
    subgraph D [🔔 發現階段 - 分鐘級]
        D1[監控告警觸發] --> D2[確認問題存在]
        D2 --> D3[評估影響範圍]
        D3 --> D4[啟動回應流程]
    end

    subgraph R [⚡ 回應階段 - 小時級]
        R1[組建回應團隊] --> R2[建立溝通管道]
        R2 --> R3[並行止血和調查]
        R3 --> R4[定期同步進展]
        R4 --> R5[對外溝通]
    end

    subgraph H [✅ 恢復階段 - 天級]
        H1[驗證問題解決] --> H2[恢復正常服務]
        H2 --> H3[處理遺留問題]
        H3 --> H4[總結經驗教訓]
    end

    D --> R --> H

    style D fill:#ffcdd2
    style R fill:#ffe0b2
    style H fill:#c8e6c9

危機時刻的決策#

危機時刻，止血優先於追因。先讓服務恢復，再調查原因。

張雪峰的經驗：

CTO 的艱難時刻：差點引咎辭職。在巨大壓力下保持冷靜，做出正確決策，是最大的考驗。

危機決策的要點：

1. 保持冷靜：恐慌會導致更大的錯誤
2. 快速決策：資訊不完整時也要做決定
3. 承擔責任：不要浪費時間追責
4. 持續溝通：讓相關人員知道情況
5. 留有記錄：為事後檢討準備

對外溝通#

危機發生時，對外溝通也很重要：

溝通原則：
├── 及時：第一時間告知，不要等問題解決
├── 誠實：說實話，不要試圖掩蓋
├── 具體：說明影響範圍和預計恢復時間
├── 更新：持續同步進展
└── 負責：承認問題，說明改進措施

試圖隱瞞問題通常會讓情況更糟。使用者可以接受問題，但很難接受欺騙。

成功的慣性：別用舊解打新仗#

危機時最隱蔽的陷阱，是成功的慣性（Success Inertia）：過去屢試屢驗的解法，會變成高管的反射動作——遇到新危機，下意識套用以前奏效的那一招。但新危機的結構若已不同（見戰略轉折點），舊解可能毫無用處，甚至加速惡化。

越資深、過去越成功的人，越容易被自己的成功經驗綁架。有時候，處理新型危機需要找一個對舊做法沒有情感包袱的人來主導——不是因為他更聰明，而是因為他不會反射性地伸手去拿那把舊鑰匙。

級聯失效與系統性風險#

技術系統的大災難，往往不是單點壞掉，而是一個小故障**級聯（cascade）**放大：一個服務超時 → 重試風暴 → 拖垮下游 → 拖垮更多上游。要在設計時就為這種連鎖反應裝上閘門：

flowchart LR
    F["① 單點故障<br/>某服務變慢"]
    --> C["② 級聯擴散<br/>重試風暴、<br/>連線耗盡、<br/>拖垮下游"]
    --> S["③ 系統性崩潰<br/>整條鏈路雪崩"]

    F -. 斷路器 Circuit Breaker .-> X1["快速失敗，<br/>停止打爆下游"]
    C -. 防火牆 Bulkhead .-> X2["艙壁隔離，<br/>故障不外溢"]
    S -. 去中心化 .-> X3["無單一致命點，<br/>局部壞不拖垮全局"]

    style F fill:#fff3e0
    style C fill:#ffe0b2
    style S fill:#ffcdd2
    style X1 fill:#c8e6c9
    style X2 fill:#c8e6c9
    style X3 fill:#c8e6c9

• 斷路器（Circuit Breaker）：偵測到下游異常就「跳閘」，快速失敗而非一直重試，避免把下游打得更慘。
• 防火牆／艙壁（Bulkhead）：把資源池隔離，某一塊燒起來不會燒光全船的資源。
• 去中心化：消除單一致命點，讓局部故障無法升級成全局災難。

專案風險管理#

專案風險的特點#

專案風險與系統風險不同，更多涉及：

• 需求和範圍
• 時間和資源
• 人員和溝通
• 技術和依賴

寶玉的專案風險管理建議#

專案啟動時：
├── 識別主要風險
├── 制定應對計劃
├── 分配責任人
└── 建立監控機制

專案執行中：
├── 定期風險評審
├── 跟蹤風險狀態
├── 更新應對措施
└── 新風險識別

專案收尾時：
├── 總結風險管理經驗
├── 記錄到知識庫
└── 為未來專案參考

常見的專案風險應對#

建立風險管理文化#

從個人到組織#

風險管理不只是領導者的事，應該成為組織的習慣：

• 鼓勵報告問題：不懲罰報告問題的人
• 重視事後檢討：從問題中學習
• 獎勵預防行為：識別風險也是貢獻
• 透明的溝通：問題和風險要及時共享

如果團隊成員因為報告問題而受到批評，以後就沒人敢報告了。要獎勵發現問題的行為，而不是懲罰。

本章要點#

1. 風險管理是日常工作：不是額外的事，是核心職責
2. 主動識別風險：問「什麼可能出錯」
3. 評估並優先排序：可能性 × 影響
4. 四種應對策略：規避、減輕、轉移、接受
5. 危機時止血優先：先恢復，再追因
6. 建立風險文化：鼓勵報告，從問題中學習