“よくあるファイル命名ルール”でデータ消失の危機?半径300メートルのIT(1/2 ページ)

先日、ソースコードを管理するサービス「GitLab.com」で、管理作業中に誤って本番データベースを削除してしまうトラブルが発生しました。実はこの事件からは、エンジニアでない私たちも学ぶべき点があります。

» 2017年02月14日 13時00分 公開
[宮田健ITmedia]

 「他山の石、以て玉を攻むべし」――。誰かの失敗も、自分の糧にすることができます。先日起きた事件は、さまざまな教訓を与えてくれました。

 2017年1月31日、プログラムのソースコードを管理するサービス「GitLab.com」で、管理作業中に誤って本番データベースを削除してしまうトラブルが発生しました。

 サービスの根幹部分が消えてしまい、複数のバックアップを取っていたはずが、そのほとんどが復旧には使えず、たまたま取っていたデータのおかげで、丸2日後に復旧できたというのです。

 この大きなトラブルはGitLabの優秀なエンジニアにより、その復旧作業が逐一「ネットで生中継」され、世界からはサービス停止の苦言よりも「頑張れ」という声が飛び交っていたようです。その詳細は、Publickeyなどでも記事になっていますので、エンジニアや情報システム部の方はぜひ参考にしてください。

“安易なファイル命名ルール”が致命傷に?

 この事件で私が一番気になったのは、「バックアップが取られていたのに使えなかった」ことでも、「生中継が行われた」ことでもありません。トラブルの経過報告も詳細なリポートも素晴らしいと思います。バックアップの重要性は言わずもがなです。

 エンジニアじゃなくても、情報システム部の人じゃなくても、この事件が「他山の石」となりそうなポイントは、「命名規則」です。今回のリポートには、下記のような一文があり、これはまさに、本トラブルが致命的になった瞬間です。

4. 2017/01/31 23:00-ish

1. YP thinks that perhaps pg_basebackup is being super pedantic about there being an empty data directory, decides to remove the directory. After a second or two he notices he ran it on db1.cluster.gitlab.com, instead of db2.cluster.gitlab.com

GitLab.com Database Incidentより引用)

 GitLabのエンジニア、YP氏はバックアップ環境「db2.cluster.gitlab.com」だと思って削除作業をしたところ、実際は「db1.cluster.gitlab.com」、つまり本番環境に対して削除作業をしてしまっていたのです。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ