エムオーテックス株式会社が運営するテックブログです。

インシデント対応ロールプレイ

インシデント対応ロールプレイ

はじめに

こんにちは、アプリケーションチームの野地です。
私は普段、LANSCOPE エンドポイントマネージャー クラウド版の開発業務に携わっています。

開発現場では、日々、新機能や機能改良がリリースされていきます。しかし、これら機能はリリースして終わりではなく、製品の一部として運用面の対応も必要です。
そしてその一つが、インシデント対応です。

インシデント対応と聞くと、たとえ決まった対応手順があっても、いざ対応するとなった時に「製品環境を操作するのは大変そう」「作業をミスするかもしれず、不安だ」と感じる人もいると思います。

今回はこうした運用者に向けて、「作業経験を持ってもらい、少しでも不安を減らす」ために、インシデント対応ロールプレイという取り組みを実施しましたので、ご紹介します。

普段のインシデント対応

インシデントの例

インシデント対応が必要になるシナリオとして、例えば、「ネットワーク不調により処理が失敗し、自動的に実施される規定のリトライ回数を経てもすべて失敗した」があります。

リトライ回数が規定された処理フローのイメージ
このような場合は、処理の失敗を検知し、運用者によるインシデント対応(再処理して成功させるなどの対応)が必要です。

運用監視システムとインシデントの検知

エムオーテックスでは、LANSCOPE エンドポイントマネージャー クラウド版を提供しており、その運用監視を社内で行っています。
そこでは、内製した運用監視システムを使用してインシデントを検知しています。

異常検知と通知発生のイメージ図
図のように、AWSの各種リソースに関するログやメトリクスに対してアラームをセットし、異常が検知されるとチャットに通知される仕組みです。
通知内容を確認し、対応が急務なもの(いわゆるインシデント)があれば対応にあたります。

ロールプレイを実施するわけ

先ほど示したような通知システムは存在しますが、日々の改善業務によって、インシデント対応につながる通知そのものが減っています。
これは本当に素晴らしいことなのですが、同時に対応する機会も減少しています。
対応する機会が減ることで、新規参入者はインシデント対応をしたことが少ない・全くない状態となり、経験不足から不安を感じる場合もあるでしょう。

そこで、インシデント対応が必要な通知が来た時に「何から始めるべきか」「実際にどのように作業を進めるか」をロールプレイで経験してもらい、運用者の不安を解消することを目指します。

ロールプレイの内容

事前準備

ロールプレイはテスト環境で実施します。
まずは、先ほど例で挙げたようなインシデントを意図的に発生させます。

インシデントとなる異常の発生

すると、運用監視システムが異常を検知し、チャットに通知がきます。

検知と通知のイメージ
このチャット通知を元にインシデント対応ロールプレイをしていきます。

進め方の概要

ナビゲーターとドライバー

ロールプレイは以下の役割に分かれ、本番環境と(ほぼ)同じ対応をテスト環境で行います。

ナビゲーター:インシデント対応の経験者
 ・指示を出す。また、その作業の必要性も伝える。
ドライバー:ロールプレイの体験者
 ・実際に手を動かし、現象の解消を目指す。疑問があればその場で質問する。

2役に分かれてロールプレイ実施
作業の必要性を補足したり、質疑応答を交えることで、システムの運用・設計に関する周辺知識も補っていきます。

つづいては、実際のインシデント対応を大まかに4フェーズに分けてみましたので、紹介します。

フェーズ1 事象と影響範囲の特定

まずは、運用監視システムがチャットに送信したメッセージから、事象と影響範囲を特定します。

通知イメージ
通知には、該当するAWSリソースのログへ飛ぶリンク、対応にあたる通知のチケットへ飛ぶリンクがあります。
チケットでは、過去の類似通知とその対処方法を確認できるようになっており、これも合わせて確認します。

フェーズ2 対応作業準備

事象と影響範囲の調査が終わり、対処方法が判明したら実際の作業に入っていきます。
ここで事前準備として、以下の内容をお客様サポートを実施する部署に連携します。
(※ロールプレイ実施時はメンバーを連携部署に見立てて実施します)

  • 速報レベルで、事象や影響範囲等をまとめたもの
  • 解消作業の実施連絡

フェーズ3 修正・解消作業

事象の解消に向けて、フェーズ2でまとめた内容に沿って作業を実施します。

修正・解消作業などの実施と復旧確認(例:ネットワーク不調により失敗した処理の再実行)
このとき、必ず2人以上でダブルチェックをしながら作業を行います。
作業後、発生した現象が解消されていること(処理の成功)を確認し、終了です。

フェーズ4 現象解消の共有と作業内容の記録

最後に、修正作業が終わったら、作業の完了および解消したという事実を共有します。
また、作業の証跡を文書で残すため、該当のチケットへ実施内容を漏れなく記載します。

これらの作業をテスト環境で行い、インシデント対応ロールプレイは完了です。

ロールプレイ実施の効果

新規参入者のインシデント対応に対する不安の解消度を計るため、ロールプレイの体験前後でアンケートを実施しました。

ロールプレイ体験前後のアンケート結果

結果として、ロールプレイ体験前と比べて不安の度合いを平均47.5%減少できました。
体験前のアンケートでは、「インシデント対応について分かっていないことが不安」という声がありました。
しかし、体験後では「ロールプレイのおかげで、過去のインシデントに関するナレッジを活用して対応でき、運用監視の一連の流れを経験できた」といった回答ももらえました。
実施した側としても、非常に嬉しい結果でした。

終わりに

ロールプレイを行うことで、インシデント対応の機会を設けて、不安を減らすという目的を達成することができました。
不安の解消や経験値を増やすことは、全体的な対応力の向上、ひいてはお客様の安心感にもつながる重要な取り組みだと思います。
今後は、新規参入者の研修への導入や、ロールプレイを実施したい社員のために常設を推進していきます。
ここまでお読みいただきありがとうございました。