大家好！歡迎來到鐵人賽第二十五天。

昨天我們完成了 n8n Credentials 憑證管理，將 API Key、Token 與 SSH 私鑰集中管理，降低機密外洩的風險。

但自動化系統除了安全性，也必須具備穩定性。如果今天 VirusTotal API 無法連線、LINE 通知失敗，或是 SSH 節點執行指令時發生錯誤，整個工作流就可能中斷。

因此，今天我們要利用 n8n 的 Error Trigger 與錯誤工作流（Error Workflow），建立統一的異常處理機制。當 SOAR 系統執行失敗時，自動整理錯誤資訊並透過 LINE 發送通知，讓管理者能夠及時排查問題。

一、建立錯誤處理工作流

首先，我們需要建立一條獨立的工作流，專門負責接收其他工作流的執行錯誤。

1. 在 n8n 建立新的 Workflow，命名為 SOAR_Error_Handling。
2. 新增 Error Trigger 節點。
3. 儲存工作流。

當其他工作流發生錯誤，且已指定這條錯誤工作流時，Error Trigger 就會接收相關的執行資訊，例如工作流名稱、執行 ID、錯誤訊息與失敗節點。

這樣就不需要在每一條主要工作流中重複建立完整的錯誤處理流程。

二、整理錯誤資訊

接著，在 Error Trigger 後方新增 Edit Fields（Set） 節點，將重要資訊整理成容易閱讀的格式。

新增以下欄位：

• workflow_name：發生錯誤的工作流名稱
• execution_id：本次執行的識別碼
• error_message：錯誤訊息
• last_node：發生錯誤的節點

不同版本的 n8n 或不同錯誤情境，傳入的欄位結構可能略有差異，因此要先執行測試，確認 Error Trigger 實際收到的 JSON，再使用對應的 Expression 取值。

例如，若錯誤資料位於 execution 物件中，可以依照實際輸出設定：

{{ $json.execution.id }}

取得執行 ID。

如果欄位路徑與實際輸出不同，就必須依照測試結果調整，避免錯誤處理流程本身再次發生錯誤。

三、透過 LINE 發送異常通知

接下來，新增 HTTP Request 節點，將錯誤資訊傳送至 LINE Messaging API。

設定方式如下：

• Method：POST
• URL：https://api.line.me/v2/bot/message/push
• Authentication：使用先前建立的 LINE 憑證，或透過安全方式設定 Bearer Token
• Content-Type：application/json

在 Body 中設定接收對象的 User ID，以及通知文字。

例如：

{
  "to": "你的 LINE User ID",
  "messages": [
    {
      "type": "text",
      "text": "【SOAR 異常告警】\n工作流：{{$json.workflow_name}}\n執行 ID：{{$json.execution_id}}\n錯誤原因：{{$json.error_message}}\n失敗節點：{{$json.last_node}}"
    }
  ]
}

請將範例中的 LINE User ID 替換為實際接收者的 ID，並依照整理後的欄位調整 Expression。

注意：LINE Messaging API 的 Push Message 需要有效的 Channel Access Token，且接收者必須符合 LINE 的訊息推送條件。若請求失敗，仍需另外檢查 HTTP Request 的回應與憑證設定。

四、將錯誤工作流套用至 SOAR 系統

錯誤工作流建立完成後，還需要將它指定給主要工作流。

1. 開啟主要的 SOAR 工作流。
2. 進入工作流設定。
3. 找到 Error Workflow 選項。
4. 選擇 SOAR_Error_Handling。
5. 儲存設定。

可以先選擇一條測試工作流進行驗證，再逐步套用至 VirusTotal 情資查詢、SSH 遠端指令與其他重要流程。

如此一來，當主要工作流發生未被正常處理的錯誤時，n8n 就能呼叫指定的錯誤工作流，集中處理異常資訊與通知。

五、實際測試錯誤通報

最後，我們需要確認整條流程真的能運作。

1. 建立一條測試工作流，加入會故意產生錯誤的節點。
2. 確認測試工作流已指定 SOAR_Error_Handling。
3. 手動執行測試工作流，觸發錯誤。
4. 查看 SOAR_Error_Handling 是否收到執行資訊。
5. 確認 LINE 是否成功收到異常通知。
6. 回到 n8n 的 Executions 頁面，確認失敗的工作流與執行紀錄。

如果沒有收到通知，可以依序檢查 Error Workflow 是否正確指定、錯誤工作流是否已儲存、JSON 欄位路徑是否正確，以及 LINE API 的回應內容。

今天的成果

今天我們替 SOAR 系統加入了集中式錯誤處理與 LINE 異常通報機制。當工作流執行失敗時，系統可以自動收集錯誤資訊並通知管理者，減少人工反覆檢查執行紀錄的時間。

不過，錯誤通知不等於自動恢復。對於暫時性的網路異常或 API 限流，還需要搭配重試機制；對於 SSH 指令失敗等可能影響系統安全的情境，則應保留執行紀錄並由管理者確認後再處理。

明天（Day 26），我們將繼續強化 SOAR 的可靠性，實作 API 失敗重試與退避機制（Retry & Backoff），讓系統面對短暫的網路中斷或服務異常時，能夠更有彈性地處理問題。我們明天見！