データベースを誤って初期化した人の結末 81
ストーリー by reo
非実在ドジっ娘 部門より
非実在ドジっ娘 部門より
ある Anonymous Coward 曰く、
「大事なデータベースをうっかり削除してしまった」という話はたまに聞く話だが、米国のスタートアップで働いていた若いエンジニアが実際にデータベースを削除してしまったときの顛末が「How I Fired Myself (どうやって自分は仕事を辞職したか)」というブログ記事でまとめられている (日本語訳) 。
そもそも運用系の DB に直接開発者が触れるようになっているのがやばいという話ではあるが、皆様もご注意ください。
体制の方にも問題あるような……？ (スコア:5, すばらしい洞察)
管理者の削除一発でこんな大問題になるなら、
システムトラブルでデータ飛んでもやっぱり致命的な問題になっちゃうんじゃ？
他のテーブルのデータを元にしてUSERSテーブルの上辺を繕おうとする、とかじゃなくて、
バックアップから少し前のデータ復旧して、差分はログから復旧、とか、
そういったプロセスになるべきなんじゃないのか……？
いやむしろ体制の問題では？ (スコア:5, すばらしい洞察)
開発者にはミスはあったが罪は無いかと。
バックアップ無し、本番DBで開発、チェック体制無し
とか起こるべくして起きたとしか…
Re:いやむしろ体制の問題では？ (スコア:1)
>開発者にはミスはあったが罪は無いかと。
だよねえ、本番DBで開発することに疑問を持たないレベルの開発者にDB弄らせるほうが間違い。
むしろこの人かわいそうですよ。
##DBバックアップどころかシステム丸ごとバックアップが好き。
Re: (スコア:0)
遊びでやってんじゃねえんだぞとか言っちゃう人に多いような気がする(ソースなし)けど、発生状況を見るとふざけて遊びで開発運用してるとしか思えない
事故った時も下っ端に押し付けて再発防止とか全く考えてる節がないし、収益を求める姿勢が見えない
甘え
Re:体制の方にも問題あるような……？ (スコア:2, 興味深い)
> MySQLのインスタンスのバックアップは2ヶ月以上前にキャンセルされている
と記事にあります。
バックアップがあれば、最悪でも１日の巻き戻しですんだはず。
責任はバックアップを怠った管理者にあるはずで、
削除した馬鹿者を責めても、解決にはなりませんよね。
何かをやらかす予備軍な人は大勢いて (スコア:5, 興味深い)
ちなみにうちの職場ではこういう伝説が残ってました。
全員がrootを使用している環境で/etcに*という名前のファイルができてしまった。
それを削除しようとして/etcでrm *を実行した人がいて、大変なことになった。
Re:何かをやらかす予備軍な人は大勢いて (スコア:2, 興味深い)
かつて勤めていた会社にて私が入社前の話。
rootでログイン、何か作業中にカレントディレクトリを勘違いしていてルートディレクトリでrm *をやっちゃった人がいたとかgkbr
Re:何かをやらかす予備軍な人は大勢いて (スコア:2, すばらしい洞察)
そこから学ぶ事柄で２種類の人に分かれます。
・rm使う時は気をつけよう、特にrootでシステムファイル以下をいじる時には。
・全員rootである必要性を検討し、再発しない運用ルールにしよう。
その積み重ねで差が生まれてくる。
Re: (スコア:0)
「気をつけよう」じゃなくて、「ミスっても復旧する方法を最初に作ろう」じゃないんですかね。
Re:何かをやらかす予備軍な人は大勢いて (スコア:1)
「気をつけよう」とか心構えの問題で片付けてしまうのか、
実際のルール作りまでするかの違いを言っているんじゃない？
前者は1週間もすれば、忘れてまた繰り返す。
Re: (スコア:0)
それは「再発しない運用ルール」に入れて良いのでは。
元コメの2パターンは、オペレータ型思考と、システム管理者型思考の事で、オペレータ目線でしか考えられない人は、
ずっとオペレータのままという皮肉なのではないでしょうか。
ところで、バックアップはシステム側の問題で、今回のDBの件では、彼のせいでバックアップから復帰出来なかった訳では無いのですよね。
作業ミスの影響でダウンしたのは彼の責任なのですが。全責任を背負わされるのは納得いかないですね。
Re:何かをやらかす予備軍な人は大勢いて (スコア:1)
rm -R ./* と rm -R /* とかな…。
//以外にも ミスりがちなので trashコマンド使うようにすると ちょっぴり安心かも。
見習いrootのHUP (スコア:1)
kill - 1 67921
余計な空白一つでサーバが脳死状態に…。既にディスクに書かれているデータが消えるわけではないけども。
Re:見習いrootのHUP (スコア:3, 参考になる)
そういうことがありうるからKILLでシグナルを送るときには数字で書くな文字列で書け
って師匠に教わったぜ
実際その時アイドル中だったワークステーションで実演してくれたから強く心に残ってる
Re:見習いrootのHUP (スコア:1)
やらかして以降は文字列で書いてたけどね。事前の指導は特になかったな。事故後には言われたけどw
Re: (スコア:0)
そこで間違えて \* ですよ
Re:何かをやらかす予備軍な人は大勢いて (スコア:1)
rm 系ではないけど、某商用UNIX の /usr 以下を全部 Linux の /usr に置き換えた人はいました。
なんでも家で作ってきた自分のプログラムをそのまま使いたかったとのことで。
コマンドほとんど使えなくなったのでシステムバックアップ戻しました。
～パタポン教徒～
Re: (スコア:0)
普通にやってしまいそうで怖いミス
某大手サービスの場合 (スコア:4, 興味深い)
技術者３００人体制のとあるウェブサービスでは、本番データベースに直接さわれるのはデータベース アドミニストレーターの５人だけでした。
極端に少ない開発体制の場合は開発者が直接さわるのは当然だけど、しつこくバックアップしないとダメだなと。
自分なんかは本番データベースのテーブルいじるたびに毎回バックアップ取ってました。
Re:某大手サービスの場合 (スコア:1)
それで『スキルの高い人に任せれば失敗しない』という考えで運用したのがファーストサーバ…
JCOM事件 (スコア:4, 興味深い)
JCOM事件の現場にいた人の話を聞いたことがあります。
フロア中が板にくぎ付けになって、まさかこれうちじゃねーよな、
みたいな軽口が飛び交ってる中で、おずおずと手を挙げて
自分がやったと申し出たそうです。
その人も結局居づらくなったか、しばらくして退社したとか。
自分はそういう地雷を踏まないように気を付けよう。
# 自分が地雷を撤去しようとは思わない。
思えば懐かしいあの日・・・ (スコア:2)
DBサーバは大事だからとRAID1（だったと思う）で組んでいた。
その日、彼女はDBサーバにあるハードディスクのシリアルIDを調べていた。
そう、やってしまったのだ・・・。
アクティブのハードディスクを引き抜き、シリアルIDをチェック。
そして、サブのハードディスクを引き抜き、シリアルIDをチェック。
ええ、その日はとてもとても大変な一日だったそうな。
既に十年以上前の話なので一日で復旧できるデータ量だったけど、
今やったら・・・・・
＃あの頃はまだ元気だったな、僕・・・
Re: (スコア:0)
なんて萌えるシチュエーション。
天然ドジっ子ですねわかります。
Re:思えば懐かしいあの日・・・ (スコア:3)
＞なんて萌えるシチュエーション。
＞天然ドジっ子ですねわかります。
あははは。
しかもその後、
その人とデータベース管理者が付き合って結婚までしてたら、
まさにゲームみたいな感じですねｗ
・・・実際にそうなりました（ホント）
＃特定されるのがイヤで言わなかったけど、事実は小説より奇なりｗ
Re:思えば懐かしいあの日・・・ (スコア:2)
＞あ、それとも抜いてさして、リビルド中にさらに抜き差ししたってことだろうか？
おお！大正解です！
後で聞いた話だと、リビルド中にどっちかを抜いたらしいです。
Re:思えば懐かしいあの日・・・ (スコア:2)
＞RAIDのコンソールツールから見るだろ。
＞普通、いや絶対。
＞HDD抜いて調べるなんて有りえない。
ふふふ。
普段自分のPCしか触らないような人に、
そんな常識があると思いまして？
はっきり言いましょう。そんなものはない！
＃僕が作った社内ツールを使ってるのを見たときゃ、
＃「そんな使い方してんのか！」ってリアルでビビった。素人は怖いよｗ。
Re:思えば懐かしいあの日・・・ (スコア:2)
＞そんな人間がサーバに物理アクセス可能な会社なんてこの世から消えて無くなれば良いと思うよ。
世の中には、「ベンチャー企業」というものもありましてですね（苦笑）。
何でもかんでも、自分の思い通りになるものではないんですよ。
逆に、アナタは絶対に失敗しない人なんですか？
そうじゃないでしょ？
失敗しない人間なんていないんですよ。大なり小なりはあるけれど。
それをお互いに補っていくのが、「組織」なんじゃないかなぁって僕は思います。
Re:思えば懐かしいあの日・・・ (スコア:2)
＞その彼女の失敗談で一番反省をするべきなのは、素人の彼女じゃなくて、素人に作業をさせた組織でしょ。
ふむ・・・・。
＞全員技術知識がない組織ならともかく、リビルト無視してRAIDのHDDを抜くと障害が発生するという技術知識がある人間が組織内にいたのなら、その知識を生かして先のその彼女の行為に待ったをかけられなかった組織の問題と認識すべき。
なるほど。その視点はありませんでした。
＞なのに、なぜそこで「失敗しない人間なんていない」なんて、人間を庇う言葉が出てくるの？
＞なぜ「そんな人間」が責められていると思った？
＞もしかして「そんな人間」が組織よりも責められるべきだと無意識に考えていないか？
ん～、僕は「ミスは誰にでもある」って事を言いたかったのです。
なので、逆に「そんな人間を責めてはいけない」と思っています。
ただ、「組織」単位では、上記通り考えてませんでした。
＞このストーリーへのコメントとして他人の失敗を笑い話にして書いている時点で小さな違和感があったけど、もしその失敗談を「彼女の知識の問題」と捉えているのなら、このストーリーへのコメントを読み直すべき。
なるほど。ありがとうございます。
僕の中に「ベンチャーだから」という甘えがあった気がします。
キチンと読んで、考えなおしたいと思います。
貴重なコメント、ありがとうございます。
Re:思えば懐かしいあの日・・・ (スコア:2)
＞これ書いた者ですが、運用管理系で大小様々な会社行ったので、属人的システムがコストに見合う状況は
＞なんとなく分かりますが、ベンチャー全てがそうじゃないですよ。
そうですね。確かにキチンとした会社なら、ベンチャーでも問題ないですもんね。
＞もし、その女性がシステム担当以外なら、そもそもそれはミスでは無いです。
システム担当以外の女性でした。
ただ、部署は同じで、事務的な事を手伝ってくれていた人でした。
＞事故を防ぐ措置も講じず、それを彼女のミスだと認定するような会社は、この世から無くなれば良いなと思った次第です。
なるほど。確かにその通りです。
僕の勘違いでした。申し訳ありませんでした。
＃冷静に考えたら、僕の精神的障害も・・・
＃でも今更考えても遅いか・・・
Re:思えば懐かしいあの日・・・ (スコア:2)
＞容量を増やすかなんかの話になったとき、ホットスワップ対応のRAIDユニットでHDDを全部同時に引き抜いた作業員が…
＞ホットスワップだから大丈夫だと思っていたらしい。
ホットスワップだろうがなんだろうが、全部HDD抜かれたら終了ですよね。
ご愁傷様でした・・・。
覚えたての頃は今では考えられない事を平気でやる (スコア:2)
ことってあるよね。
かくいう私も覚えたてのころに、アレコレありました。
幸い運よく（？）大事に至っていないというだけではあるけど。
# ある程度いくと何が良くて何が悪いというのはわかってくるけど
# 無知ゆえに考えられないことを平気でしたりすることががあるかな～
Re: (スコア:0)
慣れてきた時のほうが起きやすいですよ。
だんだん慣れてくるんです。組織が。
「バックアップメディア足りない？じゃあバックアップ回数減らすか」
「緊急でシステムを他に使いたい？じゃあバックアップ用のマシン貸すから」
・
・
「メインマシンダウン？バックアップがあるだろ。ない？何でだよ。じゃあレストア、なに半年前のバックアップしか無いだと？」
Re:覚えたての頃は今では考えられない事を平気でやる (スコア:2)
たしかにそういう面はありますね～。
自分の都合ではなく組織側の都合としておざなりになっていくというやつですね。
Re: (スコア:0)
原発・・・・。
Re:覚えたての頃は今では考えられない事を平気でやる (スコア:2)
Re: (スコア:0)
『一旦全部止める』に対応する手段はありません。
俺もやった (スコア:2, 興味深い)
しかもお客さんのところで全ユーザーテーブルをドロップしちまった!
バックアップちゃんと動いてなくて、復旧したのは7日前まで、そのあとは紙の帳票をせっせと電子化しました。
そのとき感じたのは普段中がよくない人でも、ピンチのときは助けてくれる。
お客さんのものだからというのもあるけど10人くらい来てくれてせっせと紙の帳票を電子化してくれました。
そして私はバックアップにとてもこだわるようになりました。
やっちゃう心理 (スコア:1)
やらかした後に、うん、この手順だとこの結末になる可能性は予想してしかるべきだったよね、と反省する。
# 仕事では必要以上と思える細かい手順を遵守してるからやらかしたことはないけど、その鬱憤を自宅サーバで晴らしてるのかな・・・
ミスが起こったときのフォローが大事 (スコア:0)
ミスは誰にでも期せずしておこるもの。DBを操作する人を制限していてもその人がミスらないとは限らない。
ミスは起こるものと考え起きた時になるべく早く復旧できる体制を整えるのが大切です。連絡体制しかりバックアップしかり。
日本でのケース (スコア:0)
30分前に顧客DB消しちゃったけど質問ある？
でぐぐればでてくるので、お好きな纏めサイトでどうぞ。
Re: (スコア:0)
30分前だったらまだ後始末の仕事が残ってるだろ。
スレたててる場合か?
Re: (スコア:0)
まとめサイトまで行かなくても、スラドでストーリーになってる。
・間違ってデータベースを削除してしまったらどうする？
http://askslashdot.srad.jp/story/12/03/08/028231/ [srad.jp]
Re: (スコア:0)
ちょうど一年前か…。
Re:日本でのケース (スコア:1)
なんでもないようなことが幸せだったと思う
サーバのデータを抹消した事にして (スコア:0)
また新しく課金してくださいね（ﾃﾍｯ
ってことですか？
Re: (スコア:0)
誰が誰に何を課すの？
逃亡先 (スコア:0)
>I left town the next day, headed ultimately for New York City.
やらかした奴が反対海岸を目指して旅立つのはもう様式美よね
東海岸でやらかしたら西海岸へ
西海岸でやらかしたら東海岸へ
rm a.out* (スコア:0)
イマドキのlsはファイル属性をカラフルな色違いで表示してくれるが、
20年ほど昔の白黒コンソールでは、色の違いは分からない。
じゃあどうだったかっていうと、lsで並ぶファイルの末尾に*が付くことで
そのファイルが実行ファイルだってことを教えてくれていたんだ。
その彼は、いろいろと条件を変えてコンパイルしては数値実験を行なっていた。
律儀な彼は、コンパイルしたファイルの末尾に、順番に番号を付けて保存して
いたんだ、そう、a.out1、a.out2、a.out3、... てな具合に
あるとき、間違えて作っちゃった実行形式を、彼は消そうとしたんだよ。
もう分かるよね。rm a.out* ってやったんだ。
数分後、悲しみにくれた目をして研究室から出てきた彼の表情は今でも忘れられない。
（これは実際にあった出来事です）
Re: (スコア:0)
>ls
a.out*
a.out1*
>rm a.out*
>ls
こういうことかな？
給与相当の仕事 (スコア:0)
これだけ重要で神経を使うべき仕事なら給与は年数千万円払うべき。
年数百万円の給与ならすべての責任を負わせるべきではない。
会社の存続に関わる仕事なら社長並みの給与であるべきだ。
つまりこの場合はドンマイで済ませるべきである。
これでクビにする社長は自分が社員に課している仕事の難易度を評価し直して給与を見直しなさい。