Retry Policy

再試行ポリシーとは、スケジュールされたタスクが失敗した後、再試行すべきかどうか、何回再試行するか、間隔をどれだけ空けるかを定めた固定のルール一式を指す。これは失敗発生後の最初の反応層を扱い、「今回の失敗をもう一度試すべきか」に答える。fallback instruction（フォールバック指示）とは異なる。fallback instruction は再試行ポリシーが尽きた後、あるいはそもそも再試行すべきでないと判定された場合にどう締めくくるかを扱う。両者は同じ失敗処理の流れの中で前後に連なる二つの段階であり、再試行ポリシーはもう一度試すかどうかを決め、fallback instruction は試しても最後まで駄目だったときにどうするかを決める。再試行ポリシーのないスケジュールタスクは、どんな失敗にも二つの極端な反応しかできない。即座に人へ通知する（一時的な小さな問題も大事として扱う）か、まったく通知しない（本当の問題が沈黙の中に埋もれる）かのどちらかだ。

この仕組みが必要とされるのは、スケジュールされたタスクには傍らで「今回の失敗が深刻かどうか」をリアルタイムで判断してくれる人がおらず、あらかじめ書かれたロジックにしか従えないからだ。そして失敗そのものにはまったく異なる二つの性質がある。サーバーのタイムアウトやネットワークの一瞬の切断といった一時的な問題は、通常は少し待って同じことをもう一度やれば自然に治る。認証の期限切れや形式エラーといった構造的な問題は、何回再試行しても結果は変わらない。再試行ポリシーがなければ、システムはこのまったく性質の異なる二種類の失敗に同じ反応しかできない。一時的な問題を即座に人が対応すべき大事として扱えば、長期的にはオンコール担当者が次第に通知に麻痺していく。あるいは一切再試行も通知もしなければ、本当に対応すべき構造的な問題が静かに見過ごされてしまう。再試行ポリシーが存在する理由は、一時的な問題にまず自然回復の機会を与えつつ、際限なく待ち続けないよう有限の回数で区切ることにある。

実務では三つの決定を行う。第一に、どのエラー種別が再試行可能かを決める。タイムアウト、接続切断、相手からの5xx系サーバーエラーは通常再試行可能に分類し、認証失敗、相手からの4xx系リクエストエラー、データ検証エラーは通常再試行不可に分類する。再試行ポリシーは前者にのみ適用すべきだ。第二に、再試行間隔をどう増やしていくかを決める。よくある方式は指数バックオフで、一回目は1分待ち、二回目は5分、三回目は15分待ち、失敗回数が増えるにつれて待機時間を伸ばし、毎回同じ短い間隔で無理に叩き続けるのではなく、一時的な問題に自然回復の余地を徐々に広げていく。第三に、最大再試行回数を決める。通常は3回とし、3回とも失敗して初めて fallback instruction による処理へエスカレーションする。回数を少なすぎに設定する（1回など）と一時的な問題に十分な回復時間を与えられず、多すぎに設定する（10回以上など）と、本当に人が知るべきタイミングを遅らせてしまう。この三つの決定を合わせたものが、完全な再試行ポリシーとなる。

あなたにとって、再試行ポリシーが本当に変えるのは、オンコール担当者を真夜中に起こすべきかどうかを、その場の判断から事前に定めたルールへと変える点だ。再試行ポリシーがない場合、失敗のたびに誰かがその場で「これは重大か」を判断しなければならず、その基準はその場にいる人や疲労度によって緩くなったり厳しくなったりする。再試行ポリシーがあれば、その判断は固定のロジックに委ねられ自動的に処理される。一時的な問題は誰にも通知される前に自然に回復する機会を得られ、本当に知らせるべき構造的な問題が不必要に遅れることもない。注意すべきは、再試行ポリシーが答えるのは「もう一度試すかどうか」だけであり、「試しても最後まで駄目だったときにどうするか」には答えない点だ。再試行ポリシーが尽きた後、明確に人へ通知する fallback instruction が伴っていなければ、システムは静かに停止し、表面上は正常に見えても実際にはタスクが既に諦めている状態になる。この空白は再試行ポリシーが全くない状態よりも危険だ。正常に動いているという錯覚が、人にそう思い込ませてしまうからである。