処理がコケたりバグコードにより誤った処理が実行されてたりしたときに緊急対応する必要があるが、焦って誤った判断をしがちなので対応方法を考えておく。
影響範囲の調査
まずはどういう影響があるのか、いつまでに対応しないといけないのかを調べる。
自分でわからない範囲の場合まず「有識者に聞く」。
大体その対象業務に関わっている詳しい人がいるはず。
調査項目としては、
- 失敗した（している）処理はなんのために必要な処理なのか？
- これがうまく実行されないことでどういう影響があるのか？
- いつまでに修正されないとどういう問題が発生するか？
対応時間を稼げないか検討する
制限時間があり充分でない場合、伸ばせないか検討する。
例）
〜〜までに〇〇バッチが動くのでそれまでに修正されていなければならない
=>バッチの実行を止められないか？
シビアに優先度をつけて、原因調査を行う
複数問題がある時、どれも重要に思えるのでシビアに優先度をつける。
たとえば、
誤請求が発生してしまったとしても後で個別に対応できる。
それに比べて、データが消えたりすると復旧できないし、サービスが止まっている事で客の業務が止まっているなどしている場合、現在進行系で被害が大きくなっている状態なのでこちらが優先。
損害額的にも大きいはず。
原因がわかったらデータ状態調査を行う
原因の予想が立ったら、実際のデータの状態を実際に見ることで原因の予想が確かであることを確認する。
結構予想が間違ってたりもする。
復帰手順を検討する
復帰手順の作成は難しい。
いつもと違うことをやるので予想外の事が起こったりする。
時間をたっぷり使う開発でもバグを作り込んでしまったりするので、気をつけても見逃してしまうパターンは完全には除去できない。
だから、できるだけ既存のロジックを実行してやるような形がいい。
何らかの原因で処理がコケてしまっているパターン
実行されていない処理を再実行してやる。
ロジックに間違いがあり、間違ったデータが生成されてしまっているパターン
データが再生成可能な場合（処理に冪等性がある場合）はロジック修正後、改めて処理を実行してやるのがいい。
処理に冪等性がない場合、他に方法がなければデータを直接あるべき形に修正するしかない。。（気をつけて）
※ロジックで生成可能なデータは別途保存するのではなく、必要なときに都度都度生成させる作りにしておけば、ロジックを修正すれば自動的に問題が解決する。なるべくそういう作りにしておきたい。
