# インシデントレポートでの 5 Why 分析の使用
インシデントレポートを生成するとき、CloudWatch 調査は 5 Why 根本原因分析を実行して、運用上の問題の基になる原因を体系的に特定できます。この構造化されたアプローチによりインシデントレポートが強化されて、インサイトの深さが増し、修復ステップが実行可能になります。
この機能は、チャットで会話できるように Amazon Q を使用します。AWS マネジメントコンソール にサインインするユーザーは、次のアクセス許可を持っている必要があります。
```
{
"Sid" : "AmazonQAccess",
"Effect" : "Allow",
"Action" : [
"q:StartConversation",
"q:SendMessage",
"q:GetConversation",
"q:ListConversations",
"q:UpdateConversation",
"q:DeleteConversation",
"q:PassRequest"
],
"Resource" : "*"
}
```
これらのアクセス許可を直接追加することも、[AIOpsConsoleAdminPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsConsoleAdminPolicy.html) または [AIOpsOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsOperatorAccess.html) マネージドポリシーをユーザーまたはロールにアタッチすることもできます。
## 5 Why 分析とは
5 Why は、「なぜ」を繰り返し、インシデントの症状から基本的な原因にドリルダウンする根本原因分析手法です。各回答が次の質問のベースとなり、単なる表面レベルの症状ではなく、真の根本原因を明らかにする論理チェーンが作成されます。
インシデントレポートの生成中、CloudWatch 調査はこの方法を使用して調査の検出結果を分析し、直接的な技術上の障害を超えてプロセス、設定、または体系的な問題を特定する構造化された根本原因分析を提供します。
## インシデントレポートにとっての利点
インシデントレポートに 5 Why 分析を含めると、いくつかの利点があります。
+ **包括的な根本原因の特定** - 直接的な技術的原因を超えて、基盤となるプロセスやシステムの問題を特定します。
+ **実行可能な修復計画** - 一時的な修正ではなく、具体的でターゲットを絞ったアクションを提供して、再発を防止します。
+ **組織学習** - 将来のリファレンスとチームの知識共有のために、完全な因果連鎖をドキュメント化します。
+ **構造化分析** - アドホックな問題解決ではなく、調査を体系的に行います。
## インシデントレポートのシナリオ例
### データベース接続障害インシデント
**起点となるインシデント:** E コマースアプリケーションで 500 件のエラーが広範囲に発生
1. **Why 1:** ユーザーに 500 件のエラーが発生するのはなぜですか? アプリケーションがプライマリデータベースに接続できないからです。
1. **Why 2:** アプリケーションがデータベースに接続できないのはなぜですか? データベースインスタンスで使用可能な接続を使い果たしたからです。
1. **Why 3:** データベースが接続を使い果たしたのはなぜですか? バッチ処理ジョブが多くの接続をオープンして適切にクローズしなかったからです。
1. **Why 4:** バッチジョブが接続を適切にクローズしなかったのはなぜですか? ジョブのエラー処理に障害シナリオでの接続クリーンアップが含まれないからです。
1. **Why 5:** 適切なエラー処理が実装されなかったのはなぜですか? コードレビュープロセスにリソース管理パターンに特化したチェックが含まれないからです。
**根本原因:** リソース管理に対するコードレビュー基準が不十分
**推奨されるアクション:** コードレビューチェックリストの更新、接続プーリングモニタリングの実装、自動リソースリーク検出の追加
### パフォーマンス低下インシデント
**起点となるインシデント:** API 応答時間がトラフィックの急増時に 200 ミリ秒から 5000 ミリ秒に増加
1. **Why 1:** 応答時間が長くなったのはなぜですか? すべてのアプリケーションインスタンスで CPU 使用率が 100% に達したからです。
1. **Why 2:** 自動スケーリングがインスタンスを追加しなかったのはなぜですか? 自動スケーリングがトリガーされましたが、新しいインスタンスがヘルスチェックに失敗したからです。
1. **Why 3:** 新しいインスタンスがヘルスチェックに失敗したのはなぜですか? アプリケーションのスタートアッププロセスには 8 分かかり、これがヘルスチェックのタイムアウトより長いからです。
1. **Why 4:** スタートアップに時間がかかるのはなぜですか? アプリケーションは、スタートアップのたびに S3 から大きな設定ファイルをダウンロードするからです。
1. **Why 5:** このスタートアップの遅延が自動スケーリング設定で考慮されなかったのはなぜですか? パフォーマンステストが、コールドスタートではなく、事前にウォームアップされたインスタンスで行われたからです。
**根本原因:** パフォーマンステストの方法に本番環境での自動スケーリングシナリオが反映されていないこと
**推奨されるアクション:** コールドスタートテストを含める、アプリケーションのスタートアップを最適化する、ヘルスチェックのタイムアウトを調整する、設定キャッシュを実装する
### 分析の分岐を伴う複雑なインシデント
**起点となるインシデント:** OpenSearch Serverless の顧客に対して 11 時間にわたる 48.3% の可用性低下
**メイン分析チェーン:**
1. **Why 1:** 顧客へのサービスが低下したのはなぜですか? インジェスタースケーリングが正しくないため、サービスの可用性が 48.3% に低下したからです。
1. **Why 2:** インジェスタースケーリングが正しくなかったのはなぜですか? CortexOperator が AZ バランスの計算ミスにより、インジェスターを 223 から 174 に減らしたからです。
1. **Why 3:** CortexOperator が AZ バランスを誤って計算したのはなぜですか? バージョン 1.17 へのアップグレード後、コードが新しい Kubernetes ラベル形式に対応できなかったからです。
1. **Why 4 (分岐 A - テクニカル):** コードが新しいラベル形式に対応しなかったのはなぜですか? コードは「failure-domain.beta.kubernetes.io/zone」ラベルを想定していましたが、Kubernetes 1.17 が「topology.kubernetes.io/zone」に変更したからです。
1. **Why 5 (分岐 A):** 下位互換性が実装されなかったのはなぜですか? デプロイ計画中にレビューされたアップグレードノートにラベル形式の変更が記載されていなかったからです。
**分岐 B - プロセス分析:**
1. **なぜ 4 (分岐 B - プロセス):** これがテストで捕捉されなかったのはなぜですか? 統合テストで古いラベル形式の事前設定済みクラスターを使用したからです。
1. **5 (分岐 B):** テストにラベル形式の検証が含まれなかったのはなぜですか? テスト環境の設定が本番環境の Kubernetes バージョンのアップグレードシーケンスを反映していなかったからです。
**特定された根本原因:**
+ テクニカル: Kubernetes ラベル形式の変更に対する下位互換性がない
+ プロセス: テスト方法が、バージョンのアップグレードの影響を検証するようになっていない
**統合した修復計画:** ラベル形式検出ロジックを実装し、アップグレードテストの手順を強化し、自動互換性検証を追加し、バージョン変更の影響評価プロセスを確立する。
## ガイド付き 5 Why ワークフローの使用
CloudWatch 調査には、欠落している事実への対処やインシデントレポートの強化に役立つ、ガイド付き 5 Why 分析ワークフローが用意されています。この機能は、システムが根本原因分析に強化する余地があると判断すると、推奨されるワークフローとして表示されます。
### インタラクティブな分析エクスペリエンス
CloudWatch 調査の 5 Why 分析では、調査プロセスをガイドするインタラクティブなチャットベースのアプローチを使用します。会話によるこの方法は、質問間の論理フローを維持しながら、分析を包括的にするのに役立ちます。
**インタラクティブエクスペリエンスの主な機能:**
+ **事実に基づいた初期設定** - システムは、調査から関連する事実を事前に提示し、それを使用して明らかな回答は事前に記入し、事実に基づく提案か推論に基づく提案かを明確に示します。
+ **ガイド付き探索** - 「なぜ」の質問ごとに、システムは利用可能な事実に基づいて回答を提案し、特定の追加コンテキストをリクエストし、先に進む前に重要な側面を考慮するようにガイドします。
+ **分岐管理** - 複数の要因が寄与していると特定されると、システムは分岐オプションを明確に提示し、分岐間の関係を説明し、並列調査の優先順位付けを補助します。
+ **段階的検証** - 応答ごとに、システムはわかりやすく回答を再編成し、確認を求め、主要なインサイトを強調し、検出結果をより広範なコンテキストに接続します。
このアプローチにより、最も重要な因果関係に焦点を当てながら、すべての関連情報を確実に取得できます。
**ガイド付きワークフローへのアクセス:**
1. インシデントレポートの生成中に、右側のパネルの **[注意が必要な事実]** セクションを確認してください。
1. **[推奨ワークフロー]** で **[ガイド付き 5-Why 分析]** の提案を探します。
1. **[ガイドしてください]** を選択して、インタラクティブな 5 Why のプロセスを開始します。
1. ガイド付きプロンプトに従って、「なぜ」の質問ごとに体系的に作業し、症状から根本原因までの完全な因果関係の連鎖を構築します。
ガイド付きワークフローは、5 Why 方法論の各ステップを順に進めて、包括的な根本原因情報を把握するのに役立ちます。分析結果はインシデントレポートに自動的に組み込まれ、インシデント後のレビューと組織学習のための構造化されたドキュメントになります。
また、「このインシデントに対して 5 Why 分析を実行する」や「5 Why 方法論を使用すると根本原因は何になりますか?」などの質問をすることで、チャットインターフェイスから 5 Why 分析をリクエストすることもできます。
## 複数の原因がある複雑なインシデントの処理
一部のインシデントには、並列分析パスを必要とする複数のコントリビューターが含まれます。CloudWatch 調査は、分岐分析をサポートし、確実にすべての重要な原因を特定し、対処します。
**分岐分析が必要な場合:**
+ 複数の独立した障害が同時に発生した場合
+ さまざまなシステムコンポーネントが同一の顧客への影響に寄与した場合
+ 技術的障害とプロセス障害の両方が重要な役割を果たした場合
+ 連鎖的障害により複数の因果関係の連鎖が作成された場合
**分岐分析プロセス:**
1. **分岐の特定** - システムは複数の原因が収束または分岐するポイントを特定します。
1. **並列調査** - 各分岐は、完全な 5 Why 方法論を使用して分析されます。
1. **接続マッピング** - 分岐間の関係は、それらがどのように相互作用するかを示すために文書化されています。
1. **統合された解決策** - 特定されたすべての根本原因とその相互作用に対処する修復計画
この包括的なアプローチにより、複雑なインシデントを徹底的な分析し、寄与するすべての要因に最終的な修復計画で対処します。
## 効果的な 5 Why 分析のベストプラクティス
インシデントレポートで 5 Why 分析の有効性を最大化するには、運用経験から導き出された以下のベストプラクティスに従います。
### 質問策定のガイドライン
+ **顧客への影響から始める** - ビジネスへの影響に焦点を当てるために、顧客が直面している問題から各分析を開始します。
+ **技術的な深さを段階的に増やす** - 質問を進めるにつれて、ビジネスへの影響から技術的な詳細に移行します。
+ **論理的な継続性を維持する** - 各回答が論理的なギャップなしに次の質問に自然につながるようにします。
+ **サポートする証拠を含める** - 具体的なメトリクス、ログ、またはタイムラインイベントを参照して、各回答を検証します。
### 分析の検証
以下の基準を使用して 5 Why 分析を検証します。
+ **論理フロー** - 欠落したステップがなく、症状から根本原因への進行が明確
+ **技術的正確さ** - 用語が正確、システム動作の説明が正確、コンポーネント間の相互作用が妥当
+ **完全性** - 分析では、観察されたすべての症状について説明し、対処すれば再発を防ぐ根本的な原因に到達している
+ **アクション可能性** - 特定された根本原因は、具体的で実装可能な修復アクションにつながる
### 回避すべき一般的な落とし穴
+ **症状で停止する** - 最初の技術的障害で分析を終了しないでください。システム的またはプロセス的な原因に到達するまで続行します。
+ **非難に焦点を当てた分析** - 個人のアクションではなく、システムとプロセスの障害に焦点を当てます。
+ **単一パス思考** - 複数のコントリビューターを考慮し、必要に応じて分岐分析を使用します。
+ **証拠が不十分** - 各回答が調査の具体的なデータでサポートされていることを確認します。
### インシデントレポートセクションとの統合
5 Why 分析は、インシデントレポートの他のセクションと統合され、次のような包括的なドキュメントになります。
+ **タイムラインの相関** - 「なぜ」の質問ごとに特定のタイムラインイベントを参照し、因果関係の時間的コンテキストを提供できる
+ **メトリクスの検証** - 回答が説明されている技術的な動作を示すメトリクスとグラフでサポートされている
+ **影響評価の調整** - 最初の「なぜ」が影響評価セクションに記載されている顧客への影響メトリクスに直接結びつく
+ **教訓の基礎** - 5 Why 分析によって特定された根本原因は、教訓セクションと是正措置セクションへの直接の情報源になる
この統合により、インシデントレポート全体の一貫性が確保され、初期症状から根本原因、修復計画まで、完全で一貫した説明が利害関係者に提供されます。