Gitlabの障害対応に学ぶこと

redditを見ていたら、大学卒業後はじめてエンジニアの正社員として職を得たものの、初日で本番データベースをふっ飛ばしてしまい即クビになったあげく、法的対応もすると言われて可哀想すぎる若者がいた。

https://np.reddit.com/r/cscareerquestions/comments/6ez8ag/accidentally_destroyed_production_database_on/

「盛大にやらかしたな〜」と思いつつ、よく読むとこの会社の方が相当にダメダメであった。開発環境セットアップ方法のドキュメントになぜか本番DBへの接続設定が書かれていた上に、そもそもローカルマシンから本番DBに直で疎通できてしまうのもあり得ないし、バックアップからのリストアにも案の定失敗している。付いているコメントもほとんどが若者を擁護する論調であった。

たくさんのコメントが付いてるなかで

大盛り上がりのスレッドであったが、Gitlab社のエンジニア、Yorickさんもコメントしていておっと思った（アドバイスは極めて適切であった）。なぜかというと、今年のはじめにGitlabもオペミスにより盛大にデータベースをふっ飛ばしてテック業界で話題になったのを思い出したからだ。

この事件で凄かったのは、復旧対応の様子を詳細かつ迅速にGoogle Docsにアップしていき、しまいにはYouTubeでライブストリーミングまで始めるという驚異の透明性であった。障害対応のライブなんてもちろん見たことも聞いたこともない。

GitLab.com Database Incident - 2017/01/31
https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

GitLab Live Stream

世界中からウオッチャーが集まり盛り上がったわけだが、こんなことを考えて実際にやるのがすごい。Twitterなどでもおおいに賞賛されていた。

障害は発生原因や破損状況が多岐に渡る事が多く、素早い状況判断と方針決めが求められる（しかも極限の緊張下）ので難易度が高いのだけど、その判断と実行を細かに記録してくれているので、同業者としては非常に勉強になる。実際に、感想戦もエンジニア界隈で盛り上がっていたのを覚えている。

とはいえですよ

Gitlabはソースコード管理ソフトのgitのホスティングサービスで、開発者が集うプラットフォームである。なので、Gitlabユーザの多くはエンジニアであり、今回のようなインシデントには理解がある（なんなら経験したこともある）のだ。「まあ、そういうこともあるよね」である程度分かってもらえる土壌があるのである。

なので、この試みはフツーのサービスでやっても多くの場合「とっとと直せ」と思われて逆効果になるんじゃなかろうか。盲目的に真似しないほうがいいかもね、とは思いました（言われても真似しないよね）。