このユニットの結論
相手システムが止まったとき、すぐに再送してはいけません。
最初に確認するべきなのは、
- どこまで処理されたのか
- 相手はデータを受け取ったのか
- 同じ処理をもう一度実行しても安全なのか
- どこから再開すればよいのか
です。
障害対応の基本は、
- 止める
- 保存する
- 記録する
- 再開する
です。
1. 何の話か
アステリア刷新プロジェクトには約36本のシステム連携があります。
自分たちのシステムが正常でも、連携先が止まることがあります。
データ送信後にタイムアウトしたとします。
ここで、
「エラーになったから再送する」
と判断するのは危険です。
2. タイムアウト = 処理失敗ではない
たとえば、
- 自システムが送信
- 相手が受信
- 相手が処理
- 相手が完了応答
という流れで、3まで終わり4だけ届かなかった可能性があります。
自システムには「タイムアウト」と見えても、相手では処理済みかもしれません。
その状態で再送すると、二重処理になる可能性があります。
3. THINK — 復旧したから全部再送する？
相手システムが復旧しました。
自システムには送信記録がありますが、相手側でどこまで処理されたか未確認です。
判断例を開く
判断
この段階では再送しません。
まず、
相手が処理済みではないか
を確認します。
4. 障害対応の4段階
STEP 1 止める
被害を増やさない。
STEP 2 保存する
送信済み、未送信、応答済み、状態不明など、現在の状態を残す。
STEP 3 記録する
事実と推測を分ける。
STEP 4 再開する
どこから何をどう再実行するか決める。
5. 再開前の6確認
- 障害原因と現在状態
- 再開対象
- 重複処理の可能性
- 再実行方法
- 制御された再開
- 最終整合性
特に危険なのは、
状態不明を「失敗」と決めつけること
です。
6. Retry / Timeout / Queue / 冪等性
- Timeout: 一定時間内に応答を確認できなかった
- Retry: 同じ処理を再試行する
- Queue: 今処理できないものを保持する
- 冪等性: 同じ処理を再実行しても結果がおかしくならないようにする考え方
Retry回数を増やせば安全になるわけではありません。
再実行してはいけない処理もあります。
7. 判断表
| 状態 | 対応 |
|---|---|
| 相手未受信を確認 | 再送候補 |
| 相手処理済み | 原則そのまま再実行しない |
| 相手処理中 | 状態確認 |
| 処理済みか不明 | 追加確認 |
| 一部処理 | 境界確定 |
| 状態確認手段なし | 設計・運用上の課題 |
8. AI WORKFLOW
AIには、
- ログ整理
- 時系列整理
- 事実と仮説の分離
- 原因候補
- 重複リスク
- 追加確認事項
を整理させます。
指示例:
「障害情報を、確認済み事実、未確認事項、原因仮説、再実行リスク、追加確認すべき証拠に分けてください。原因を断定しないでください。」
9. REVIEW
AIが、
「未処理の可能性が高いため再送してください」
と回答しても、そのまま再送しません。
確認する:
- 未処理の証拠
- AIの推測
- 二重処理
- 再処理範囲
- 再開後の確認
- 判断記録
10. 人間が判断すること
- 業務影響
- データ整合性
- 再処理範囲
- 再開タイミング
- 関係者連絡
- 復旧完了条件
技術的に再実行できることと、業務として再実行すべきことは別です。
11. 判断演習
タイムアウト後、相手側に一部データが存在していますが、全件完了したか不明です。
「全部再送しますか？」
と聞かれました。
最初に、
- 到達済み
- 処理済み
- 状態不明
- 再送時の挙動
- 重複判定方法
- 再開後の確認方法
を確認します。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
エラー = 未処理ではない。
分からない状態のまま、とりあえず動かさない。
止める判断も、システム設計の一部です。