ヴェルク - IT起業の記録

受託開発と自社サービスの両立への取り組み

board(SaaS)障害時を想定したサポート対応訓練をやってみた

弊社ではboardというSaaSを提供していますが、障害が発生した状況でのサポート対応訓練をやってみたところ、気づくことがいくつもあり、とても良かったので、書いてみたいと思います。

訓練の内容

障害対応訓練をやるのは初めてなので、やり方やシナリオなどは手探りでしたが、訓練自体の経験値を貯めるのも兼ねて、今回は以下のような内容でやってみました。

シチュエーション

今回は、オーソドックスに、以下のようなシチュエーションにしました。

  • AWSの障害でboardを利用できない状況が発生
  • 「エラーになる」「利用できない」という問い合わせが届く
  • CSチームは実際の障害時を想定して対応していく

また、今回の訓練は「障害に備えて、CSチームとして準備しておくべきことを洗い出す」ことを一番の目的としていました。そのため、CSチームは訓練のためにあまり構えすぎず、ごく普通のCS対応中の状況にしておいてもらいました。

役割分担

今回は、以下のような役割分担でやってみました。

  • CSチームは問い合わせ対応。CSチーム内の役割分担はCSチームにお任せ。僕は障害調査を行っている前提で、エスカレーションは対応できるけど、こちらからCSチームに対して指示出しはしない。
  • エンジニアはユーザー役で、いくつかの経路で問い合わせをする。
  • 僕は主に進行役で、障害の発生や状況の進展などを流す。

また、今回の訓練の目的ではないですが、障害時にエンジニアが対応するインフラ的な作業も一緒にやってみて、その作業手順の確認も行いました。

事前準備

自分+エンジニアが今回の訓練の「運営チーム」だったので、シナリオや問い合わせの準備などをしていました。

シナリオは、大まかな時間ごとに発生するイベント(障害や原因判明など)を書いていきます。また、それぞれごとに、問い合わせ内容を事前に準備しておきます。

問い合わせ内容は、「エラーになる」「使えない」といった基本的なものから、少しひねったもの、クレーム的なもの、対応できないような内容(例:電話で説明してほしい)など、さっと対応できなさそうなものをいくつか混ぜるようにしました。

進め方

Slackに「訓練進行用」と「運営用」の2つのチャンネルを作りました。

「運営用」チャンネルには、自分+エンジニアだけが入っていて、CSチームには見えないところで、事前準備をしていました。また、当日、CSチームの対応状況などを見つつ、進行の微調整などの話をここで行っていました。

「訓練進行用」のチャンネルでは、障害発生のアナウンスを流したり、CSチーム内でのやり取りなど、訓練当日のやり取りをすべてここで行うためのチャンネルです。

当日のシナリオ

訓練全体の時間は45分間としました。

10分〜15分ごとに、Slackの「訓練進行用」チャンネルに以下のイベントを流しました。

  • 障害の発生
  • 障害の原因は「これかも」という予想
  • 障害の原因判明
  • 障害の復旧

 

障害発生を受けて、CSチームでは以下のような対応がすぐに始まりました。

  • 1名がベースとなる回答文の作成
    • これをもとに、各メンバーが問い合わせ内容に応じて微調整して送る
  • ステータスページ更新の準備
  • 問い合わせ状況の確認

*ステータスページとは、障害時などに対応状況を発信するためのページで、システム本体の障害の影響を受けないよう、切り離して用意しています。たとえばboardのステータスページは https://www.the-board-status.jp/ というかたちでドメインから分けています。

 

その後、CSチームは以下のようなことを行っていました。

  • 回答の準備ができ次第、順次返信
  • ステータスページの更新
  • 技術的な観点で確認が必要であればエンジニアにメンションして確認
  • CS対応として確認事項があれば、僕にメンションして対応を確認

 

訓練をやってみて気づいたこと

まず、とても良かったなと思いました。これは定期的にやりたい。

今回が初めてなので、訓練の進行やCSチームの対応など、もっとうまくいかないところが出てくるかなと思っていましたが、意外とスムーズに進みました。

CSチームの対応も、チーム内でよくコミュニケーションを取っており、それぞれのメンバーの特性・得意不得意を踏まえた役割分担ができていて、すばらしいなという感じでした。

今回の訓練で気づいた改善点などは、以下のような点でした。

初動のスピードはもう少し早くしたい

問い合わせへの返信やステータスページの更新などは、もっと早くしたいなと思いました。

とくに障害の初期段階だと、こちらも詳しいことはわからない可能性が高いので、「弊社側でも状況は把握していて調査中」ということをなるべく早く伝えた方が良いと思っています。

それに対して、文章を考えることにやや時間を使いすぎた印象でした。ただ、これはある程度事前に準備しておくことで改善できるので、実際の障害に備えて、準備しておくべきこととして明確になりました。

また、上記のような「障害対応時には何を優先するか」といったことの共通認識を持てると良いので、それを考える機会にもなりました。

ステータスページ運用の習熟度を上げる

ステータスページの更新は、日常的にやるものではないので、慣れておらず、また、各自の理解度・認識にもバラツキがあるなと思いました。

CSメンバー・エンジニアメンバーともに、事前に「ステータスページを一通り操作して使い方を把握しておく」ということはやっていたのですが、「こういう時はどれを選べばいいんでしたっけ?」みたいなやり取りが発生していたので、各個人の理解度・習熟度を上げていく必要があるなと思いました。

想定できることを事前に想定して目線を合わせておく

障害時のCSチームとしての対応で、事前に想定できるものは想定して、それに対しての方針などをチーム内で共有して目線を合わせておけると、実際に発生したときに、意思疎通がスムーズになりそうだなと思いました。

実際の障害時に、意思疎通や目線合わせがさっとできると、想定できていないケースや返信に集中することができ、かつ、各個人での対応レベルのバラツキも減ります。

 

準備の大切さ

障害はイレギュラーな状況ですが、事前に準備できること、習熟度を上げておけることはあります。その準備をしっかりしておけば、実際に障害が発生したときにはもっとスムーズでタイムリーな対応ができそうですし、余裕ができれば対応の品質も上がります。

経験値が少ないシチュエーションだと、普段どおり能力を発揮できなかったり、戸惑ったり、うまく対応するのが難しかったりします。子供の頃から学校などでやっている避難訓練と同じで、訓練であっても、そういうイレギュラーで焦る状況を経験しておくことは、とても大事だなと思いました。

また、CSチームからの感想で「訓練自体はリアルな感じでとてもよかった」とあったので、「擬似体験をして経験値を貯めておく」という点でも、うまくいったかなと思います。

 

総じて、とても良かったので、今後も定期的にやっていきたいと思います。準備大事。