Retry-as-Recovery
A Derived Failure Pattern of Temporal Assumptions and Hidden Side Effects
Summary
Retry-as-Recovery は、障害や失敗からの回復手段として リトライが事実上の唯一の戦略となり、 時間・状態・副作用に関する前提が崩れていく Failure Pattern である。
本 Pattern が扱うのは、リトライという技術自体の是非ではない。 部分失敗が常態化した環境において、 「とりあえず再実行する」判断が合理的に積み重なり、 結果として回復不能な状態が生まれる構造を扱う。
Context
分散システムや外部 API 連携において、 一時的な失敗は避けられない。
ネットワークエラー、タイムアウト、競合などは 時間をおけば解消することも多く、 リトライは有効な対処として一般的に採用されている。
Forces
この Pattern を生み出す主な力学は以下である。
-
一時失敗の一般化
多くの失敗が一過性であるため、 再試行すれば成功するという期待が形成されやすい。 -
回復設計の後回し
明示的な回復戦略を設計するより、 リトライを入れる方が短期的に安く見える。 -
副作用の不可視性
再実行による影響が即座に表面化せず、 問題が後から現れる。 -
境界の不明確さ
どこまでが安全に再実行できる範囲かが共有されない。
Failure Mode
リトライが回復の代替として使われることで、 時間と状態に関する前提が維持されなくなる。
その結果、以下のような壊れ方が同時に進行する。
-
同一処理が複数回実行される
冪等性が保証されない処理が再実行され、 データの重複や不整合が発生する。 -
遅延が副作用を拡大させる
リトライによって処理が遅れ、 その間に別の状態変更が介入する。 -
失敗原因が不明確になる
元の失敗とリトライ後の結果が混ざり、 問題の切り分けが困難になる。
Consequences（定着する影響）
-
回復時間が予測できなくなる
（Part II: Why It Breaks — 計測不在） -
「成功したが正しかったか分からない」状態が増える
（Part II: Why It Breaks — コンテクスト不足）
Countermeasures（向きを変える最小介入）
以下は解決策の一覧ではなく、 Failure Mode に対して最小限の介入で力学を変えるための対抗パターンである。
- 再実行可能な範囲と、 再実行してはならない境界を明示する
- リトライを回復戦略の一部として位置づけ、 成功条件と失敗条件を分離する
- リトライが発生した事実を、 学習可能なイベントとして扱う
Resulting Context（新しい当たり前）
リトライは引き続き利用されるが、 それは限定された状況における戦略となる。
回復は再実行だけに依存せず、 状態や副作用を考慮した設計判断として扱われる。
その結果、失敗は制御可能なものとなり、 時間と状態に対する理解が回復する。
See also
-
Boundary-Blind Integration
境界上の失敗が局所化されないことで、再実行が回復手段として過剰に利用されやすくなる基底パターン。 -
Test-Passing Illusion
リトライ後に一度成功した結果が、正しく回復したという誤った確信を生みやすくなる派生パターン。
Appendix: Conceptual References
- Information Hiding & Boundaries
再実行可能性の境界が明示されないことで、 副作用が時間軸を越えて漏出する構造の背景。 - Systems Thinking & Constraints
局所的な成功（再実行）が全体の回復を阻害する力学の背景。 - Feedback, Measurement & Learning
リトライが学習されず、失敗原因が蓄積されない構造の背景。
Appendix: References
- David L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, 1972.
- Fred Brooks, No Silver Bullet—Essence and Accidents of Software Engineering, 1987.
- Donella H. Meadows, Thinking in Systems: A Primer, 2008.
- W. Edwards Deming, Out of the Crisis, 1982.