結合IT管理場景，對這五個階段進行深度解讀與應用思考：

階段一：收集並審視證據 (Collect and Review Evidence)

核心定義： 找出核心事實與數據，質疑一切。建立堅實的事實基礎。

• 圖片關鍵點： “這條信息從哪裏來的？”、“樣本量真實嗎？”、“數據相關性？”

• IT管理者應用與思考：

  • 拒絕“我覺得”： 在處理系統故障或性能問題時，下屬常説“我覺得是數據庫慢了”。管理者需反問：“Log在哪裏？APM監控數據怎麼説？復現路徑是什麼？”

  • 需求偽真偽： 當業務方提出“緊急且必須”的功能時，應用此思維：“這個需求的數據支撐是什麼？多少用户反饋了此問題？是核心痛點還是偽需求？”

  • 技術選型陷阱： 看到新技術宣稱“性能提升10倍”時，質疑：“測試環境是什麼？是否針對特定場景？是否有各方利益相關（如廠商軟文）？”

階段二：識別並質疑假設 (Identify and Question Assumptions)

核心定義： 揭示支撐論點的潛在信念。任何論點都建立在未言明的假設之上。

• 圖片關鍵點： “我們默認哪些是事實？”、“如果我想錯了會怎樣？”、“我自己有哪些隱蔽偏見？”

• IT管理者應用與思考：

  • 挑戰隱性假設： 在架構設計時，團隊往往假設“流量會線性增長”或“第三方服務永遠穩定”。管理者需問：“如果網絡斷了怎麼辦？如果流量突增10倍怎麼辦？”

  • 打破“經驗主義”： “我們以前都是這麼做的”是最危險的假設。技術環境在變，過去的最佳實踐可能是現在的技術債。

  • 識別偏見： 團隊是否因為熟悉Java就強行在不適合的場景（如AI訓練）使用Java？這是“工具錘子”偏見。

階段三：探索多元視角 (Explore Multiple Perspectives)

核心定義： 跳出自己的認知圖層。引入外部視角，獲得全面理解。

• 圖片關鍵點： “誰不同意這個觀點？”、“不同背景的人會怎麼看？”、“我們遺漏了誰的聲音？”

• IT管理者應用與思考：

  • 跨部門視角（Stakeholder Management）： 技術不僅僅是代碼。

    • 運維視角： “代碼寫得好，但好部署、好監控嗎？”

    • 安全視角： “功能很炫，但數據傳輸加密了嗎？”

    • 業務視角： “架構很完美，但能趕上雙十一嗎？”

  • 新老員工視角： 聽取新員工的意見，他們往往能發現老員工習以為常的“不合理流程”。

  • 客户視角： 作為技術人員，很容易陷入“技術自嗨”。必須強制團隊站在最終用户的角度看問題。

階段四：提出其他可能 (Propose Alternatives)

核心定義： 跳脱思維定勢。在充分理解問題後，進行創造性思考。

• 圖片關鍵點： “有沒有別的切入角度？”、“當前方案的反面是什麼？”、“能否整合不同思路？”

• IT管理者應用與思考：

  • 方案B與方案C： 在技術評審（Design Review）中，永遠不要接受唯一的解決方案。管理者應要求：“如果不使用微服務，單體能不能解決？如果不用自研，買SaaS行不行？”

  • 逆向思維： 面對“系統太慢”的問題，常規思路是優化代碼。逆向思路可能是：“是否可以通過業務流程調整，讓用户感覺不到慢（如異步處理）？”

  • 整合創新： 能否將開源方案與內部定製相結合，而不是非此即彼？

階段五：描繪並評估影響 (Map and Evaluate Implications)

核心定義： 往前看，預測連鎖反應。系統性地預測和評估後果。

• 圖片關鍵點： “第一、二、三層影響是什麼？”、“誰受益，誰受損？”、“可能會引發哪些新問題？”

• IT管理者應用與思考：

  • 二階效應（Second-Order Effects）：

    • 決策： 為了趕進度，允許代碼不寫單元測試。

    • 一階影響： 上線快了。

    • 二階影響： Bug增多。

    • 三階影響： 團隊陷入無盡的修Bug循環，新功能開發停滯，士氣低落。

  • 技術債評估： 現在的臨時方案（Workaround）在未來6個月會變成什麼樣的阻礙？

  • 團隊影響： 引入這個複雜的框架，團隊的學習成本是多少？如果核心維護者離職，誰能接手？

IT故障覆盤模版

蘇格拉底式深度覆盤模版 (Socratic Deep-Dive Post-mortem)

覆盤原則： 對事不對人（Blameless），不僅關注“發生了什麼”，更關注“我們是如何思考的”。

0. 基礎信息概覽

• 故障 ID / 名稱：

• 發生時間（起止）：

• 影響時長：

• 嚴重等級 (P0-P3)：

• 覆盤主持人：

第一階段：還原事實 (Stage 1: Evidence)

蘇格拉底式追問： 我們依據的數據來源可靠嗎？日誌和監控是否完全吻合？

1.1 時間軸與關鍵操作

請精確到分鐘，列出系統表現、報警時間、人工介入點。

• [hh:mm] 現象...

• [hh:mm] 報警...

• [hh:mm] 操作...

1.2 證據審查

• 核心報錯信息 (Log/Trace)：

• 關鍵指標變化 (Metrics)：

• 證據質疑： 有沒有哪條日誌具有誤導性？有沒有哪個報警被我們忽略了？我們是否基於推測而非數據做出了初步判斷？

第二階段：挖掘假設 (Stage 2: Assumptions)

蘇格拉底式追問： 我們之前默認了什麼“事實”，結果被證明是錯的？

2.1 根因分析 (5 Whys + 假設層)

不要只寫代碼bug，要挖掘背後的思維定勢。

• 直接原因： （例如：空指針異常）

• Why 1： 為什麼會出現空指針？

• Why 2： 為什麼測試沒覆蓋到？

• Why 3： （核心）我們潛意識裏做了什麼假設？

  • 示例：我們假設了第三方API永遠會返回標準JSON格式，沒有做容錯。

  • 示例：我們假設流量增長是線性的，沒預料到促銷帶來的突發脈衝。

2.2 流程失效點

• 我們在哪個環節（設計/開發/測試/發佈）過於自信了？

第三階段：全視角審視 (Stage 3: Perspectives)

蘇格拉底式追問： 跳出技術視角，其他人怎麼看這次故障？

3.1 影響範圍圖譜

• 用户視角： 用户看到了什麼？（白屏？報錯？數據錯誤？）用户的信任度受損了嗎？

• 業務視角： 造成了多少資金/訂單損失？是否影響了正在進行的營銷活動？

• 客服/運營視角： 他們是否擁有足夠的信息去安撫用户？還是他們也是最後知道的？

• 開發/運維視角： 報警是否及時？排查工具是否順手？當時是否壓力過大導致判斷失誤？

第四階段：反思與可能性 (Stage 4: Alternatives)

蘇格拉底式追問： 除了修好Bug，我們還有沒有更聰明的路？我們是否只是運氣好？

4.1 運氣成分評估

• 如果故障發生在半夜/流量高峯，後果會嚴重多少？

• 我們是因為監控發現的，還是用户投訴才發現的？

4.2 替代方案頭腦風暴

• 偵測層面： 有沒有可能在故障發生前5分鐘就預警？我們需要什麼樣的監控指標？

• 止損層面： 除了回滾，有沒有降級開關？如果沒有，為什麼當初設計時沒加？

• 架構層面： 如果不修這行代碼，從架構上能否規避此類問題（例如：熔斷、隔離）？

第五階段：行動與二階影響 (Stage 5: Implications)

蘇格拉底式追問： 修復方案會帶來新問題嗎？誰負責落實？

5.2 預測連鎖反應 (Second-Order Effects)

• 為了修復這個Bug，我們引入的新代碼是否增加了系統複雜度？

• 新增的報警規則會不會導致“報警風暴”從而掩蓋真正的故障？

• 這次覆盤的結論是否需要同步給其他團隊（避免他們踩同樣的坑）？

管理者覆盤結語 (Summary)

本次故障給我們最大的認知升級是什麼？（用一句話總結）

總結：從“執行者”到“思考者”的躍遷

這張圖對於技術管理者最大的價值在於，它提供了一套從“解決Bug”升級到“解決系統性問題”的方法論。

• 初級管理者通常停留在階段一（看Log）和階段四（給方案）。

• 高級管理者則會在階段二（質疑架構假設）、階段三（平衡業務/技術/成本）和階段五（預判長期風險）投入更多精力。

如有想了解更多軟件設計與架構, 系統IT,企業信息化, 團隊管理 資訊，請關注我的微信訂閲號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。 該文章也同時發佈在我的獨立博客中-Petter Liu Blog。