インシデントの追跡
インシデントにはライフサイクルがあります。 最も効果的に対応するには、インシデント自体の進展と、それに対する対応の進展を、そのライフサイクルの最初から追跡できる必要があります。
自分の知識を評価する
特定のインシデントを使用してインシデント追跡手順を評価するには、次の一連の質問に答えてみることをお勧めします。
- 問題について最初に知ったのはいつですか。 インシデントからの復旧にかかる時間を短縮することが目標である場合は、問題を認識した時点から情報の取得を開始する必要があります。
- どのようにして問題の存在に気付きましたか。 監視システムからインシデントについてアラートが通知されましたか。 問題について最初に知ったのは、直接またはソーシャル メディアでのお客様の苦情からですか。
- 問題の存在に気付いた場合、問題について最初に知ったのはあなたですか。 その場合、誰に通知する必要がありますか。 そうでない場合、他には誰が問題を認識していますか。
- 他の誰かが認識している場合は、何が行われていますか。 他の誰かが調査していると全員が思っていませんか。対処するアクションを誰かが開始していますか。
- どのくらい深刻ですか。 重大度や影響の概念を欠いていると、問題の深刻度や誰が影響を受けるかに気付く余地がありません。
何も追跡されていない場合は、これらの質問に答えるのが難しかもしれません。
インシデント情報の追跡場所を標準化する
インシデント (アクティブまたはそれ以外) のリストと、それらのインシデントに関する現在のすべての情報を保持し、共有することが可能な場所は多数あります。 Word 文書を含む共有ファイル領域のように簡単なものも、高度に特殊化されたインシデント追跡ソフトウェアやサービスのように複雑なものもあります。 これらの両極の間にチケット発行システムと作業追跡システムがあり、このタスクに利用できます。 どのシステムを選択するかより、それをどのように使用するかの方が実際には重要です。 どのシステムを使用する場合でも、インシデントに少しでも関係している全員 (エンジニア、カスタマー サポート、管理、広報、法務など) が、システムが置かれている場所、インシデントを上げる方法、およびデータにアクセスする方法を必要なときに知っている必要があります。 システムで支援されるメンバーがシステムへのアクセス方法を必要なときに把握していないと ("システムの URL は何でしたっけ?")、インシデント追跡は必ず失敗します。
このモジュールでは、追跡システムの例として、Azure DevOps の作業項目機能を使用します。
会話ブリッジを作成する
前の「自分の知識を評価する」セクションにある一部の質問に回答し、インシデント対応プロセスを開始するには、インシデントについて他のメンバーと連絡を取る方法が必要です。 電話ブリッジでも同様に機能しますが、会話用の "チーム コラボレーション" 電子媒体のようなものが理想的です。 電話会議/電話ブリッジは、インシデントに関する連絡をさかのぼって確認するのが困難であるため (前述の "筆記者" ロール)、優先度が低くなります。
どのような媒体を選択する場合でも、このインシデントに関するディスカッションに限定された固有のチャネルに分けてください。 後にインシデント後レビューでデータを取得して分析できることが必要なため、関連性のないディスカッションをこのチャネルから排除することが重要です。
このモジュールでは、Microsoft Teams をインシデント連絡方法として使用します。
インシデント追跡の開始を自動化する
では、これまでにまとめた部分を見てみましょう。 次のものがあります。
- 待機メンバーの名簿 (および定義されたローテーション)。
- インシデントを担当しているメンバーに割り当てることができるロール。
- インシデントを宣言して追跡する特定の場所。
- インシデントを担当しているメンバーがそれに関する連絡を取るための固有のチャネル。
これらすべての作成と管理を自動化できます。また、可能な限り最大限にそうするべきです。 緊急の問題が発生したときに、インシデントを上げ、適切なメンバーを参加させ、インシデントを追跡するために、必要なすべての手順を思い出したくはないでしょう。 本当に必要なのは、"開始" ボタンを押すだけで、問題の処理をすぐに開始できることです。
コードなし自動化に Logic Apps を使用する
初期対応を自動化する方法の 1 つとして、Logic Apps を使用する方法があります。これにより、タスク、ビジネス プロセス、およびワークフローのスケジュール設定、自動化、および調整のジョブを簡略化できます。
Logic Apps は、統合ソリューションを構築するための Azure クラウド サービスです。 コネクタを使用して、自動化されたワークフローが作成されます。 特定のイベントが発生したとき、またはデータが指定された条件を満たしたときに、"トリガー" によってロジック アプリが起動されます。 アクションは、ロジック アプリ ワークフローで実行される操作です。
この例では、次のロジック アプリ コネクタを使用してインシデント追跡を行います。
- Azure Boards (Azure DevOps の一部)。これを使用して、問題/インシデントを作成および追跡できます。
- Azure Storage。インシデントに対応する適切なメンバーを割り当てることができるように、待機メンバーに関する情報を格納および取得できます。 この例では、Azure Table Storage を使用します。非常に単純な "キーと値" ストアが提供され、エンジニアとその待機状態の一覧を簡単に格納できるためです。
- Microsoft Teams。これを使用して、新しい固有のインシデント チャネルを作成し、エンジニアリング チームが特定のインシデントについて連絡を取るときに、その会話をリアルタイムで追跡することができます。 これにより、後でインシデントの事後レビューを実行するときに、イベントのタイムラインと関連付けて対話を保存できます。
それでは、これらすべてをロジック アプリに関連付けましょう。 まず、Logic Apps デザイナーに表示されるアプリ全体を見ていきます。次に、順を追って説明します。
最初の手順は、前述の HTTP 要求であるトリガーを処理することです。 ロジック アプリに対して HTTP POST 要求が行われます。これには、宣言するインシデントに関する情報を含む JSON ペイロードが含まれています。 ペイロードを解析し、受け取ったことを示す受信確認を送り返します。
この情報を使用して、このインシデントを表す新しい作業項目を Azure DevOps 組織に作成します。
その後、インシデントの新しい Teams チャネルが作成されます。
チャネルが作成されると、先ほど作成した作業項目が新しいチャネルへのリンクで更新されます。 これにより、すべての情報が同じ場所 (作業項目) に保持され、後でそれを見た人には、そのチャネルに参加したい場合のアクセス先がわかります。
ここで、待機メンバーについて見てみましょう。 Azure Table Storage で、"待機中" と示されているエンジニアのメール アドレスの検索を実行します。 これによって JSON 応答が返され、その後それを解析します。
クエリはリストを返すため、次の手順として、そのリスト内の各項目を反復処理する必要があります。 各メンバーに作業項目を割り当てます (インシデントの "所有者" になります)。
その後、最後の手順として、作業項目へのポインターを含むメッセージを Teams チャネルに送信します。チャネルに参加するメンバーは、そのインシデントに関する正式な情報が保存されている場所を知ることができます。
これは、インシデント追跡と連絡のメカニズムの設定を自動化する方法の一例にすぎません。 次のユニットでは、インシデントに関する連絡の側面についてもう少し詳しく説明します。