■

戦意喪失。


ありえないミスの連続で、もうビックリですYO


≪背景≫
私が働くJチームは、開発、導入支援がメイン
Nチームは外注さんでサポートチーム
Cチームは保守グループであり、ユーザーとのやり取りや、J & Nチームとの連携を取る

≪経緯≫
4/5
既に導入を終えた場所のユーザーからデータがおかしいという連絡がJチームに直接来る。これは本来、ダメなルート*1なので、「ごめんね。Cチームに連絡を入れるのが正規のるーとよん」と伝える。
4/8
しかし、何もしないわけには行かないので、調査をする。明らかに重複して計算されているデータがある。 データをまとめ、Cチームに、「この件をNチームに伝えて調べてねん」と連絡。ちなみにこのまとめたデータを見れば、誰だっておかしい点に気付く。
4/16
「Cチームの対応が遅いの！ だからJチームが私を助けて！」とユーザーから悲痛の連絡が入る。急いで確認を入れたら、どうもあんな素晴らしい調査結果送ったのに全然対応してない臭い。直接Eチームにこちらから連絡を取る
4/20
Nチームから返信が来る。「あのねー。不具合なのー。リカバリーするのー」とかぬかす。至急修整プログラムとリカバリ方法とその実行内容を確認。不具合って・・・これすごいことだよ。このプログラムデイリーで動いているのですが、毎日重複データが作られていた。ありえん。ていうかユーザーももっと早く気付け。
4/21
Nチーム Cチームに指示を出しリカバリを行う（本来保守の作業のはずなのに何故俺が？）いざ実行をすると3月、4月の両方のデータをリカバリしている。しかし3月データはもう締めているため実行してはならない。至急バックアップからデータを戻し、4月だけリカバリ対応するように指示して帰宅
4/22
ありえない。「バックアップからデータ戻すつもりだったんだけど、間違ってまたバックアップとって上書きしちゃった。だからもどせないよ。他にバックアップデータ無いの？」とかNチームが言ってるし、いやいや。何のためのバックアップだよ。そういうの防ぐためのバックアップであり、バックアップのバックアップとってたらどこまで取ればいいんだよ。そこはもっとも注意すべきところだろう。何故そんなありがちなミスをする。これどうすんだ？どうやってもどすんだ？○一日かけて、リカバリ模索。打つ手無し。唯一の方法はサーバー管理が行ってるデイリーバックアップのDBイメージをごっそりどこか別サーバーなり別インスタンスに戻して、そこから必要なデータを抽出する必要アリ。しかしこれ時間とコストと人手が尋常じゃないくらい必要。無理。


ミスはミスを呼ぶ。そしてミスの影響は単純な足し算では算出できない。



この話は、フィクションであり実在の人物、団体とは関係ないことを切に願う

_no more 中国

*1:正しいルート User ⇔ C ⇔ J or N