見出し画像

オジサン事件簿~UNIXサーバで「#rm *」やっちゃった事件のフォロー~

こんにちは!広報チームの遠藤です。
今回はエンジニア向け(と、言いつつ皆様に見ていただきたい)ブログを
お届けします💡

ブログの記事を書いてくださったのは、
エンジニア歴25年のNさんです🖥
普段はインフラ構築をメインにやられていますが、運用や保守の経験もある
ベテランエンジニアさん✨です!

そんなNさんが、社内で起こった事件を解決に導いた経験談と
IT業界ではお馴染みの『なぜなぜ分析』についても
お話ししてくださいました!

『オジサン事件簿~UNIXサーバで「#rm *」やっちゃった事件のフォロー~』


以上の内容でお届けしますので、是非お楽しみください😊


数年前(確か4年前の2019年)の話になります。

たまたま別件打ち合わせで帰社した際に周辺がざわざわしていて、
何があったんだろう?と思いながら聞き耳を立てていたところ

「客先のUNIXサーバで障害を引き起こしたので助けてほしい」という
SOSを受けました。

ワタクシ、インフラエンジニア歴25年のおじさん(ベテラン?)エンジニア
なのですが

UNIX=今は全然聞かなくなってしまった「Solaris」という事もあり
諸々調整の上フォローを実施する事と相成りました。


内心ドキドキしながら翌日フォローへ向かったのですが、いろいろと衝撃を受けました。。。その際の教訓を残すべく、今回初めて筆を執った次第です。


1.事件内容

端的に言うと、タイトル通りでお客様環境の開発用(本番ではない)サーバで

「rm *」を誤って実行してしまったという内容でした。


(ちょっと脱線)

Solaris含むUNIXサーバで「rm *」を実行すると
OSが問答無用で破壊されてしまいます。

興味のある方はこのあたりの記事をご覧頂ければと思います。

(Solarisについてではありませんが、壊れゆくのは変わらないので。
もし試す場合は全く影響のない環境での自己責任でお願いしますm(__)m)


Amazon Linux 2 で「rm -rf /*」を実行してみた | DevelopersIO (classmethod.jp)


2.事象ヒアリング

上記事象について、作業を担当したメンバーにヒアリングしてみました。

少々技術的な話になってしまうのですが、実際にやりたかったコマンドを
誤ってしまったのが事実との事。。。


【やりたかった事】
作業用ディレクトリ配下のファイル一括削除


≪やりたかったコマンド≫

#cd (作業用ディレクトリパス)

#rm ./*


≪やってしまったコマンド≫

#cd (作業用ディレクトリパス)

#rm *
「./」を付け忘れてしまったというものです。


3.ちょっと深堀(なぜなぜ分析編)

問題が発生した際には

『なぜなぜ分析』という手法(「なぜ」を掘り下げ)で
真因を見つける事が多いです。

詳細についてはこのあたりの記事が参考になるかと思いますが、
今回も実施しました。


図解「なぜなぜ分析」の8つのポイント|事例や例題つきで解説 (biz-skill.com)



当時の記憶がだいぶ欠落してしまったのですが、結果はこのような感じでした。

事象:「rm *」を実行してしまった。


【なぜ1】

・単独作業だった為、作業時のコマンド誤りに気付けなかった

・ファイル削除時に「-i」オプションが付与されてなかった

・作業手順のレビューが実施できていなかった


【なぜ2】

・プロジェクト体制として複数人で作業できる形になっていなかった

※もう少し分析結果があったような記憶があるのですが欠落してしまいました。。。


4.復旧対応について

今回実行してしまった「rm *」ですが、
短時間で気付き「Ctrl+C」で処理を止めていたのが功を奏して
完全に業務処理に必要なファイルが消えずに済んでいました。
それを受けて以下の流れで対応し、復旧に漕ぎ付けることに成功しました。


・tarコマンドで生きているファイルをひたすらバックアップ取得

・OS初期インストール、ミドルウェアインストール・セットアップ

・バックアップからのファイル戻し

→必要なファイル権限含めてバックアップ出来ていたのでダメージは最小限


5.教訓

今回得られたものは大きく以下であったと考えます。

・作業手順書の品質向上

・バックアップ取得の重要性

前者については昔の話になりますが、

「幼稚園児が実施しても同じ結果が得られる」作業手順書の品質向上を
目指すという事を聞いたことがあります。
なかなかコストパフォーマンスを考えると実現は難しいのですが、
決して誤っているものでは無いので可能な限り目標としては
意識付ける必要があるかと思った次第です。

後者についてはこれも環境・コスト等を考慮すると
難しい部分もあるかもしれませんが、
何事においても「耐障害性」を意識するのは重要なので
これも改めて意識付けが必要かなと考えます。

※今回の事象発生時に取得できていたバックアップで
対応のスピード感も劇的に上がりましたので。。。


いかがでしたか?😊
事件を起こさないことが一番ですが、起こしてしまった時に
『なぜなぜ分析』を行って、同じ過ちを繰り返さないことが大切だと
気づかされました!
また、「幼稚園児が実施しても同じ結果が得られる」作業手順書
という言葉が印象的で、
誰にでも伝わる手順書は事件を起こさないためだけでなく、
普段からの手順書作成にあたっても大事な意識だと思いました。


当ブログでは他にもエンジニア体験談などをご紹介しておりますので、
是非ご覧くださいね!
エグゼクションには個性豊かなメンバーが揃っていて、
楽しい場所です🍀
ブログにてその雰囲気を少しでも感じていただけるよう、
これからも発信していけたらと考えておりますので、お楽しみに!



エグゼクションでは一緒に働く仲間を募集してます!

IT業界未経験でも経験者でも、だれにでも活躍の場があるのが
エグゼクションです!
少しでも興味を持ってくださった方は、下記まで🤩

👆クリック