2020年秋、ちょっと手術で入院してまして、その間の運用・保守は他人に引き継いだものの、大きな問い合わせはなく、クライアントも問い合わせを止めていたようでした。
で、職場復帰して数日後にサーバーのログからでないと調査が難しい案件を指示されたので、スクリプトを組んで調査しようと思ったのです。
どんなコードを書いたのか
もう覚えてないのですが、以下のような感じのコードです。
# !/bin/sh
cd $(dirname $0)
TMP_DIR="tmp"
rm -rf ${tmp}/*
# do something
意図としては、tmpディレクトリを作って、中間作業ファイルをそこに入れて、結合やgrepやAWKして、最終的な結果を出力するという私的には鉄板のやり方でした。
でもおかしくないですか。5行目が。
tmpなんて変数は定義していない。TMP_DIR変数と間違えていたみたいです。
結果、rm -rf /*という終末のラッパのようなコマンドが走っていました。
異変に気づく
スクリプト実行後やけに時間がかかるのと、想定外にPermission deniedが多いなと思って、スクリプトをキャンセルしてlsしてみるとカレントディレクトリのファイルが無くなっている。。。
スクリプトファイルはローカルマシンで組んでいたので、見返してみると、「あっ・・・」って感じでした。
焦ってはいけない
まずいところはいくつかあるのですが、まずこれを実行したのが、本番サーバーのうちの1台だったのです。（同じような構成のサーバーが数十台以上あります）
SSHクライアントとWinSCPでSSH接続は維持している状態でした。
焦ってはいけない。
まずは他のサーバーの同じユーザーから.sshディレクトリを持ってきて、パーミッションを設定。新規にSSHできるように復旧しました。
リモートできなくっては元も子もありません。
ウェブ系を始めとするアプリケーションファイルは/var以下に設置していたので、アルファベット順的に最後の方なので、被害は免れているみたいでした。
念の為、再同期、再デプロイしておきましたが。
また実行したのはrootユーザーでもなく、sudoしていたわけでもなかったので、被害はログインユーザーのホームディレクトリだけとなっていました。
報告と謝罪
新規SSHができるところまで確認したらとにかく報告と謝罪です。
共有アカウントだったので、調査用に仕込んでいたログが消失していたのだとか。
それ以外のスクリプトなり何なりは他のサーバーから復旧できるということでした。
サービス上実害がなかったこともあり、私が打たれ弱いのを知ってか、お咎めはなく、「まぁ誰でもやることだから」と始末だけして、許してもらえました。
アプリケーションが止まったわけでもないので、クライアントへの報告もなし。内々で処理しました。
ただ、調査用に設置していたスクリプトは復旧できてもログやその他ファイルは復旧できない。
社内には平謝りです。
反省点
色々反省点はあります。
- なぜ本番で実行してしまったのか。
- ログファイルは大体本番にしかない。
- やっていたログ調査自体がトライ・アンド・エラー的な要素を持っていた。
- ログファイル自体が巨大で、ファイル転送に時間がかかるし、本番サーバーのパワー有り余ってるし。（ちょっとした言い訳）
- みんなも本番でやっていることだし、今までも大丈夫だったし。。。（正常性バイアスみたいな？）
- 意図しないコードを実行させない工夫をしなかったのか
- いっぱいコードを書いてきましたけど、独学ゆえ知らなかっただけです。。。
最後に
これからも本番でしていまうでしょう。
気をつけたいと思います。
みなさんもお気をつけください。