ＰＣ関連スレ - 1036414893 - したらば掲示板

2082：とはずがたり：2017/02/14(火) 18:51:38: “よくあるファイル命名ルール”でデータ消失の危機？
http://www.excite.co.jp/News/it_biz/20170214/Itmedia_enterprise_20170214056.html
ITmedia エンタープライズ 2017年2月14日 13時00分 (2017年2月14日 13時55分更新)

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

　気になるのはその名前。「1」「2」しか違いません。エンジニアの作業的に、これが本トラブルの原因であるとは思いませんが、私たちは、ドキュメントやスプレッドシートに対してこういう名称を付けがちで、それがトラブルの原因になることが多いような気がします。

　Office文書を作成してなにかの作業を行っていたとき、ちょっとしたバックアップのつもりでファイル名の頭に「新」と付けたり「最新」と付けたり、末尾に「2」「3」「4」……と連番を付けたり。そしてその作業を引き継いだ人が、本当は最新ではない「最新」ファイルに対して作業をしてしまって……という話はよくあります。

　それを考えると、遠隔操作をする可能性があるもの、例えばグループで管理するファイル群などは、連番を使わないなどの「命名規約」をあらかじめ作っておくことがトラブル防止の1つのアイデアなのかもしれません。もちろん、新、最新、真、最終……といった修飾語も。

　振り返ってみると、大学時代や新入社員のころに知り合ったシステム管理者はみな、サーバを連番ではなく、惑星の名前などで統一していたのを思い出します。きっと夜空が大好きか、それともセーラー戦士なのか……。

　こういった名称規則をあらかじめ作っておくことは、トラブル防止に役立つだけでなく、ちょっとした気分転換になるかもしれませんね。ちなみに計算機の命名規約についてはRFC 1178でも触れていますので、迷ったときはこちらをどうぞ。