

AWS Systems Manager Incident Manager は新規顧客に公開されなくなりました。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、「[AWS Systems Manager Incident Manager  可用性の変更](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-availability-change.html)」を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Incident Manager での対応計画の作成と設定
<a name="response-plans"></a>

対応計画を使用して、ユーザーに影響を与えるインシデントへの対応方法を計画します。対応計画はテンプレートとして機能するもので、エンゲージする担当者、イベントの予想される重大度、開始する自動ランブック、モニタリングするメトリクスに関する情報が含まれます。

**ベストプラクティス**  
事前にインシデントの計画を立てておくと、チームへのインシデントの影響を軽減できます。チームは、対応計画を作成する際に以下のベストプラクティスを考慮する必要があります。
+ **エンゲージメントの合理化** - インシデントに最も適したチームを特定します。エンゲージの範囲が広すぎたり、間違ったチームにエンゲージさせたりすると、混乱を招き、インシデント発生時に応答者の時間を無駄にする可能性があります。
+ **確実なエスカレーション** — 対応計画に取り組む場合は、連絡先やオンコールスケジュールではなく、エンゲージメント計画を選択することをお勧めします。エンゲージメント計画には、インシデント発生時にエンゲージする個々の連絡先またはオンコールスケジュール (複数の交代連絡先を含む) を指定する必要があります。エンゲージメント計画に指定されている応答者に連絡が取れないことがあるため、そのようなシナリオをカバーするために対応計画にバックアップ応答者を設定する必要があります。バックアップの連絡先を指定すると、主要連絡先と副連絡先が不在だったり、カバレッジにその他の予定外のギャップが生じたりした場合でも、Incident Manager はインシデントについて連絡先に通知します。
+ **ランブック** - 繰り返し可能でわかりやすいステップを提供するランブックを使用して、インシデント中に応答者が経験するストレスを軽減します。
+ **コラボレーション** - チャットチャネルを使用して、インシデント中のコミュニケーションを合理化します。チャットチャネルは、応答者が最新の情報を維持するのに役立ちます。応答者はこれらのチャネルを通じて他の応答者と情報を共有することもできます。

## 対応計画の作成
<a name="response-plans-create"></a>

以下の手順に従って対応計画を作成し、インシデント対応を自動化します。

**対応計画を作成するには**

1. [Incident Manager コンソール](https://console.aws.amazon.com/systems-manager/incidents/home)を開き、左のナビゲーションペインで、**[対応プラン]** を選択します。

1. **対応計画の作成**を選択します。

1. **[名前]** に、対応計画の Amazon リソースネーム (ARN) に使用する、一意で識別可能な対応計画名を入力します。

1. (オプション) **[表示名]** に、インシデントを作成するときに対応計画を識別するのに役立つ、わかりやすい名前を入力します。

1. 続けて、[インシデントレコードのデフォルト値を指定](#incident-defaults)します。

### インシデントデフォルト値の指定
<a name="incident-defaults"></a>

インシデントをより効果的に管理するために、デフォルト値を指定できます。Incident Manager は、これらの値を対応計画に関連するすべてのインシデントに適用します。

**インシデントのデフォルト値を指定するには**

1. **[タイトル]** に、Incident Manager のホームページで識別するのに役立つように、このインシデントのタイトルを入力します。

1. **[影響]** では、この対応計画から作成されるインシデントの潜在的な範囲を示す影響レベル (**[重大]** や **[低]** など) を選択します。Incident Manager での影響評価の詳細については、「[トリアージ](incident-lifecycle.md#triage)」を参照してください。

1. (オプション) **[概要]** に、この対応計画から作成されたインシデントのタイプの簡潔な概要を入力します。

1. (オプション) **[重複排除文字列]** は、重複排除文字列を入力します。Incident Manager は、この文字列を使用して、同じ根本原因が同じアカウントに複数のインシデントを作成しないようにします。

   重複排除文字列は、システムがインシデントの重複をチェックするために使用する用語またはフレーズです。重複排除文字列を指定すると、Incident Manager はインシデントを作成するときに `dedupeString` フィールドに同じ文字列が含まれる未解決のインシデントを検索します。重複が検出されると、Incident Manager は新しいインシデントを既存のインシデントに重複排除します。
**注記**  
デフォルトでは、Incident Manager は同じ Amazon CloudWatch アラームまたは Amazon EventBridge イベントによって作成された複数のインシデントを自動的に重複排除します。これらのリソースタイプの重複を避けるために、独自の重複排除文字列を入力する必要はありません。

1. (オプション) **[インシデントタグ]** の下に、この対応計画から作成されたインシデントに割り当てるタグキーと値を追加します。

   対応計画内にインシデントタグを設定するには、インシデントレコードリソースに対する `TagResource` アクセス許可が必要です。

1. 続いて、解決者どうしがインシデントについてやり取りするための[オプションのチャットチャネルを指定](#chat-channel)します。

### (オプション) インシデント対応チャットチャネルの指定
<a name="chat-channel"></a>

対応計画にチャットチャネルを含めると、応答者はこのチャネルを通じてインシデントの最新情報を受け取ります。応答者は、チャットコマンドを使用して、チャットチャネルから直接インシデントを操作できます。

チャットアプリケーションで Amazon Q Developer を使用すると、、Slack、Microsoft Teamsまたは Amazon Chime のチャネルを作成して、対応計画で を使用できます。チャットアプリケーションの Amazon Q Developer でチャットチャネルを作成する方法については、[https://docs.aws.amazon.com/chatbot/latest/adminguide/](https://docs.aws.amazon.com/chatbot/latest/adminguide/)」を参照してください。

**重要**  
Incident Manager には、チャットチャネルの Amazon Simple Notification Service (Amazon SNS) トピックに公開するための許可が必要です。この SNS トピックに公開する許可がない場合、対応計画に追加することはできません。Incident Manager は、SNS トピックにテスト通知を発行して、許可を検証します。

チャットチャネルの詳細については、「[Incident Manager でのレスポンダーのチャットチャネルの作成と統合](chat.md)」を参照してください。

**インシデント対応チャットチャネルを指定するには**

1. **チャットチャネル**では、インシデント中にレスポンダーが通信できるチャットアプリケーションチャットチャネルで Amazon Q Developer を選択します。
**ヒント**  
Amazon Q Developer でチャットアプリケーションで新しいチャットチャネルを作成するには、**「新しい Chatbot クライアントを設定する**」を選択します。

1. **[チャットチャネルの SNS トピック]** で、インシデント中に公開する追加の SNS トピックを選択します。複数の に SNS トピックを追加すると、インシデント発生時にリージョンがダウンした場合の冗長性 AWS リージョン が向上します。

1. 続いて、インシデント発生時にエンゲージする[連絡先、オンコールスケジュール、エスカレーション計画を選択](#engagements)します。

### (オプション) インシデント対応にエンゲージするリソースの選択
<a name="engagements"></a>

インシデントが発生したときに、最も適切な応答者を特定することが重要です。ベストプラクティスとして、以下を実行することをお勧めします。

1. エスカレーション計画のエスカレーションチャネルとして、連絡先とオンコールスケジュールを追加します。
**注記**  
現在、別のアカウントから共有された問い合わせを対応計画に追加する機能はサポートされていません。

1. 対応計画のエンゲージメントとして、エスカレーション計画を選択します。

連絡先とエスカレーション計画の詳細については、「[Incident Manager での問い合わせの作成と設定](contacts.md)」と「[Incident Manager でのレスポンダーエンゲージメントのエスカレーション計画の作成](escalation.md)」を参照してください。

**インシデント対応にエンゲージするリソースを選択するには**

1. **[エンゲージメント]** では、エスカレーション計画、オンコールスケジュール、個別の連絡先をいくつでも選択できます。

1. 続いて、オプションで、インシデント軽減の一環として[実行するランブックを指定](#runbook)します。

### (オプション) インシデント軽減のためのランブックの指定
<a name="runbook"></a>

のツールである [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) のランブックを使用して AWS Systems Manager、 AWS クラウド 環境内の一般的なアプリケーションおよびインフラストラクチャタスクを自動化できます。

各ランブックでは、ランブックワークフローを定義します。ランブックワークフローには、Systems Manager がマネージドノードまたは他の AWS リソースタイプで実行するアクションが含まれます。Incident Manager では、ランブックはインシデント対応とインシデントの軽減に役立ちます。

対応計画でのランブックの使用の詳細については、「[インシデント修復のために Systems Manager Automation ランブックを Incident Manager に統合する](runbooks.md)」を参照してください。

インシデント軽減のためのランブックを指定するには:

1. **[ランブック]** で、以下のいずれかを実行します。
   + **[テンプレートからランブックを複製]** を選択し、デフォルトの Incident Manager ランブックのコピーを作成します。**[名前]** に、新しいランブックのわかりやすい名前を入力します。
   + **[既存のランブックを選択]** を選択します。**[所有者]**、**[ランブック]**、使用する **[バージョン]** を選択します。
**ヒント**  
ランブックを一から作成するには、**[新しいランブックを設定]** を選択します。  
ランブックの作成の詳細については、「[インシデント修復のために Systems Manager Automation ランブックを Incident Manager に統合する](runbooks.md)」を参照してください。

1. **[パラメータ]** 領域で、選択したランブックに必要なパラメータを指定します。

   使用可能なパラメータは、ランブックに指定されているパラメータです。ランブックに応じて、別のランブックとは異なるパラメータが必要になることがあります。パラメータには必須のものとオプションのものがあります。

   多くの場合、Amazon EC2 インスタンス ID のリストなど、パラメータの静的な値は、手動で入力することを選択できます。インシデントによって動的に生成されたパラメータ値を Incident Manager に入力させることもできます。

1. (オプション) **[AutomationAssumeRole]** に、使用する AWS Identity and Access Management (IAM) ロールを指定します。このロールには、ランブック内に指定されている個々のコマンドの実行に必要なアクセス許可が必要です。
**注記**  
`AssumeRole` が指定されていない場合、Incident Manager はランブックサービスロールを使用して、ランブック内で指定されている個々のコマンドを実行しようとします。

   以下から選択します。
   + **[ARN 値を入力]** — AssumeRole の Amazon リソースネーム (ARN) を`arn:aws:iam::account-id:role/assume-role-name` 形式で手動で入力します。例えば、**arn:aws:iam::123456789012:role/MyAssumeRole**。
   + **[既存のサービスロールを使用]** — アカウント内の既存のロールのリストから、必要なアクセス許可を持つロールを選択します。
   + **新しいサービスロールの作成** – AssumeRole にアタッチする AWS 管理ポリシーから選択します。このオプションを選択した後、**[AWS マネージドポリシー]** で、リストから 1 つ以上のポリシーを選択します。

     新しいロールに提示されたデフォルト名を使用することも、選択した名前を入力することもできます。
**注記**  
この新しいランブックサービスロールは、選択した特定のランブックに関連付けられます。別のランブックでは使用できません。これは、ポリシーのランブックセクションが他のランブックをサポートしないためです。

1. **[ランブックサービスロール]** に、ランブック自体のワークフローへのアクセスと開始に必要なアクセス許可を提供するために使用する IAM ロールを指定します。

   少なくとも、このロールは、特定のランブックの `ssm:StartAutomationExecution` アクションを許可する必要があります。ランブックがアカウント間で動作するためには、[Incident Manager での AWS アカウント および リージョン間のインシデントの管理](incident-manager-cross-account-cross-region.md) 中に作成した `AWS-SystemsManager-AutomationExecutionRole` ロールに対する `sts:AssumeRole` アクションも許可する必要があります。

   以下から選択します。
   + **[新しいサービスロールを作成]** — Incident Manager は、ランブックワークフローを開始するために最低限必要なアクセス許可を含むランブックサービスロールを自動的に作成します。

     **[ロール名]** には、提示されたデフォルト名を使用することも、選択した名前を入力することもできます。この名前には、提示された名前を使用するか、ランブックの名前を残しておくことをお勧めします。これは、新しい AssumeRole には、選択した特定のランブックに関連付けられており、他のランブックに必要なアクセス許可が含まれていない可能性があるためです。
   + **[既存のサービスロールを使用]** — ユーザーまたは Incident Manager が以前に作成した IAM ロールは、必要なアクセス許可を付与します。

     **[ロール名]** で、使用する既存のロールの名前を選択します。

1. **追加オプション**を展開し、次のいずれかを選択して、ランブックワークフローを実行する AWS アカウント を指定します。
   + **対応計画所有者のアカウント** — ランブックワークフローを AWS アカウント 作成した で開始します。
   + **[影響を受けたアカウント]** — インシデントを開始または報告したアカウントでランブックワークフローを開始します。

     **[影響を受けたアカウント]** は、Incident Manager をクロスアカウントシナリオで使用していて、ランブックが影響を受けたアカウントのリソースにアクセスしてそれらを修正する必要がある場合に選択します。

      

1. 続いて、オプションで [PagerDuty サービスを対応計画に統合](#integrations)します。

### (オプション) PagerDuty サービスの対応計画への統合
<a name="integrations"></a>

**PagerDuty サービスを対応計画に統合するには**

Incident Manager を PagerDuty と統合すると、Incident Manager がインシデントを作成するたびに、PagerDuty は対応するインシデントを作成します。PagerDuty のインシデントは、Incident Manager に含まれるものに加えて、そこで定義したページングワークフローとエスカレーションポリシーを使用します。PagerDuty は、Incident Manager からのタイムラインイベントをインシデントに関するメモとしてアタッチします。

1. **[サードパーティ統合]** を展開し、**[PagerDuty 統合を有効にする]** チェックボックスをオンにします。

1. **[シークレットを選択]** で、PagerDuty アカウントにアクセスするための認証情報を保存する AWS Secrets Manager のシークレットを選択します。

   PagerDuty 認証情報を Secrets Manager のシークレットに保存する方法については、「[PagerDuty アクセス認証情報を AWS Secrets Manager シークレットに保存する](integrations-pagerduty-secret.md)」を参照してください。

1. **[PagerDuty サービス]** で、PagerDuty アカウントから PagerDuty インシデントを作成したいサービスを選択します。

1. 続いて、[オプションでタグを追加して対応計画を作成](#tags)します。

### タグを追加して対応計画を作成する
<a name="tags"></a>

**タグを追加して対応計画を作成するには**

1. (オプション) **[タグ]** 領域で、1 つ以上のタグキーの名前と値のペアを対応計画に適用します。

   タグは、リソースに割り当てるオプションのメタデータです。タグを使用して、目的、所有者、環境などのさまざまな方法でリソースを分類できます。例えば、軽減対象となるインシデントの種類、含まれるエスカレーションチャネルの種類、関連するエスカレーション計画を識別するために、対応計画にタグを付けることができます。Incident Manager リソースへのタグ付けの詳細については、「[Incident Manager でのリソースのタグ付け](tagging.md)」を参照してください。

1. **対応計画の作成**を選択します。

    