とある学生web開発者のブログ

知ったこと、感じたことを書きます

【freee19新卒アドベントカレンダー】こころ

はじめまして、すぎけんです!

この記事はfreee19新卒の内定者が独自に企画したアドベントカレンダーの2日目の記事です。

それは冷たい空気が澄み渡る1月の東京で

これは遠い昔にどこかの誰かがやってしまったかもしれない、冷や汗が出るお話。

僕が Kが小説家ならその日は間違いなく鈍色の空にしただろう。その日は実によく晴れていたので、まさかあんな事件が起きるとは誰も思っていなかった。
僕は Kは勤め先であるA社の開発を自宅でしていた。自宅で開発できるなんて、なんて優しい会社なんだ。出不精なKにとっては最高だった。

その日のissueはなんであったかなぞ、今となってはどうでもいい。大事なのはKのissueがmigrateをたくさんするissueであったことだ。
データベースにカラムを追加し、モデルを追加し、「あっこのカラムはもういらないじゃん」。なんてことない。Railsを触り始めてもう2年は経つ。自分でサービスもやっている。Kは完全におごっていた。大罪である。

そして事件は起きた

「あーなんかスキーマがおかしいなーdropしてやり直すか。」

dropとはデータベース(db)を一度削除することだ。この時はdbのスキーマを変更するissueでありながら、レビューのためにmasterや別のbranchに移動したりなどしていた。コードはcheckoutできてもdbまでは変わらない。
一度削除してしまえば、開発しやすくなるとKは確信した。

dbを削除すること自体は大したことではない。Railsではコマンドも用意されている。 rails db:drop だ。 Kはいつもと同じようにローカルのターミナルでコマンドを実行した。

$ bundle exec rails db:drop

消えない。
何かメッセージが出ている。

$ bundle exec rails db:drop

{productionモードで起動したよね?削除できないよ〜どうたらこうたら〜}

そう、Kはこのissueで訳あってproductionモードでrails serverを起動していた。当然それはよく考えての決断で、CTOの許可ももらいやっていたのを思い出した。

Kの目にはエラーメッセージだけが映っていた。Rails5からproductionのdbは簡単に削除できない。

「あーそうか」

$ RAILS_ENV=production DISABLE_DATABASE_ENVIRONMENT_CHECK=1 bundle exec rails db:drop

これがKの最後のコマンドだった。

それでも晴れている

その後は悪夢である。

まずエラーを告げるSlack通知。見たことのないエラーだ。

「なんだこれ・・。」一人家で首をかしげるK。こういう時は歴史を見るものだ。
最近のmergeのせいか?いつデプロイした?CTOを中心に原因を調査していく。

コードが悪いわけではないとすぐにわかる。
インフラっぽい。

「何もできないなぁ」
リモートだし、サーバーやAWSへのアクセス権はないので手持ちぶたさである。

そしてKが自覚するまで30分かかった。そう、まさか、まさかローカルからproductionのdbに繋がる訳・・・あったのだ。database.ymlへの直書き・・。

$ history 50
やはり歴史が悪行を証明する。

「もしかしたら僕のせいかもしれないです。」

冷や汗。腹痛。涙目。喉が渇く。呆れる。なぜ・・。 あの時の感情と体の異変は再現不可能だ。

その後はバックアップからdbを復元。消えた分のデータはSlack通知や、営業の方々の協力により9割復元。致命的な損失も発生せず、Kが血しぶきをあげることもなかった。

後日CTOに直接謝った。あんなことをしたのにヒョンとしていた。

「ついにうちもやられたかと思ったわーいやでもなかなかない経験できたんじゃない?」

当たり前だ。もうしたくない。
この言葉に救われたが、忘れるわけにはいかない。
平成は終わるが崩御はされない。殉死などもってのほかだ。

そんなKはこれからfreeeで道を極めていく。

最後に

書いているうちに「『こころ』っぽい!」ってなって『こころ』のネタをいくつか散りばめてみました。探してみてね🤗
dbをdropするまでのコマンドとかエラーは覚えていないのでちょっと適当です。Rails、そしてDHHとContributersは悪くないです!

明日のアドベントカレンダーはカズヒロ!!
お楽しみに!😆