
「rm -rf」コマンドでエンジニア人生がバルスしました
「rm -rf」は絶対やるな
「rm -rf」は確認なしでディレクトリを全て消してしまうLinuxコマンドで、消したら二度と復旧できない
データを消す時はコマンドではなくFTPソフトなどを使って目視で消すべし
通称「バルスコマンド」と呼ばれているから死にたくなかったら使うな!
「linux 削除 コマンド」と検索し、このページにたどり着いたそこのエンジニアさん。
あなたは大変運がいい。
なぜなら僕のようにエンジニア人生を終わらせなくて済むからだ…
「rm -rf」コマンドでSE人生がバルスした男


僕は新卒未経験から3年2か月ほどSEとして働いていました。
最初の現場はJavaが中心で、その現場に2年ほど常駐した後、Linux系の現場へ異動になりました。
最初の現場ではLinuxはちょろっと触った程度で、基本的に別チームの管轄だったのでLinuxを使って開発をすることはありませんでした。
しかし次の現場は、ディレクトリ作成からミドルウェアの稼働確認まで、ガッツリインフラ系の開発を担当するチームに配属されるのでした。
しかも、なぜかLinux経験者だと思われており、
「え、Linuxで開発してたって伝えちゃったよ!?」
と上長に言われたのは今でも忘れられない。
今思えば、面談時に
「既存システムを他システムに移行する案件やってました」
と言ったのがまずかったのかもしれない。
配属されたチームは「既存環境を他環境に移行するためのインフラ整備」をやっていたのだ。
実際にやっていたのはJavaのリファクタリング(動作を変えずにコードだけ変える)で、インフラ系は他システムの担当がやっていた。
とはいえ、僕も新しい現場で心機一転頑張りたいという思いもあったので、Linuxコマンドを自習したり、ちゃんと調べながら開発したりと、あらゆる困難をググり抜けてきました。


「rm -rf」 とは?
冒頭にでっかく書きましたが、
確認なしでディレクトリやらファイルやらを問答無用で消すLinuxのコマンドです。
Linuxはコマンドの組み合わせで成り立っているのですが、
「rm」→削除(remove)
「r」→ディレクトリ内を再帰的に選択
「f」→警告を表示しない
という意味を持っています。
つまり、ディレクトリ内に消したらマズいファイルがあっても確認することなく消してしまえるコマンドなんです。
これをroot権限のある強ポジアカウントでやった日には…
最悪の場合、テスト環境をぶっ壊してまともに開発できない状況にも陥ります。
なので、現場によっては削除コマンドを使う際に申請が必要だったり、経験年数の深いベテランだけがやったりするようです。


なぜ「rm -rf」コマンドを使用したか
僕も何となく使ったわけではないんですよ。
ちゃんと「rm -rf」コマンドの意味と危険性を理解した上で使ったんですよ。


ディレクトリ自動作成ツールを作っていた
僕が担当していた案件は、上述したように既存環境を他環境に移行するためのインフラ整備でした。
守秘義務もあるので具体的には言えませんが、ざっくり言うと、既存システムと同じディレクトリ構成のまま他システムのテスト環境を作ったり、ミドルウェアが正常に動作するかをテストしたりするお仕事でした。



他環境はいくつもあったので、いちいちコマンド打つのは面倒くさい。
そこで、自動でディレクトリ作成できるツールを作っちゃおうとなりました。
たしかにそっちの方が効率いいですし、一度ちゃんと作ってしまえば動作確認も担保取りやすくなります。
そこで、そのツールを作る担当が僕になったのです。
このあと迫る悲劇にも気づかず…
こんなファイル構成

基本的に変数ファイルだけを編集し、実行バッチをクリックするとディレクトリ作成ファイルの変数が変換されて勝手にディレクトリが作られ、ファイルが置かれるという仕様です。
図解すると簡単そうですが、Linux初心者の僕は必死に調べ、毎日残業し、5日間くらいかけて作成しました。
そして悲劇は起こる
いざ完成して上長に報告。

ディレクトリ作成ファイルの権限部分を修正し、次はディレクトリを消すことに。
そこで僕はひらめいた。
ディレクトリ作成コマンドを削除コマンドに変えてバッチ実行すれば確実に消せるんじゃね?
自動でやるなら確認もいらないよね、ということで「rm -rf」コマンドを使うことに。

消しすぎた原因
原因はディレクトリ作成ファイルにありました。
この現場のサーバはこんな感じの構成をしていました。(イメージ)
home
∟hoge
∟fuga
∟IT
∟ITA
∟ITB
∟ST
・・・
「fuga」配下にそれぞれのテスト環境がある構成です。
今回動作確認でやったのは、「IT」のディレクトリに「ITC」の環境を作ること。
そして、ディレクトリ作成コマンドの最初の2行はこう書いてあった。
cd home/hoge/fuga
mkdir IT
つまり、
「『fuga』配下に移動して『IT』ディレクトリを作れ」
と書いているんですね。
「fuga」配下にもディレクトリが作れるように設計したんです。
僕は「mkdir」を「rm -rf」に全置換したので、もちろん「mkdir IT」は「rm -rf IT」に。
cd home/hoge/fuga
rm -rf IT
「『fuga』配下に移動して『IT』ディレクトリを消せ、確認はいらないよ」 と変換されたコマンドに気付かず実行し、コマンドプロンプトに出てきたログを見て絶望するのであった…

その後…
顔面蒼白の上長と冷や汗が止まらない僕。
異変に気付いた近くのメンバーが声をかけ、何とか復旧できないかと試みるのであった。
上長は、誤ってテスト環境を消したことの謝罪メールを関係各所に送り影響調査、近くのメンバーは復旧に何が必要かを調べ、配属2か月目の僕は復元コマンドがないか必死に調べるのでした。
結局帰ったのは23時過ぎ、しかも週末4連休の金曜日…
連休明けの火曜日、会社の部長とリーダーに呼ばれ、なぜ起きたか、コマンドの意味を知っていたか、対策はどうするのかを話し合いました。
僕はコマンドの意味を知った上で実行したので弁解の余地はなく、ただただ泣きそうになりながら謝罪と反省。
復旧の工数はどうするだの、どうやって復旧するだの、完全に余計な作業を増やしてしまった僕。
「あまり気を落としすぎないで」と言ってくれた上長。
でもあなたが一番残業してますよね。
「君のせいにしたくもないし、だれが犯人ってわけでもない」と言ってくれた副リーダー。
それでも僕がやりました。
「テスト環境ゴミだらけだったからいい機会だったかもしれん」と言ってくれたリーダー。
でもゴミ以外も消しましたよ。
結局1週間ほどでなんとか復旧はできたのですが、主に復旧していたのは同じ現場にいた有識者レベルの同期。
現場に必要な存在になりつつある同期と、同じ経験年数を積んでるはずなのに大事故を起こすポンコツ。
僕が考えた再発防止策は
「これ以上の被害が出ないようにSEを辞めること」
でした。
最後に
バルスコマンドはテスト環境を破壊しただけでなく、僕のエンジニア人生をも終わらせるものでした。
さしずめ世界征服を企んだムスカ大佐の末路のように、エンジニア人生という名のラピュタがバルスによって崩壊したのでした…
僕の失敗談を反面教師に、絶対バルスコマンドは使わないように。
僕が調べた限り、一度消したら復元できないからな!


※この記事は2021年11月にワードプレスにて公開していた記事の移植です。
ブログ自体は閉鎖したのですが、若きSEがバルスコマンドでSE人生をバルスしないよう警鐘を鳴らし続けるためだけにこのnoteに残しました。