外部操作の成否が不明なときのインシデント対応

タイムアウトは、未実行の証拠ではない

外部サービスへの送信中に接続が切れた場合、エージェントが結果を受け取れなくても、相手側では処理が完了していることがあります。ここで自動的に再試行すると、通知、注文、登録、更新が重複するおそれがあります。

この状態は成功でも失敗でもなく『成否不明』です。通常のエラー処理から分離し、新しい外部操作と自動再試行を止めたうえで、確認に必要な証跡を固定します。

最初に止め、観測可能な事実を保存する

初動で優先するのは原因の推測ではなく、影響範囲の拡大防止です。同じ対象への後続処理を止め、実行時刻、対象、要求内容、応答、識別子を改変せず保存します。ログにない状態を推測で補わないことも重要です。

• 同じ対象への新規実行、再試行、定期処理を一時停止した
• 実行ID、外部要求ID、対象ID、送信時刻を保存した
• 受信できた応答と、応答が途切れた位置を記録した
• 人が行った確認や操作も同じ記録へ追記した
• 対応責任者と、次の状態確認時刻を決めた

アクション単位で状態を照合する

複数ステップの処理では、ワークフロー全体を一つの成功・失敗にまとめません。各アクションを『実行済み』『未実行』『成否不明』『失敗確認済み』に分類し、外部システムの現在状態と照合します。

照合には、外部要求ID、更新時刻、対象の現在値、送信履歴など、独立して確認できる情報を使います。記録が一致しない項目は成否不明のまま残し、再試行可能な項目と混ぜないようにします。

• 送信・更新・通知などを個別のアクションへ分解した
• 各アクションの期待状態と現在状態を比較した
• 外部側の識別子で、既存処理の有無を検索した
• 確認できない項目を失敗扱いに変更していない
• 既知の影響範囲と、まだ不明な範囲を分けて記録した

再試行と取り消しを、別の判断にする

失敗が確認できても、直ちに再試行してよいとは限りません。操作が重複を防ぐ仕組みを持つか、同じ識別子で再送できるか、後続処理との整合性が保てるかを確認します。条件を満たさない場合は、新しい操作として承認を取り直します。

実行済み操作を戻す必要があるときは、取り消しも独立した外部操作として扱います。元の状態へ完全に戻せると決めつけず、取り消し対象、想定される追加影響、確認方法を明示してから実行します。

再開条件を満たしてから、自動処理を戻す

個別の復旧が終わっても、同じ原因で次の実行が不明状態になるなら再開できません。原因への対策、停止中に滞留した処理の扱い、監視方法、再開承認者をそろえ、小さな範囲で動作を確認します。

• すべてのアクションが確定状態になった、または不明項目が隔離された
• 重複実行を防ぐ制御と、状態照合の手順を追加した
• 滞留した処理を再実行・破棄・個別確認に分類した
• 限定した対象で復旧後の動作を確認した
• 停止解除の根拠、承認者、実施時刻を記録した