Close

インシデント管理改善への道はここから始まります

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

Incidents have always been a fact of life for people in IT and Ops. Today, it’s also DevOps and customer support teams getting a crash course in incident communication.

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

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

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

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

  • インシデント コミュニケーションが重要な理由
  • インシデント コミュニケーションの準備方法
  • インシデント コミュニケーションのプロによるタスクの対処方法
  • インシデント コミュニケーションがインシデント後に終了しない理由
インシデント コミュニケーションの図

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 専用のステータス ページ
  • 組み込みステータス
  • E メール
  • 職場のチャット ツール
  • ソーシャル メディア
  • SMS

専用のステータス ページ

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

組み込みステータス

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

E メール

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

チャット ツール

近年、Slack のようなチャット ツールが職場を席巻しています。多くのチームはインシデント コミュニケーション専用の指令室を設置するか、インシデントごとに新しい指令室を立ち上げます。こちらで、Atlassian のチャット ツールとの統合をご確認ください。

ソーシャル メディア

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

これらのチャネルはいずれも、インシデント コミュニケーションの特効薬ではありません。それぞれに異なる強みがあり、これらを組み合わせて使用したときに真の力が発揮されます。たとえば、ステータス ページにインシデントを投稿して、同時に最新情報を Twitter でも発信します。これは Web アプリ内にも埋め込まれています。これらのメッセージから、ステータス ページでインシデントの詳細を確認するようにユーザーを誘導します。いずれか 1 つを基本のコミュニケーション手段に設定して、他のチャネルからすべてのユーザーをそこに集めることをお勧めします。

SMS

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

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

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

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

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

  • サイトでは現在、通常より高い負荷が発生しており、ページの読み込みが遅くなったり応答しなくなったりする可能性があります。原因を調査中です。詳細が分かり次第お知らせいたします。
  • 公開指標データのストレージ プロバイダーで、現在インフラストラクチャの問題が発生しています。状況に進展があるか詳細が分かり次第、お知らせいたします。

インシデント テンプレート ライブラリで、その他の例をご覧ください。

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

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

パート 1: 最初の連絡

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

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

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

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

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

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

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

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

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

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

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

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

ブログから引用します。

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

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

  • 問題を認めて影響を受けた人に共感を示して謝罪する
  • どのような問題が発生したのかとその理由を説明する
  • インシデントを修正するために何を行ったかと、再発を防ぐために何を行ったかを説明する
  • もう一度問題を認めて共感を示し、謝罪する

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

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

このような言葉を使うことで、顧客や同僚は皆様が冷静に問題に対処できるチームを配備して、問題を注視していることを信頼するようになります。

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

関連する製品
Statuspage Logo

ステータスをリアルタイムで、ユーザーに簡単に連絡できます。

次の記事
On call schedule