プロローグ

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

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

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

ワタクシ、インフラエンジニア歴25年のおじさん(ベテラン？)エンジニア
なのですがUNIX=今は全然聞かなくなってしまった「Solaris」という事もあり諸々調整の上フォローを実施する事と相成りました。

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

事件内容

端的に言うと、タイトル通りでお客様環境の開発用(本番ではない)サーバで「rm *」というコマンドを誤って実行してしまったという内容でした。

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

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

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

事象ヒアリング

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

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

本来やりたかった事
作業用ディレクトリ配下のファイル一括削除
本来実行すべきコマンド
#cd (作業用ディレクトリパス)
#rm ./*
やってしまったコマンド
#cd (作業用ディレクトリパス)
#rm *
※「./」を付け忘れてしまっています。

ちょっと深堀（なぜなぜ分析）

問題が発生した際には

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

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

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

事象
「rm *」を実行してしまった。
なぜ１
　・単独作業だった為、作業時のコマンド誤りに気付けなかった
　・ファイル削除時に「-i」オプションが付与されてなかった
　・作業手順のレビューが実施できていなかった
なぜ２
　・プロジェクト体制として複数人で作業できる形になっていなかった
　※もう少し分析結果があったような記憶があるのですが失念してしまいました。。。

復旧対応について

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

tarコマンドで生きているファイルをひたすらバックアップ取得
OS初期インストール、ミドルウェアインストール・セットアップ
バックアップからのファイル戻し
→必要なファイル権限含めてバックアップ出来ていたのでダメージは最小限

エピローグ（教訓）

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

作業手順書の品質向上
バックアップ取得の重要性

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

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

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