3分で分かるAmazon Q Developer Operational Investigations

Operational Investigationsとは

Amazon Q Developer の機能の一つで、CloudWatch と連携して発生中のインシデントを自動調査してくれる生成AIアシスタントです。
メトリクスやログ、デプロイイベントなどを横断的に分析し、関連しそうな原因や次に取るべきアクションを提示してくれます。

🔗 サポート対象 AWS サービス（公式ドキュメント）

使いどころ

✅ アラームから自動調査開始

CloudWatch アラーム（監視項目）が発火すると、自動で調査が始まります。
約10分ほどで調査が完了し、確認すべきコンポーネントや関連リソースを提案してくれます。

♻️ 調査の再利用

生成された仮説や調査ステップは履歴として残るため、類似インシデントの再発時に再利用できます。

動かしてみる

シナリオ

1. バグ(変数名のタイポ)を仕込んだPythonコードをLambda 関数 yyyにデプロイする
2. エラー数をしきい値にしてCloudWatchアラームを設定
3. API GatewayからLambda 関数 yyyを呼び出す
4. エラー発生 & Operational Investigations が自動で調査開始

発生するエラーログ

ERROR] NameError: name 'タイポ変数名' is not defined Traceback (most recent call last): File "/var/task/lambda_function.py", line 54, in lambda_handler

調査結果

※ 実際の出力は英語ですが、日本語で要約しています。

仮説として提案された内容

ユーザー `xxx` が Lambda 関数 `yyy` にコードをデプロイしたことが、一連の障害の引き金となりました。
デプロイしたコードには依存関係の不足や設定ミスなどの問題が含まれていた可能性があり、呼び出し時に Lambda 関数が失敗しました。
これらの Lambda 実行失敗は関数のメトリクスにおけるエラー率の増加として表れました。
このエラーは当該 Lambda 関数に依存する API Gatewayにも波及し、API Gateway レベルで 4XX および 5XX エラーが発生しました。

提案されたアクション

- `yyy` という Lambda 関数の CloudWatch ログを調査し、特定のエラーパターンを特定する
- ユーザー `xxx` が `yyy` Lambda 関数にデプロイした最近のコード変更を確認する
- API Gateway ログをチェックして、4XX および 5XX エラーの内容を理解する

まとめ

Operational Investigationsによる運用調査は、原因を特定する手掛かりを与えるものの、
必ずしもログに記載された具体的なエラー内容まで踏まえた提案をしてくれるわけではありませんでした。
それでも、アラート発生時の初動サポートは精度高く的確に行ってくれそうです。
運用現場での一次切り分け支援ツールとして非常に有用だと感じました。