環境

• EC2 (Amazon Linux)
• Apache
• php7.1

私がやってしまったこと

この事件が起きたのは2020年6月。既に稼働しているWebサービスでとあるデータ取得の処理が止まってしまっているので調査してほしいと頼まれました。また、サービスに影響が出るものだからなるべく早めに対処してほしいと言われました。

マネージャー 「今日の夕方までにはお願いね。もし難しそうだったら午後イチで一旦MTGしよう。14時までに連絡をください。」

わたし　「任せてください！」

・・・・ とは言ったものの、本番サーバーで起きている障害の調査は今までやったことがありませんでした(もちろん本番サーバーにログインしたこともない)し、進め方も全く思いつきませんでした。しかも、対応するサービスの開発には携わったことがなく、sshログインの設定から行う次第でした。

まあ、今まで頼まれたタスクを期限内に終えられなかったことないし大丈夫！という謎の自信で本番環境に対する緊張感も持たず乗り切りろうとしていました。そして、

わたし　「とりあえずログインできた！まずログを見たいな〜ええと、あれ、なんか警告出てるな。sudo yum update か。よし、やっておこう。」

この時自分が何をしたのかわかっていませんでした。

調査は結局先輩に手伝っていただくことにはなりましたが、なんとかデータ取得も再開され無事にタスクを終えたと思っていました。

翌日

先輩 「すみません、どなたか昨日sudo yum updateというコマンド叩きましたか？パッケージのアップデートによって動かなくなってしまった処理があり、エラーが多発してます。。。。」

この時、ようやく自分がしたことの重大さに気がつき、血の気が引いていくのがわかりました。ああ、めちゃくちゃ怒られる、どうしよう、と思いました。
しかし、私が思っていたように怒る人は誰もおらず、どうしたらこういう事故が起こらなくなるか一緒に考えようと言ってくれました。この時心から安心して、気持ちもだいぶ楽になったことをよく覚えています。

実際動かなくなってしまったのは、curlコマンドを使う処理(Guzzle使ったAPI系もろもろの処理)で、原因としてはcurlのバージョンが上がったことでSSLの中間証明書がうまく働かなくなってしまったためでした。こちらの問題も先輩が対応してくださり、そこまで大ごとにはなりませんでした。

惨劇はなぜ起こってしまったのか

私がやってしまったこと、の中の太字部分が原因だと考えています。

• 本番サーバーにログインしたこともないのに緊張感を持たずに作業してしまった
• 慣れないことなのに期限が短く焦っていた
• できなかったことがないせいか、謎に自信だけあった
• できなかったことがないせいか、謎にプレッシャーを感じていた
• プロジェクトに参加していたわけではないので、わからないことを誰に聞けば良いのかわからなかった。長期プロジェクトで、自分以外の人は割と親密だったことも聞きにくかった原因

二度と惨劇を起こさないためにどうしたのか

自分がどうしたのか と プロジェクトとしてどうしたのか に分けて書きます。

自分がどうしたのか

• 本番環境がどういうものなのか意識する(この事件以降、自然に緊張するようになりましたw)
• 自分一人でなんでもできるなんて思わない(調子に乗りすぎてました。。)
• 時間がないからといって焦らない。焦ってもいいことない。

こう書いてみると、エンジニア職に限らず必要なことだと思いますね。

プロジェクトとしてどうしたのか

• sshログインできるユーザーが実行できるコマンドを制限する
• 障害にどう対応したのか、チケットに細かくコメントを残す

プロジェクトメンバーの誰もが管理者権限で本番環境にログインできる、という状況はやめた方がいいと考えています。ただ、やり方を変えるのはとても難しいことで時間がかかります。少しずつ、安全な環境になっていってほしいものです。

最後に

ここまで読んでくださり、有難うございます。この事件以降インフラ周りの作業を半年くらい続けて、今は新しい人に引き継ぐ作業をしていますが、この事件のおかげか以前より良い緊張感を持てていて、セキュリティに対する意識が高くなったと感じています。
明日はnobu0605さんによる本番でTableを1つDeleteしてしまいON DELETE CASCADEでさらに4つTable dataが消えた話、楽しみですね。自分がやってしまったら1週間くらい立ち直れなそう。。笑