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

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

[宮田健，ITmedia]

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

GitLab.comが誤って本番データを失ったことをTwitterで報告

　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」、つまり本番環境に対して削除作業をしてしまっていたのです。