イノベーション エンジニアブログ


株式会社イノベーションのエンジニアたちの技術系ブログです


このエントリーをはてなブックマークに追加

GitLab Down Incidentは私たちに何を残したか

寒中お見舞い申し上げます。 皆様既にご存知かと思いますが先日、GitLab.comのデータベースが大方吹っ飛ぶという悲しみが世界を包みました。

何よりも、 インシデントの経緯がこと細やかに記され、挙句には復旧の様子が YoutubeにてLive streamingという凡そエンジニア以外には理解されがたい光景が広がった今回。 サーバのドメイン名や中のディレクトリ構造まで包み隠さずレポートし、誰を責めるでもなくリラックスした雰囲気で障害対応に向かう風景には個人的にひたすら感銘を受けました。

By Ty Wilkins (https://about.gitlab.com/2015/07/03/our-new-logo/) \[CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)]

日本語での詳細は Publickeyが詳しいのでそれ以上あまり書くことはありませんが、私達はこれらを観て何を感じるか? ユーザへの実害はそこまで大きく無かったこともあり、第三者が運用の不備体制に対する批判や茶化した揶揄でネタにする風潮もあります。

そこには深い分断がありそうに思いました。

あ、消しちゃった

(従来とは異なり叙情的な見出しで進んでいきます)

これほどの規模ではありませんが、じんわり血の気が引く経験は私もあります。 私が若造のころの環境では、自動バックアップという気の利いたものはなく、本番サーバに入ってsudoでいじくるのも日常茶飯事。 あっ間違った!と思ったときには既にディレクトリごとお亡くなりになった後。

そんな感じで軽い気持ちだったりして、事故が起きるのは大体が元は些細な不具合を急いで直そうと焦って作業した結果だったりします。 もう定時過ぎてプライベートの約束の時間迫っとるのにー みたいな心ここにあらずな状態で発生するところも典型パターン。

そもそも今回は、元がDDoS攻撃でまあそいつが一番悪いわけです。 「なんだよ、ふざけんなよ」と思いながら渋々対応せざるを得ない。 といった具合に事故ってしまう要因は揃っていたし、何よりこのような日常的な事象の重なりで起こりうる身近な出来事かと思います。 もうこれはサーバ運用が完全自動化されない限り無くすことは難しいんじゃないでしょうか

結局運用のお仕事です

たまたま現在無事なだけなのは分かっているのです。 何かあったら影響は大きく、だからこそ可用性は重要であることも。

けれど「いつくるか分からない障害に備えて整備する時間があるなら、日常のタスクを少しでも減らしたい、効率化したい」 「まぁ○ヶ月くらいなら大丈夫っしょ」という根拠なきオプティミズムから後回しになる。

運用とは本来、業務を回す運用ではなく、システムを正しく回すのが一義的であるからして置かれるポジションでありますので 目的を見失わないように今一度気をつけるべき だと警告をいただきました。

惜しむべきでない手間を惜しむな

ここを見極めて、英断を下せるエンジニアでありたい。

あれバックアップは?

私も先日、STG環境へバックアップしていたDBのデータが自分自身からdumpを取ったものだったという輪廻転生的な体験をしました。 滅多に使うことがないとちゃんと取れていないことに気づかない。

6本中5本はさすがにアレですが、今とってるはずのバックアップ、ちゃんと取れてますか? と問い直す機会になります。

つまり何よ?(言いたいこと)

「対岸の火事じゃないんだよ!」

と言っている私を 茶化してた方々が対岸から見ている感じがしますよ!

そしてこうやって事故の全てを露見してくれることは、私たちにとっては本当は物凄い意義深いことなんです!

と言いたいんです。

今のうちにImmutableに

実はここからが本番でして(おいTL;DR書いとけと) さきほどSTG環境DBのバックアップの話をしましたが、AWSでサーバ運用している場合、コンソールで何でもできちゃう(直感的に使いやすい)ので、逆に人的操作に依存しやすいです。 人がそのUIに慣れた操作はいずれ思考停止からミスや漏れを誘発するのは確かです。 なんでも自動化すればいいってもんでもないですが、ロバストネスの観点からも、(バックアップに限らず)起動管理など積極的に自動管理していくべきだと考えます。

そしてImmutableインフラにするという選択肢ですが、決して導入しやすいとかイケてるということもなく、むしろイニシャルコストは掛かる可能性のほうが高い。 これも人的操作に依存しない管理方法であるからそうするわけで(勿論エンジニアがそう感じることが前提条件ですが)、回り回って大きなインシデントを無くすための準備ということを声を大にして言いたい。

ログ大事

さて、今回のGitLabの出来事経緯についても、全て明らかになったのは操作をログとして残してくれたからですね。 そしてもし、レプリケーションのlogが無かったら・・・なんてのは極端な例えですが、考えただけでも恐ろしいのは確か。

ImmutableだのEphemeral言う前に、まずログをちゃんと残す。

  • まずバックアップのバッチが実行されたのかわからない

  • 実行されてても正常に終了したのかわからない

  • 正常に終了してても何を処理したのかわからない

  • ログ残してても見に行けない

仮にログを取っていてもこれでは無意味。

というわけで、syogaさんが ログのお話 でも書いてくれてますが、もう一度言います。

ログをちゃんと残しましょう

最後までまとまりがない駄文でしたが、これまで読んでいただいてありがとうございました。 こちらからは以上です。