恥の多い生涯を送って来ました。

というわけでブログをご覧の皆さまこんにちは。エンジニアの小川です。 前回前々回とエンジニアとは思えぬ記事を書いていますので、たまには真面目・・・は無理でも、仕事に関係する記事を書いてみようと思います。

データベースをふっとばした話

初っ端から洒落にならないレベルの失敗の話です。

あれはもう１０年以上前のこと。ボクはとある開発会社でWEBアプリ開発をしていた時の話です。

その時自分が勤めていた会社はブラックもブラックみたいな所で、炎上案件のデスマーチの中、ボク含む開発メンバーのエンジニア３人は、連日連夜の徹夜泊まり込み休みなしでぶっ続けて働き続け、それが数ヶ月続き、ようやく完成して製品/サービスがリリースしました。

しかし多くの方はご存知の様に、WEBアプリはリリースしても終わりません。その後はサービスの保守作業や新しい機能の開発に移行します。開発メンバーの３人も、そのまま新機能開発に移行し、本番の保守と開発を並行する、そんな中の出来事でした。

その時ボク達はWEBアプリで使用しているデータベースをとあるクライアントソフトをWindowsにインストールして操作していました。MacでいうとTable PlusやSeaquelPro の様なソフトです。

こちらを各自使用し、普段はローカルPCや開発,動作検証用サーバのDBのテーブルやデータを編集。そして時折クライアントから本番サーバから分析データ取得や変更の依頼が飛んでくる、そんな運用をしていました。 　 事故が起きたのはそんな中の出来事でした

---

開発メンバー「確認したいから、開発環境のテーブルAのデータ全部消してー」

ボク「あいよー...消したよー！」

開発メンバー「あれ、消した? 残ってるけど... 」

ボク「・・・は・・・え？」

---

もうお分かりかと思いますが、消したのは本番環境のDBです。

消したことに気付いた時、手の震えが止まらず心臓がバクバクと鼓動を強め、頭の中は 如何に早く死ぬか ぐらいしか考えられませんでした。

だってどう考えても取り返しがつかないですからね。DBのバックアップは取ってありましたけど、毎日リアルタイムで取っているわけじゃありません。 そのWEBアプリは毎日ユーザから課金が行われているサービスでしたから、１日前のバックアップがあった所で「今日の分の課金情報ふっとばしました。すいません」 じゃ済まされません。個人で取れる責任の範囲をぶっちぎってしまった訳です。

そもそも何故こんな事故が起きたのかというと、データベースのクライアントソフトは同じ画面で複数のデータベースに同時に繋ぐことができます。その時も下の様に開発と本番のDBの両方に接続しながら作業をしていました。

こちらを見て分かる通り、開発と本番の違いは選択中DB名の周りに選択カーソルが付いているかいないか程度で、それ以外は全く同じ表示です。 開発作業中の自分が操作しているのは開発環境だと思い込み、テーブルのデータを全消ししたのでした。。。

あの時、もしこうしたクライアントソフトが「本番操作中は背景が赤くなる」等、ひと目で「今触ってる環境はヤバい」と分かる機能があれば...と思って止みません。残念ながら今でもその様なソフトは出ていません。

この事故の顛末としまして、結局削除前まで復旧することはできました。

この仕事はとある環境からとある環境への移植作業だったのですが、消したテーブルが重要だったこともあり、そのテーブルに対してアプリが行ったInsertやUpdate,Deleteといった更新系のSQLの全てのログをDB上の別テーブルに格納していた為、その記録されていたSQLを頭から全て流せば元のデータに戻る、というものでした。

本当にたまたま全消ししたテーブルのログを残す構造だった為、自分は九死に一生を得る事ができたのでした。

そしてボクへの処罰として、始末書の提出とクライアントソフトの使用禁止（便利すぎるから)で長い1日は終わったのでした。

事故から得た学び

他にも考えられる失敗の理由として、連日連夜の仕事で疲れていたとかストレスが溜まっていたとかぼーっとしていたとか、いくらでも挙げることはできますが、 ではしっかり休めていれば事故は起きないのかと考えるとそんな事も無い気がします。

大事なのは 人は失敗する生き物である ということ。

人は失敗するものだということを最初から想定していたら、運用方法をもっと考えられたかと思います。

1. 失敗しにくい環境を作る

「何でもできる」ということは「何でも起きる」ということに他なりません。

今回の場合、例えばそもそも本番環境のDBはガンガンに使われて動いている環境の為、頻繁に触るものではないはずです。

①管理画面を用意し、データを操作する際には管理画面から決まった操作しかできない様にする
②クライアントソフトからは読み込み権限だけを持たせたユーザを使用し、見るだけ専用にする

などの制限を行えば、今回の様な事故が起きにくくなるのではないかと思います。

2. 失敗したあとのリカバリ

今回の事故では更新系のSQLのログが残っていた為、１から復旧させることができました。 おかげで「いつかは事故が起こるもの」を念頭に、できるだけこういった更新系のログを残そうと思う様になりました。

しかしそれから今まで様々な案件に関わってきましたが、そんなにしっかりと管理画面やSQLのログを残している案件をあまり見ません。 それはコスト面(開発工数/データを残すストレージ料金)や作業のパフォーマンス等を考慮した費用対効果から、どうしても除かざるを得ない部分なのかもしれません。

しかし一方でそうした検討もなく「そんなのは失敗しなければ良い」「失敗する奴が悪い」と直接言われた事もあります。
でもそれは「交通事故を起こさなければ良いのだから、保険なんて入らなくて良い」と言っているのと同じ気がします。 どんなにベテランの運転手でも、運転のプロの長距離トラック運転手でも、ちょっとした気の緩み、また気の緩みが無く注意しても事故は起きます。車の運転と同様に、ボク達はできる限りの「かもしれない運用」を心がけ、それでも起きる事故の保険まで考えておきたい所です。

世の中にある数多のプロジェクトでは、同様に多くの失敗が起きているかと思います。それで本当に命を散らした人も出ているかもしれません。 安全対策を除いた事によるその負担や責任が、全てその失敗を起こした人が被るのでなく、そもそも「取り返しがつかない事故が起きる環境になっている事」こそが本当の問題である 、となるといいなと願っています。

次回は「某大手SNSプラットフォームをダウンさせた話」を書こうと思います。それではまた！