警報只報出情況，不會替你定義問題
假設一個電商系統開始延遲完成付款。監控告警標成「支付授權逾時」，聊天室很快有人猜測供應商變慢，另一位值班者準備把重試次數調高。這個名稱看起來像診斷，實際上仍是尚待解釋的訊號。
調查後發現，供應商的授權延遲維持在平常範圍，內部事件佇列的等待時間卻一路增加。最近一次設定變更把付款工作者的併發數從八個降為兩個。值班者在一個小範圍恢復舊設定後，佇列延遲下降，付款完成率回升，而且沒有觀察到重複授權增加。
這是用來說明方法的假設案例，不是某家公司的事故紀錄。它要指出的差別是：警報提供了問題情境的一部分，卻沒有先替團隊決定應該問哪個問題。
上一篇海德格的器具分析追問中斷會讓哪些工作關係浮現；杜威的探究模式接著處理另一件事：當線索陸續出現，調查者如何形成、檢查並修正正在回答的問題？
杜威把問題看成探究的一部分
在《Logic: The Theory of Inquiry》第六章〈探究的模式〉中，杜威把探究描述為：從一個尚未形成秩序的情境出發，透過觀察、構想與操作，使情境變得較為確定。問題不是總在調查前就完整存在；我們需要先整理情境，才能說清楚究竟要解決什麼。杜威也把假設連到可預期的後果，再以行動檢查這些後果是否出現。原典第六章，尤其第 101–119 頁
這不是一張每次都要照順序走完的檢查表。Stanford Encyclopedia of Philosophy 將杜威的探究模式整理成問題形成、提出假設、推演後果與行動檢驗等環節，同時提醒這只是示意模式，真實推理不一定線性前進。John Dewey，§4.1
杜威在談的是邏輯與知識如何透過探究形成，不是現代的值班手冊。把他的觀點用於事故調查，是本文的工程推論：別急著把告警文字改寫成根因；先記錄已知影響，讓問題陳述隨證據調整，並要求每個假設說明什麼觀察會支持或削弱它。
讓每個假設都說出可觀察的後果
事故紀錄可以先保留五個欄位：目前看到的影響、正在回答的問題、彼此競爭的解釋、能區分它們的證據，以及下一個有界限的操作。付款案例可寫成以下概念紀錄；實際欄位名稱應對應團隊的指標與系統狀態。
impact: 付款完成時間上升，內部事件佇列等待增加
question: 延遲發生在供應商授權，還是內部事件處理？
hypotheses:
- claim: 供應商回應變慢
predicts: 供應商授權延遲同步升高
observation: 延遲維持基線
status: weakened
- claim: 工作者併發數下降
predicts: 佇列等待增加，供應商延遲維持基線
observation: 設定變更後工作者數量減少
status: likely
next_action: 在限定範圍恢復原併發設定
expected_result: 佇列等待下降，且重複授權沒有增加這些欄位迫使團隊分開三件事：看到的訊號、對訊號的解釋，以及採取行動後得到的結果。若觀察和預測不合，應更新假設或重新界定問題；不必把調查硬塞回最早的告警分類。
操作也可能改變正在調查的系統。增加併發、重試或切流都可能引入新風險，所以要先寫出預期結果、停止條件與回復方式。高嚴重度事故若已有經驗證的安全緩解措施，應先降低使用者傷害；探究紀錄不能成為延遲必要處置的理由。
把事故結論寫成可再檢查的操作判斷
杜威重視探究是否讓情境得到足以繼續行動的秩序。工程上可以把這轉成一條結案規則：事故結論要說明影響是否消退、哪項假設得到哪些證據支持、介入後預期訊號是否改變，以及仍有哪些未知事項。
例如，付款案例除了確認佇列排空，也要觀察付款完成率是否回穩，以及重複授權、錯誤率或其他相關副作用是否增加。若佇列下降但付款完成率未恢復，這項操作只處理了部分問題，調查就應重新展開。單一指標改善，不足以證明整個使用情境已恢復。
事故報告不需要宣稱找到了唯一、永遠不變的「根因」。它可以交代一個由證據支持的操作性結論，並保留待查的因果鏈與後續責任。這也讓下一次探究有可用的起點，而不只是複製上一份 postmortem 的標籤。
這個方法不能替事故指揮官選擇風險
杜威沒有替軟體團隊規定可接受的停機時間、回復優先順序或操作權限。假設檢驗也可能受限於資料品質；一次部署和指標同時變化，不足以單獨證明兩者有因果關係。事故指揮官仍要依使用者影響、回復能力、證據品質與安全措施選擇操作，必要時先緩解、再調查。
下次整理事故紀錄時，先把「警報名稱」和「目前要回答的問題」分開。為一個主要假設寫出可觀察的預測，再補上一個能區分它的替代解釋。若新證據推翻問題本身，就更新問題；不要只把原來的根因欄位填得更完整。
系列前篇：系統邊界不是地圖外框：模型會先決定誰看得見、故障會讓系統關係浮現：從海德格的器具分析到可驗證的復原路徑。下一篇將討論例外何時應寫成規則，何時需要有權責的人作出判斷：例外處理要先決定誰負責：用亞里斯多德實踐智慧設計自動化停點。