“よくあるファイル命名ルール”でデータ消失の危機?:半径300メートルのIT(1/2 ページ)
先日、ソースコードを管理するサービス「GitLab.com」で、管理作業中に誤って本番データベースを削除してしまうトラブルが発生しました。実はこの事件からは、エンジニアでない私たちも学ぶべき点があります。
「他山の石、以て玉を攻むべし」――。誰かの失敗も、自分の糧にすることができます。先日起きた事件は、さまざまな教訓を与えてくれました。
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のエンジニア、YP氏はバックアップ環境「db2.cluster.gitlab.com」だと思って削除作業をしたところ、実際は「db1.cluster.gitlab.com」、つまり本番環境に対して削除作業をしてしまっていたのです。
関連記事
- 「半径300メートルのIT」記事一覧
- 私が「パスワードがない世界」を選べない理由
面倒なことこの上ない「パスワードの手入力」。誰もが、この面倒な操作をしたくないと思っているのではないでしょうか。手入力なしの認証方法も登場していますが、私はこれを選びませんでした。その理由は…… - 毒をもって毒を制す? 本格セキュリティ家電に“まさか”の技術
ゲーム機やNAS、STBなどの“ネット家電”が増えている今、ここに攻撃を仕掛けるケースが出始めています。こうした中で登場したのが“ネットの脅威から家全体を守る”セキュリティデバイス。その仕組みがなかなか面白いのです。 - iPhoneをなくして分かる、二要素認証の落とし穴
このコラムでもセキュリティ対策としてお勧めしている「二要素認証」。しかし、あるシーンで思わぬ壁にぶち当たったのです……。 - あらゆる個人情報を奪われたWIRED記者が犯した“痛恨のミス”
一見、強固に見える「本人確認」にもスキがある――。それを実感させられる事件が米国で起こりました。あらゆる個人情報をハッキングされたこの事件はどうして起こったのでしょうか。こうした事態を防ぐ方法はあるのでしょうか。 - TwitterやECサイトのパスワードは“5分もあれば”盗まれる?
先日、Twitterのパスワードらしき数千万件の情報が流出したという報道がありました。こうしたWebサービスのパスワードは、あなたが思っているより簡単に盗まれてしまう可能性があることを意識していますか?
Copyright © ITmedia, Inc. All Rights Reserved.