上一篇〈系統邊界不是地圖外框：模型會先決定誰看得見〉追問系統分析把誰納入、哪些後果算進成果。本文往執行流程走一步：一段工作順利完成時，哪些程式、資料與人員關係退到背景？中斷發生後，又有哪些依賴才浮現？
假設使用者上傳一份文件，畫面立刻顯示「完成」。檔案已寫入物件儲存，資料庫狀態卻還是 scanning；掃描事件排進佇列，但背景工作者沒有回報。使用者認為上傳好了，下載端點仍拒絕提供檔案，客服只看到「處理中」，工程師則得沿著佇列、掃描器與狀態紀錄追查。
這個假設情境有一個設計問題：「完成」把不同的事實壓成同一個詞。使用中斷不只指出某個元件失效，也能暴露一項工作原本依賴哪些關係才能完成。
器具的意義來自它接續的工作
海德格在《存在與時間》§15–16 討論我們如何在實際活動中遇見器具。錘子首先不是一組重量與材質，而是用來敲釘子的東西；釘子連著木料，木料連著工作台與正在進行的工作。器具的意義落在這個「為了什麼」的關聯脈絡裡，而不是孤立物件的清單。《存在與時間》Macquarrie 與 Robinson 英譯本；Stanford Encyclopedia of Philosophy 對器具關聯脈絡的整理
海德格把器具這種在使用中派得上用場的存在方式稱為上手性（Zuhandenheit，常譯為 readiness-to-hand）。這不是說工具真的從視線消失，而是人在熟練地做事時，注意力通常落在要完成的工作，不會先把每個工具當成等待檢查的物件。Stanford Encyclopedia of Philosophy：Martin Heidegger
把這個觀察用在軟體，是本文的工程推論，不是海德格提出的架構原則。使用者要的是「安全地取得檔案」，不是物件儲存、狀態資料表、佇列與掃描工作者各自正常。系統分析若只列元件，很容易忘記它們如何共同完成一件事；若只畫成功路徑，也可能把非同步處理和人工接手藏在一個「完成」狀態後面。
中斷會讓三種依賴問題變得醒目
在《存在與時間》§16，海德格分析器具不可用、必要器具缺席，或現有事物妨礙手邊工作時，原先熟悉的關聯如何顯露。Macquarrie 與 Robinson 將這幾種情況譯為 conspicuous、obtrusive 與 obstinate；這些詞描述的是使用經驗，不是現代軟體的故障分類。《存在與時間》§16；Stanford Encyclopedia of Philosophy：較早版本對 §16 的說明
把它們當成需求工作坊的提問，可以得到三個不同方向：
- 有東西，但現在不能用。 掃描器逾時或儲存服務拒絕寫入時，哪些後續操作必須停下？系統要保留哪個狀態，才能讓重試不被誤認成成功？
- 工作需要的東西不在。 檔案已寫入，但掃描事件沒有送達或工作者沒有接手時，誰能看出這條關係斷了？使用者與客服各自看見什麼？
- 某個流程擋在工作前面。 檔案進入人工審查後，如果沒有明確負責人或逾時規則，安全檢查就可能成為無人收尾的等待狀態。這未必是錯誤政策，卻必須有可見的責任與下一步。
這些問題不會自動指出應該拆服務、換佇列或增加重試。它們先幫分析者辨認：中斷的是哪一段工作、缺少哪個關係、以及誰要讓流程恢復。
從上傳流程寫出狀態與復原契約
回到檔案掃描流程，先把「上傳成功」拆成能各自驗證的狀態：
received：系統已保存檔案內容。scanning：檔案等待掃描結果，尚不可下載。available：掃描通過，下載端點可以提供檔案。rejected：掃描判定不應提供檔案。review_required：掃描服務持續不可用，流程交由明確的人工責任人處理。
狀態拆清楚後，程式可以守住幾條行為契約：
- 只有
available能通過下載檢查；檔案已儲存不等於已可用。 - 掃描逾時只能維持等待、重試或轉交審查，不得被轉成通過。
- 同一掃描結果重送時，狀態更新與通知保持冪等，不重複發布「檔案已可用」事件。
- 重試耗盡時，紀錄要指出目前狀態、最後一次錯誤與負責的復原路徑。
對應的驗收條件可以先寫成以下概念片段，再轉成團隊使用的測試：
Given 檔案仍在等待掃描
When 使用者要求下載
Then 系統不提供檔案，並顯示目前的處理狀態
Given 掃描器暫時無法回應
When 系統重試掃描
Then 檔案保持不可下載，直到收到可驗證的掃描結果觀測資料也應沿著同一段工作串起來，例如保留 upload_id、事件識別碼、狀態轉換時間與重試次數。這讓值班人員能從使用者看到的狀態往回追，而不只知道某個服務回了 5xx。
在需求階段先做一次中斷走查
不必等正式事故才運用這個視角。下一場需求或架構工作坊，可以挑一條重要的成功流程，再逐步走查：
- 說清楚使用者要完成的工作，以及系統回報「完成」時承諾了什麼。
- 列出支撐這段工作的器具與關係，包含資料、背景工作、外部服務和人工角色。
- 暫停或移除一項必要依賴，觀察哪個狀態先變得不明確、哪位使用者先承受影響。
- 寫下可恢復的狀態、責任人、重試或人工接手機制，以及能證明流程恢復的測試。
這個走查把哲學問題帶進工程工作：分析的單位不只是服務或資料表，也是人正在完成的工作，以及使工作可能或不可能的關係。若流程中斷時沒有人知道它停在哪裡、誰該接手，系統模型就還少了一段重要的依賴。
故障提供線索，不會替你決定架構
海德格的器具分析不是可靠度工程方法，也不會告訴團隊要不要使用微服務。一次中斷可能來自部署失誤、外部供應商或罕見資料，未必代表模組邊界錯誤；同樣地，追蹤圖也無法取代受影響者的經驗。這個哲學視角提供的是觀察入口，架構改動仍要由重現證據、失敗代價、團隊責任與維護成本來決定。
下次設計一條含有背景工作或外部服務的流程時，先挑一個最重要的依賴做中斷走查。把「成功」拆成可驗證的狀態，再寫明失敗後誰能看見、誰負責恢復；這會比只在元件圖上多畫一個方塊更早發現流程缺口。
若已經找出哪些依賴在中斷時浮現，接著可以讀事故調查別讓警報替你下定義：用杜威探究法更新故障假設，學習如何在調查過程中形成並修正問題陳述。