aws-investigation

AWS の調査

調査では、AWS アカウントで何が行われているかという問いに答えます。回答に含めるすべての主張は、読み取った情報、つまりデプロイ済みの成果物、サービス独自のログ記録、またはクエリ結果に基づいている必要があります。名前や説明、保存されている最新バージョン、あるサービスから見た別のサービスの状況に基づく推測は、調査の手掛かりにはなりますが、証拠にはなりません。

参照資料を選ぶ

調査を始める前に、質問に合った参照資料を読みます。多くの調査では、複数の資料が必要です。

質問の内容	読む資料
デプロイ済みシステムが現在行っていること、提供していること、実行していること：稼働中の設定、機能フラグ、パラメーター、実行中のコード、コードパスのクエリの再現、または最初のデータ経路が遮断されている状況	references/deployed-artifacts.md
複数のサービスにまたがるリクエスト、アラーム、インシデント：リクエストの追跡、失敗したリクエストの件数、イベントが失われた場所の特定	references/multi-service-logs.md
アカウント内のデータに関する事実：データの保存場所、正確な件数と内訳、レコードのフィルタリング、結合、エクスポート、失敗または一致しなかったレコードの背後にあるルール	references/data-investigation.md
調査結果が網羅的か、根本原因が妥当かどうか：すべてのリージョンとスコープの検索、件数を数える前のページネーション、日付範囲の網羅性、1つのエンティティと影響を受けた集団全体の違い、根本原因の一貫性、ランブックで原因を解決できるか、ユーザー自身の質問への回答	references/completeness-and-root-cause.md

すべての調査で守るルール

1. 諦める前に調べます。 認証情報は意図された環境のものと考えます。見慣れない用語や内部用語（サービスの通称、PDX = us-west-2、IAD = us-east-1 のような空港コード由来のリージョン名）は検索の手掛かりとして扱います。実行できないと判断する前に、該当しそうなリージョンでリソース、ロググループ、データストアを一覧表示し、リクエスト内の識別子を検索します。
2. 証拠と推測を分けます。 主張ごとに、出典を簡潔に記録します（claim <- artifact, record or query）。読み取っていない内容は、試した経路を示したうえで、仮説または 未検証 と明記します。
3. 正確に数えます。 エンジンで実行した集計クエリを使い、質問された範囲だけを対象にして、ユニークなエンティティ数と生のレコード数を分けて報告します。
4. 言い換えずに引用します。 識別子、フィールド値、エラーコード、メッセージは、null や空の値を含め、ソースに記録されたとおりに示します。
5. タスクを最後まで完了します。 求められた成果物（ファイル、表、計画）をすべて作成し、最終回答で前提条件を明記します。

最終確認リスト

分析を提出する前に、次の点を確認します。

1. 関連するすべてのリージョンとスコープを検索しましたか？
2. すべての結果をページネーションで確認し、要求された範囲のうち、どの部分にデータがあるかを示しましたか？
3. 失敗の範囲（特定のエンティティに限られるか、全体に及ぶか、影響を受けた集団全体）を確認しましたか？
4. 根本原因は、見つかったすべての事実と整合していますか？
5. 確認できなかった仕組みをすべて未検証と明記し、存在するはずだった場合に限り、欠落したコンポーネントを不具合として報告しましたか？
6. 稼働中の設定に関する主張は、保存されている最新バージョンではなく、デプロイ済みの成果物に基づいていますか（deployed-artifacts.md）？
7. サービスをまたぐリクエストについて、各サービス独自のログを読み、イベントごとに失敗した境界を特定しましたか（multi-service-logs.md）？
8. ユーザーの具体的な質問に直接答えましたか？
9. 作業を終える前に、収集した証拠の一つひとつと照らし合わせて結論を読み直し、矛盾する記述を削除しましたか？
10. 調査結果と推奨事項の矛盾を取り除き、ランブックの各選択肢が確認済みの原因に対処するものかどうかを確認しましたか？