Amazon Web Services ブログ

AWS Systems Manager Incident Managerで連絡先、エスカレーションプラン、対応プランを作成する

多くのお客様はオペレーショナル・エクセレンスやパフォーマンス効率向上に効果的なインシデント管理やインシデント対応のソリューションを必要としています。インシデント管理プロセスでは、インシデントによって影響を受ける側と、インシデント対応を行う側の間にある透明性が重要になってきます。今発生しているアプリケーションやワークロードのインシデント対応について、どのチームが最適であるかを判断するには数時間かかることもあります。それに加えて、インシデント対応のプロセスはたいてい手動であり、多くの不確定要素が伴います。特にビジネスインパクトの大きいアプリケーションであればこの状況は望ましくありません。

お客様は多くの場合、社内でインシデントをどのように管理すべきかを課題に感じられていることがあります。 インシデント対応の管理をシンプルにするために、AWS Systems Managerの新機能としてIncident Managerがリリースされました。この機能には、Amazonでのインシデント管理におけるベストプラクティスが組み込まれています。Incident Managerを使用すると、適切な担当者を適切なタイミングでアサインし、インシデントの更新を追跡し、修復アクションを自動化し、チャットでの連携を可能にします。

このブログ記事は、二部構成のうちの一つ目となります。一つ目のブログ記事では、前提条件、オンボーティング、インシデント管理を行うためのコンポーネントの設定についてご紹介していきます。二つ目のブログ記事では、Incident ManagerをAmazon CloudWatchと統合する方法、Incident Managerのコンポーネントを使ったインシデント管理、インシデント発生後の分析の重要性についてご紹介していきます。

 

インシデントとは何か？

ここで言うインシデントとは、AWS環境にホストされているアプリケーションで発生する問題のことを指します。Amazon Elastic Compute Cloud(Amazon EC2)のLinuxインスタンスで稼働するアプリケーションについて考えてみましょう。このアプリケーションは、モニタリングにAmazon CloudWatchを利用しています。アプリケーションに急激なスパイクアクセスが発生し、CPU使用率が85%を超えました。このアプリケーションは、高負荷状態に対応する準備が出来ていなかったため、パフォーマンスが低下してしまいました。このような状況では、インシデントについて調査し、影響を軽減させるために、適切な担当者のアサインを行う対応プランが必要になってきます。

インシデントの影響を軽減させるためには、適切な連絡先を把握している必要があります。即時対応が必要であるが、最初の担当者と連絡がつかないようなシナリオでは、別の担当者にエスカレーションできるプランが必要です。適切な担当者がインシデント対応にアサインされた後は、インシデントの影響を軽減させるための詳細な手順が記載されたRunbook(手順書)が必要になります。特に重大なインシデントでは、対応者は大きなストレスにさらされ、作業ミスにつながる傾向があります。Runbook(手順書)があることで、担当者はインシデント調査及び管理方法について確認できるため便利です。連絡先、エスカレーションパス、Runbook(手順書)の組合せを「対応プラン」と呼びます。

 

前提条件

このウォークスルーを完了するためには、以下のリソースが必要となります

  • AWSアカウントとAmazon EC2、AWS Systems Manager、Amazon CloudWatchの権限を持ったAWS Identify Access and Management(IAM)。IAM ユーザまたはIAMロールには、 iam:CreateServiceLinkedRole の権限が付与されていること。Incident Managerは、 AWSServiceRoleforIncidentManagerロールを作成するためにこの権限を使います。詳細な情報については、コチラをご覧ください。
  • Incident ManagerがAWS Systems Manager automation runbookを実行するためのIAMロール。詳細については、コチラをご覧ください。
  • 詳細モニタリングが有効なLinuxのEC2インスタンス。このウォークスルーでは、t2.microのインスタンスタイプで充分です。このインスタンスは、Auto Scalingグループに所属させないでください。なぜかというと、このブログ記事の後半で、インシデント対応担当者がインスタンスをAuto Scalingグループに追加するためのRunbookを提供するためです。このRunbookはコマンドのスニペットによって作成します。EC2インスタンスへの接続方法については、Amazon EC2のLinuxインスタンス用ユーザーガイドのLinux インスタンスへの接続をご確認ください。

オンボーディングを完了させる

初めてIncident Managerを使う際は、オンボーディングを完了させる必要があります。すでにオンボーディングが完了している場合はこのセクションはスキップし、連絡先の追加のセクションへ進んでください。

  1. AWSマネージメントコンソールにサインインし、検索バーからIncident Managerを検索してください。
  2. Incident Managerのページで、Prepare(準備する)をクリックしてください。

図1: Incident Manager画面

  1. オンボーディングのウィザード画面から、対応プランの設定の流れが確認できます。General settings(全般設定)の下部にあるSet up(セットアップ)をクリックしてください。

図2: 対応プランのワークフロー

  1. Term and Conditions(利用規約)にて、記載内容をご確認いただき、チェックボックスにチェックを入れ、Next(次へ)をクリックしてください。

図3: 利用規約

  1. この手順では、レプリケーションセットを作成します。レプリケーションセットは、AWS Key Management Service(AWS KMS)を使用して、データの暗号化とクロスリージョンでのレプリケートを行います。AWSが所有するデフォルトキーまたは、個別で作成したキーを利用できます。このウォークスルーでは、レプリケーションセットに一つだけリージョンを設定します。もちろん複数のリージョンをレプリケーションセットに追加することも出来ます。詳細についてはコチラをご覧ください。

図4: レプリケーションセットの作成

レプリケーションセットの作成完了後、連絡先の追加セクションへお進みください。

 

連絡先の追加

連絡先には、インシデントに関わる可能性がある全てのユーザを含める必要があります。次の手順に沿って連絡先を追加していきましょう。

  1. AWS Systems Managerのコンソール画面から、Operations Management(運用管理)を開き、Incident Manager(インシデントマネージャー)を開きます。
  2. Contacts(連絡先)を選択し、Create contact(連絡先を作成)をクリックしてください。

図5: 連絡先を作成

  1. Contact Information(連絡先情報)画面にて、Name(名前)とContact channel(連絡先チャネル)を設定します。Contact channel(連絡先チャネル)はインシデント発生時、担当者に連絡をする手段になります。
  2. Contact channel(連絡先チャネル)設定では、Eメール、SMS、音声を選択出来ます。また、複数の連絡先チャネルを設定することが出来ます。実際のシナリオではインシデント対応の運用強化のため、連絡先の名前部分は一般的な用語ではなく、担当者の名前に置き換えます。

図6: 連絡先情報

  1. Engagement plan(エンゲージメントプラン)の設定では、担当者へ連絡が届くまでの時間を指定出来ます。図7は、インシデント発生から0分でEメール連絡、10分後にSMSで担当者に連絡が来る設定例です。入力項目を埋めたら、Create(作成)をクリックしてください。

図7: エンゲージメントプラン

追加した連絡先には、連絡先チャネルを確認するための6桁のアクティベーションコードが届きます。連絡先をアクティベートすると、その連絡先をエスカレーションプランに追加することが出来ます。

図8: 連絡先チャネルのアクティベーション

  1. (Optional)1-5の手順を繰り返し、別の連絡先を追加しましょう。このウォークスルーでは、別の連絡先としてエイリアス名：sr-incident-responder(訳注: 上位のインシデント対応者の意)を作成しました。実際のシナリオでは、連絡先の設定には個人またはチームを指定しましょう。

 

エスカレーションプランの作成

以下の手順に沿ってエスカレーションプランを作成しましょう。

  1. AWS Systems Managerのコンソール画面から、Operations Management(運用管理)を開き、Incident Manager(インシデントマネージャー)を開きます。
  2. Escalation plans(エスカレーションプラン)を選択し、Create escalation plan(エスカレーションプランを作成)をクリックしてください。

図9: エスカレーションプラン

  1. Create escalation plan(エスカレーションプランを作成)画面では、エスカレーションプランに含めるステージの数を指定出来ます。Stage 1(ステージ1)の設定では、Stage duration(ステージの期間)に5と入力します。最初に作成した連絡先をプライマリの連絡先として設定します。Contact name(連絡先名)の隣にあるチェックボックスをオンまたはオフにすることで、ステージ1に設定された担当者がインシデントに応答した後に、エスカレーションを停止するかどうかを指定します。

図10: プランの進行停止チェックボックス

  1. 別の連絡先を作成していた場合は、Stage 2(ステージ2)に連絡先を追加することが出来ます。ステージ1では、ステージ期間を5に設定しているため、ステージ1の担当者がインシデントの連絡に気付かなかった場合、5分後に次の連絡先であるsr-incident-responderに連絡が行われます。

図11: ステージ2

対応プランの作成

これでインシデントの対応プランを作成する準備が整いました。対応プランには、連絡先、エスカレーションプラン、Runbookが紐づきます。インシデントが発生すると、対応プランによって担当者、連絡方法、実行するRunbook、モニタリング対象のメトリクスが定義されます。明確に定義された対応プランを作成することで、インシデント対応の時間を削減出来ます。

  1. AWS Systems Managerのコンソール画面から、Operations Management(運用管理)を開き、Incident Manager(インシデントマネージャー)を開きます。
  2. Response plans(対応プラン)を選択し、Create response plan(対応プランを作成)をクリックしてください。

図12: 対応プラン

  1. Create response plan(対応プランを作成)画面にて、Name(名前)にEC2HighCPU、Title(タイトル)にcpu-incident-1、Impact(影響)にMedium(中)と設定します。

図13: 対応プランを作成

必要に応じて、担当者がチャットでコミュニケーションがとるために、AWS Chatbotチャネルを対応プランに設定できます。詳細については、コチラをご覧ください。

図14: チャットチャネル

  1. Engagements(エンゲージメント)の設定では、先ほど作成したエスカレーションプランを指定します。

図15: エンゲージメント

  1. Runbook(ランブック)の設定では、Clone runbook from template(テンプレートからランブックを複製)を選択し、Runbook name(ランブック名)にec2-cpu-util-runbookと入力します。
  2. Execution permissions(実行アクセス権限)では、Role name(ロール名)に、Incident Manager用のRunbookの実行権限を持ったIAMロールを設定します。このIAMロールは前提条件で作成したものになります。最後に、Create response plan(対応プランを作成)をクリックします。

図16: Runbook

  1. これで作成した対応プランを確認できます。Document(ドキュメント)の下にあるRunbook(ランブック)をクリックします。デフォルトのテンプレート(ec2-cpu-util-runbook)からクローンしたものです。このランブックはインシデントに適合するよう、後ほど修正します。

図17: ec2-cpu-util-runbook

  1. デフォルトのテンプレートから複製されたRunbookには、インシデントの影響を軽減させるための一般的な手順があります。Actions(アクション)から、Create new version(新しいバージョンを作成する)を選択します。

図18: ドキュメントの説明

  1. Create new version(新しいバージョンの作成)画面にて、Editor(エディタ)タブを選択し、Edit(編集)をクリックしてください。「ドキュメントエディタを使用して変更を加えた場合、Builder タブに戻ることはできません。」というメッセージが表示されたらOKをクリックします。

図19: エディタータブ

以下のコードをDocument editor(ドキュメントエディタ)にコピー&ペーストしてCreate new version(新しいバージョンの作成)をクリック。このコードスニペットは、担当者が手動でインシデント対応にあたるためのRunbookを作成します。インスタンスをAuto Scalingグループにアタッチする手順が記載されています。

description: |-
  This runbook walks you through how to resolve high CPU utilization of your EC2 instance by adding your instance to an Auto Scaling group. 
schemaVersion: '0.3'
mainSteps:
  - name: Inspect
    action: 'aws:pause'
    inputs: {}
    description: |- 
    
      Navigate to the **Amazon CloudWatch** console, determine the instance in question. Copy the source code of the metrics for CPU utilization.
      
  - name: AddMetrics
    action: 'aws:pause'
    inputs: {}
    description: |-
    
      Navigate back to **Incident Manager**, click the incident you are engaged to resolve. 
      Under the **Metrics** tab, click **Add**.  Select **From CloudWatch metrics**, and paste the metric source. Now you can start monitoring the CPU utilization throughout the incident.
      
  - name: AttachToAutoScalingGroup
    action: 'aws:pause'
    inputs: {}
    description: |- 
      
      1. Open the **Amazon EC2** console, navigate to **Instances**. Select the instance in question. 
      2. Choose **Actions**, then **Instance settings**. Click **Attach to Auto Scaling Group**. 
      3. On the *Attach to Auto Scaling group* page, for *Auto Scaling Group*, enter a name for the group, then choose **Attach**.
          The new Auto Scaling group is created using a new launch configuration with the same name that you specified for the Auto Scaling group. The 
          launch configuration gets its settings from the instance that you attached.
      4. On the left pane of the Amazon EC2 console, under **AUTO SCALING**, choose **Auto Scaling Groups**. Select the checkbox next to the new Auto 
      Scaling group you have just created, and choose the **Edit** button. Change the setting to Max size = 3. Choose **Update**.
      5. Under Automatic scaling, click **Add policy**. Choose *Target tracking scaling* and set the *Metric type* to *Average CPU utilization* of 50. Click **Create**.    
    
  - name: Validate
    action: 'aws:pause'
    inputs: {}
    description: |- 
    
      Navigate back to the incident under **Incident Manager**. Check out the **Metrics** tab. Observe the changes and validate that the incident has been resolved.
  
  - name: CloseIncident
    action: 'aws:pause'
    inputs: {}
    description: |- 
    
      After you validate that the incident has been resolved, you can close the incident.

以上の手順で対応プランが作成されました。このプランではインシデント対応者に連絡を行い、事前定義済みのランブックを提供することでインシデント影響の緩和を助けます。

二つ目のブログ記事では、作成したコンポーネントを使ったインシデント管理方法についてご紹介します。

まとめ

このブログ記事では、Incident Managerを使ってどのようにインシデント対応の準備を行い、インシデントの影響を軽減するかについてご紹介してきました。インシデント管理を成功させるには、準備が重要です。Incident Managerはエスカレーションプランと、独自のRunbookの作成に役立ちます。また、Slackで担当者に連絡する機能や、自動化されたRunbookの使用など、より多くの機能も提供します。詳細については、Incident Managerのユーザガイドをご覧ください。

 

著者について

Harshitha Putta

Harshitha Puttaは、シアトルに拠点を置く、AWSプロフェッショナルサービスのシニアクラウドインフラストラクチャーアーキテクトです。彼女は、AWSサービスを使い革新的なソリューションを構築して、お客様がビジネス目標を達成できるように尽力しています。家族や友人とはボードゲームやハイキングを楽しんでいます。

 

Guyu Ye

Guyu Yeは、テキサス州オースティンに拠点を置くAWSのクラウドアーキテクトです。彼女は、テクノロジーを通じてお客様の抱える複雑な問題をシンプルにするお手伝いを楽しんでいます。休日は、友人や家族との時間を過ごしたり、子犬のアルバートとハイキング、ヨガ、ランダムDIYプロジェクトに取り組むことが好きです。

 

 

翻訳はSA上野が担当しました。原文はコチラ