オペレーションミスによるデータ直接修正！

■　今日の顛末

今日は色々と問題が発生して、その対応に追われる１日でした。

システム障害が発生して、その対応というのであれば時々は発生しているのですが、今回は久しぶりにオペレーションミスによって壊れたデータの復旧でした。

■　仕組み

勤め先のシステムは五十日の単位で請求処理を行います。最初に請求データ作成という処理を行う事で請求残高、請求明細といったデータを作り、作成された内容に問題が無ければ請求締め処理を行う二段重ねになっています。

請求データ作成は、締め処理の前であれば何度でも再処理が可能なので、入金や請求明細が漏れているようなら漏れたデータを登録後に再処理をすることで請求書に反映させる事が出来ます。そして締め処理を行う事で、その締日の請求が確定されます。

という絡繰りの処理を、各支店ごとに実行可能にしているのですが、システム稼働時から私は一つだけ不安がありました。

処理的には、請求データ作成が実行されていなければ請求締め処理も出来ないのですが、言い方を変えれば請求データ作成が実行されていれば請求締め処理は実行可能です。そして、請求締め処理を取り消す処理は存在しません。

「間違って請求締め処理をされたらどうしよう？」

■　オペレーションミス！

はい、間違えました。

・・・さて、どうしようか。

単純にフラグを立てるだけの処理であればどうとでもなるのですが、請求締め処理は内部的にかなり複雑な動きをしているので、迂闊にデータを弄る訳にも行きません（まぁ、だからこそ取消処理が存在しないのですが）。

影響が小さければ放置（運用でカバー）したかったのですが、話しを聞くとかなりの請求漏れになるらしく、何としてでも戻して欲しいという話です。

■　対応

運用でカバー出来ないようなオペレーションミスが発生した場合、対応策は大きく二つあると思います。一つは、バックアップからデータを復旧させる方法。もう一つは、データ直接修正によってオペレーションミスが起こる前の状態にデータを戻す方法。

前者は確実に元に戻す事が出来ますが、復旧作業中はシステムが使用出来なくなるし、バックアップ取得後に発生した全てのデータが消えてしまう欠点があります。

後者の場合、システムを停止させずに実行可能で影響範囲も限定される利点がありますが、修正方法を誤ると二次災害を引き起こす恐れがあります。

どちらを選ぶかはケースバイケースでしょうが、今回はデータ直接修正の道を選びました。請求締め処理（と関連する処理群）の仕様をほぼ把握していたので出来た決断ですが、我ながら勇気ある選択だったと思います。

■　後書き

オペレーションミスをした担当者は随分と気にしていたのですが、ミスをしない人間なんかいないのだし仕方ないと思うし、うっかりミスを取消せないシステムに問題があるようにも思います。

システムを作る時に、正常系だけを真剣に考えて異常系はおざなりになっているケースを見かけますが、システムの真価が問われるのは異常系だと思います。今回のデータ直接修正も、いくつかのデータで処理前の状態が分からず、バックアップを開発環境に戻して、そこから処理前の状態を確認する必要がありました。

今後の事を考えると、処理前の状態を何処かに退避させる処理を追加した方が良いかもしれないですね。

投稿記事の一覧：http://harikofu.web.fc2.com/

--- blog end —