• Home
• コーポレートブログ
• サービス障害対応訓練を行いました

石川です。今回のブログでは先日ファーエンドテクノロジーで行ったサービス障害対応訓練について書きます。

サービス障害対応訓練

ファーエンドテクノロジーではMy RedmineやMy SubversionなどのSaaSを提供しています。サービスに障害が起きないに越したことはありませんが、いざ障害が発生したら原因調査、復旧、お客様からのお問い合わせへの対応、サービスの障害状況の発信など様々なことを行う必要があります。また、それらを迅速に行うためには適切なエスカレーションや情報共有、作業分担などが必要になります。

ファーエンドテクノロジーではサービス障害時の対応フローを作成しており、いざMy RedmineやMy Subversionなどに障害が発生したときに参考にできるようにしています。そのため、今回のサービス障害対応訓練では次のような目的を決めて訓練を行いました。

今回のサービス障害対応訓練の目的

• サービス障害対応のフローが実用的かを再確認する
• サービス障害対応のフローに沿った対応を体験する
• 体験の中で課題に感じた点を洗い出す
• サービス障害対応のフローの改善

訓練のシナリオ

「火事だー」をキーに実際には火事で無くても起こっているものとして行う避難訓練と同じように、「My Redmineの動作が重い」というお問い合わせが複数のお客様から届く というところから実際に障害が起こったものとして対応を進めるサービス障害対応訓練を行いました。

• 訓練には社員全員が参加
• そのうち2名が訓練の運営担当として参加

大まかな流れ

1. 訓練の運営担当が実際のサポート窓口に「【訓練】My Redmineの動作が重い」というようなお問い合わせチケットを複数作る
2. そこからサポート担当がお問い合わせに気づき、社内全体に情報共有
3. フローに沿ってサービス障害対応を始める
4. 障害発生から60分後に問題の根本的原因が分かり、その更に30分後に復旧対応が完了

実際にやるところ／やらないところ(やった振りをするところ)を明確に

訓練の中では実際にやるところと実際にはやらないところ(やった振りをするところ)が混在しているので、訓練中に参加者が混乱してうまく進まなくなってしまうことを一番危惧していました。対策として、事前に実際にやるところと実際にはやらないところのリストを作成しておき、参加者があまり行動を迷わないで済むようにしました。

実際に作業するとお客様に影響のある作業はSlackで「作業を行った宣言」を行うのみに

フローの中には障害状況の発信、Webサポート窓口に障害発生中のお知らせを表示するといった手順もありましたが、これらを実際にやってしまうとお客様を混乱させてしまいます。そのため、訓練では次のように作業を行ったという宣言をSlackに書き込む形で対応してもらいました。

障害調査・復旧部分は擬似的にのみ実施

障害調査・復旧部分の訓練を行おうとするとダミーの環境の構築などに時間がかかるため、今回は障害調査・復旧部分は擬似的にのみ行い、お客様からのお問い合わせへの対応・サービスの障害状況の発信やそれを行うための情報共有の部分を中心に訓練を行いました。

障害調査・復旧部分は実際には行わないで訓練を進める為にある程度対応が進んだら訓練の運営担当が次のように情報を出し、次の対応フェーズに進むように調整しました。

関わる人数の多い訓練なので、確保していた時間内に訓練が終わりそうに無かったらこのアナウンスによって多少強引に対応フェーズを次に進めることも考えていました。(今回は順調に進んだため不要でした)

また、実際に作業はしない訓練でも障害原因を特定するためのお客様とのやりとりは体験できるよう、以前発生したサービス障害の事例を参考にどういうことが原因で「My Redmineの動作が重い」という現象が起きているかを訓練の運営担当側で決めておき、質問が来てもそれをベースに答えられるように準備していました。

今後障害調査、障害復旧部分の訓練に着目した訓練も行うことを考えています。

後から振り返りやすくするように口頭で話した内容もSlackに記録

あとから振り返りを行いやすくするため、口頭で話した内容もSlackに記録してもらいました。これによって、後からでもどんな流れで対応が行われたかを追うことができました。

連絡がつかない人がいる訓練

今回は 関連スタッフの一部は移動中(Slackを見ていない) という前提で訓練を行っていました。

今回の訓練では「サービスに障害が発生した」ということを 社内で声を上げて伝える + Slackで全員に対してメンションをつけて通知 というやり方で共有したため、途中まで移動中のスタッフは障害が起きていることに気がつかないままになっていました。在宅勤務の時も声が聞こえないため同じように気づかないことがありそうです。状況を把握すべき内容は、メンションを飛ばすだけでなく関係者がきちんと気づいているかを確認する必要があるという学びを得ることができました。

訓練には社員全員が参加

「My Redmineがいつもより遅い」という問題が発生したときに直接的には対応を行わない人も社内にはいますが、そういった人にも訓練には参加してもらい、通常通りの業務を行いつつ障害対応の様子を見ていてもらいました。

以下の感想があり、全体の流れを見た上でのフローの改善提案などを出してもらうことができました。

• 直接関わりはありませんでしたが、障害発生した時の様子を一通り感じることができてよかったです。(slackのやり取りや、社内の雰囲気など)
• 気になってSlackをずっと見ていて通常業務はできませんでした。

今回の訓練ケースで関わりが無い人も別のサービス障害では関係者になり得るので、フローや障害対応の様子を見てもらえたのは良かったと思います。

訓練終了後

「サービス障害対応のフローの改善」を目的の一つとして記載していたので、改善に繋げるための訓練を通した感想や困った点などをGoogleフォームで参加者から収集しました。

今回の訓練でサービス障害対応を体験して終わり！では無く、ここで得た学びを元にフローの改善を行う予定です。(スケジュールの都合で終了後すぐにはできませんでしたが、フローの改善を行うためのミーティングの実施日程はすでに決定しており後日行う予定です。)

訓練を行った感想

どのように訓練を進めるか考える上では、実際にやるところと実際にはやらないところ(やった振りをするところ)の切り分けが難しく訓練の中でも混乱してしまうのではと思いながら進めていたのですが、大きなトラブル無く訓練を終了できました。結果的には、想定以上にリアリティ・緊張感のある訓練になっていました。訓練シナリオを把握している人が何人か参加者側に混ざっていたことも良かったのかもしれません。

Googleフォームを使って収集した「障害対応フローに対して見直しができそうな点」についても多くの回答が集まったので、これを元にサービス障害対応時のフローをより良くしていけそうです。関わる人が多かったり、シナリオ決めが難しかったりと大変なことが多かったですが、その大変さに見合うだけの良い経験ができました。また、実際にサービス障害が起こった際の対応を良くすることにも十分に繋げられそうです。

こういった訓練を今後も定期的に行い、いざサービス障害が起きた際も迅速に対応できるようにしていきます。