間違ってデータベースを削除してしまったらどうする？ 121
ストーリー by hylom
手作業の場合はチェック体制を 部門より
手作業の場合はチェック体制を 部門より
あるAnonymous Coward 曰く、
2ちゃんねるのニュース速報(VIP)＠２ちゃんねる板で、「30分前に顧客DB消しちゃったけど質問ある？」というスレが立ち話題となっている（ログ、VIPPER速報）。2ちゃんねるの話題なので真偽は不明だが、バックアップを取っていないデータベースに対し手動で「TRUNCATE TABLE」コマンドを実行してしまった、という話だ（スレ立て主のコメント、コメント2）。
削除するテーブルと、削除すべきでないテーブルの名前が似ていたためにうっかり削除してしまったという非常にリアリティのある話で、最終的には別の似たようなデータから再生成、作業をしていたスレ立て主はボーナスカット＆1週間の出勤停止ということで決着が付いたという内容だ。
実際、データベースを触る技術者にとっては笑えない話なのだが……。こうならないように対処するのが当然なのだろうが、そのような対応策をとれない場合もあるだろう。こういうミスを防ぐためにはどうすればよいのだろうか？
脆弱性やプライバシーの件にも言えるけど (スコア:3)
痛い目を見るまでは対策の必要性など理解されないんですよ。
一人以外は全員敗者
それでもあきらめるより熱くなれ
Re:脆弱性やプライバシーの件にも言えるけど (スコア:1)
そういう会社だと、痛い目を見た後でも定期バックアップや自動化などは夢にも思わず、
目視確認のダブルチェックで済まされてしまう可能性が捨てきれない。
ど忘れ (スコア:3, おもしろおかしい)
truncate ってどういうコマンドでしたっけ?
調べるのが面倒なので、ちょっと会社のDBで試してみるか。
そもそも論をいうその前に、 (スコア:2, すばらしい洞察)
そんな環境を許す職場に向けて、そもそもバックアップ・・・とか言っても意味ナッシングだと思うよ。
さらにその前に、 (スコア:0)
巫女SEが本番環境落としたときもそうだけどなんで実話という前提になるの? VIPはホラ話を吹き合うところですよ(釣り宣言の有無にかかわらず)。
Re:さらにその前に、 (スコア:1)
実話かどうかはさておき、日本のあちこちで日常的に起きている事件だから。
ケーススタディとしては申し分ない。
この状況下になってしまったら (スコア:2)
まず上司に報告して、DB入ってるサーバーをダウンさせて、上書きされるのを回避。
そののちに専門業者に復旧委託。
だろうか。
この場合は原因がわかっているので、まずは復旧させてからのちほど辞表や転職を考える。
コマンドやバッチのようなものを用意 (スコア:1)
手打ちだとどうしても何回かに一回はミスが出るので「これをダブルクリックしてください」「このボタンを押してください」って指示で大丈夫なようにしている。
#全部そうするのが理想だけどこれがなかなか……。
LIVE-GON(リベゴン)
Re:コマンドやバッチのようなものを用意 (スコア:2, 参考になる)
DB案件じゃないですが、オペレータに警告出すシステム構築しても、「無視するのが日常」なせいで事件になったのもありますたね.。。
http://ja.wikipedia.org/wiki/%E3%82%B8%E3%82%A7%E3%82%A4%E3%82%B3%E3%8... [wikipedia.org]
やっぱダブルチェックしかないんじゃない？ (スコア:1)
重要な更新は（どんな熟達者でも）二人で確認しながら作業するしかないんじゃないかね。
出来ればロールバック含めた作業手順を前日までにチェック済みにしとくのがいいけど。
当日の突発作業については「一人でやらない」を徹底するくらいしか手立てを思いつかないなぁ。
// バックアップとらずに「tar xvf /home/uneune/work/release/atarasiimono.tar -C /」ってやってしまって障害起こしてもうて
// マジでチビッた。ひさびさに「やってもうたー！！！！！」って叫んだ…
// 結局前任者のローカルから古いソースを適用して事なきを得たけど、それが出来なかったらと思うと… (:>^
意味不明 (スコア:1)
「こうならないように対処するのが当然なのだろうが、そのような対応策をとれない場合もあるだろう。こういうミスを防ぐためにはどうすればよいのだろうか？」
さっぱり何が言いたいのか分からない。
「こうならないように対処する」というのは「ミスを防ぐよう対処する」ということじゃないのか？
「そのような対応策をとれない場合」というのは「ミスを防ぐための当然の対応策が取れない場合」ということじゃないのか？
ミスを防ぐための当然の対応策が取れない場合に、どうやってミスを防ぐか、という話なら、「優秀な人間が慎重に作業を進める」とか「臨機応変に対応する」とか、中身のない話しかできないだろう。
バックアップとるだけではなくて (スコア:1)
バックアップから復元するテストまで定期的にやってる会社ってどのくらいあるんだろう。
バックアップとったつもりになってるだけだったら、笑えないぞ。
裁定 (スコア:1)
顛末の書き込みを読んだのだけれど、
結論から言うと、
・主任降格＆治療費支払い＆謝罪
・例の先輩が主任に昇格
・>>1はボーナスカット＆1週間の出勤停止
と相成りました。
とりあえず朝社長に呼ばれたので、主任とともに向かうと、「やらかしたのか」と一言。
詳しく事情を説明すると、「細かいことは分からんが、お前が間違えるくらいだからよほどだったのだろう」とのこと。
上の処分は情状酌量が入った模様。
DBについては、別のテーブルに似たようなデータがあったためそれを編集して流用。
あまり深いことは言えんが、データ流用ができたのもずさんな管理だったことが幸い？
普通は似たデータを複数箇所に置かんもんな
あと、今後はデータのバックアップおよび直にSQLを打つときは2人以上での確認などもろもろの運用事項が
加わりました。
オペミスでこういった直接的な罰則があるというのが結構驚きなのだけれど、そういうもの？
オペミスは作業者の責任を追及しない印象が頭の中にあったので。
# 内容がうそかほんとかはさておき
名は体を表す (スコア:1)
テーブルには
わかりやすく、簡潔かつテーブル構成が想像しやすい
命名をするよう心がけましょう。
そうするとこういうミスも減ります。
・・・いや、序盤は心がけててもクライアントとのやりとりを通して
テーブルがポコポコ増加すると
いつのまにか挫折してるんですよねえ（遠い目）。
Re:名は体を表す (スコア:1)
そういった所に限って、OSとDBで文字コードが違っていたり・・・・・
実際に合った怖い話 (スコア:1)
11/12/28 【重要】証券システム障害に関する重要なお知らせ [live-sec.co.jp]
そもそもだけど (スコア:0)
顧客DBのバックアップをとっていないという状況が考えられない。
個人のミスの前に会社的にどうなのよと。
Re:そもそもだけど (スコア:1)
本番環境のテーブルに対してtruncateかけるってのがよくわからん。ふつーそんなことする？
似たようなテーブルからデータを再作成って、つまりそのテーブルは不要だったかビューの類で良かったんじゃないの？
Re:そもそもだけど (スコア:1)
某社は昔、正規化はおろかindexでさえまともに設定していなかった。
そして、近年また一緒に仕事をしたが正規化を行き過ぎにしていて、
テーブル結合の半数近くが内部結合できず。
さらに事前に決定していた、結合は４テーブルまでという規約を軽く
超える事に・・・
※作成日時・ユーザ、更新日時・ユーザを必ず入れているので
データ量もその分無駄に消費
Re: (スコア:0)
「手作業で全削除してタイプミスしたらどうする？」と心配するのでは無くて、
「そういうミスが起こらない仕組みを作る」が基本だよな。定期バックアップも含めて。
定型業務らしいし、せめて前もって作ったスクリプトを実行するようにしていれば、テーブル名の
タイプミスでついうっかりというのは防げるだろうに。
＃つか普通は手作業でやるんじゃなくてcronで(ry
そういう点も含めて、やっぱり会社的にかなりアレだし、そういう所で働いている
人たちなので技術者的もそうとうにアレなんだろう。ほんの２～３年前にバージョン管理も
使わずにWeb開発やってて、開発サーバー上のが最新版ソースという会社も知ってるので、
このくらいは想像できるけどさ。
Re:そもそもだけど (スコア:3, おもしろおかしい)
> ＃つか普通は手作業でやるんじゃなくてcronで(ry
cronで実行すれば大丈夫なんて計画を立てるのは机上のcronです。
Re:そもそもだけど (スコア:2)
> 「手作業で全削除してタイプミスしたらどうする？」と心配するのでは無くて、
>「そういうミスが起こらない仕組みを作る」が基本だよな。定期バックアップも含めて。
「ミスが起こらない仕組みを作る」だけじゃなくて「ミスが起きてもリカバリーできる仕組みを作る」ってのも基本です。
てかtruncateするのに、直前にバックアップを取らないとか信じられないですね。
Re:そもそもだけど (スコア:1)
そもそもクローンを作る段階を cron で実行しろ、と言う事ですな (^w^)
# ごめん、それが言いたかっただけなんだ。
fjの教祖様
Re:そもそもだけど (スコア:1)
これはあるよなー。今の会社に来てびっくりした。何もかもめちゃめちゃで本来生ずるはずのない問題だらけなんだけど、みんなそれに最適化されててそのめちゃめちゃなのを運営できてる自分達が凄いとプライド持ってしまってるんだよね。無理が通れば道理がひっこむというか。
だからバックアップを取っておけとあれほど (スコア:0)
> バックアップを取っていないデータベースに対し
はい解散
Re:だからバックアップを取っておけとあれほど (スコア:3)
「データ消してしまったあー！」（悲鳴）
「あああああ慌てるな、ここここんなときのためにDATにバックアップが…久しぶりにみるけどDATでライトプロテクトするのどっちだったっけ…間に合う、まだ操業開始まで2時間ある、急げば間に合う…ええと、ええと…」
> exp system/Password file=/dev/tape ...
Re:だからバックアップを取っておけとあれほど (スコア:2)
あせるとimpと間違えて普段から良く実行しているexpを反射的に打っちゃいますよね。
ミスして空のデータを上書きしたことあるんで良く分かります。
自分の場合はバックアップのコピーを上書きしただけだったので大したことなかったですが。
Re:だからバックアップを取っておけとあれほど (スコア:2)
そもそも本番の重要なデータのバックアップにDDS (DAT) は使わない。
HIRATA Yasuyuki
Re:だからバックアップを取っておけとあれほど (スコア:1)
マーフィーの法則 ： 「バックアップをとってない時には必ずHDDがクラッシュする」
最近はクラッシュが珍しくなったので、人為的ミスにとってかわられたんですね、分かります。
タイプミス？資料ミス？その場でコマンド作った？ (スコア:0)
本番DBで危険な作業するときは事前にコマンド作成＆複数人でレビューが当たり前
そして打ち間違えないようにコピペ→ダブルチェック→Enter投下
さらに言うなら、可能な限り作業前にDB全体のバックアップも取っておく
そもそも1人（2人？）のイージーミスで重大な事故が起こるような仕組みがおかしい
リアリティなし (スコア:0)
> 非常にリアリティのある話
DBのバックアップとっていないなんてぜんぜんリアリティないです。
Re:リアリティなし (スコア:2, すばらしい洞察)
「こんな労働基準法違反の会社が存在するなんて話全然リアリティがないです」と言ってるのと同じ。
Re:リアリティなし（オフトピ） (スコア:0)
＞「こんな労働基準法違反の会社が存在するなんて話全然リアリティがないです」と言ってるのと同じ。
ですよねー。残業200時間超で10年勤務して手取り20万なんてあるわけないじゃないですかー
Re:リアリティなし (スコア:1)
「バックアップを取ってないこと」という今回の作業全体の話ではなく
「削除するテーブルと、削除すべきでないテーブルの名前が似ていたこと」についての感想でしょう。
切り分けをちゃんとしないと。
Re:リアリティなし (スコア:1)
Re: (スコア:0)
「間違ってハードディスクをフォーマットしてしまったらどうする？」
って堂々と聞かれても、そりゃもうリカバリ屋に頼むほかないだろう・・・・
としか言えない脱力感がありますよね
Re:リアリティなし (スコア:1)
そのままformatコマンド実行でCドライブを消し飛ばしてくれる所が希に・・・
テープから初期状態にリカバリ、formatコマンドをリネームしてbatファイルを
作成して、その中でAドライブをデフォルトでフォーマットするように仕掛けたなぁ
割と良くある話 (スコア:0)
ですよ。
技術者から見ると信じられないかもしれませんが。
最新パッチなにそれ？ ウイルス対策っているの？ 金の無駄じゃね？ って人たちにバックアップが必要って説得するのは骨が折れるというか、一度喰らわないと分かって貰えないというか。
Re:割と良くある話 (スコア:1)
なんどでも言おう。
サブジェクトを本文の一行目として使うな！
Re: (スコア:0)
truncate たたくにしたって先にｅｘｐｏｒｔとるだろ。
export xxxx
で
truncate xxxx
(xxxx)は貼り付け。
あるとしたら、
テスト環境につないでいるつもりでバックアップとらない（＜＝これもいかんのだが）で
実は本番環境につないでた。か？
Re: (スコア:0)
大きな変更時には作業前にバックアップが基本でしょうにねぇ・・・
事前に手順確認 (スコア:0)
保守/テスト環境上で、事前に手順が正しいことを確認しておく。
…って、バックアップを取っていないような体制で、そこまで環境を揃えるのは
無理かなぁ…
事故は必然 (スコア:0)
sqlを本番で直叩きするような運用は地雷原でフラダンスを踊っているようなものだし
クリティカルなことをする前にバックアップを取らないのは、保険をかけずにクルマを運転するようなものだから、事故は必然だったと思う。
起きるべくしておきた。
それでも、やらなければというならば、今回のように情報を別のテーブルやアプリログ、その他にもおとすようにしといてそこから頑張って復旧しかないよね。
そっちのほうが最終的に高くつくから、そうならないように設備投資をケチるなよ、みたいな。
これ自体ブラックじゃん (スコア:0)
そもそも、作業ミスに対してこういう懲罰っていいんだっけ?(請求がダメなんだっけ?)
# ちょっとググったらこんなん [goo.ne.jp]出てきた
おまけにスレでは
とかだし。
Re:これ自体ブラックじゃん (スコア:1)
本人とその会社よりも (スコア:0)
顧客の会社がそのあとどうなったかのほうが気になる。
データベースの内容によってダメージはピンキリだろうけど、
最悪、倒産して社長が首つるくらいのことはあるかもしれない。
Re:本人とその会社よりも (スコア:1)
そういえばつい最近、データが戻せずに運営中止になった
オンラインゲームがありましたね。
ここがバックアップとってたかどうかは不明ですが、
場合によってはこういうことも起こりうるってことを思えば、
やはり日頃のバックアップは大切ですね。
Re: (スコア:0)
> データが戻せずに運営中止になった
> オンラインゲームがありましたね。
そーゆーのって、最新ピリオドにおいては赤字状態になってて、
運営側が切り捨てるタイミングを見計らってた、なんて事が多いので、
データが消えた事によるダメージは無いどころか、
経営的には赤字を減らすポジティブな結果だったり…
Re:釣りでしょ。 (スコア:1)
＞m9（＾Д＾）プギャーってのが目に浮かぶ
最近のはもうそういう娯楽目的でやってるんじゃなくて、まとめサイトで使えるスレを作るために、お金で雇った作家みたいなのがビジネスライクにやってるらしいよ。
Re:逆に (スコア:1)
「友達の話なんだけどさ…」