ビズリーチでサーバーサイドエンジニアをしている蒲池です。今日はビズリーチで行ったシステム防災訓練について書きたいと思います。実施したのか?サービスを運営していく中で、ソフトウェア/ハードウェアの両方で障害は発生しうるものです。ビズリーチでは、いざ発生した時に迅速に対応できるようにするため、障害対応フローというものを用意しています。障害対応フローが定義されているからといって、誰でも有事で対応できるという話は別です。指揮官をやりきるリーダーシップが発揮できるか適切な報告を社内外にできるかそもそも障害内容に応じたシステム的に適切な処置ができるかなど、障害対応には様々なスキルが求められます。呼ぶことにします)この障害対応力を少しでも向上させるために、特に若手エンジニアに向けて、システム防災訓練を行いました。今回は以下の2つの障害を検証環境で発生させることで訓練を行いました。DBへのアクセス設定に不備があり、Batchサーバの起動ができないソースコード内のUpdate文に不具合あり、意図しないデータ破壊を発生させている普段のリリース作業を行ったところ障害が発生した想定で行いました。リリース直後にはアプリケーションログ/サーバーに異常ないか見ていますが、その時に異常を検知し、訓練開始です。対応方法は冒頭で説明した障害対応フローに則って行いました。新卒1~4年目のメンバーで行いました。情報を集める場所を作ろう実際の障害を目の前にすると経験が浅い人はあたふたすると思います。訓練でもそんな状況になりました。みんなが手当たり次第ログを見て、様々なSlackチャンネルに情報共有しました。効率良く情報収集ができない、という問題が発生しました。状況を図にすると以下の状態です。情報共有をしようスプレッドシートやホワイトーボートなどに情報をまとめていくと、現状を一目で理解できるようになります。ホワイトボードは、自然と人がそこに集まってくるというメリットがあります。共有すべき情報は以下のようなものになると思います。1つの障害の障害に対し1つの運用体制をつくろう今回は2つの障害を発生させたからこそ発見できたのですが、1つの体制で2つ障害を対応するのは無理がありました。作業進捗を共有されるたびにどちらの障害の話をしているかわからず、コミュニケーションコストが無駄に発生したためです。対応のパターンはあらかじめ用意しておこうDBへのアクセス設定に不備があり、Batchサーバの起動ができないソースコード内のUpdate文に不具合あり、意図しないデータ破壊を発生させている今回は以下のような流れで対応を取ることで、迅速に1次対応はできました。被害を最小限にするためにサービスをメンテナンス画面に切り替えここから以降のフローは改善の余地があったかと思います。実際にとったフローは以下の通りです。修正後のアプリケーションをリリースする問題点は全て解決するまで、サービス全範囲を止めてしまっていたことです。今回であれば、メンテナンス画面切り替え後に以下のような判断をすべきでした。前回バージョンに切り戻すことでサービスは利用可能にできないか対象のUpdate文を修正後に、部分的に公開できるところはないか基本的な対応方法は事前に準備しようメンテナンス画面への切り替え前回バージョンへの戻しなどの良くある対応方法に関しては、どういう条件でその対応をするか事前に決めておくと良いかと思います。1次対応をすぐにできることで2次災害を防止でき、早期の復旧に繋がると思います。他には、ログの調査を素早くするために、Linuxの各種コマンドは使いこなせるように日々トレーニングしておいた方が良いと思いました。誰がやっているか直感的にわかりやすくするため、マリオとルイージの帽子をかぶることルールがあります。蒲池柾紀(ちーかま)2015年新卒入社。サーバーサイドエンジニアです。