サポートケースレビューは何をしますか？

このスキルは、インシデント調査時にAWSサポートケース（現在のインシデントに関連するケース、または関連するコンテキスト、類似症状、実績のある修復手順を含む可能性のある過去のケース）をレビューする必要がある場合に使用します。

このスキルを使用するタイミング

アクティブなインシデントが、以前に解決された問題と症状を共有している場合。
過去24ヶ月以内に類似のサポートケースが提出されたか確認する必要がある場合。
現在のインシデントを既知のAWSサービスイベントと関連付けたい場合。
以前のケースからコミュニケーションや解決の詳細を取得する必要がある場合。
複数のサポートケースにわたって繰り返し発生するパターンを特定したい場合。

前提条件

AWSアカウントがBusiness Support、Enterprise Support、または Unified Operations プランを持っていること（AWS Support APIに必要）。
エージェントがターゲットアカウントで support:DescribeCases および support:DescribeCommunications を呼び出す権限を持っていること。
サポートケースデータは作成後24ヶ月間利用可能です。24ヶ月より古いケースはAPIで取得できません。

ステップ1: 現在のインシデントコンテキストを特定する

サポートケースを検索する前に、現在のインシデントから重要な詳細を収集します。

影響を受けたAWSサービス（例: EC2、RDS、Lambda、ELB）。
ログやアラームで観測されたエラーメッセージまたはエラーコード。
インシデントの時間枠（開始時間、期間）。
影響を受けたリソース（インスタンスID、ARN、エンドポイント名）。
症状（レイテンシのスパイク、5xxエラー、接続タイムアウト、スロットリング）。

これらの詳細をサポートケースをフィルタリングする際の検索条件として使用します。

ステップ2: 関連するサポートケースを検索する

AWS Support APIを使用して、関連性のあるケースを取得します。

最近のケースをすべて取得（オープンおよび解決済み）

aws support describe-cases \
  --include-resolved-cases \
  --include-communications \
  --after-time "<ISO-8601-start>" \
  --before-time "<ISO-8601-end>" \
  --language "en"

特定のケースIDでフィルタリング（既知の場合）

aws support describe-cases \
  --case-id-list "case-123456789010-muen-2024" \
  --include-communications

主要なフィルタリング戦略

戦略	適用方法
時間枠で絞り込む	`--after-time` と `--before-time` を使用して、該当期間（例: 過去30日間、または以前のインシデント日付前後）にケースを範囲指定します。最近のケースほど現在のインフラストラクチャ状態を反映している可能性が高いためです。
サービスで絞り込む	返されたケースの `serviceCode` フィールドを確認し、影響を受けたサービス（例: `amazon-elastic-compute-cloud`、`amazon-rds`）と一致させます。同じサービスでは繰り返し障害パターンが発生することが多いためです。
重要度で絞り込む	`severityCode` フィールドを確認し、重大なインシデントについては `urgent` および `critical` のケースに焦点を当てます。重要度の高いケースほど、AWSサポートから詳細な根本原因分析が得られる傾向があるためです。
ステータスで絞り込む	`--include-resolved-cases` を使用してクローズされたケースを含めます。解決済みケースには、現在のインシデントとの関連付けに最も価値のある根本原因と修復手順が含まれているためです。
件名キーワードで絞り込む	返されたケースの `subject` フィールドをスキャンし、現在のインシデント症状に一致するキーワードを探します。類似症状はしばしば同じ根本原因を共有するためです。

ステップ3: ケースコミュニケーションを確認する

includeCommunications: true を指定した describe-cases のレスポンスは、各ケースの最新のコミュニケーションを recentCommunications フィールド（最大5メッセージ）に返します。根本原因分析と解決手順は通常、解決済みケースの最終メッセージにあるため、これで十分なことがほとんどです。

recentCommunications フィールドに nextToken が含まれている場合、そのケースにはさらに古いメッセージがあります。最近のメッセージに明確な根本原因や解決策が含まれていない場合（例えば、最後のメッセージが最終回答ではなくフォローアップ質問である場合）にのみ、describe-communications を使用してページネーションを行います。

aws support describe-communications \
  --case-id "case-123456789010-muen-2024" \
  --max-results 10 \
  --next-token "<nextToken-from-recentCommunications>"

コミュニケーションを確認する際は、以下に注目します。

根本原因の記述 — AWSサポートエンジニアは最終応答で根本原因を要約することがよくあります。
修復手順 — 問題を解決するために実行された具体的なアクション（例: 「max_connections を増加」、「セキュリティグループルールを適用」、「インスタンスタイプをスケールアップ」）。
設定の推奨事項 — AWSが提供するベストプラクティスやチューニングの提案。
エスカレーションノート — ケースがエスカレーションされた場合、専門チームによるより詳細な技術分析を確認します。

ステップ4: 調査結果を現在のインシデントと関連付ける

関連するケースを確認した後、調査結果を関連付けます。

パターンマッチングチェックリスト

過去のケースは、同じ影響を受けたサービスとリソースタイプを共有していますか？
エラーメッセージまたはコードは同一または類似していますか？
過去のインシデントは、同じ時間帯または曜日に発生しましたか（負荷パターンを示唆）？
根本原因は、まだ存在している可能性のある設定の問題でしたか？
解決策は、期限切れまたは元に戻された一時的な回避策でしたか？
AWSは、繰り返し発生する可能性のあるサービス側の問題を特定しましたか？

ステップ5: 調査結果を要約する

構造化された要約を提供します。以下を含めます。

見つかった関連ケースの数 — 検索条件に一致した過去のケースの数。
最も関連性の高いケース — 上位一致のケースID、件名、ステータス、作成日。
過去の根本原因 — 過去に同様の問題を引き起こした原因。
過去の解決策 — 適用された修復手順と、それらが恒久的な修正か一時的な回避策か。
推奨事項 — 過去のパターンに基づいて、現在のインシデントに対する調査パスや修復手順を提案します。
繰り返しパターンのアラート — 同じ問題が複数回発生している場合、恒久的な修正やアーキテクチャ変更を必要とする繰り返し問題としてフラグを立てます。

決定木: ケース検索戦略

現在のインシデントに関連する既知のケースIDはありますか？
├── はい → その特定のケースとそのコミュニケーションを取得（ステップ2、ケースIDでフィルタリング）
└── いいえ → 以下に進む

影響を受けたAWSサービスは既知ですか？
├── はい → 過去90日間のそのサービスのケースを検索し、必要に応じて12ヶ月に拡大
└── いいえ → 過去30日間のすべてのケースを検索し、エラーキーワードでフィルタリング

関連する過去のケースは見つかりましたか？
├── はい → コミュニケーションを確認（ステップ3）、調査結果を関連付け（ステップ4）、要約（ステップ5）
└── いいえ → 検索条件を拡大:
         - 時間枠を拡大
         - 関連サービスで検索（例: ELBが影響を受けている場合、EC2およびターゲットグループのケースも確認）
         - ケース件名のエラーコードまたは症状キーワードで検索

効果的なケースレビューのためのヒント

狭く始めて、広げる: 特定のフィルター（サービス＋時間枠）から始め、関連ケースが見つからない場合にのみ拡大します。
解決済みケースを確認する: 最も価値のある情報は、根本原因と修正が文書化されている解決済みケースから得られることがよくあります。
ケースの重要度パターンに注目する: 同じ問題の過去のケースが critical 重要度で提出されていた場合、現在のインシデントも同様の緊急性を要する可能性があります。
デプロイメントと相互参照する: 過去のケースがデプロイメントによって引き起こされた場合、現在のインシデントの前に同様のデプロイメントが行われたか確認します。

スコア	基準
高	同じサービス、同じエラー、同じリソースタイプ、類似の時間枠
中	同じサービス、異なるエラーだが関連症状あり
低	異なるサービスだが、類似のアーキテクチャパターンまたは障害モード

サポートケースレビュー