インシデントへの対応

検出

会社の社員は、さまざまな方法でインシデントに気付けます。監視機能からのアラート、顧客からのレポート、または直接観察することで障害を知ります。ただし、インシデントが起きたときにチームが最初に行うステップは、インシデント チケット (Atlassian の場合は 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 のデプロイ）と対応していることを確認します。

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

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

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

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

エスカレート

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

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

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