見出し画像

久しぶりにS級トラブルの対応をした話

災いは突然やってくる

全サービスのwebサーバーを乗せているGKEがみるみるうちにdeleteされていく。
冷や汗がジワリと湧き出し、頭の中は物凄く騒がしいような、それでいて、オブラートに包まれているようなくぐもった音がする。静かですらある。

我々は大地震が直撃したように呆然とし、そして動き始めた。

私はPMという立場上、状況確認、方々への連絡、復旧への見積もり、作業アサインなどをした。
原因特定は後回し、新機能リリースも後回し、全てのリソースは復旧に充てられた。

とできれば良かったが、そうもいかない。
インフラ周り(GCP周り)の作業なので、対応できる人は限られていた。対応可能者は上長も含まれていたので、上長は全力で復旧にあたる。

例えるならミサトさんがEVAに乗り使徒と戦いながらたまに状況確認、マヤがオペレーターを普段の倍頑張る、みたいな感じた。

マヤである私は、エンジニアチーム内で忙しく交わされる最新状況を速報としてslackで流す。

@channel ○○○が再開されました

@channel ○○○に異常が見つかりました。×××の作業はストップして下さい。

エンジニア向けのものもあれば、非エンジニア向けのものもある。
とにかく激しい流れをなるべく簡潔にまとめて適宜報告する。

アラート(slackのチャンネル)は鳴りっぱなし。優先順位を常に確認しながら順次復旧していく。
一つずつサービスが再開されていき、その度に再開日時を記録していく。

結局復旧完了までは4時間程度かかった。

反省

チームとして
・クラスタ全削除が可能な権限が制限されていなかった(誰でも可能だった)
・クラスタ移行という処理に対して無防備だった(頻繁に行うような作業ではなかったので、フローが整理されていなかった)
・インフラ知識が属人化されている

PMとして
・外国人エンジニアに対して英語で状況報告する余裕がなかった(ちなみに彼らはインフラに明るくはない)
・自分も復旧に参戦すべきか否か結構な時間迷っていた
・インフラ知識が少なく、復旧作業状況の理解が浅かった

今後

一通り落ち着いたので、ひとまず専用のふりかえりを行って恒久対策をチームで考える。

#システムトラブル #コラム #プロジェクトマネジメント #GCP #GKE

いいなと思ったら応援しよう!