インシデント コミュニケーションのベスト プラクティス

インシデントは、IT 部門と運用部門のスタッフにとっては常に現実のことです。現在、DevOps やカスタマー サポート チームも、インシデント コミュニケーションのクラッシュ コースを受講しています。

インシデント コミュニケーションとは、サービスに何らかの停止またはパフォーマンスの低下が発生していることをユーザーに警告するプロセスです。これは、24 時間無休の可用性が期待される Web サービスおよびソフトウェア サービスでは特に重要です。

Web 規模のインシデント コミュニケーションは単にメールを一括送信するより複雑で、考慮する対象者もメッセージや対応に期待される基準値もさまざまです。

ダウンタイムは避けられないため、チームが確実に対応できるように事前に計画を立てておくことが最善です。

ここでは、Atlassian のインシデント コミュニケーションのベスト プラクティスをご紹介します。扱う内容は次のとおりです。

• インシデント コミュニケーションが重要な理由

• インシデント コミュニケーションの準備方法

• インシデント コミュニケーションのプロによるタスクの対処方法

• インシデント コミュニケーションがインシデント後に終了しない理由

インシデント コミュニケーション: 誰が気にするのか?

顧客も同僚も気にしていて、あなたも気にする必要があります。ダウンタイムに適切に対処できないと、顧客とチームにとって非常に不快な経験となり、収益に影響する恐れがあります。顧客の中には、さらに不快な経験が隠れているのではないかと不安になり、競合他社に乗り換える人もいるかもしれません。信頼の欠如によって、将来の顧客を失います。チームの士気に悪影響をもたらして、生産性を低下させます。そして、良い口コミによる宣伝効果がすべて失われます。

幸いなことに、予期しないダウンタイムが必ずカスタマー サービスの悪夢に変わるというわけではありません。何が起こっているのか、問題を修復するために何を行っているのかに関する最新情報を常に顧客に伝えさえすれば、顧客は理解してくれて全体的な状況に対する否定的な反応は大幅に抑えられます。

インシデント コミュニケーションの準備する

適切な準備があれば、悲惨な結果は防げます。これが戦闘に赴く際のスローガンとして十分優れているなら、インシデント コミュニケーション戦略のスローガンとしても十分優れています。インシデントが発生している最中、インシデント コミュニケーションに時間をかけた自分に感謝するでしょう。

何をインシデントと見なすかを定義する

インシデントについて伝える前に、インシデントが何で構成されているのかを決定する必要があります。多くの Web 企業が、標準化された 4 階層の重大度定義システムを利用しています。Atlassian 独自の Incident Handbook から、重大度の定義に関する分かりやすいガイドをご紹介します。

インシデントの重大度に対するしきい値がどのようなものであれ、明確な基準を設けることが重要です (何らかの測定可能な指標を使用することが望ましい)。インシデントに重大度 1 を指定する場合は、チームの全員がその正確な意味を理解できなければなりません。

重大度システムは、ダウンタイムに伴う白黒はっきりしない部分を排除するためにも役立ちます。

どのようなシステムを利用する場合でも、セキュリティの問題やデータ損失に関わるインシデントでは、一切の妥協を許さないコミュニケーション計画を採用することをお勧めします。

コミュニケーション ソリューション、チャンネル、メッセージ テンプレートを事前に選択する

専門的なサポート チームとサイト信頼性エンジニアは、どのチャンネルでコミュニケーションを行うかをその場で決定することはありません。事前に計画を立てます。

インシデント コミュニケーションには、主に次の 5 つの通信チャンネルがあります。

• 専用のステータス ページ

• 組み込みステータス

• E メール

• 職場のチャット ツール

• ソーシャル メディア

• SMS

専用のステータス ページ

基本のインシデント コミュニケーション ソリューションとして、チームで専用のステータス ページを使用することをお勧めします。自分で構築する場合でも Statuspage のようなホスト型ソリューションを利用する場合でも、インシデントの発生中に顧客と同僚に明確で信頼できる情報源を提供することが重要です。Statuspage には、最新情報が投稿されるとすぐに、ユーザーがその情報を受け取れるように登録するためのオプションも用意されています。これによって、問題の修正に集中する必要があるチームがサポートを行わなくて済むようになります。

組み込みステータス

Statuspage では、顧客が運用する Web サイトにステータス情報を簡単かつ直接埋め込むこともできます。訪問者のほとんどはステータス ページを確認する前に、プロバイダーのホーム ページかサポート ページを確認します。埋め込みウィジェット (例をご覧ください) なら、そのような訪問者にインシデントが発生しているかどうかを簡単に通知できます。また訪問者はウィジェットをクリックして、ステータス ページにアクセスできます。

E メール

対象者に、Statuspage などの製品についてメールで最新情報を受け取れるように登録するためのオプションを自由に提供できます。メール ツールから直接送信する場合であっても、ステータス ページを使用してメールの送信をトリガーする場合であっても、メールはインシデント コミュニケーションのための優れたチャンネルを介して送信されます。

チャット ツール

Jira Service Management チャットを利用すれば、コンテキストの切り替えや、従業員とエージェント間の情報のギャップが軽減されます。Jira Service Management チャットを使用すれば、Slack や Microsoft Teams での対話とチケットを同期できます。一般的なチャット ツールとサポートの間でのシームレスな対話は問題に関する大まかな状況の提示に役立ち、迅速な解決につながります。

ソーシャル メディア

多くのチームが、インシデント発生中のコミュニケーション手段として Twitter のようなソーシャル チャンネルを利用しています。これを戦略の一部として利用するのは構いませんが、唯一のコミュニケーション手段とはしないでください。

SMS

SMS メッセージ (テキスト メッセージ) は一般に、誰かに連絡するためのよりも即時性の高い方法であり、ダウンタイムの通知といった重大なアラートを受信するために多くの人が好む方法です。一方で、非常に速くメッセージによる疲弊を引き起こしかねないチャンネルでもあり、自分に関係のないメッセージが多く届きすぎた場合、ユーザーは登録を解除します。

これらのチャンネルはいずれも、インシデント コミュニケーションの特効薬ではありません。それぞれに異なる強みがあり、これらを組み合わせて使用したときに真の力が発揮されます。たとえば、アトラシアンでは、ステータス ページにインシデントを投稿して、同時に最新情報を Twitter でも発信します。このインシデントに関する通知は Jira Service Management ポータルにも表示されます。ユーザーは、これらのメッセージから直接ステータス ページに戻るよう誘導され、インシデントの詳細を確認することができます。Jira Service Management でのインシデントの管理は、重複したり、変換によってお客様からの信頼を失ったりすることなく、さまざまコミュニケーション ポイントに利用できます。

該当する対象者に合わせてアラートやコミュニケーションを調整する

インシデントが発生した場合、カスタマー サービスの過剰な労働やコミュニケーション不全を回避するために、連絡する相手は誰か、どのように連絡するか、それを最も摩擦が少なく、最小限のリソースで処理できるかを知っておく必要があります。最初は社内の即時対応チームから始め、そこから外部に働きかけ、適切な対象者に向けてメッセージを作成することをお勧めします。

組織はそれぞれ異なりますが、一般に、コミュニケーションが必要な対象者を次のように 5 つのグループに分けて考えると良いでしょう。

1. コアのオンコール チーム: 何かエラーが発生した場合、影響を受けるとほぼ同時にそれを (通常は監視ツールやアラート ツールから) 把握します。社内チームは、コラボレーションのためのコミュニケーション ツールを使用して、背後でインシデントを検出、対応し、コンテキスト化して解決します。

2. 現場のサポート チーム: インシデントの発生中、質問に直接回答し、お客様に最新情報を提供します。非常に重要な役割であるため、このチームがエンド ユーザーに正しい情報を渡す必要があります。

3. マネージャーと経営陣: コア チームはこのグループとコミュニケーションを取り、何が発生しているか、次の 2 つのグループにどのような影響があるか、また可能であればこれがいつまで続くかなどを把握しておく必要があります。

4. 一般社員: 社員は、自分達が利用しているサービスの停止や稼動について常に把握しておく必要があります。このようなユーザーと前もって会話すると、「今のステータスは何か」といった質問が少なくなり、IT サポート チケットの重複を減らすことができるため、その時点で取り組んでいる問題の修正に集中することができます。

5. 外部のお客様: インシデントが外部のお客様に影響する場合、問題についての説明や、いつ修正されるかを少なくとも n 時間ごとに最新情報を送信する必要があります。現在も引き続き、アトラシアンの製品使用の可否について影響を及ぼしている問題については、最新情報の送信を 1 時間以上空けないようにしてください。また、次の最新情報がいつ提供されるかを常に示す必要があります。特にセキュリティやデータの損失に関わるような重大度の高いインシデントの場合、外部とのコミュニケーションを促し、他に必要なチーム (法務、人事、セキュリティなど) を引き込む必要があります。

インシデントおよびサービス停止のコミュニケーション用のテンプレートを準備する

インシデントが発生している最中に、最も避けたいのはインシデントの通知の文章に思い悩むことです。インシデントを伝える表現に問題があった場合は、あなたのチームの対応プロセスを批判する理由を探している非技術職のマネージャーの格好の標的となります。

事前に共通の言葉を決定してマネージャーの承認を得て、テンプレートに保存しておいてください。そうすれば、関連する詳細をはめ込んで、その日にインシデントの通知を送信することが容易になります。

Atlassian がステータス ページに使用しているインシデント テンプレートのうちの 2 つを次に示します。

• サイトでは現在、通常より高い負荷が発生しており、ページの読み込みが遅くなったり応答しなくなったりする可能性があります。原因を調査中です。詳細が分かり次第お知らせいたします。

• 公開指標データのストレージ プロバイダーで、現在インフラストラクチャの問題が発生しています。状況に進展があるか詳細が分かり次第、お知らせいたします。

専門家らしくコミュニケーションを管理する

インシデントのライフサイクルには、複数の連絡時点が含まれる可能性が高くなります。適切に対応した場合、インシデントの連絡は、最初の連絡、インシデント発生中の最新情報の連絡、解決と事後分析という、よく知られた 3 つの対応の構造になります。

はじめに: 内部チームのコミュニケーションの一元化

何よりも先に、インシデントのバックエンドにいる社内チームがコミュニケーション プラットフォームを確立しておき、問題が発生したときに協力して対処できるよう備えておきます。

監視、ロギング、CI/CD ツールの一元化とフィルタリングによって、チームは迅速に対応できるようになります。Jira Service Management などのプラットフォームでは、インシデントに素早く対応し、状況を把握し、インシデントの発生中に常に連絡を取り合うことができます。

パート 1: 最初の連絡

最初の連絡が最も重要です。何を伝えるかから、いつどのように伝えるかまでのすべてが、皆様の対応がどう受け取られるかの方向性を決定します。事前にテンプレートを準備しておくと非常に役立つのはこのときです。

皆様の目標は、迅速に問題を認めて判明している影響を簡単に要約し、今後も最新情報を通知することを約束することです。可能であれば、セキュリティやデータ損失に関する懸念を和らげます。正確な詳細がまだ分からなくても、問題があることを認めることが重要です。

パート 2: インシデント発生中の定期的な最新情報の連絡

インシデント中におけるコミュニケーションは重要です。

Google の SRE チームは、コミュニケーション リードをインシデントの発生中に監督すべき重要な役割の 1 つとして挙げています。

コミュニケーション リードの役割に関する Google の書籍『サイト リライアビリティ エンジニアリング』から引用します。

この人物は、インシデント対応タスク フォースの代表者です。その職務に絶対に含まれるのは、インシデント対応チームと利害関係者への定期的な最新情報の連絡 (通常はメール) です。その職務はインシデント ドキュメントを正確かつ最新の状態に保つなどのタスクに及ぶこともあります。

この人物は、状況の進展に伴って継続的にステータス ページに最新情報を掲載して、他のチャンネルに最新情報を投稿する作業も担当します。「引き続き問題解決に取り組んでいます。新しい情報はありません」と伝えるだけでも、何も言わずにユーザーを放っておくよりも良い対応です。何も知らされずにいる人々は、最悪の事態を予想し始めます。

影響を受けるユーザーやその他の利害関係者とは、コミュニケーションが不可欠です。あらかじめ定義したチャンネルを利用して、何が起きているのかをユーザーに伝えましょう。ホームページでは、これは Statuspage アラートであり、チームが問題を把握し、その冗長性に取り組むことによってエージェントの時間を節約していることをお客様に伝えます。SMS、メール、モバイル プッシュなど複数の通知チャンネルを利用して、常にお客様に最新情報を届けます。

使用するツールが何であれ、そのツールを主要なコミュニケーション手段として認識し、他のチャンネルから全員をそこに取り込むことをお勧めします。Jira Service Management でインシデントのコミュニケーションを管理すれば、適切な人に適切なメッセージを送ることができます。

パート 3: 解決、事後分析、今後の対処

2010 年に Facebook は、過去最大のサービス停止に見舞われました。当時 5 億人いたユーザーのうち数百万人が、約 2.5 時間ソーシャル ネットワークを利用できませんでした。

急成長中の大手テクノロジー企業にとって、タイミングはこれ以上ないほど最悪でした。同社は爆発的にユーザー数を増やしている初期の段階で、サービスが過剰な期待に見合うものであることをビジネス界に証明しようとしているところでした。

事態が収拾したとき、Facebook のエンジニアは 395 語のインシデントの概要を会社のエンジニア ブログに投稿しました。

ブログから引用します。

今朝早く Facebook は約 2.5 時間ダウンして、多くの皆様が利用できない状態になりました。これは、過去 4 年間に当社で発生したサービス停止では最悪のものです。まずは皆様にお詫び申し上げます。また、発生した障害に関する技術的な詳細と、ここから学んだ大きな教訓をご説明します。

事後分析の概要はシンプルです。

• 問題を認めて影響を受けた人に共感を示して謝罪する

• どのような問題が発生したのかとその理由を説明する

• インシデントを修正するために何を行ったかと、再発を防ぐために何を行ったかを説明する

• もう一度問題を認めて共感を示し、謝罪する

このようなコミュニケーションには、華美な言葉や大げさな主張は不要です。簡潔で率直なものにします。Facebook のブログから例を挙げます。

サイトの停止について、改めてお詫び申し上げます。Facebook では、パフォーマンスと信頼性を極めて真剣に受け止めています。

このような言葉を使うことで、顧客や同僚は皆様が冷静に問題に対処できるチームを配備して、問題を注視していることを信頼するようになります。詳細については、アトラシアンのインシデント対応事後分析テンプレートをご覧ください。

常時稼働のサービスを運用する場合の現実として、時には予期しない問題が発生します。ダウンタイムの発生中に効果的なコミュニケーションができれば、むしろ同僚と顧客の双方との信頼を築けます。適切な対応によって状況を一変させることができます。アトラシアンでは、インシデントの発生中に効果的なコミュニケーションを迅速に作成するためのシンプルなツールもご用意しています。