Fallback Instruction

フォールバック指示とは、スケジュールされたタスクが二つの状況でどう締めくくるべきかを明確に定義することを指す。一つは retry policy（再試行ポリシー）が既に尽き、定められた回数だけ試しても失敗したままの場合、もう一つは失敗が最初から構造的な問題だと判定され、再試行に時間を費やす価値がそもそもない場合だ。これは失敗処理の流れの中で最後の段階を扱い、再試行ポリシーとは前後に連なる二つの段階になっている。再試行ポリシーはもう一度試すかどうかを決め、フォールバック指示は試しても最後まで駄目だったときにどうするかを決める。フォールバック指示のないシステムは、再試行が尽きると通常そのまま止まるだけで、以降の動作は何もない。この「そのまま止まる」状態は、表面上は流れが終わったように見えるが、実際には誰も気づかない空白を残してしまう。タスクは既に諦めているのに、誰にもそれが伝えられていない。

この仕組みが必要とされるのは、「再試行が尽きた」ことと「タスクが完了した」ことが、システムの外から見るとほとんど同じに見えるからだ。スケジュールは設定どおりの時刻に通常どおり実行され、目立ったエラーウィンドウも出ず、表面上はすべて正常に見える。実際にログを開いて初めて、今回は3回再試行して失敗し自動的に諦めたのだと分かる。この種の静かな失敗は特に危険だ。すぐに崩壊するエラーのようにその場で気づかれるのではなく、積み重なっていくからだ。データが何日も更新されない、レポートが何週間も古いデータのまま使われ続けるのに、何の警告もない。誰かがたまたま照合して初めて、問題が既にしばらく前から存在していたことに気づく。フォールバック指示が存在する理由は、再試行が尽きたその瞬間に、システムに何もせず静かにやり過ごすのではなく、目に見える動作を強制することにある。

実務ではまず一つの判断を行い、それによって三つの締めくくり方のうちどれを使うかが決まる。判断とは、このタスクの出力が「不完全あるいは遅延した結果を先に出す」ことを許容できるか、それとも完全に正しくなければ意味がないかである。部分的な結果を許容できるなら、「不完全とマークした部分的な結果を出す」を選ぶ。例えばレポートの欠落項目を「データ待ち」と表示し、下流の利用者にこのデータが完全ではないことを伝え、完全だと誤解させない。バックアップのデータソースが使える場合は「バックアップソースへの切り替え」を選ぶ。主要APIが落ちたときにキャッシュや二次ソースを取得するが、出力にはこれがバックアップソースから生成されたものであることを明記し、品質の差が通常の結果と誤認されないようにする。以上のいずれも当てはまらず、タスクが完全に正しくなければ使えない場合は「即座に停止し通知する」を選び、失敗の詳細（どの段階か、どんなエラーメッセージか）を整理して人に渡す。「タスク失敗」とだけ表示して、あとは各自で調べさせるようなことをしてはならない。三つの方式に共通する要件は、どれを選んでも、システムが自分がタスクを成功裏に完了できなかったことを認識していると証明する、明確で人の目に見える信号が必要だという点だ。

あなたにとって、フォールバック指示の本当の価値は、「タスクの失敗」を完全に見過ごされかねない静かな出来事から、必ず目に見える明確な状態へと変える点にある。この違いは、データが何日も更新されないのに誰も気づかないという状況で特に重要になる。フォールバック指示がなければ、上司からある数字が想定と大きく違うと聞かれて初めて、スケジュールタスクが既にとっくに静かに諦めていたことに気づくかもしれない。フォールバック指示があれば、タスクが諦めたその瞬間に誰かへ通知が届き、問題がまだ小さいうちに対処され、より大きな面倒に膨らむことはない。注意すべきは、三つの締めくくり方のうち「部分的な結果を出す」は一見リスクが最も低く、流れを最も妨げないように見えるが、不完全であることを示すマークが十分に目立たなければ（システムログに一行書かれるだけで、フロントエンドにはまったく現れないなど）、下流の利用者は不完全なデータを完全なものとして使ってしまいかねない。この状況は即座に停止するより危険だ。誤ったデータが正しいデータとして扱われ続けているからである。