致命的なオペレーションミスが起きたらどうするか。
http://alfalfa.livedoor.biz/archives/51443035.html
システム屋としては、他山の石としちゃいけない話。エピソードとしてはこんな感じです。
- データベースサーバを操作する際、うっかりTRUNCATE文打っちゃってデータ丸ごと消滅。
- バックアップから復旧しようとしたらバックアップが動いてない。
- 現場から逃走。会社からも逃走。
- 別の会社に転職したら、そこでの仕事で前の会社の人とバッタリ。
- 鬱だ氏脳
このエピソードで学ぶべき点は何より、
- 超ド級の障害が起きても、どこかに活路はあるから絶対にその場で戦うべき
ってところですかね。でも、こういう一番大事な事って、往々にして新人研修とかで教えてもらえないんですよ。そして現場でおろおろすることになる、と。ホント、現場の知恵や経験を次代に継承するのは難しいもんですね。
例えば、この事例では「伝票明細」が記録されているテーブルが丸ごと消えてしまっているので、100%の復旧は、確かに不可能だと思うんですよ。どこかに別のバックアップがある訳でもないようですし、状況を見る限りおそらくこれはもうどうしようもないです。次の日現場が大混乱になるのは間違いないでしょう。
でも、そこからどこまで復旧できるか、は別の問題なんですよ。
このシステムが具体的にどんなシステムかは分からないですけど、データベース・テーブル以外にもデータが残っている場所は当然ある訳で。
- 削除直後のサーバのメモリ
- アプリケーション側に残っているログ／中間ファイル
- バックアップできていた頃の情報
- 他システムに残っている情報
- データ入力者のPCなどに残っているファイル
- 関係者の持っている紙文書／記憶
- 取引先が持っている情報
など、現場によって使える情報使えない情報はあるでしょうが、いろんな所にデータは残っています。それを集めれば、少なくとも業務への影響は、案外軽減できるはずなんですよ。同じ「データ」といっても、一部の重要な「データ」さえなんとかすれば、あとは何とかなる、というケースだってあります。
事故が起きる前にはもう戻れないんだから、やるだけの事をやり、次回の再発防止策を立て、あとは腹をくくる。それしかないと思うんですよ。それで過剰に責任を問われるような事があるなら、そのときこそ「辞めていい」と思うんです。
そもそも本来、このようなケースでオペレーターが100%の責任を問われるような事は稀です。それは以下の根拠を考えれば明らかで、
- オペレーターが、一人で直接TRUNCATE文を打つような運用体制になっていた
- バックアップが動作しない状況が検知できていなかった
- バックアップの挙動を監視するツール／アプリが入っていないということが分かる。少なくともそこがケチられていた事も復旧を困難にした大きな原因
- (これは推定ですが)これだけ重要なデータを扱うのに、手順書を作成して、その手順だけを行うような体制になっていなかった
- (これは推定ですが)「眠かった」というコメントがある事から、重要な作業なのにオペレータの休息が十分に取れていたかどうかも疑問
つまり、(おそらくはコストの問題で)十分な運用体制が取れていなかったのだから、事故が大きくなってしまった責任の多くは、システムを請け負った会社と、ユーザーに帰属する訳で、オペミスをした本人の問題にはならないはずなんです。何か理不尽な事を言われたら、「半分は自分の問題、でも残り半分は会社の問題」と言い返すぐらいでよかったと思うんですよ。
まあ、こんな事を書いてきた私も、ここまで大きなトラブルはないものの、いろいろとミスをやらかして、いっぱいいっぱいごめんなさいしてきたので、あまり偉そうに書ける訳ではないんです。ただ、腹をくくって進めて行った結果、(いろいろ怒られたり叱られたりキツい事言われたりもしましたし、お客様にも上の人にもいろいろ迷惑をかけてきましたが)時間の経過とともに落ち着くべき所に落ち着きました。
そういう自分の経験を振り返っても、逃げずに進めてほしかったな〜、というのが正直な気持ちですね。
