インシデントへの対応

重要なポイント: アトラシアンのインシデント対応プロセスは、チケットが記録された瞬間からビジネスへの影響がなくなるまでインシデント マネージャーによって主導され、検知、起票、コミュニケーションの開始、評価、初回コミュニケーションの送信、エスカレーション、委任、フォローアップ コミュニケーションの送信、レビュー、解決という 10 のステップで実行されます。

• 概要: 信頼できる情報源としての Jira インシデント チケット、それにちなんで名付けられたチャット チャンネルとビデオ ブリッジ、共有のインシデント状態ドキュメント、誰を呼び出すかを決定する重大度レベル、社内外のコミュニケーション用の Statuspage に基づいて構築された、反復可能なガイドです。

• これが重要な理由: 明確な指揮系統、名称が割り当てられたチャンネル、および文書化されたタイムラインが、プレッシャーの下でも対応の連携を維持し、事後分析の作業の基盤となります。

• Jira Service Management のメリット: インシデント記録、オンコールのアラートとエスカレーション、チャットとビデオの統合、Statuspage や事後分析へのリンクを提供するため、プロセスを 1 つのプラットフォームから実行できます。

以下のセクションでは、アトラシアンのインシデント対応プロセスについて説明します。インシデント マネージャー (IM) は、この一連の手順に従って、インシデントを検出から解決まで導きます。以下の各ステップはそれぞれ独立したセクションとなっており、それらを合わせたものが、インシデント マネージャーが従うガイドです。

検出

社員は、さまざまな方法でインシデントに気付きます。モニタリング、顧客からの報告、または自らの観察を通じて知る場合がありますが、インシデントの発生時にチームが行う最初のステップは、インシデント チケット (アトラシアンの場合は Jira 課題) の記録です。

アトラシアンでは、社内の Jira Service Management ポータルへリダイレクトされる、覚えやすい短い URL を使用しています。アトラシアン社員は、Jira ダッシュボードまたは Confluence の Jira マクロを見ることで、インシデントがすでに進行中かどうかを確認できます。カスタマー サポート チームなどのチームは、進行中のインシデントを監視するために、わかりやすい場所にダッシュボードを配置しています。

すべてのインシデントで以下のフィールドに入力する必要があります。

インシデントが作成されたら、インシデントについてのすべての内部コミュニケーションに課題キーが使われます。

お客様は、自身に影響するインシデントについてサポート ケースを作成することがよくあります。カスタマー サポート チームは、これらのケースがすべてインシデントに関連していると判断すると、顧客への影響を追跡し、インシデントが解決した際に影響を受けた顧客へのフォローアップをより簡単に行うために、インシデントの課題キーを使用してこれらのケースにラベルを付けます。

新しいインシデントを提起する

インシデント課題は作成されたけれども、まだインシデントマネージャー（IM）が割り当てられていない場合は、そのインシデントの状態は新規となります。これが、Jira `インシデントワークフローの初期ステータスです。

新しい重大なインシデントが作成されたときに、Jira webhooks を使用して呼び出しアラートをトリガーできるサービスがあります。このサービスは、選択されたサービスに基づいて、待機中の IM に通知を送信します。例えば、Bitbucket の障害の場合は、Bitbucket インシデントマネージャーを呼び出します。「待機中のインシデントマネージャー」または IMOC として知られている、主要なインシデントマネージャーのグローバル名簿もあります。

呼び出しアラートには、インシデントの課題キー、重大度、および概要が含まれ、どこからインシデント（Jira 課題）を管理し始めるべきか、一般的に何が問題なのか、およびその重大度をインシデントマネージャーに伝えます。

オープンなコミュニケーション

IM がオンラインになってから最初にすることは、自分自身にインシデント課題を割り当てて、その課題を修正状態に進めることです。Jira 課題の担当者フィールドにも、現在の IM が表示されます。緊急時の対応では、誰が担当者なのかが明確であることがとても重要です。そのため、このフィールドが正確であることを厳格に確認しています。

IM は次に、インシデント チームのコミュニケーション チャンネルを設定します。この時点での目標は、すべてのインシデントチームのコミュニケーションを周知の場所に確立し、集中させることです。通常、すべてのインシデントに対して 3 つのチーム コミュニケーション方法を使用しており、それぞれが Jira 課題のフィールドで表されます。

• チャット ルームは、Slack またはその他のメッセージ サービスを使用します。チームがコミュニケーションを取って、見解、リンク、スクリーンショットをタイムスタンプ付きで共有して保存できます。チャット チャンネルに課題キーと同じ名前 (たとえば、HOT-1234) を付けると、関与する必要がある人が会話に加わりやすくなります。

• ビデオチャットは、Skype、Blue jeans、またはその他の会議アプリを使用します。全員が同じ場所にいるのであれば、実際に会議室に集まってミーティングを行います。対面コミュニケーションの方がチームがより迅速に仕事を進めることができ、議論の堂々巡りが減ることがわかっています。

• Confluence ページは、「インシデント状況のドキュメント」と呼ばれています。スタッフが同時に同じページを編集している場合、どの情報が集められているのかをリアルタイムで確認することができます。変更（例えば、誰が、何を、いつ、どのように、なぜ変更したか、また、それを元に戻す方法を示すテーブル）、複数の仕事の流れ、拡張タイムラインを追跡できる便利な方法です。複雑なインシデントや拡張インシデント発生中の信頼できる情報源として、インシデント状況のドキュメントはとても役に立ちます。

ビデオ チャットとチャット ルームはそれぞれ異なる目的に最適化されているため、インシデント中は両方を使用するのが最適であることがわかりました。ビデオ チャットは、グループでの話し合いを通じてインシデントの共通認識をすばやく形成するのに優れています。一方、テキスト チャットは、インシデントのタイムスタンプ付きの記録、ダッシュボードへの共有リンク、スクリーンショット、その他の URL を保持するのに最適です。

これらの方法は、記録していない会話にあった重要な見解、変更、結論を記録するためにも使用できます。IM またはインシデント チームの誰もが、リアルタイムで専用チャット ルームで交わされる見解、変更、結論を記録するだけで、この作業を行えます。独り言をつぶやいているように見えても大丈夫です。チームがインシデント タイムラインを再構築して原因を解明する事後分析では、これらのメモは非常に価値のあるものとなります。

ほとんどのチャットシステムにはルームトピック機能があります。IM は、インシデント情報と以下のような便利なリンクでルームトピックを最新の状態に保ちます。

• インシデントの概要と重大度。

• 誰がどの役割を割り当てられているか（IM から記入）。

• インシデント課題、ビデオチャットルーム、およびインシデント状況のドキュメントへのリンク。

これによって、インシデントの課題キーを知っている人は誰でもチャットに参加でき、インシデントの状況を把握できるようになります (チャット チャンネルの名前は、インシデントの課題キー (例: HOT-1234) に基づいて命名したことを思い出してください)。

最後に、IM 自身の個人チャットのステータスを、管理中のインシデントの課題キーに設定します。これで、同僚に自分がインシデントの管理に当たっていることを知らせられます。

評価

インシデント チームの通信チャンネルを設定したらインシデントを評価して、チームがそのインシデントについて何を伝えるべきかと誰が修正するかを決定できるようにします。

IM からチームに行う質問をまとめて示します。

• 顧客 (内部または外部) にはどのような影響がありますか?

• 顧客には何が起こっているか？

• 何人の顧客が影響を受けているか（一部、全員）？

• いつ開始したか？

• サポートケースはいくつ開いているか？

• Twitter、セキュリティ、データの損失など、その他の要因はあるか？

このタイミングで、インシデントのタイムラインへの追加を開始しましょう。新しく参加するメンバーがすぐに状況を把握できるように、チームの観察結果を記録します。これは、後ほどの事後分析プロセスでも重要になります。変更をロールバックしてインシデントを解決できる可能性があるため、インシデントの開始時刻が変更 (たとえば、Bamboo のデプロイなど) と一致しているかどうかを必ず確認してください。

インシデントの影響とチームが考える解決に要する作業量に基づいて、以下の重大度レベルのいずれかを課題に割り当てます。

インシデントの影響を確認したら、インシデント課題の重大度を調整または確定し、チームに重大度を伝えます。重大度レベルを数字で表すことは、重大度を明確に伝えるのに非常に有益です。

アトラシアンでは、重大度 3 のインシデントはデリバリーチームが営業時間内で対応しますが、重大度 1 と 2 では即時の修正が必要なのでチームメンバーを呼び出します。重大度 1 と 2 の対応の違いは微妙で、影響を受けるサービスによって異なります。

インシデントの顧客への影響に基づいて一貫した対応ができるように、重大度マトリックスを文書化し、チーム全体で合意しておく必要があります。

初回コミュニケーションの送信

インシデントが本物だと確信したら、できるだけ早く内部と外部に伝えなければなりません。内部コミュニケーションの目標は、インシデント対応を一元化して混乱を減らすことです。外部コミュニケーションの目標は、皆さんが不具合の発生を把握し、それを緊急の問題としてとらえて、解決に向けて行動していることを顧客に伝えることです。インシデントについて迅速に正しいコミュニケーションを取ることは、スタッフと顧客の信頼関係を構築するのに役立ちます。

内部および外部とのインシデントコミュニケーションには、Statuspage を使用します。内部の従業員と外部の顧客向けに別々のステータスページがあります。それぞれの使い方は後ほど説明しますが、今の目標はできるだけ迅速にコミュニケーションを立ち上げることです。そのために、以下のテンプレートに従います。

Statuspage インシデントの作成に加えて、エンジニアリングリーダーシップ、主要なインシデントマネージャー、その他の関連するスタッフを含むインシデントコミュニケーション配布リスト宛にメールを送信します。このメールの内容は、内部向け Statuspage インシデントのコンテンツと同じです。メールでは返信したり質問をしたりできますが、Statuspage は一方向のブロードキャストコミュニケーションに似ています。

インシデントに関するすべての社内連絡には、必ずそのインシデントの Jira 課題キーを記載するようにしています。この課題キーにより、スタッフはどのチャットルームに入室して追加の質問ができるかわかります。

エスカレート

皆さんはインシデント対応の指揮をとり、チームのコミュニケーションを確立して状況を評価し、インシデントが進行中であることをチームと顧客に伝えます。次にすべきことは何でしょうか?

最初の対応者だけでインシデントを解決できる場合もあるかもしれません。けれども、大抵は、他のチームを呼び出してインシデント対応に当たってもらう必要があります。これをエスカレーションと呼びます。

このステップの鍵となるシステムは、OpsGenie のような呼び出し名簿とアラートツールです。OpsGenie などのシステムで待機中名簿を定義すると、任意のチームで緊急対応時に連絡が取れるとことが期待されるスタッフのローテーションを設定できます。これは、常に特定の個人を必要とする（例：「またボブを呼んで」）よりも優れています。なぜなら、個人は、いつでも対応可能とは限らないからです（休暇を取得し、仕事を変える。呼び出しすぎると消耗する）。また、どの個人に対応責任があるかが明確なので、「できる限り努力する」待機システムよりも優れています。

インシデントの Jira 課題キーは必ず、そのインシデントについての呼び出しアラートに含めてください。これは、アラートを受け取った人がインシデントチャットルームに参加するために使うキーです。

権限委譲

誰かにインシデントをエスカレートし、彼らがオンラインになったら、IM は彼らに役割を委譲します。自分の役割に何が求められているか理解していれば、インシデントチームの一員として迅速かつ効果的に働くことができます。

アトラシアンで使用している役割は以下のとおりです。

• インシデント マネージャー: 概要ページで説明しています。

• 技術リーダー：上級技術対応者です。何がどのような理由で壊れたのか理論を発展させ、変更を決定し、技術チームを指揮する責任があります。IM と緊密に協力します。

• コミュニケーションマネージャー：パブリックコミュニケーションに精通している人が担当します。カスタマーサポートチームや広報のスタッフが担当する場合があります。インシデントについて、内部および外部コミュニケーションを作成し、送信する責任があります。

現在、誰がどの役割を担当しているかは、チャットルームのトピックスに表示されます。インシデント中に役割が変更された場合は、最新情報に更新されます。

IM は、インシデントの必要に応じて役割を作成し、委譲することもできます。例えば、2 つ以上の仕事の流れがある場合に、技術リーダーを複数人に割り当てます。または、内部と外部コミュニケーションマネージャーを分けることもできます。

複雑な、または大規模なインシデントでは、インシデント マネージャーに対する「健全性チェック」を行うバックアップとして、別の適格な IM を配置することが推奨されます。彼らは、タイムラインの管理など、IM の負担を軽減する特定のタスクに集中できます。

フォローアップコミュニケーションの送信

すでに最初のコミュニケーションを送信しましたが、インシデント チームが本格的に立ち上がったら、スタッフと顧客にインシデントの最新状況を知らせる必要があります。

社内スタッフへの最新情報の共有は、インシデントに関する事実認識を組織内で一貫して共有するために重要です。何か問題が発生したとき、特に初期段階では問題に関する情報が不足しがちです。そして、何が起こったのかや、どのように対応しているかについての信頼できる情報源が確立されていなければ、スタッフは自分だけの偏った結論に飛びつきかねません。

内部コミュニケーションは、以下のパターンに従います。

• 上記の「初回コミュニケーション」で説明したとおり、アトラシアンでは、内部 Statuspage とメールでコミュニケーションをとっています。

• インシデント名とメールの件名の書式は、同じ規則を使用します。

• まず、1 ～ 2 行で現在の状況と影響の概要を説明します。

• 「現在の状況」セクションは、ポイントを 2 つから 4 つ箇条書きにします。

• 「次のステップ」セクションは、ポイントを 2 つから 4 つ箇条書きにします。

• いつ、どこで次回のコミュニケーションが送信されるかを記載します。

Atlassian では以下のチェックリストを使用して、コミュニケーションの完全性を確認しています。

• 顧客への実際の影響は何ですか？

• 何人の内部顧客と外部顧客が影響を受けていますか？

• 根本原因は分かっていますか？それは何ですか？

• 復元のための ETA はありますか？それは何ですか？

• 次の更新は、いつどこで予定されていますか？

インシデントマネージャーは、内部コミュニケーションでは何が不明であるかを明確にすることが推奨されます。これによって不確実性を減らすことができます。例えば、根本原因がまだ分かっていない場合に何も言及せずに省略するよりも、「今のところ根本原因は不明です」と言うほうがはるかにいいのです。

外部の顧客に最新情報を提供することは、信頼の構築に役立つため重要です。影響を受ける可能性がある場合でも、最新情報が提供されると分かっていれば、顧客は他の作業を進めることができます。

外部向けコミュニケーションについては、先ほど外部の Statuspage でオープンしたインシデントをアップデートし、必要に応じてステータスを移行させるだけです。外部のお客様はインシデントの技術的な詳細には関心がなく、すでに解決したかどうか、まだであればいつ解決するのかということだけを知りたがっているため、更新情報は「簡潔」に保つようにしています。通常、1 つか 2 つの文章で十分です。

インシデントコミュニケーションは技術であり、訓練すればするほど上達します。アトラシアンのインシデントマネージャートレーニングでは、仮想インシデントでロールプレイを行い、そのためのコミュニケーションの下書きをし、クラスで発表します。これは、実際のインシデントコミュニケーションを行う前にスキルを構築するのに適した方法です。また、コミュニケーションを送信する前に誰かに「セカンドオピニオン」として見直してもらうことも推奨します。

レビュー

すべてのインシデントを解決する唯一の規範的なプロセスは存在しません。もしそのようなものがあれば、それを自動化して実行していたでしょう。その代わりに、Atlassian では以下のプロセスを繰り返し行って、さまざまなインシデント対応シナリオに迅速に適応できるようにします。

• 何が起こっているのかを観察します。見解を共有し、確認します。

• 何が起きているかに関して、理論を発展させます。

• それらの理論を証明または反証する実験を開発し、それらを実行します。

• 繰り返します。

例えば、あるサービスで見られた高いエラー率が、地域のインフラストラクチャプロバイダーが Statuspage に投降した障害と一致する場合もあるでしょう。その障害はこの地域に隔離されていると理論立てて、他の地域にフェイルオーバーすることを決定し、結果を観察するかもしれません。

この時点での IM の最大の課題は、チームの規律を維持することです。

• チームは効果的にコミュニケーションをとっていますか？

• 現在の見解、理論、作業の流れは何ですか？

• 効果的な決定を行っていますか？

• 意図的に慎重に変更を行っていますか? どのような変更を行っているのか理解していますか?

• 役割は明確ですか？それぞれの仕事をしていますか？さらに多くのチームにエスカレートする必要はありますか？

いずれにせよ、パニックにならないでください。何の役にも立ちませんから。落ち着いて行動すれば、チームの他のメンバーもそれに倣うでしょう。

IM はチームの疲労に目を配り、チームの引き継ぎを計画しなくてはいけません。複雑なインシデントを解決しているとき、専任のチームが燃え尽きてしまうリスクがあります。IM は、メンバーが何時間起きているか、このインシデントのために何時間働いているか注意する必要があります。そして、次に彼らの役割を担当する人物を決定します。

解決

現在または差し迫ったビジネスへの影響が終了したら、インシデントが解決したと言えます。その時点で緊急対応は終了して、チームはクリーンアップ タスクと事後分析に移行します。

クリーンアップタスクは、インシデントの Jira 課題からの課題リンクとして、簡単にリンクを作成し、追跡することが可能です。

アトラシアンでは、Jira カスタムフィールドを使用して、すべてのインシデントの影響の開始時間、検出時間、影響が終了した時間を追跡しています。それらのフィールドを、開始から終了までの間隔である time-to-recovery（TTR、復旧までの時間）と開始から検出までの間隔である time-to-detect（TTD、検出までの時間）を計算するのに使用します。インシデントの TTD と TTR の分布は、多くの場合重要なビジネス指標となります。

インシデントが解決されたら、最終的な内部および外部コミュニケーションを送信します。内部コミュニケーションでは、インシデントの影響と継続時間の振り返りを記載します。何件のサポートケースが提出されたかなど、その他のインシデントの重要な側面を含みます。インシデントが解決したこと、これがこのインシデントについての最後のコミュニケーションであることをはっきりと示します。通常、外部コミュニケーションは簡潔に済ませます。顧客にサービスが復元されたこと、事後分析でフォローアップをすることを伝えます。

Jira Service Management が、アラートの一元化やインシデント コミュニケーションの整理から、根本原因分析のためのインシデントの事後分析の実行によるチームの統合まで、チームが対応プロセスの各ステップを実行するのを支援する方法については、以下のボタンからご覧ください。

ハンドブックの印刷版または PDF 版を入手する

インシデント管理ハンドブックの印刷版は、数量限定で無料配布しています。または、PDF 版をダウンロードしてください。

ハンドブックを入手する