OutcomeGuard の仕組み
読み取り専用の API key から、対応できる通知まで 6 段階です。n8n instance の中で動くものはなく、instance へ書き戻すものもありません。
- 1
接続
n8n の API key を作り、instance の URL と一緒に入力します。OutcomeGuard が触るのは n8n の public REST API だけです。self-hosted でも n8n Cloud でも動きます。
- 2
基準の学習
各 workflow の execution 履歴を読み、その workflow 自身の普段を学習します。どれくらいの間隔で動くか、どれくらい時間がかかるか、何件出すか、いつもどの node で終わるか、空の結果が本当に普通なのか。
- 3
監視
以降は取得のたびに execution ごとの要約を集めます。status、開始時刻、所要時間、件数、最後に実行された node、秘密情報を除去したエラー文、そして workflow 定義のハッシュです。
- 4
検出
各 workflow を、自身の基準と宣言された schedule に照らして判定します。cron と interval は timezone まで解析するので、08:30 JST に動くはずの実行は 08:30 JST の時点で不足と判定します。08:30 UTC ではありません。
- 5
成果の検証
Outcome Contract を設定した workflow は、期限を過ぎた時点で結果を確認します。実行されたか、成功したか、件数は足りたか、時間内に終わったか、そして連携先が実際に変わったことを downstream probe が確認できたか。
- 6
通知と報告
検出結果は問題 1 件につき 1 つの incident にまとめます。重複排除とクールダウン、段階的なエスカレーションがあるため、1 回の障害でメールが 40 通届くことはありません。月次レポートは Pro と Agency に含みます。
各段階は、証明できたことだけを次へ渡します。根拠が足りない段階は「データ不足」と報告してそこで止まります。
検出結果は、判断の過程まで出します
検出結果はラベルだけではありません。signal の種類、判断の元になった根拠の行、時刻、0 から 1 の確信度、そして判断を平易な 1 文にした理由が付きます。
- Signal
- どの障害パターンに一致したか。たとえば SILENT_FAILURE、MISSED_RUN。
- 根拠
- 判断の材料。最後の実行、想定していた間隔、件数、最後の node、秘密情報を除去したエラー文。
- 確信度
- 参照できた履歴の量を踏まえて、engine がどれくらい確からしいと見ているか。
- 理由
- そのまま同僚に転送できる 1 文。読み替えは不要です。
OutcomeGuard がやらないこと
- workflow への書き込み、credential の変更、課金や設定の代行は行いません。
- 推測はしません。instance に接続できない間は UNKNOWN のままにし、接続できるまで判断を保留します。
- 2 件のデータで異常と呼ぶことはありません。統計的な検出は、履歴が十分に集まるまで待ちます。
- 自動復旧は安全で取り消せる操作だけです。当社側のチェックの再試行、失敗した通知の再送、検証のやり直しに限ります。