検出結果から incident へ
検出結果は、1 回の取得における 1 つの判断です。incident はその背後にある問題です。fingerprint が同じ検出結果（同じ workflow の同じ障害パターン）は新しい incident を作らず、同じ incident に合流します。5 分ごとに失敗する workflow で受信箱が埋まらないのはこの仕組みです。
incident は問題が続く間は開いたままで、workflow が正常に戻ったときに閉じます。閉じたことの通知は、開いたことの通知と同じくらい役に立ちます。
重複排除、クールダウン、エスカレーション
- 重複排除
- 同じ workflow の同じ問題は 1 つの incident です。何回の取得で観測しても同じです。
- クールダウン
- 通知を送ったあとは、問題が続いていても一定時間その incident については黙ります。
- エスカレーション
- クールダウンを越えて続く問題は、同じ通知を繰り返すのではなく段階を上げます。2 通目には新しい情報（どれだけの時間壊れているか）が入ります。
結果として、1 回の障害につきメール 1 通、まだ壊れていればしばらく後に 2 通目、復旧したときに 3 通目になります。
通知に入るもの
- workflow 名と signal。たとえば「日次請求取り込み」の SILENT_FAILURE。
- 1 文の理由。そのまま転送できる書き方にしています。
- 根拠の行：想定していた間隔、最後の実行、件数、最後の node、除去済みのエラー文。
- 確信度。際どい判断が、際どいものとして見えるようにするため。
- ダッシュボードの該当する検出結果へのリンク。
通知に載るのは要約レベルの根拠だけです。業務データがメールに入らないのは、そもそも OutcomeGuard に入っていないからです。
チャンネル
v1 はメールです。通知先は workspace ごとにダッシュボードで設定します。Agency プランでクライアントごとの通知が混ざらないのはこの仕組みによるものです。
Slack、Microsoft Teams、Discord、汎用の webhook は今後の予定です。時期は示しません。
通知が届かないとき
- ダッシュボードからテスト通知を送り、通知先の一覧を確認します。
- 迷惑メールフォルダを確認し、メールの管理者に送信ドメインの許可を依頼します。
- そもそも検出結果があるかを確認します。workflow が「データ不足」の一覧にある場合、通知する対象がまだありません。
- instance に到達できているかを確認します。instance が UNKNOWN の workflow は、壊れていると報告しません。壊れていると分かっていないからです。
自動の復旧試行
OutcomeGuard は、自分の仕事については安全な範囲で再試行します。失敗したチェックのやり直し、送れなかった通知の再送、検証の再実行です。試行の記録は incident と一緒に残ります。
お客様の workflow を再実行したり、書き換えたり、credential を変更したりはしません。お客様のシステムを変える操作は、お客様のものです。