インシデントの追跡

インシデントにはライフサイクルがあります。 最も効果的に対応するには、そのライフサイクルの最初からインシデント自体の進化とそれに対する対応の進化を追跡できる必要があります。

知っていることを評価する

特定のインシデントを使用してインシデント追跡手順を評価する良い方法は、一連の質問を自問することです。

• 問題について最初に知ったのはいつですか? インシデントからの復旧にかかる時間を短縮することが目的の場合は、問題を認識した時点から情報のキャプチャを開始する必要があります。
• どのように問題を見つけたのですか? 監視システムからインシデントに関する警告が表示されましたか? 最初にそれについて知ったのは、直接またはソーシャルメディアで顧客が苦情を言ってきた時ですか?
• 問題について今知ったばかりなら、あなたが最初に知った人ですか? その場合、誰に通知する必要がありますか? そうでない場合は、他の誰が問題を認識していますか?
• 他のユーザーが認識している場合、(何かあれば) それについて何が行われていますか? 誰もが他の誰かがそれを調べていると仮定していますか、それとも誰かがそれに対処するために行動を起こしましたか?
• どのくらい悪いですか? 重大度や影響に関する概念がない可能性があり、問題が本当にどれほど悪く、誰が影響を受けているかを知る場所はありません。

何も追跡されていない場合は、これらの質問に答えるのが難しい場合があります。

インシデント情報を追跡する場所を標準化する

インシデントの一覧 (アクティブまたはその他) と、それらのインシデントに関する現在のすべての情報を保持して共有できる場所は多数あります。 これらは、Wordドキュメントを含む共有ファイル領域と同じくらい単純で、高度に特殊化されたインシデント追跡ソフトウェアやサービスと同じくらい複雑です。 これら2つの極端の間に位置するのは、チケット管理と作業追跡システムであり、このタスクで使用することができます。 どのシステムを選択するかは、実際に使用する方法よりも重要ではありません。 どのシステムを使用する場合でも、インシデント (エンジニア、カスタマー サポート、管理、広報、法律など) にまったく接続できる可能性があるすべてのユーザーは、システムを検索する場所、インシデントを発生させる方法、必要に応じてデータにアクセスする方法を知る必要があります。 インシデント追跡で失敗する確実な方法の 1 つは、サポートされているユーザーに、必要なときにシステムにアクセスする方法 ("システムの URL が再び何でしたか") を知らないようにすることです。

このモジュールでは、例の追跡システムにAzure DevOpsの作業項目機能を使用します。

会話ブリッジを作成する

前の「知っていることを 評価 する」セクションの質問に回答し、インシデント対応プロセスを開始するには、インシデントについて他のユーザーと通信する方法が必要です。 電話ブリッジも同様に機能しますが、理想的には、これは会話のための何らかの"チームコラボレーション"電子媒体になります。 電話会議/電話ブリッジは、インシデント通信をさかのぼって確認するのが難しいため、あまり好ましくありません（したがって、前述の"Scribe"ロールが必要になります）。

どのような媒体を選択しても、このインシデントに関する議論に厳密に限定され、他に何もないユニークなチャネルを切り開く必要があります。 インシデント後のレビューでデータを取得して分析できる必要があるため、無関係な議論をこのチャネルから除外することが重要です。

このモジュールでは、インシデント通信方法としてMicrosoft Teamsを使用します。

インシデント追跡の起動を自動化する

それでは、ここまでにまとめた部分を確認しましょう。 私たちには次のものがあります：

• 通話中のユーザーの名簿 (およびユーザーに対して定義されたローテーション)。
• インシデントに取り組むユーザーに割り当てることができる役割。
• インシデントを宣言して追跡する特定の場所。
• そのインシデントに取り組んでいるユーザーが、そのインシデントについて伝える固有のチャネル。

これらのすべてのものの作成と管理は、可能な限り自動化でき、自動化する必要があります。 緊急の問題が発生した場合、インシデントを発生させ、適切なユーザーを呼び込んで追跡するために必要なすべての手順を思い出す必要はありません。 あなたが本当にしたいのは、作業がすぐに問題に対処し始めることができるように「go」ボタンを押すことができることです。

コードレス自動化に Logic Apps を使用する

最初の応答を自動化する 1 つの方法は、Logic Apps を使用することです。Logic Apps を使用すると、タスク、ビジネス プロセス、ワークフローのスケジュール設定、自動化、調整のジョブを簡略化できます。

Logic Apps は、統合ソリューションを構築するためのAzureクラウド サービスです。 コネクタを使用して自動化されたワークフローを作成します。 トリガーは、特定のイベントが発生したとき、またはデータが指定された条件を満たす場合に、ロジック アプリを起動します。 アクション は、ロジック アプリ ワークフローで実行される操作です。

この例では、インシデント追跡に次のロジック アプリ コネクタを使用します。

• Azure DevOps。これを使用して、Azure Boardsのインシデント作業項目を作成および追跡できます。
• Azure Table Storageを使って、当番の人に関する情報を保存および取得し、インシデントに対応するために適切な人々に通知することができます。 この例では、これを、呼び出し中の名簿データの単純なスキーマレス キー/属性ストアとして使用します。
• Microsoft Teams。これを使用して、エンジニアリング チームが特定のインシデントについて通信するときにリアルタイムで会話を追跡する、新しい固有のインシデント チャネルを作成できます。 これにより、インシデント後のレビューを実行するときに、後でイベントのタイムラインに関連する相互作用を保持できます。

それでは、これをロジック アプリと結び付けてみましょう。 まず、Logic Apps デザイナーに示されている完全なアプリを見た後、ステップごとに順を追って進めていきましょう。

最初の手順は、前述の HTTP 要求であるトリガーを処理することです。 HTTP POST 要求は、宣言するインシデントに関する情報を含む JSON ペイロードを含むロジック アプリに対して行われます。 そのペイロードを解析し、受信したことの確認を返信します。

この情報を使用して、このインシデントを表すAzure DevOps組織に新しい作業項目を作成します。

その後、インシデント用の新しいTeamsのチャネルが作成されます。

チャネルが作成されると、少し前に作成した作業項目が、新しいチャネルへのリンクで更新されます。 これにより、すべての情報が同じ場所 (作業項目) に保持され、後でそれを見ているユーザーは、そのチャネルに参加する必要がある場合に移動する場所を知ることができます。

次はオンコール担当者を状況に参加させる時です。 現在のオンコール エンジニアを識別する名簿エントリのAzure Table Storageクエリを実行します。 これにより JSON 応答が返され、次に解析されます。

クエリはリストを返すことができるため、次の手順として一致する各項目を反復処理する必要があります。 運用ワークフローでは、そのデータを使用して、プライマリ インシデント所有者とバックアップを特定します。 プライマリ レスポンダーはAzure DevOps作業項目に割り当てることができますが、追加のレスポンダーはリンクされたタスク、コメント、または通知を通じて追跡できます。

次に、最後の手順として、チャネルに参加し、そのインシデントの権限のある情報が格納されている場所を知りたいユーザーの作業項目へのポインターを含むメッセージを Teams チャネルに送信します。

これは、インシデント追跡と通信のメカニズムの設定を自動化する方法の 1 つの例にすぎません。 次のユニットでは、インシデントに関するコミュニケーションの側面についてもう少し詳しく説明します。