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