真夏の怪談とは

晴れても、曇っても、降っても、暑苦しい2013年、夏。みなさん、いかがおすごしでしょうか？　CodeGrid編集の外村です。

Web制作をやっていると、そんな暑苦しさが一挙に引いていき、背筋が凍るような思いをすることはありませんか？　足下の床が消えて、底なしの暗い穴へと垂直落下するような、そんな瞬間。そう、事が起こった直後には、頭が真っ白になり、その後、走馬灯のように「リカバー策」が駆け巡る作業ミス。このシリーズでは、スタッフが実際に体験した身の毛もよだつ体験をお届けします。

と、ちょっと怪談めいた書き出しをしましたが……。このような大きな事故にいたる前のミスは「ヒヤリ・ハット体験」などとも呼ばれます。その体験事例や対策をきちんと共有して、同じミスが再び起こらないようにすることは、医療現場や製造業をはじめ、さまざまな業務で重視されている取り組みです。

そこでCodeGridでも制作に関わるエンジニア、アートディレクターに、過去の「ヒヤリ・ハット」体験を提出してもらいました。中にはさまざまな制約からリカバーができなかった苦い体験もあります。もちろんこのような体験はないに越したことはありません。

ですが、人間のやることにはミスが起きる可能性があります。それならば、体験を共有して、きちんと対策につなげましょうというのが、この「真夏の怪談」シリーズの主旨なのです。

くれぐれも、深夜、作業の片手間には、お読みにならないでくださいね。なにかが起こっても、責任はとれませんので……。

サーバーが突然……

体験者：フロントエンド・エンジニア 外村 和仁（@hokaccha）

あれは、まだ僕がエンジニアとして経験の浅かったころの話です。サーバーにSSHでログインして、HTTPサーバーかなにかのログを確認しようと思いました。そこで、おもむろにターミナルから次のコマンドを実行しました。あんなことになるとも知らずに。

$ vim /path/to/access.log

リターンキーを押しました。ターミナルにはアクセスログが表示されるはずです。ところが、あれ、反応がない……。

サーバーが重いのかなと思い、しばらく待ちました。

それでも、反応がない。おかしいなあ、どうしたんだろう？　と思ってると、隣に座っていた先輩が、恐ろしい一言を口にしました。

先輩「あれ、サーバー落ちてる？」

確信はないのですが、自分の操作とあまりにもタイミングが一致しています。いろいろ察して、青くなる僕……。

hokaccha「あ、あの、今ログファイルvimで開こうとして、フリーズしちゃったんですが……」

先輩「えー！　それはダメだよー！！！」

なんとかすぐにサーバーを再起動して、事なきを得ましたが、血の気が引きました。サービスが稼働しているサーバーを落としてしまったのですから。

対策

この恐怖体験の原因は、とんでもなくでかいサイズのファイルをvimで開いたため、メモリが食いつぶされたことです。

まず一番ベーシックな対策はvimなどのエディタで巨大なファイルを開かないことです。例えば、ファイルの最後の数行だけを表示させるtailコマンドや、ファイルの表示結果をページングするlessコマンドなどを使いましょう。

次のようなコマンドです。

$ tail -f /path/to/access.log

また、根本的な解決策として、サービスが動いているサーバーで、直接ログを見るなどの操作をしないようにするのも重要です。

最近ではクラウドのログ集計サービスなども多くあります。例えばPaperTrailというサービスがあります。このサービスは、ログをWeb上で閲覧でき、フィルタや時間指定などの機能で、ログを絞り込んだり、特定のログの場合にアラートメールを送ることもでき、非常に便利です。

ちなみに、CodeGridもこのサービスを使っていて、なにか致命的な問題が起きれば、できるだけ速く復旧できるような仕組み作りをしています。

もしサービスが動いているサーバー上で、なにか作業することがあったら、肝が冷える体験にならないように、コマンドの実行一つ一つを慎重に行うことをおすすめします。

消えたデータベース

体験者：フロントエンド・エンジニア 中村 享介（@kyosuke）

あれは僕がディレクターとして働いていた頃の話です（8年ぐらい前でしょうか）。クライアントから開発用にと、レンタルサーバーの提供を受けました。この提供されたレンタルサーバーには、まったく関与していないプロジェクトのデータもすでにある状態でした。

そのサーバー上でMySQLとPHPで作られた簡易更新システムのテストと開発プレビューをしていたのです。

このプロジェクトは、社内だけでは開発が難しかったので、デザイン＋HTMLは社内、管理画面の要件定義だけは社内で、設計・実装は外注という体制を組みました。

順調に開発は進み、提供された開発用のレンタルサーバーの役割も終了し、無事リリースも完了したところで「それ」は起こりました。

クライアント「開発が終了したので、提供した開発用のレンタルサーバーから、今回の開発に関連するものだけ消しておいてください」

Kyosuke「承知しました」

その作業は自分でもできそうだと思いましたが、データベースを直接いじるのは怖い。やはりプロである外注の人に頼むことにし、さっそくメールで連絡を取りました。

Kyosuke「提供された開発用サーバーのデータベースから、今回の開発に使ったtableだけ消していただけますでしょうか。僕たちの関与していない、元々あったtableは消さないようにお願いします」

ちょっとややこしいのですが、1つのデータベースの中に、プロジェクト関連のtableと、関与していないプロジェクトのtableが共存していたのです。

メールを送信してから、たぶん数分後のことだったと思います。外注先からメールの返信がきました。作業完了の報告かと思いメールを開くと、そこには……

すみません！！データベースごと消してしまいました

との一文が。

僕はすぐさま電話をかけ、バックアップの状況など確認するも、社内も、外注先もバックアップをしていなかったことがわかりました。結局、もとの状態に戻すのは不可能であるということがわかり、社長と菓子折りを持ってクライアントのところに謝りに行きました。

対策

原因はいくつかありますが、対策すべき原因は、レンタルサーバーで権限の大きいデータベースユーザーアカウントを使いまわしていたこと、今回の開発用にデータベースを分けられなかったことだと思います。

当時のレンタルサーバーではMySQLのようなデータベースは使えるものの、1サーバーにつき、ユーザーアカウントとデータベースの数は1つずつなど、制限があることがよくありました。通常、開発ではシステムごとにデータベースを分けて使うのがよいでしょう。またシステムごとに、権限を細かく設定したユーザーアカウントを発行することも必要です。

この件でも、きちんとそのような対策がされていれば、外注先のユーザーアカウントは、データベース全体を消す権限がないはずなので、ミスも起きなかったでしょう。

また、セキュリティやクライアントのコンプライアンスなどの問題から難しいこともありますが、できれば開発環境および、そのプレビュー環境は制作会社側で用意したほうがよいと思います。

サーバー上のデータを効率よく間違いがないように管理する仕組みを適宜用意するには、自社で自由に管理できる開発サーバーは必須でしょう。

まとめ

いかがだったでしょうか？　真夏の怪談。今回は2つの体験談をご紹介しました。もし、あなたにも心当たりがあることがあれば、今すぐ対策や、情報の共有をしてみてください。

ちなみに……この原稿を編集しているとき、なぜかこの原稿の入ったフォルダとファイルの保存日時だけが「日付なし」と表示されてしまう現象が起きました。あれは……いったいなにが原因だったのでしょう。