

# Incident Detection and Response のワークロードのオンボーディングとアラームの取り込みに関するアンケート
<a name="idr-gs-questionnaire"></a>

このページでは、ワークロードを AWS Incident Detection and Response にオンボーディングする場合と、サービスに取り込むアラームを設定する場合に、入力する必要があるアンケートについて説明します。ワークロードのオンボーディングに関するアンケートでは、ワークロード、アーキテクチャの詳細、インシデント対応の問い合わせに関する一般的な情報をカバーします。アラームの取り込みに関するアンケートでは、Incident Detection and Response でワークロードのインシデントの作成をトリガーする重要なアラームと、誰に連絡すべきか、どのようなアクションを実行すべきかに関するランブック情報を指定します。アンケートへの適切な入力は、AWS ワークロードのモニタリングおよびインシデント対応プロセスを設定する重要なステップです。

[ワークロードオンボーディングのアンケート](https://d3oc37omrta8ht.cloudfront.net/AWS-Incident-Detection-and-Response-Workload-Onboarding-Questionnaire.xlsx)をダウンロードします。

[アラームの取り込みのアンケート](https://d3oc37omrta8ht.cloudfront.net/AWS-Incident-Detection-and-Response-Alarm-Ingestion-Questionnaire.xlsx)をダウンロードします。

## ワークロードオンボーディングのアンケート - 一般的な質問
<a name="idr-gs-questions-general"></a>


**一般的な質問**  

| 質問 | レスポンスの例 | 
| --- | --- | 
| エンタープライズ名 | Amazon Inc. | 
| このワークロードの名前 (略語を含む) | Amazon Retail Operations (ARO) | 
| プライマリエンドユーザーとこのワークロードの機能。 | このワークロードは、エンドユーザーがさまざまなアイテムを購入できるようにする e コマースアプリケーションです。このワークロードは、弊社のビジネスの主要な収益源です。 | 
| このワークロードに適用されるコンプライアンスおよび/または規制要件、インシデント発生後に AWS から要求されるアクション。 | ワークロードは、安全と機密性を保持する必要がある患者の健康記録を扱います。 | 

## ワークロードオンボーディングのアンケート - アーキテクチャに関する質問
<a name="idr-gs-questions-arch"></a>


**アーキテクチャに関する質問**  

| 質問 | レスポンスの例 | 
| --- | --- | 
| このワークロードの一部であるリソースを定義するために使用される AWS リソースタグのリスト。AWS は、これらのタグを使用してこのワークロードのリソースを識別し、インシデント中のサポートを迅速化します。 タグでは、大文字と小文字が区別されます。複数のタグを指定する場合、このワークロードで使用されるすべてのリソースに同じタグが必要です。 | appName: Optimax environment: Production | 
| このワークロードで利用される AWS のサービスとそれらが存在する AWS アカウントとリージョンのリスト。 各サービスごとに新しい行を作成します。 | Route 53: インターネットトラフィックを ALB にルーティングします。 アカウント: 123456789101 リージョン: US-EAST-1、US-WEST-2 | 
| このワークロードで利用される AWS のサービスとそれらが存在する AWS アカウントとリージョンのリスト。 各サービスごとに新しい行を作成します。 | ALB: ECS コンテナのターゲットグループに受信トラフィックをルーティングします。 アカウント: 123456789101 リージョン: 該当なし | 
| このワークロードで利用される AWS のサービスとそれらが存在する AWS アカウントとリージョンのリスト。 各サービスごとに新しい行を作成します。 | ECS: 主要なビジネスロジックフリートのコンピューティングインフラストラクチャ。受信ユーザーリクエストを処理し、永続化レイヤーにクエリを実行する役割があります。 アカウント: 123456789101 リージョン: US-EAST-1 | 
| このワークロードで利用される AWS のサービスとそれらが存在する AWS アカウントとリージョンのリスト。 各サービスごとに新しい行を作成します。 | RDS: Amazon Aurora クラスターは、ECS ビジネスロジックレイヤーによってアクセスされたユーザーデータを保存します。 アカウント: 123456789101 リージョン: US-EAST-1 | 
| このワークロードで利用される AWS のサービスとそれらが存在する AWS アカウントとリージョンのリスト。 各サービスごとに新しい行を作成します。 | S3: ウェブサイトの静的アセットを保存します。 アカウント: 123456789101 リージョン: 該当なし | 
| 停止が発生した場合にこのワークロードに影響を与える可能性のある、オンボードされていないアップストリーム/ダウンストリームコンポーネントの詳細。 | 認証マイクロサービス: 認証されていないため、ユーザーが健康記録を読み込めなくなります。 | 
| このワークロードにはオンプレミスコンポーネントまたは非 AWS コンポーネントがありますか。ある場合、それらはどのようなもので、どのような機能が実行されますか。 | AWS に出入りするすべてのインターネットベースのトラフィックは、オンプレミスのプロキシサービスを介してルーティングされます。 | 
| アベイラビリティーゾーンおよびリージョンレベルで、手動または自動フェイルオーバー/ディザスタリカバリプランの詳細を指定します。 | ウォームスタンバイ。成功率が持続的に低下している間の US-WEST-2 への自動フェイルオーバー。 | 

## アラームの取り込みのアンケート
<a name="idr-gs-questions-runbook"></a>


**ランブックに関する質問**  

| 質問 | レスポンスの例 | 
| --- | --- | 
| AWS は、サポート ケースを通じてワークロードの問い合わせをエンゲージします。このワークロードでアラームがトリガーされた場合、主な連絡先は誰ですか。 優先する会議アプリケーションを指定すると、AWS はインシデント中にこれらの詳細をリクエストします。 優先する会議アプリケーションが指定されていない場合、インシデント中に AWS が連絡を取り、参加できる Chime ブリッジを提供します。 | アプリケーションチーム app@example.com \$161 2 3456 7890 | 
| インシデント中に主な連絡先が利用できない場合は、希望する通信順序でエスカレーション連絡先とタイムラインを指定してください。  | 1. 10 分経過しても、主要連絡先から応答がない場合は、次の連絡先と連絡を取ります。 John Smith - アプリケーションスーパーバイザー john.smith@example.com \$161 2 3456 7890 2. 10 分経過しても、John Smith から応答がない場合は、次の連絡先と連絡を取ります。 Jane Smith - オペレーションマネージャー jane.smith@example.com \$161 2 3456 7890 | 
| AWS は、インシデント全体で一定の間隔で、サポートケースを通じて更新を伝達します。これらの更新を受け取る必要がある追加の連絡先はありますか。  | john.smith@example.com、jane.smith@example.com | 

## アラームのマトリックス
<a name="idr-gs-questions-alarm-matrix"></a>

ワークロードに代わってインシデントを作成するために AWS Incident Detection and Response をエンゲージする一連のアラームを特定するために、次の情報を提供します。AWS Incident Detection and Response のエンジニアがアラームを確認すると、追加のオンボーディング手順が提供されます。

**AWS Incident Detection and Response の重大なアラーム基準**:
+ AWS Incident Detection and Response のアラームは、オペレーターの即時対応を必要とするモニタリング対象のワークロードに、重大なビジネスへの影響 (収益の損失/カスタマーエクスペリエンスの低下) がある場合にのみ、「Alarm」状態に入る必要があります。
+ AWS Incident Detection and Response のアラームは、ワークロードのリゾルバーを同時に、またはエンゲージメントの前に、エンゲージさせる必要もあります。AWSIncident Managers は、緩和プロセスでリゾルバーと連携しますが、エスカレーションする第一線の応答者としては機能しません。
+ AWS Incident Detection and Response のアラームのしきい値は、アラームが発せられたときに調査が行われるように、適切なしきい値と期間に設定する必要があります。アラームが「Alarm」状態と「OK」状態の間で移動している場合、オペレータの応答と注意を必要とする十分な影響が発生しています。

**基準違反の AWS Incident Detection and Response ポリシー**:

これらの基準は、イベントが発生したときにケースバイケースでのみ評価できます。インシデント管理チームは、テクニカルアカウントマネージャー (TAM) と連携して、顧客のアラームがこの基準に準拠しておらず、一定の間隔で不必要にインシデント管理チームにエンゲージしていると疑われる場合、アラームを調整し、まれにモニタリングを無効にします。

**重要**  
連絡先アドレスを提供する際にグループ配布用の E メールアドレスを指定すると、ランブックを更新せずに受信者の追加と削除を制御できます。  
最初のエンゲージメント E メールを送信した後に AWS Incident Detection and Response チームから電話をもらいたい場合は、サイト信頼性エンジニアリング (SRE) チームの連絡先電話番号を指定します。


**アラームのマトリックスの表**  

| メトリクス名/ARN/しきい値 | 説明 | 注意事項 | リクエストされたアクション | 
| --- | --- | --- | --- | 
| ワークロードボリューム/ *CW Alarm ARN*/ 5 分以内に 5 つのデータポイントの CallCount が 100,000 未満の場合、欠落したデータを欠落として処理します。 | このメトリクスは、Application Load Balancer レベルで測定された、ワークロードへの受信リクエストの数を表します。 このアラームは重要です。受信リクエストの大幅な減少は、アップストリームネットワーク接続に問題があるか、DNS 実装に問題があり、その結果ユーザーがワークロードにアクセスできない可能性があるためです。 | アラームは先週 10 回「Alarm」状態になりました。このアラームは誤検出のリスクがあります。しきい値の見直しが計画されています。 問題は? いいえまたははい (いいえの場合は空白のまま): このアラームは、特定のバッチジョブの実行中に頻繁に入れ替わります。 リゾルバー: サイト信頼性エンジニア | *SRE@example.com* に E メールを送信して、サイト信頼性エンジニアリングチームを関与させます。 ELB および Amazon Route 53 サービスの AWS サポート ケースを作成します。 即時のアクションが必要な場合: EC2 の空きメモリ/ディスク容量を確認し、*Example* チームに E メールで通知してインスタンスを再起動するか、ログフラッシュを実行します。(即時のアクションが必要ない場合は空白のままにします) | 
| ワークロードリクエストのレイテンシー/ *CW Alarm ARN*/ 5 分以内に 5 つのデータポイントの p90 レイテンシーが 100 ミリ秒超の場合、欠落したデータを欠落として処理します | このメトリクスは、ワークロードによって実行される HTTP リクエストの p90 レイテンシーを表します。 このアラームは、レイテンシー (ウェブサイトのカスタマーエクスペリエンスの重要な指標) を表します。 | アラームは先週 0 回「Alarm」状態になりました。 問題は? いいえまたははい (いいえの場合は空白のまま): このアラームは、特定のバッチジョブの実行中に頻繁に入れ替わります。 リゾルバー: サイト信頼性エンジニア | *SRE@example.com* に E メールを送信して、サイト信頼性エンジニアリングチームを関与させます。 ECW および RDS サービスの AWS サポート ケースを作成します。 即時のアクションが必要な場合: EC2 の空きメモリ/ディスク容量を確認し、*Example* チームに E メールで通知してインスタンスを再起動するか、ログフラッシュを実行します。(即時のアクションが必要ない場合は空白のままにします) | 
| ワークロードリクエストの可用性/ *CW Alarm ARN*/ 5 分以内に 5 つのデータポイントの可用性が 95% 未満の場合、欠落したデータを欠落として処理します。 | このメトリクスは、ワークロードが満たすべき HTTP リクエストの可用性を表します。(HTTP 200 の数/リクエストの数) 期間あたり。 このアラームは、ワークロードの可用性を表します。 | アラームは先週 0 回「Alarm」状態になりました。 問題は? いいえまたははい (いいえの場合は空白のまま): このアラームは、特定のバッチジョブの実行中に頻繁に入れ替わります。 リゾルバー: サイト信頼性エンジニア | *SRE@example.com* に E メールを送信して、サイト信頼性エンジニアリングチームを関与させます。 ELB および Amazon Route 53 サービスの AWS サポート ケースを作成します。 即時のアクションが必要な場合: EC2 の空きメモリ/ディスク容量を確認し、*Example* チームに E メールで通知してインスタンスを再起動するか、ログフラッシュを実行します。(即時のアクションが必要ない場合は空白のままにします) | 
|   | 
| New Relic アラームの例 | 
| エンドツーエンドの統合テスト/ *CW Alarm ARN*/ 3 分間の期間で 1 分間のメトリクスの失敗率が 3% の場合、欠落しているデータを欠落として処理します。 ワークロード識別子: エンドツーエンドのテストワークフロー、AWS リージョン: US-EAST-1、AWS アカウント ID: 012345678910 | このメトリクスは、リクエストがワークロードの各レイヤーを通過できるかどうかをテストします。このテストが失敗した場合、ビジネストランザクションの処理に重大な障害があることを示しています。 このアラームは、ワークロードのビジネストランザクションを処理する能力を表します。 | アラームは先週 0 回「Alarm」状態になりました。 問題は? いいえまたははい (いいえの場合は空白のまま): このアラームは、特定のバッチジョブの実行中に頻繁に入れ替わります。 リゾルバー: サイト信頼性エンジニア | *SRE@example.com* に E メールを送信して、サイト信頼性エンジニアリングチームを関与させます。 Amazon Elastic Container Service と Amazon DynamoDB サービスの AWS サポート ケースを作成します。 即時のアクションが必要な場合: EC2 の空きメモリ/ディスク容量を確認し、*Example* チームに E メールで通知してインスタンスを再起動するか、ログフラッシュを実行します。(即時のアクションが必要ない場合は空白のままにします) | 