疑難排解常被當成某些人「天生會」的直覺，其實是可學、可教的方法：以觀察為起點提假設，再逐一驗證或否證。把它當成反覆的「假設—測試」循環，新手也能系統化地逼近根因。
🧠 Intuition
TIP
假設—演繹法（hypothetico-deductive）：問題回報 → 檢視遙測 → 結合系統知識提假設 → 測試/處置驗證 → 找到根因 → 修復 → 寫事後檢討。每一輪都在縮小可能原因的範圍。
- 先止血，再找根因：大事故的第一直覺是「快點找根因」——忽略它。第一要務是讓系統盡量運作（切流量、丟流量避免連鎖、關非必要子系統）；可能造成不可逆資料毀損時，凍結系統好過繼續惡化。
- 聽到馬蹄聲先想馬，別先想斑馬：偏好簡單解釋（Occam’s razor），但也記得多個小毛病加總可能比單一稀有原因更可能。
- 診斷三問「什麼、哪裡、為什麼」：故障系統通常仍在做某件事，只是不是你要的——它在做什麼？資源/輸出去了哪？為什麼？
- 最近動了什麼：系統有慣性，正常運作會持續到被外力推動；把版本部署、設定變更的起訖標在儀表板上，好把「錯誤率變化」對齊「事件」。
⚖️ Tradeoffs
憑直覺跳到結論 — 常見陷阱
- 看到不相關症狀或誤解指標 → 追錯方向；把「相關」當「因果」——大型系統指標多到必有巧合相關。
- 抓住「過去某次的原因」就認定這次也一樣，或提出過於離奇的假設。
- 不知道如何安全地改動系統做測試，反而把狀況弄得更糟。
系統化診斷 + 記錄一切 — 標準做法
- 簡化與化約：對每個元件注入已知測試資料檢查輸出（黑箱）；大型系統用**二分法（bisection）**對半切、檢查中間路徑，超大型比線性走完整堆疊快。
- 測試要互斥、由可能性高的先測，但顧及測試本身的風險與混淆因子（如只從自己 workstation ping 失敗不能下結論）；注意主動測試會改變結果（開 verbose log 可能讓延遲更糟）。
- 詳細記錄你想了什麼、測了什麼、結果如何（共享文件/聊天室自帶 timestamp）——事後檢討用得到，也讓旁人看到進度。負面結果是寶：能解決設計爭議、替後人省成本。
🔑 Takeaways
- 疑難排解是可教的假設—測試循環，不是天生直覺；大事故先止血再找根因。
- 診斷靠「什麼/哪裡/為什麼」+ 二分法 + 「最近動了什麼」；偏好簡單解釋但別漏掉多因疊加。
- 測試要互斥、顧及風險與混淆因子，全程記錄；負面結果同樣有價值，並從設計階段就為可觀察性投資。
No notes yet — jot your takeaways or Q&A here.