インシデントの事後レビュー プロセス

完了

インシデントの事後レビューの重要な部分は、インシデントの非線形な性質を反映する、共有された正確な時系列を構築することです。

非線形であるということは、インシデントはほとんど "これが起き、次にあれが起き、そこで気づき、何かしらの対応をし、完了した" のようなものではありません。さまざまな人が関係し、さまざまな人間が気づいてさまざまな行動を起こし、うまくいくものも、そうでないものもあります。 また、複数の人物が同時に作業している場合も、インシデントは同時に発生する可能性があり、より複雑になります。

このようなタイムラインを作成するには、複雑なものも含めて、常に重要な最初のステップとして、データの収集があります。

データを収集する

インシデントの事後レビューを実施する前に、まずデータを収集する必要があります。 具体的には、事象に関連する会話とコンテキスト (技術的および非技術的な両方) をできる限り収集することで、その中の重要なデータをすべて使用できるようにする必要があります。 停止またはインシデント中に発生したチーム メンバー間の会話は、最も豊富な情報源の 1 つです。

また、監視システムやインシデントに関係した人物がコンテキストを指摘した対象のデータを収集する必要があります。 インシデントが発生したときにシステムからどのような情報が得られたのでしょうか。

最後に、インシデントが発生したとき、変更がその要因となることが多いため、可能であればインシデントの直前または最中に変更された内容を把握しておくと役に立ちます。

このプロセスは、3 つの独立した部分として見ることができます。

  • 会話を収集します。このラーニング パスの他のモジュールでは、インシデントの間にコミュニケーションをとるための特定の場所を作成することが重要であることを説明しました。 インシデントが発生したときに、人々が成功したことと失敗したこと、試すのを躊躇していること、過去に試したことを共有することが理想的です。 このような、人々が取り組み、問題を解決する際の会話が、学習の最適な情報源です。
  • コンテキストを判断します。インシデントの関係者は、さまざまな場所からサインを受け取っています。 主なものの 1 つは監視システムです。 このラーニング パスの前のモジュールで、強固な監視システムを持つことの重要性について説明しました。 理想的には、監視システムを調べて、インシデントの前後または関係する期間の特定の時点のスナップショットを作成できるようにする必要があります。
  • 変化を見つけます。これを行うには、アクティビティ ログと監査ログを使用します。

データの収集に役立つ Azure ツール

Azure には、このプロセスに役立つさまざまなツールが用意されています。

インシデントに関するメタデータを保持するための Azure DevOps

このラーニング パスの前のモジュールでは、最初の対応からインシデントに関するすべての情報を収集するための単一の場所として、Azure DevOps suite の Azure Boards の使用について説明しました。 インシデントが最初に宣言されたタイミング、待機していた人物、インシデントに割り当てられた人物などに関する疑問に役立ちます。 また、Azure DevOps Wiki を一元的に使用して、インシデント自体と、インシデント中に発生した会話に関する情報の一部を取得することもできます。

会話を抽出するための Microsoft Graph API

Microsoft Graph API は、この特定のインシデント専用の Teams チャネル内で収集された会話を、プログラムによって検索、エクスポート、および取り込む方法を提供します。 取得されるデータには、チャネルに参加した人物 (とそのタイミング)、会話の個々の部分に関するタイムスタンプを含む時系列を構築するときに役立つメタデータも含まれます。

Microsoft Graph API を使い始める簡単な方法の 1 つは、Microsoft Graph エクスプローラーを使用することです。 Microsoft Graph エクスプローラーは、事前に設定されたオプションを選択することによって API 呼び出しを選択できる Web ベースの API ブラウザーです。 次のように表示されます。

Microsoft Graph エクスプローラー Web ページのスクリーンショット。

ここでは、一連の "Microsoft Teams" と "Microsoft Teams (ベータ)" の API 呼び出しのステップを進めて、会話を取得します。 各ステップで、クエリを選択してクエリを実行し、応答から次のステップに役立つ情報を選択します。 その後、この情報を使用して次の要求を作成します。 たとえば、最初にチーム ID の一覧のクエリを実行して、所属するチームを表示します。 応答から必要なものを選択し、ID を次のクエリ URL に入力してそのチームのチャネルの一覧を取得します。

ステップは次のとおりです。

  1. GET "参加済みチーム" (使用するチームのチーム ID を検索するため)。
  2. GET "私がメンバーであるチームのチャネル" (インシデントに使用したチャネルのチャネル ID を検索するため)。
  3. GET "チャネル内のメッセージ" (会話を取得するため)。

後からそれぞれのステップを実施するプログラムを構築したい場合 (実際にそうしたいのですが)、さまざまなプログラミング言語のクエリのサンプルコードを提示するコード スニペット オプションが要求ウィンドウにあります。

コンテキスト表示のためのターゲット ダッシュボード

Azure のダッシュボードは、運用上の認識のために重要な Azure Monitor からの情報を単一のページに集約することを可能にします。 ユーザー インターフェイスでは表示される期間を選択できるため、"時間を巻き戻して" インシデントに関係する期間のダッシュボード情報を表示することができます (Azure Monitor で保存されていないほど情報が古くなければ)。 この再構成されたユーザー インターフェイスは、インシデントの最中に人々が見たものを判断するのに役立ちますが、インシデントのレビューを行う人物が手動で適切な期間を検索する必要があります。

Azure のダッシュボードで見過ごされることが多い機能の 1 つに、ダウンロード (下矢印) ボタンを使用して表示されているあらゆるダッシュボードのテンプレートを JSON ファイルにダンプし、アップロード (上矢印) ボタンでロードすることができるというものがあります。 つまり、手動で適切なタイミングを検索して、その状態のダッシュボードをダウンロードして他者と JSON ファイルを共有するか、単に現在のダッシュボードして JSON を仕様に合わせて変更することができます。 ダウンロードした JSON ダッシュボード ファイルの "time" という文字列を検索すると、次のようなセクションが確認できます。

"metadata": {
  "model": {
    "timeRange": {
      "value": {
        "relative": {
          "duration": 24,
          "timeUnit": 1
        }
      },
      "type": "MsPortalFx.Composition.Configuration.ValueTypes.TimeRange"
    },
    "filterLocale": {
      "value": "en-us"
    },
    "filters": {
      "value": {
        "MsPortalFx_TimeRange": {
          "model": {
            "format": "utc",
            "granularity": "auto",
            "relative": "24h"
          },
          "displayCache": {
            "name": "UTC Time",
            "value": "Past 24 hours"
          },

このセクションを仕様に合わせて変更し、再アップロードします。 使用されているフォーマットになれていない場合は、ダッシュボードを手動で変更し、ダウンロードし、必要なフォーマットを確認できます。

変化の探索のための監査ログとログ分析

Log Analytics ワークスペースは、Azure アクティビティ ログを含む多くのソースからデータを取得できます。 まず、新しい Log Analytics ワークスペースを作成します。 次にポータルのアクティビティ ログ機能に異動し、[診断設定] を選択します。 これにより、新しいワークスペースに Azure サブスクリプション向けのアクティビティ ログを送信するオプションが得られます。

短時間で、Kusto クエリ言語 (KQL) のすべての力を使ってデータソースを接続してからそのサブスクリプションに起きた変化に関する詳細な情報を取得することができるようになります。

たとえば、次のクエリは、変更または削除されたリソースに関する情報を示しています。 必要であれば、クエリ エクスプローラーからクエリの期間を設定し、さらにインシデントの直前をより詳細に見ることができます。

AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatus, Caller
| order by TimeGenerated nulls first

注意: Azure アクティビティ ログをデータ ソースとして設定すると、その時点から情報が Log Analytics ワークスペースに流れ始めます。 接続の前に起きた事象についてデータをさかのぼってワークスペースにクエリを実行することはできません。

これらのツールは、インシデントの事後レビューで使用する時系列情報に必要な情報を収集し始めるために役立ちます。 インシデントの事後レビューを始める前に、一般的に陥りやすい問題について注意を喚起したいと思います。 それが次のユニットのテーマです。

自分の知識をチェックする

1.

レビュー後のプロセスを開始するための最初のステップは何ですか。

2.

インシデントの事後レビューでチームの会話を取得するのに役立つツールはなんですか?