# 運用
**Topics**
+ [
# OPS 8. 組織でワークロードのオブザーバビリティを活用するにはどうすればよいでしょうか?
](ops-08.md)
+ [
# OPS 9. 運用の正常性はどのように理解するのですか?
](ops-09.md)
+ [
# OPS 10. ワークロードと運用イベントはどのように管理するのですか?
](ops-10.md)
# OPS 8. 組織でワークロードのオブザーバビリティを活用するにはどうすればよいでしょうか?
オブザーバビリティを活用して、ワークロードの最適な状態を確保します。関連するメトリクス、ログ、トレースを活用して、ワークロードのパフォーマンスを包括的に把握し、問題に効率的に対処します。
**Topics**
+ [
# OPS08-BP01 ワークロードメトリクスを分析する
](ops_workload_observability_analyze_workload_metrics.md)
+ [
# OPS08-BP02 ワークロードログを分析する
](ops_workload_observability_analyze_workload_logs.md)
+ [
# OPS08-BP03 ワークロードのトレースを分析する
](ops_workload_observability_analyze_workload_traces.md)
+ [
# OPS08-BP04 実践的なアラートを作成する
](ops_workload_observability_create_alerts.md)
+ [
# OPS08-BP05 ダッシュボードを作成する
](ops_workload_observability_create_dashboards.md)
# OPS08-BP01 ワークロードメトリクスを分析する
アプリケーションテレメトリを実装したら、収集したメトリクスを定期的に分析します。レイテンシー、リクエスト、エラー、容量 (またはクォータ) はシステムパフォーマンスに関するインサイトを提供しますが、ビジネス成果メトリクスの確認を優先することが不可欠です。これにより、ビジネス目標に沿ったデータ主導の意思決定を確実に行うことができます。
**期待される成果:** ワークロードのパフォーマンスを正確に把握することで、データに基づいた意思決定ができるようになり、ビジネス目標と合致させることができます。
**一般的なアンチパターン:**
+ ビジネス成果への影響を考慮せずに、メトリクスを個別に分析している。
+ ビジネス上のメトリクスは重視せず、過度に技術メトリクスに頼っている。
+ メトリクスを見直す頻度が低く、リアルタイムの意思決定を行う機会を逃している。
**このベストプラクティスを活用するメリット:**
+ 技術的なパフォーマンスとビジネス成果の相関関係についてより詳しく把握できます。
+ リアルタイムのデータに基づいて意思決定プロセスが改善されます。
+ ビジネス成果に影響が及ぶ前に、問題を事前に特定して軽減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
Amazon CloudWatch などのツールを活用してメトリクス分析を行います。特に静的なしきい値が不明な場合や動作パターンが異常検出に適している場合、CloudWatch 異常検出や Amazon DevOps Guru などの AWS サービスを異常検出に使用できます。
### 実装手順
1. **分析とレビュー:** ワークロードメトリクスを定期的に見直して分析します。
1. 純粋に技術的なメトリクスよりもビジネス成果メトリクスを優先します。
1. データ内のスパイク、ドロップ、パターンの重要性を理解します。
1. **Amazon CloudWatch を利用する:** Amazon CloudWatch を使用して、一元化されたビューと詳細な分析を行います。
1. メトリクスを可視化して時系列で比較できるように、CloudWatch ダッシュボードを設定します。
1. [CloudWatch でパーセンタイル](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/)を使用すると、メトリクスの分布を明確に把握できます。これは、SLA の定義や外れ値の理解に役立ちます。
1. [CloudWatch 異常検出](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)を設定して、静的なしきい値に依存せずに異常なパターンを特定します。
1. [CloudWatch クロスアカウントオブザーバビリティ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)を実装して、リージョン内の複数のアカウントにまたがるアプリケーションをモニタリングおよびトラブルシューティングします。
1. [CloudWatch Metric Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) を使用して、アカウントやリージョンのメトリクスデータをクエリして分析し、傾向や異常を特定します。
1. [CloudWatch Metric Math](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) を適用すると、メトリクスの変換、集計、または計算を実行して、より深いインサイトを得られます。
1. **Amazon DevOps Guru の導入:** 機械学習で強化された異常検出に [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) を組み込み、サーバーレスアプリケーションの運用上の問題の初期兆候を特定し、顧客に影響を与える前に修正します。
1. **インサイトに基づく最適化:** メトリクス分析を基盤に情報に基づいた意思決定を行い、ワークロードを調整して改善します。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 主要業績評価指標を特定する](ops_observability_identify_kpis.md)
+ [OPS04-BP02 アプリケーションテレメトリを実装する](ops_observability_application_telemetry.md)
**関連ドキュメント:**
+ [The Wheel ブログ - メトリクスの継続的なレビューの重要性](https://aws.amazon.com/blogs/opensource/the-wheel/)
+ [パーセンタイルは重要](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/)
+ [AWS Cost Anomaly Detection の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [CloudWatch クロスアカウントオブザーバビリティ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)
+ [CloudWatch Metrics Insights を使用してメトリクスをクエリする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
**関連動画:**
+ [Enable Cross-Account Observability in Amazon CloudWatch](https://www.youtube.com/watch?v=lUaDO9dqISc)
+ [Amazon DevOps Guru の概要](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [AWS Cost Anomaly Detection を使用してメトリクスを継続的に分析する](https://www.youtube.com/watch?v=IpQYBuay5OE)
**関連する例:**
+ [1 つのオブザーバビリティワークショップ](https://catalog.workshops.aws/observability/en-US/intro)
+ [Amazon DevOps Guru を使用して AIOps による運用上の洞察を得る](https://catalog.us-east-1.prod.workshops.aws/workshops/f92df379-6add-4101-8b4b-38b788e1222b/en-US)
# OPS08-BP02 ワークロードログを分析する
アプリケーションの運用面をより詳細に把握するには、ワークロードログを定期的に分析することが不可欠です。ログデータを効率的にふるい分け、可視化し、解釈することで、アプリケーションのパフォーマンスとセキュリティを継続的に最適化できます。
**期待できる成果:** 詳細なログ分析から得られるアプリケーションの動作と運用に関する豊富なインサイトを利用することで、積極的な問題の検出と軽減が実現します。
**一般的なアンチパターン:**
+ 重大な問題が発生するまでログの分析を怠っている。
+ ログ分析に利用できるツールをフルセットで使用していないため、重要なインサイトを見逃してしまう。
+ 自動化やクエリ機能を活用せずに、ログの手動確認のみに依存している。
**このベストプラクティスを活用するメリット:**
+ 運用上のボトルネック、セキュリティ上の脅威、その他の潜在的な問題を事前に特定できます。
+ ログデータを効率的に利用して、アプリケーションを継続的に最適化できます。
+ アプリケーションの動作に関してより詳細に把握できるようになり、デバッグとトラブルシューティングに役立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) は、ログ分析のための強力なツールです。CloudWatch Logs Insights や Contributor Insights などの統合された機能を使用すると、ログから意義ある情報を導き出すプロセスが直感的かつ効率的になります。
### 実装手順
1. **CloudWatch Logs の設定**: CloudWatch Logs にログを送信するようにアプリケーションとサービスを設定します。
1. **ログ異常検出を使用する:** [Amazon CloudWatch Logs の異常検出](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html)を使用して、異常なログパターンを自動的に識別し、警告します。このツールを使用すると、ログの異常を積極的に管理し、潜在的な問題を早期に検出できます。
1. **CloudWatch Logs Insights のセットアップ**: [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) を使用すると、ログデータをインタラクティブに検索し、分析することができます。
1. クエリを作成してパターンを抽出し、ログデータを可視化して、実践的なインサイトを導き出します。
1. [CloudWatch Logs Insights パターン分析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_Patterns.html)を使用して、頻繁なログパターンを分析および視覚化します。この機能は、ログデータの一般的な運用傾向と潜在的な外れ値を理解するのに役立ちます。
1. [CloudWatch Logs 比較 (差分)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_Compare.html) を使用して、異なる期間の間または異なるロググループの間で差分分析を実行します。この機能を使用すると、変更点を特定し、システムのパフォーマンスや動作への影響を評価できます。
1. **Live Tail を使用してログをリアルタイムでモニタリングする:** [Amazon CloudWatch Logs Live Tail](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs_LiveTail.html) を使用して、ログデータをリアルタイムで表示します。アプリケーションの運用アクティビティを発生時に積極的にモニタリングできるため、システムパフォーマンスと潜在的な問題を即座に把握できます。
1. **Contributor Insights の活用**: [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) を使用して、IP アドレスやユーザーエージェントなど、カーディナリティの高い次元でトップトーカーを特定します。
1. **CloudWatch Logs メトリクスフィルターの実装**: [CloudWatch Logs メトリクスフィルター](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)を設定して、ログデータを実用的なメトリクスに変換します。これにより、アラームを設定したり、パターンをさらに詳細に分析したりできます。
1. **[CloudWatch クロスアカウントオブザーバビリティ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)を実装する:** リージョン内の複数のアカウントにまたがるアプリケーションをモニタリングおよびトラブルシューティングできます。
1. **定期的なレビューと改善**: ログ分析戦略を定期的に確認して、すべての関連情報を収集し、アプリケーションのパフォーマンスを継続的に最適化します。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 主要業績評価指標を特定する](ops_observability_identify_kpis.md)
+ [OPS04-BP02 アプリケーションテレメトリを実装する](ops_observability_application_telemetry.md)
+ [OPS08-BP01 ワークロードメトリクスを分析する](ops_workload_observability_analyze_workload_metrics.md)
**関連ドキュメント:**
+ [CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [CloudWatch Contributor Insights の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html)
+ [CloudWatch ログメトリクスフィルターの作成と管理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
**関連動画:**
+ [Analyze Log Data with CloudWatch Logs Insights](https://www.youtube.com/watch?v=2s2xcwm8QrM)
+ [Use CloudWatch Contributor Insights to Analyze High-Cardinality Data](https://www.youtube.com/watch?v=ErWRBLFkjGI)
**関連する例:**
+ [CloudWatch Logs のサンプルクエリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [1 つのオブザーバビリティワークショップ](https://catalog.workshops.aws/observability/en-US/intro)
# OPS08-BP03 ワークロードのトレースを分析する
トレースデータの分析は、アプリケーションの運用過程を包括的に把握するために不可欠です。さまざまなコンポーネント間の相互作用を可視化して把握することで、パフォーマンスを微調整し、ボトルネックを特定し、ユーザーエクスペリエンスを向上させることができます。
**期待される成果:** アプリケーションの分散された運用を明確に可視化することで、より迅速な問題解決とユーザーエクスペリエンスの向上につながります。
**一般的なアンチパターン:**
+ トレースデータを見落とし、ログとメトリクスのみに依存している。
+ トレースデータが関連するログと関連付けられていない。
+ レイテンシーや障害率など、トレースから導き出されたメトリクスを考慮していない。
**このベストプラクティスを活用するメリット:**
+ トラブルシューティングを改善し、平均解決時間 (MTTR) を短縮します。
+ 依存関係とその影響についてのインサイトが得られます。
+ パフォーマンスの問題を迅速に特定して修正できます。
+ トレースから導き出されたメトリクスを活用して、情報に基づいた意思決定を行うことができます。
+ コンポーネントのインタラクションが最適化され、ユーザーエクスペリエンスの向上につながります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
[AWS X-Ray](https://www.docs.aws.com/xray/latest/devguide/aws-xray.html) は、トレースデータ分析のための包括的なスイートを提供し、サービスインタラクションの全体像の把握、ユーザーアクティビティのモニタリング、パフォーマンスに関する問題の検出を可能にします。ServiceLens、X-Ray Insights、X-Ray Analytics、Amazon DevOps Guru などの機能により、トレースデータから導き出される実践的なインサイトが向上します。
### 実装手順
次の手順は、AWS サービスを使用してトレースデータ分析を効果的に実装するための構造化されたアプローチを提供します。
1. **AWS X-Ray を統合する**: トレースデータをキャプチャするために、X-Ray をアプリケーションと統合します。
1. **X-Ray メトリクスの分析**: [サービスマップ](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html#xray-console-servicemap-view)を使用してアプリケーションのヘルスをモニタリングし、レイテンシー、リクエスト率、障害率、応答時間の分布など、X-Ray トレースから派生したメトリクスを詳しく調べます。
1. **ServiceLens を使用する**: [ServiceLens マップ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_service_map.html)を活用して、サービスとアプリケーションのオブザーバビリティを強化します。これにより、トレース、メトリクス、ログ、アラーム、その他のヘルス情報を総合的に確認できます。
1. **X-Ray Insights を有効にする**:
1. [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html) をオンにして、トレース内の異常を自動検出します。
1. インサイトを調べてパターンを特定し、障害率の増加やレイテンシーの増大などの根本原因を突き止めます。
1. 検出された問題を時系列で分析するには、インサイトタイムラインを参照します。
1. **X-Ray Analytics を使用する**: [X-Ray Analytics](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html) を使用すると、トレースデータを徹底的に調べたり、パターンを特定したり、インサイトを抽出したりできます。
1. **X-Ray でループを使用する**: X-Ray でグループを作成して、高レイテンシーなどの条件に基づいてトレースをフィルタリングすると、より的を絞った分析につながります。
1. **Amazon DevOps Guru を組み込む**: [Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)をエンゲージして、機械学習モデルが運用上の異常をトレースで特定する利点を活用します。
1. **CloudWatch Synthetics を使用する**: [CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html) を使用して Canary を作成し、エンドポイントとワークフローを継続的にモニタリングします。Canary を X-Ray と統合することで、テスト対象のアプリケーションを詳細に分析するためのトレースデータを提供できます。
1. **Real User Monitoring (RUM) を使用する**: [AWS X-Ray および CloudWatch RUM](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-RUM.html) を使用すると、アプリケーションのエンドユーザーからダウンストリームの AWS マネージドサービスまでのリクエストパスを分析およびデバッグできます。これにより、エンドユーザーに影響を与えるレイテンシーの傾向やエラーを特定できます。
1. **ログとの相関**: [トレースデータを X-Ray トレースビュー内の関連ログ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_troubleshooting.html#servicelens_troubleshooting_Nologs)と相関させて、アプリケーションの動作を詳細に把握します。これにより、トレース対象のトランザクションに直接関連するログイベントを確認できます。
1. **[CloudWatch クロスアカウントオブザーバビリティ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)を実装する:** リージョン内の複数のアカウントにまたがるアプリケーションをモニタリングおよびトラブルシューティングできます。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS08-BP01 ワークロードメトリクスを分析する](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 ワークロードログを分析する](ops_workload_observability_analyze_workload_logs.md)
**関連ドキュメント:**
+ [ServiceLens を使用したアプリケーションのヘルスのモニタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceLens.html)
+ [X-Ray Analytics を使用したトレースデータの検索](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html)
+ [X-Ray Insights を使用したトレースの異常検出](https://docs.aws.amazon.com/xray/latest/devguide/xray-insights.html)
+ [CloudWatch Synthetics を使用した継続的なモニタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
**関連動画:**
+ [Amazon CloudWatch Synthetics と AWS X-Ray を使用してアプリケーションを分析しデバッグする](https://www.youtube.com/watch?v=s2WvaV2eDO4)
+ [AWS X-Ray Insights を使用する](https://www.youtube.com/watch?v=tl8OWHl6jxw)
**関連する例:**
+ [1 つのオブザーバビリティワークショップ](https://catalog.workshops.aws/observability/en-US/intro)
+ [AWS Lambda を使用した X-Ray の実装](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html)
+ [CloudWatch Synthetics Canary テンプレート](https://github.com/aws-samples/cloudwatch-synthetics-canary-terraform)
# OPS08-BP04 実践的なアラートを作成する
アプリケーションの動作の逸脱を迅速に検出して対応することが重要です。特に重要なのは、主要業績評価指標 (KPI) に基づく成果がリスクにさらされている場合や、予期しない異常が発生した場合を認識することです。KPI に基づいてアラートを送信することで、受信される警告が直接的に業務や運用上の影響と関連付けられるようになります。実践的なアラートに関するこのようなアプローチを採用すると、積極的な対応の促進とシステムのパフォーマンスと信頼性の維持につながります。
**期待される成果:** 特に KPI の結果がリスクにさらされている場合に、潜在的な問題を迅速に特定して軽減するための、タイムリーで関連性のある実用的なアラートを受け取ることができます。
**一般的なアンチパターン:**
+ 重大ではないアラートを多数設定しすぎて、アラート疲れを引き起こしている。
+ アラートに KPI に基づく優先順位付けを行っていないため、問題が業務に及ぼす影響を把握できにくくなっている。
+ 根本原因への対処を怠っているため、同じ問題について繰り返しアラートが送信される。
**このベストプラクティスを活用するメリット:**
+ 実践的で関連性の高いアラートに重点を置くことで、アラート疲労を軽減します。
+ 問題を事前に検出して軽減することで、システムの稼働時間と信頼性が向上します。
+ 一般的なアラートツールやコミュニケーションツールと統合することで、チームのコラボレーションを強化し、問題を迅速に解決できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
効果的なアラートメカニズムを構築するには、KPI に基づく結果がリスクにさらされている場合や異常が検出された場合にフラグを立てるメトリクス、ログ、トレースデータを使用することが重要です。
### 実装手順
1. **主要業績評価指標 (KPI) を決定する**: アプリケーションの KPI を特定します。正確に業務への影響を反映するには、アラートをこのような KPI に関連付ける必要があります。
1. **異常検出の実装**:
+ **Amazon CloudWatch 異常検出を使用する**: [Amazon CloudWatch 異常検出](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)を設定して、異常なパターンを自動的に検出します。これにより、真の異常に関するアラートのみが生成されます。
+ **AWS X-Ray Insights の使用**:
1. [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html) を設定して、トレースデータの異常を検出します。
1. 検出された問題について警告するように、[X-Ray Insights の通知](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications)を設定します。
+ **Amazon DevOps Guru との統合**:
1. [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) の機械学習機能を活用して、既存データの運用上の異常を検出します。
1. DevOps Guru の [[通知設定]](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html#navigate-to-notification-settings) に移動して、異常アラートを設定します。
1. **実践的なアラートを実装する**: 迅速なアクションに必要な、適切な情報を提供するアラートを設計します。
1. [Amazon EventBridge ルールで AWS Health イベント](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)をモニタリングするか、プログラムで AWS Health API と統合して、AWS Health イベント受信時のアクションを自動化します。これらのアクションには、計画されたすべてのライフサイクルイベントメッセージをチャットインターフェイスに送信するなどの一般的なアクションや、IT サービス管理ツールでのワークフローの開始などの特定のアクションがあります。
1. **アラート疲れを軽減する:** 重要でないアラートを最小限に抑えます。多数の重要でないアラートによりチームに負担がかかると、重大な問題の見落としにつながり、アラートメカニズムの全体的な有効性が低下する場合があります。
1. **複合アラームを設定する**: [Amazon CloudWatch 複合アラーム](https://aws.amazon.com/bloprove-monitoring-efficiency-using-amazon-cloudwatch-composite-alarms-2/)を使用して、複数のアラームを統合します。
1. **アラートツールと統合する**: [Ops Genie](https://www.atlassian.com/software/opsgenie) や [PagerDuty](https://www.pagerduty.com/) などのツールを組み込みます。
1. **Amazon Q Developer in chat applications を利用する**: [Amazon Q Developer in chat applications](https://aws.amazon.com/chatbot/) との統合により、Amazon Chime、Microsoft Teams、Slack にアラートを中継します。
1. **ログに基づくアラート**: CloudWatch の[ログメトリクスフィルター](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)を使用して、特定のログイベントに基づいてアラームを作成します。
1. **レビューと反復**: アラート設定を定期的に見直して調整します。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 主要業績評価指標を特定する](ops_observability_identify_kpis.md)
+ [OPS04-BP02 アプリケーションテレメトリを実装する](ops_observability_application_telemetry.md)
+ [OPS04-BP03 ユーザーエクスペリエンステレメトリを実装する](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 依存関係のテレメトリを実装する](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 分散トレースを実装する](ops_observability_dist_trace.md)
+ [OPS08-BP01 ワークロードメトリクスを分析する](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 ワークロードログを分析する](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 ワークロードのトレースを分析する](ops_workload_observability_analyze_workload_traces.md)
**関連ドキュメント:**
+ [Amazon CloudWatch でのアラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [アラームの組み合わせ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [異常検出に基づいて CloudWatch アラームを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)
+ [DevOps Guru 通知](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html)
+ [X-Ray インサイト通知](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications)
+ [インタラクティブな ChatOps による AWS リソースのモニタリング、運用、トラブルシューティング](https://aws.amazon.com/chatbot/)
+ [Amazon CloudWatch 統合ガイド \$1 PagerDuty](https://support.pagerduty.com/docs/amazon-cloudwatch-integration-guide)
+ [OpsGenie を Amazon CloudWatch と統合する](https://support.atlassian.com/opsgenie/docs/integrate-opsgenie-with-amazon-cloudwatch/)
**関連動画:**
+ [Create Composite Alarms in Amazon CloudWatch](https://www.youtube.com/watch?v=0LMQ-Mu-ZCY)
+ [Amazon Q Developer in chat applications の概要](https://www.youtube.com/watch?v=0jUSEfHbTYk)
+ [AWS On Air: Amazon Q Developer in chat applications での Mutative Commands](https://www.youtube.com/watch?v=u2pkw2vxrtk)
**関連する例:**
+ [Amazon CloudWatch を使用したクラウドでのアラーム、インシデント管理、修復](https://aws.amazon.com/bloarms-incident-management-and-remediation-in-the-cloud-with-amazon-cloudwatch/)
+ [チュートリアル: Amazon Q Developer in chat applications に通知を送信する Amazon EventBridge ルールの作成](https://docs.aws.amazon.com/chatbot/latest/adminguide/create-eventbridge-rule.html)
+ [1 つのオブザーバビリティワークショップ](https://catalog.workshops.aws/observability/en-US/intro)
# OPS08-BP05 ダッシュボードを作成する
ダッシュボードは、ワークロードのテレメトリデータを理解しやすいように表示します。ダッシュボードは重要な視覚的インターフェイスを提供するとはいえ、アラートメカニズムに取って代わるものではなく、補完となるべきものです。考慮して作成することにより、システムのヘルスとパフォーマンスに関する迅速なインサイトが得られるのみでなく、ビジネス成果や問題の影響に関するリアルタイムの情報をステークホルダーに提供できます。
**期待される成果:**
視覚的な表示を使用して、システムとビジネスのヘルスに関する明確かつ実践的なインサイトが得られます。
**一般的なアンチパターン:**
+ メトリクスが多すぎてダッシュボードが必要以上に複雑化する。
+ 以上を検出するアラートを設定せずにダッシュボードに依存している。
+ ワークロードが進化してもダッシュボードが更新されない。
**このベストプラクティスを活用するメリット:**
+ 重要なシステムメトリクスと KPI を即座に可視化します。
+ 関係者のコミュニケーションと理解が強化されます。
+ 運用上の問題の影響についてのインサイトを迅速に把握できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
**ビジネス視点のダッシュボード**
ビジネス KPI に応じてカスタマイズしたダッシュボードは、幅広いステークホルダーのエンゲージメントを向上させます。関係者はシステムメトリクスに関心を持つとは限りませんが、このような数値のビジネスへの影響を把握することには熱心です。ビジネス視点のダッシュボードにより、モニタリングおよび分析されるすべての技術的および運用上のメトリクスが、包括的なビジネス目標に沿っていることを確認できます。このような調整により、透明性が実現し、重要な事項とそうでない事項について、組織全体のコンセンサスが得られます。さらに、ビジネス KPI を強調表示するダッシュボードは、より実践的となる傾向があります。関係者は、業務の状態、注意が必要な領域、ビジネス成果への潜在的な影響を迅速に把握できます。
これらの点を考慮に入れて、ダッシュボード作成の際は、技術的なメトリクスとビジネス KPI のバランスが取れていることを確認します。どちらも不可欠であるとはいえ、対象者は異なります。理想的には、システムのヘルスとパフォーマンスを包括的に把握すると同時に、主要なビジネス成果とその影響を強調表示するダッシュボードが求められます。
Amazon CloudWatch ダッシュボードは、CloudWatch コンソールにあるカスタマイズ可能なホームページであり、ダッシュボードを使用すれば、異なる AWS リージョンにまたがっているリソースでも、1 つのビューでモニタリングできます。
### 実装手順
1. **基本的なダッシュボードを作成する:** [CloudWatch で新しいダッシュボードを作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html)し、わかりやすい名前を付けます。
1. **マークダウンウィジェットを使用する:** メトリクスに絞り込む前に、[マークダウンウィジェットを使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_text_dashboard.html)してダッシュボードの上部にテキストコンテキストを追加します。これにより、ダッシュボードの内容、表示されるメトリクスの重要性を説明できます。説明には、その他のダッシュボードやトラブルシューティングツールへのリンクも記載できます。
1. **ダッシュボード変数を作成する:** 必要に応じて[ダッシュボード変数を組み込み](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html)、動的で柔軟なダッシュボードビューを許可します。
1. **メトリクスウィジェットを作成する:** [メトリクスウィジェットを作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html)して、アプリケーションが出力するさまざまなメトリクスを可視化し、ウィジェットを調整してシステムのヘルスとビジネス成果を効果的に表示します。
1. **Log Insights クエリを活用する:** [CloudWatch Log Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) を使用してログから実用的なメトリクスを取得し、ダッシュボードにこれらのインサイトを表示します。
1. **アラームを設定する:** [CloudWatch アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_alarm_dashboard.html)をダッシュボードに統合して、しきい値を超えているメトリクスを簡単に確認できるビューを提供します。
1. **Contributor Insights を使用する:** [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-ViewReports.html) を組み込み、高カーディナリティフィールドを分析し、リソースの上位コントリビューターをより明確に理解します。
1. **カスタムウィジェットを設計する:** 標準ウィジェットでは満たされない特定のニーズについては、[カスタムウィジェット](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_custom_widget_dashboard.html)の作成を検討してください。カスタムウィジェットを使用すると、さまざまなデータソースからデータを引き出したり、独自の方法でデータを表示したりできます。
1. **AWS Health を使用する:** AWS Health は、AWS クラウド リソースの正常性に関する信頼できるソースです。すぐに使える [AWS Health Dashboard](https://health.aws.amazon.com/health/status) を使用するか、独自のダッシュボードやツールで AWS Health のデータを使用して、情報に基づいた意思決定を行うための適切な情報を取得します。
1. **反復と改良を実施する:** アプリケーションの進化に応じて、定期的にダッシュボードを見直し、関連性を確認します。
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 主要業績評価指標を特定する](ops_observability_identify_kpis.md)
+ [OPS08-BP01 ワークロードメトリクスを分析する](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 ワークロードログを分析する](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 ワークロードのトレースを分析する](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 実践的なアラートを作成する](ops_workload_observability_create_alerts.md)
**関連ドキュメント:**
+ [運用を可視化するためのダッシュボードの構築](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**関連動画:**
+ [クロスアカウントとクロスリージョンの CloudWatch ダッシュボードを作成する](https://www.youtube.com/watch?v=eIUZdaqColg)
+ [AWS re:Invent 2021 - AWS クラウドオペレーションダッシュボードを使用してエンタープライズレベルの可視化を実現する](https://www.youtube.com/watch?v=NfMpYiGwPGo)
**関連する例:**
+ [1 つのオブザーバビリティワークショップ](https://catalog.workshops.aws/observability/en-US/intro)
+ [Amazon CloudWatch Application Insights を使用したアプリケーションモニタリング](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch/)
+ [AWS Health イベントインテリジェンスダッシュボードとインサイト](https://aws.amazon.com/blogs/mt/aws-health-events-intelligence-dashboards-insights/)
+ [Amazon Managed Grafana を使用して AWS Health イベントを視覚化する](https://aws.amazon.com/blogs/mt/visualize-aws-health-events-using-amazon-managed-grafana/)
# OPS 9. 運用の正常性はどのように理解するのですか?
運用メトリクスを定義し、キャプチャして、分析することによって運用イベントへの可視性が得られ、適切な措置を講じることができます。
**Topics**
+ [
# OPS09-BP01 メトリクスを使用して業務目標と KPI を測定する
](ops_operations_health_measure_ops_goals_kpis.md)
+ [
# OPS09-BP02 ステータスと傾向を伝達して運用の可視性を確保する
](ops_operations_health_communicate_status_trends.md)
+ [
# OPS09-BP03 運用メトリクスのレビューと改善の優先順位付け
](ops_operations_health_review_ops_metrics_prioritize_improvement.md)
# OPS09-BP01 メトリクスを使用して業務目標と KPI を測定する
業務の成功を定義する目標と KPI を組織から取得し、それを反映するメトリクスを決定します。基準点としてベースラインを設定し、定期的に再評価します。このようなメトリクスをチームから収集して評価するメカニズムを開発します。[DevOps Research and Assessment (DORA)](https://dora.dev/guides/dora-metrics-four-keys/) メトリクスは、ソフトウェア配信の DevOps プラクティスへの進捗状況を測定する一般的な方法を提供します。
**期待される成果:**
+ 組織はオペレーションチームの目標と KPI を公開して共有します。
+ このような KPI を反映したメトリクスを確立します。以下はその例です。
+ チケットキューの長さ、またはチケットの平均経過時間
+ 問題の種類別のチケット数
+ 標準業務手順書 (SOP) の有無を問わず、問題の処理に費やした時間
+ 失敗したコードプッシュからの回復に費やされた時間
+ 通話ボリューム
**一般的なアンチパターン:**
+ デベロッパーがトラブルシューティングタスクに追われてしまうため、デプロイの期限が守れない。開発チームは追加の人員を求めていますが、開発作業に取り組めなかった時間を測定できないため、必要な人数がわからない。
+ Tier 1 デスクが、ユーザーからの電話に対応するために設置され、時間が経つにつれて、ワークロードは増えましたが、Tier 1 デスクへの人員は追加されない。通話時間が長くなり、問題が解決されないまま問題が長引くと、顧客満足度は低下するが、経営陣にはそのような兆候が明らかでないため、対策がとられていない。
+ 問題のあるワークロードは、メンテナンスのために別の運用チームに引き継がる。その他のワークロードとは異なり、この新しいワークロードには適切なドキュメントとランブックが付属していないため、チームはトラブルシューティングや障害への対処に時間を費やすが、これを文書化するメトリクスがないため、説明責任が困難となる。
**このベストプラクティスを活用するメリット:** ワークロードのモニタリングはアプリケーションとサービスのステータスを示すのに対し、モニタリングオペレーションチームは、ビジネスニーズの変化など、ワークロードのコンシューマー間の変化についてオーナーにインサイトを提供します。運用状況を反映するメトリクスを作成することで、チームの有効性を測定し、ビジネス目標に照らして評価できます。メトリクスでは、サポート上の問題を浮き彫りにしたり、サービスレベル目標から逸脱した時期を特定したりできます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
業務部門のリーダーおよび関係者とサービスの全体的な目標を決定します。さまざまな業務チームのタスクがどうあるべきか、またどのような課題に取り組むことができるかを判断します。これらを使用して、これらの業務目標を反映すると思われる主要業績評価指標 (KPI) についてブレインストーミングを行います。これには、顧客満足度、機能の構想からデプロイまでの時間、平均問題解決時間、コスト効率などが含まれます。
KPI に基づいて、このような目標を最もよく反映すると思われるメトリクスとデータソースを特定します。顧客満足度は、通話の待ち時間や応答時間、満足度スコア、発生した問題の種類など、さまざまなメトリクスを組み合わせたものです。デプロイ時間は、テストとデプロイに必要な時間に加えて、デプロイ後に追加する必要のある修正を加算したものである場合があります。さまざまな種類の課題に費やされた時間 (またはそれらの課題の数) を示す統計値から、集中的に取り組む必要がある個所を把握できます。
## リソース
**関連ドキュメント:**
+ [Quick - KPI を使用する](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html)
+ [ Amazon CloudWatch メトリクスの使用 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [ ダッシュボードの構築 ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [ KPI ダッシュボードでコスト最適化 KPI を追跡する方法 ](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
+ [AWS DevOps ガイダンス ](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)
**関連する例:**
+ [ ネイティブの AWS モニタリングツールとオブザーバビリティツールを使用してソフトウェア配信のパフォーマンスをモニタリングする ](https://catalog.us-east-1.prod.workshops.aws/workshops/3b7f3d77-c6ef-44b2-aa29-d2719b8be897/en-US)
+ [ DORA メトリクスを使用してデプロイの速度と安定性のバランスをとる ](https://aws.amazon.com/blogs/devops/balance-deployment-speed-and-stability-with-dora-metrics/)
+ [金融サービス業界における MLOps 運用メトリクスの例](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-unlock-value-data-financial-services/operational-metrics.html)
+ [How to track your cost optimization KPIs with the KPI Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
# OPS09-BP02 ステータスと傾向を伝達して運用の可視性を確保する
運用のステータスと傾向の方向性を把握することとは、その結果がリスクにさらされる可能性がある時期、追加の作業をサポートできるかどうか、または変更がチームに及ぼす影響を特定するために必要です。運用イベント中に、ユーザーや運用チームが情報を参照できるステータスページを提供することにより、コミュニケーションチャネルの負担を軽減し、情報を積極的に広めることができます。
**期待される成果:**
+ 運用リーダーは、チームがどのような種類のコール数に対応して業務を行っているのか、デプロイなど、どのような取り組みが進行中であるかを一目で把握できます。
+ 通常の運用に影響が及ぶ場合、アラートが関係者やユーザーコミュニティに配信されます。
+ 組織のリーダーや関係者は、アラートや影響に応じてステータスページを確認したり、連絡先、チケット情報、推定復旧時間など、運用上のイベントに関する情報を取得したりすることができます。
+ 経営陣やその他の関係者には、特定期間のコール数、ユーザー満足度スコア、未処理のチケット数、チケットの経過時間などの運用に関する統計値を表示するレポートが提供されます。
**一般的なアンチパターン:**
+ ワークロードがダウンして、サービスが利用できなくなります。ユーザーは何が起こっているのかを問い合わせるため、コール数が急増します。マネージャーは、問題に対処している担当者を突き止めるために問い合わせをするため、さらに負荷が増大します。さまざまな運用チームが個別に調査を行うため、作業が重複します。
+ 新しい機能が必要になると、そのエンジニアリング業務に数人の担当者が再配置されます。運用への補完人員が提供されないため、問題解決に要する時間が急増します。このような情報はキャプチャされていないため、数週間経って不満を抱くユーザーからのフィードバックが寄せられるようになってからやっと経営陣は問題に気づきます。
**このベストプラクティスを活用するメリット:** 業務に影響が及ぶ運用上のイベントの場合、状況を理解しようとするさまざまなチームからの情報請求の問い合わせに、多くの時間と労力が浪費される可能性があります。広範囲にステータスを伝えるステータスページとダッシュボードを提供することで、関係者は、問題が検出されているか、問題解決のリーダーは誰か、通常の運用に戻る予想時間はいつか、などの情報を迅速に入手できます。これにより、チームメンバーはその他のメンバーへのステータスの伝達に多くの時間を費やす必要がなくなり、問題の対処により多くの時間を割くことができます。
さらに、ダッシュボードとレポートを使用すると、意思決定者やステークホルダーにインサイトを提供し、運用チームがビジネスニーズにどのように対応できるか、およびそのリソースがどのように配分されているかを確認できます。これは、ビジネスをサポートするのに十分なリソースが存在するかどうかを判断するために重要です。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
運用チームの現在の主要メトリクスを表示するダッシュボードを構築して、運用リーダーと経営陣の両方が簡単にアクセスできるようにします。
迅速に更新できるステータスページを作成して、インシデントやイベントの発生時、担当者、対応の調整担当者などを表示できます。ユーザーが考慮すべき手順や回避策をこのページで共有し、このページの場所を広範囲に周知させます。未知の問題に直面した場合は、まずこの場所を確認するようにユーザーに勧めます。
長期にわたる運用のヘルスを説明するレポートを収集して提供し、リーダーや意思決定者に配布して、運用の作業状況を課題やニーズとともに説明します。
目標と KPI を最適な方法で反映し、変化を推進するうえで影響を及ぼした点を示すメトリクスとレポートをチーム間で共有します。このような取り組みに時間を割いて、チーム内とチーム間での運用の重要性を強化します。
独自のダッシュボードで [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) を使用するか、AWS Health イベントを統合することで、チームがアプリケーションの問題を AWS のサービスのステータスに関連付けられるようにします。
## リソース
**関連するベストプラクティス:**
+ [OPS09-BP01 メトリクスを使用して業務目標と KPI を測定する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html)
**関連ドキュメント:**
+ [ 進捗状況を測定する ](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/measure-progress.html)
+ [ 運用を可視化するためのダッシュボードの構築 ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
**関連する例:**
+ [ データオペレーション ](https://aws.amazon.com/solutions/app-development/data-operations)
+ [ KPI ダッシュボードでコスト最適化 KPI を追跡する方法 ](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
+ [大規模なクラウド移行における重要業績評価指標 (KPI) の重要性](https://aws.amazon.com/blogs/mt/the-importance-of-key-performance-indicators-kpis-for-large-scale-cloud-migrations/)
# OPS09-BP03 運用メトリクスのレビューと改善の優先順位付け
運用のステータスをレビューする時間とリソースを確保することで、日常業務への対応が優先事項として維持されていることを確認できます。運用リーダーと関係者を集めて、定期的にメトリクスのレビューを行い、目標と目的を再確認したり変更したりして、改善の優先順位を決めます。
**期待される成果:**
+ 運用リーダーとスタッフは定期的にミーティングを開き、特定の報告期間におけるメトリクスのレビューを行います。課題が伝達され、成功が認知され、学んだ教訓が共有されます。
+ 関係者と業務部門のリーダーは定期的に運用状況について説明を受け、目標、KPI、将来のイニシアチブに関する意見を求められます。サービスの提供、運用、メンテナンスの間のトレードオフが議論され、考慮されます。
**一般的なアンチパターン:**
+ 新製品が発売されたのに、Tier 1 と Tier 2 の運用チームがサポートを提供できるだけのトレーニングを受けていなかったり、追加のスタッフが割り当てられたりしていません。チケットの解決時間の短縮やインシデント件数の増加を示すメトリクスは、リーダーに確認されていません。数週間後、不満を抱いているユーザーがプラットフォームの利用を止めてサブスクリプション数が減少し始めてから対策が講じられます。
+ 長い間、ワークロードのメンテナンスを手動で実行するプロセスが実行されていました。自動化を望む声はありましたが、システムの重要性が低いため、低い優先順位が付けられていました。しかし、時間が経つにつれて、システムの重要性が高まり、現在ではこのような手動プロセスに運用時間の大半を費やしています。運用に追加のツールを提供するためのリソース計画がないため、作業負荷が増加するにつれてスタッフが燃え尽き症候群に陥ります。スタッフが離職してその他の競合他社に転職している報告を受けて、やっと経営陣が事態を把握します。
**このベストプラクティスを活用するメリット:** 組織によっては、サービスの提供や新しい製品や新しいサービスに費やされるのと同様の時間と注意を費やすことが難しい場合があります。この場合、期待されるサービスのレベルが徐々に低下し、業務部門が損害を受ける可能性があります。これは、事業の成長に伴って運用が変化したり進化したりせず、すぐに遅れをとったままになる可能性があるためです。運用部門が収集したインサイトを定期的に確認しなければ、事業に関するリスクは手遅れになるまで明らかにならない可能性があります。運用スタッフと経営陣の両方にメトリクスと手順をレビューする時間を割り当てることで、運用が果たす重要な役割の可視性が維持され、リスクが重大なレベルとなるよりもかなり前もってリスクを特定できます。運用チームは、今後起こる事業上の変化やイニシアチブについてより的確なインサイトを取得できるため、積極的な対処ができるようになります。経営陣への運用メトリクスの可視化により、チームが顧客満足度において内外の両方で果たす役割が示されるため、優先順位の選択の検討がより適切になり、新しいビジネスやワークロードの取り組みに応じて変更したり進化したりするための時間とリソースを確実に運用に対して確保できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
関係者と運用チーム間の運用メトリクスのレビューを行う時間を割いて、レポートのデータを確認します。このようなレポートを組織の目標と目的の文脈内で考察し、目標や目的が達成されているかどうかを判断します。目標が明確でない場合や、需要と提供されている内容の間に矛盾が生じる可能性がある場合は、あいまいさの原因を特定します。
時間、人材、ツールが運用の成果に貢献している個所を特定します。これがどの KPI に影響し、どのような目標を成功に導くべきかを判断します。定期的に見直して、事業部門をサポートするうえで十分なリソースが運用にあることを確認します。
## リソース
**関連ドキュメント:**
+ [ Amazon Athena ](https://aws.amazon.com/athena/)
+ [ Amazon CloudWatch メトリクスとディメンションのリファレンス ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Amazon Quick](https://aws.amazon.com/quicksight/)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)
+ [Amazon CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ [ Amazon CloudWatch メトリクスを使用する ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# OPS 10. ワークロードと運用イベントはどのように管理するのですか?
イベントに対応する手順を準備して検証し、それらによるワークロードの中断を最小限に抑えます。
**Topics**
+ [
# OPS10-BP01 イベント、インシデント、問題管理のプロセスを使用する
](ops_event_response_event_incident_problem_process.md)
+ [
# OPS10-BP02 アラートごとにプロセスを用意する
](ops_event_response_process_per_alert.md)
+ [
# OPS10-BP03 ビジネスへの影響に基づいて運用上のイベントの優先度を決定する
](ops_event_response_prioritize_events.md)
+ [
# OPS10-BP04 エスカレーション経路を決定する
](ops_event_response_define_escalation_paths.md)
+ [
# OPS10-BP05 サービスに影響するイベント発生時の顧客コミュニケーション計画を定義する
](ops_event_response_push_notify.md)
+ [
# OPS10-BP06 ダッシュボードでステータスを知らせる
](ops_event_response_dashboards.md)
+ [
# OPS10-BP07 イベントへの対応を自動化する
](ops_event_response_auto_event_response.md)
# OPS10-BP01 イベント、インシデント、問題管理のプロセスを使用する
イベント、インシデント、問題を効率的に管理する能力は、ワークロードの正常性とパフォーマンスを維持するために不可欠です。これらの要素の違いを認識し、理解することが、対応と解決の効果的な戦略を策定するうえで極めて重要です。各側面に対して明確に定義されたプロセスを確立し、それに従うことで、チームは運用面で生じる課題に迅速かつ効果的に対処できます。
**期待される成果:** 組織は、適切に文書化され、一元的に保存されたプロセスを介して、運用上のイベント、インシデント、問題を効果的に管理します。これらのプロセスは随時見直され、変更を反映させることで、処理を効率化し、サービスの信頼性とワークロードのパフォーマンスを高く維持します。
**一般的なアンチパターン:**
+ イベントに先回りして対応するのではなく、事後対応になる。
+ さまざまなタイプのイベントやインシデントに対するアプローチに一貫性がない。
+ 組織が、再発防止のためのインシデントの分析や学習を行わない。
**このベストプラクティスを活用するメリット:**
+ 対応プロセスが合理化され、標準化されます。
+ インシデントがサービスや顧客に与える影響を軽減します。
+ 問題解決を早めます。
+ 運用プロセスが継続的に改善されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
このベストプラクティスを実装すると、ワークロードイベントを追跡することになります。インシデントと問題を扱うためのプロセスができます。プロセスは文書化され、共有され、頻繁に更新されます。問題が特定され、優先順位が付けられ、修正されます。
**イベント、インシデント、問題の理解**
+ **イベント:** イベントの例として、アクションの観察、発生、状態の変化があります。イベントは計画的な場合も計画外の場合もあり、ワークロードの内部または外部から発生する可能性があります。
+ **インシデント:** インシデントとは、予定外の中断やサービス品質の低下など、対応が必要なイベントのことです。これらは、ワークロードを通常運用に復旧するために早急な対応を迫られる障害です。
+ **問題:** 問題は、1 つ以上のインシデントの根本原因です。問題を特定して解決するには、再発防止のため、インシデントを掘り下げて調査することなどが必要です。
### 実装手順
**イベント**
1. **イベントのモニタリング:**
+ [オブザーバビリティを実装](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/implement-observability.html)し、[ワークロードオブザーバビリティを活用](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/utilizing-workload-observability.html)します。
+ ユーザー、ロール、AWS サービスによって実行されたアクションを監視します。これらのアクションは、[AWS CloudTrail](https://aws.amazon.com/cloudtrail/) イベントとして記録されます。
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/) を使用して、アプリケーションで運用上の変更にリアルタイムに対応します。
+ [AWS Config](https://aws.amazon.com/config/) を使用して、リソース構成の変更を継続的に評価、監視、記録します。
1. **プロセスを作成する:**
+ どのイベントが重要でモニタリングが必要かを評価するプロセスを考案します。正常なアクティビティと異常なアクティビティのしきい値やパラメータの設定などを行います。
+ イベントをインシデントにエスカレートする基準を決定します。これは、重大度やユーザーへの影響、想定される動作から逸脱しているかどうかなどに基づいて行います。
+ イベントの監視と対応のプロセスを定期的に見直します。例えば、過去のインシデントの分析、しきい値の調整、警告メカニズムの改善などを行います。
**インシデント**
1. **インシデントに対応する:**
+ オブザーバビリティツールから得たインサイトを活用して、インシデントを迅速に特定し、対応します。
+ [AWS Systems Manager Ops Center](https://aws.amazon.com/systems-manager/features/#OpsCenter) を実装して、運用上の問題とインシデントを集約して整理し、優先順位を付けます。
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) および [AWS X-Ray](https://aws.amazon.com/xray/) などのサービスを使用して、より詳細な分析とトラブルシューティングを行います。
+ インシデント管理を強化するには [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) を検討して、その事前対処、予防、検出機能を活用します。AMS は、モニタリング、インシデントの検出および対応、セキュリティ管理などのサービスで運用サポートを拡張します。
+ エンタープライズサポートのお客様は、[AWS Incident Detection and Response](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/) を使用できます。これにより、本番ワークロードの継続的なプロアクティブモニタリングとインシデント管理が可能になります。
1. **インシデント管理プロセスを作成する:**
+ 役割、コミュニケーションプロトコル、解決手順などを明確に定義した、構造化されたインシデント管理プロセスを確立します。
+ インシデント管理を [Amazon Q Developer in chat applications](https://aws.amazon.com/chatbot/) などのツールと統合して、効率的な対応と調整を実現します。
+ インシデントを重大度別に分類し、事前定義された[インシデント対応計画](https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html)を各カテゴリに設定します。
1. **学習して改善する:**
+ [インシデント後の分析](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_perform_rca_process.html)を実施して、根本原因と解決の有効性を理解します。
+ 見直しと変化する慣行に基づいて、対応計画を継続的に更新および改善します。
+ 学んだ教訓を文書化し、チーム全体で共有することで、業務のレジリエンスを強化します。
+ エンタープライズサポートのお客様は、テクニカルアカウントマネージャーに[インシデント管理ワークショップ](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)をリクエストできます。このガイド付きワークショップでは、既存のインシデント対応計画をテストし、改善すべき点を明らかにすることができます。
**問題点**
1. **問題を特定する:**
+ 過去のインシデントからのデータを活用して、システム上の深層の問題を示唆している可能性のある、反復的なパターンを洗い出します。
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) や [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) などのツールを活用して傾向を分析し、根本的な問題を発見します。
+ 運用、開発、ビジネスユニットなど、部門横断的なチームを組織し、多様な視点から根本原因を探ります。
1. **問題管理プロセスを作成する:**
+ 構造化された問題管理プロセスを開発し、その場しのぎの修正ではなく長期的な解決策に焦点を当てます。
+ 根本原因分析 (RCA) 手法を取り入れて、インシデントの根本原因を調査し、理解します。
+ 検出結果に基づいて運用ポリシー、手順、インフラストラクチャを更新し、再発を防ぎます。
1. **継続的に改善する:**
+ 絶え間ない学習と改善の文化を育み、潜在的な問題を先回りして特定し、対処することをチームに奨励します。
+ ビジネスとテクノロジーにおける環境の変化に応じて、問題管理のプロセスとツールを定期的に見直し、改訂します。
+ 組織全体でインサイトとベストプラクティスを共有して、よりレジリエントで効率的な運用環境を構築します。
1. **AWS サポートと連携する:**
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) などの AWS サポートリソースを使用して、プロアクティブなガイダンスや最適化のレコメンデーションを行います。
+ Enterprise Support のお客様は、[AWS Countdown](https://aws.amazon.com/premiumsupport/aws-countdown/) などの専用プログラムを利用して、重要なイベント中のサポートを受けられます。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 主要業績評価指標を特定する](ops_observability_identify_kpis.md)
+ [OPS04-BP02 アプリケーションテレメトリを実装する](ops_observability_application_telemetry.md)
+ [OPS07-BP03 ランブックを使用して手順を実行する](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 プレイブックを使用して問題を調査する](ops_ready_to_support_use_playbooks.md)
+ [OPS08-BP01 ワークロードメトリクスを分析する](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS11-BP02 インシデント後の分析を実行する](ops_evolve_ops_perform_rca_process.md)
**関連ドキュメント:**
+ [AWS セキュリティインシデント対応ガイド](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [AWS Incident Detection and Response](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/)
+ [AWS Cloud Adoption Framework: オペレーションのパースペクティブ - インシデントと問題管理 ](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/incident-and-problem-management.html)
+ [DevOps および SRE 時代のインシデント管理](https://www.infoq.com/presentations/incident-management-devops-sre/)
+ [PagerDuty - インシデント管理とは](https://www.pagerduty.com/resources/learn/what-is-incident-management/)
**関連動画:**
+ [ Top incident response tips from AWS](https://www.youtube.com/watch?v=Cu20aOvnHwA)
+ [AWS re:Invent 2022 - The Amazon Builders' Library: 25 yrs of Amazon operational excellence ](https://www.youtube.com/watch?v=DSRhgBd_gtw)
+ [AWS re:Invent 2022 - AWS Incident Detection and Response (SUP201) ](https://www.youtube.com/watch?v=IbSgM4IP9IE)
+ [ Introducing Incident Manager from AWS Systems Manager](https://www.youtube.com/watch?v=I6lScgh4qds)
**関連する例:**
+ [AWS プロアクティブサービス - インシデント管理ワークショップ](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [ PagerDuty と AWS Systems Manager Incident Manager でのインシデント対応の自動化](https://aws.amazon.com/blogs/mt/how-to-automate-incident-response-with-pagerduty-and-aws-systems-manager-incident-manager/)
+ [AWS Systems Manager Incident Manager のオンコールスケジュールでのインシデント対応担当者のエンゲージメント](https://aws.amazon.com/blogs/mt/engage-incident-responders-with-the-on-call-schedules-in-aws-systems-manager-incident-manager/)
+ [AWS Systems Manager Incident Manager でのインシデント対応の可視性とコラボレーションを改善](https://aws.amazon.com/blogs/mt/improve-the-visibility-and-collaboration-during-incident-handling-in-aws-systems-manager-incident-manager/)
+ [ AMS でのインシデントレポートとサービスリクエスト](https://docs.aws.amazon.com/managedservices/latest/userguide/support-experience.html)
**関連サービス:**
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
# OPS10-BP02 アラートごとにプロセスを用意する
効果的かつ効率的なインシデント管理においては、システム内のアラートごとに明確なプロセスを定義しておくことが重要です。そうすることで、すべてのアラートに対して具体的な対応をすぐに行動に移すことができ、運用の信頼性と応答性が向上します。
**期待される成果:** すべてのアラートに対して、明確に定義された具体的な対応計画が実践に移されます。可能な場合は、所有権を明確にし、エスカレーション経路を定義して、対応を自動化します。アラートは最新のナレッジベースにリンクされているため、どのオペレーターでも一貫して効果的に対応できます。対応が全体的に迅速で一貫しており、運用の効率と信頼性が向上します。
**一般的なアンチパターン:**
+ アラートに対応プロセスが事前定義されていないため、その場しのぎの対応や解決の遅れにつながる。
+ アラート過多になり、重要なアラートが見過ごされる。
+ アラートの所有権と責任が明確でないため、アラートの処理に一貫性がない。
**このベストプラクティスを活用するメリット:**
+ 対処可能なアラートのみを発生させることで、アラート疲労が軽減されます。
+ 運用上の問題の平均解決時間 (MTTR) が短縮されます。
+ 平均調査時間 (MTTI) が短縮され、MTTR の短縮につながります。
+ 運用上の対応のスケーラビリティが向上します。
+ 運用イベント処理の一貫性と信頼性が向上します。
例えば、アプリケーションアラーム、運用上の問題、計画されたライフサイクルイベント (クラスターが自動更新される前に Amazon EKS バージョンを更新するなど) など、重要なアカウントの AWS Health イベントに対して定義されたプロセスがあり、チームがこれらのイベントを積極的にモニタリング、通信、対応できるようにします。これらのアクションは、AWS 側の変更によるサービスの中断を防止したり、予期しない問題が発生した場合にそれらをより迅速に軽減したりするのに役立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
アラートごとにプロセスを用意するには、各アラートに対して明確な対応計画を策定し、可能な場合は対応を自動化します。また、運用上のフィードバックや変化する要件に基づいて、これらのプロセスを継続的に改善していきます。
### 実装手順
次の図は、[AWS Systems Manager Incident Manager](https://aws.amazon.com/systems-manager/features/incident-manager/) 内のインシデント管理ワークフローです。これは、[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) または [Amazon EventBridge](https://aws.amazon.com/eventbridge/) からの特定イベントに対してインシデントを自動的に作成して、運用上の課題に迅速に対応するよう設計されています。インシデントが自動または手動で作成されると、Incident Manager がインシデントの管理を一元化し、関連する AWS リソース情報を整理し、事前定義されている対応計画を実践に移します。例えば、即時対応のために Systems Manager Automation ランブックを実行したり、関連するタスクや分析を追跡するための親の運用作業項目を OpsCenter で作成したりします。この合理化されたプロセスにより、AWS 環境全体でインシデント対応が迅速化され、調整されます。
![\[Incident Manager の仕組みを示したフローチャート - Amazon Q Developer in chat applications、エスカレーション計画と連絡先、ランブックから対応計画へ流れ、対応計画からインシデントと分析へ流れています。Amazon CloudWatch も対応計画にも流れます。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/incident-manager-how-it-works.png)
1. **複合アラームを使用する:** CloudWatch で[複合アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)を作成して、関連するアラームをグループ化し、ノイズを減らし、より意味のある応答を可能にします。
1. **[AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) で最新情報を入手する:** AWS Health は、AWS クラウド リソースの正常性に関する信頼できるソースです。AWS Health を使用して、現在のサービスイベントや今後の変更 (計画されたライフサイクルイベントなど) を視覚化して通知を受け取ることで、影響を軽減するための措置を講じることができます。
1. [AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) で E メールやチャットチャネルへの、[目的に合った AWS Health イベント通知を作成](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)し、[AWS Health API](https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html) または [Amazon EventBridge を通じてモニタリングツールやアラートツール](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)をプログラムで統合します。
1. Amazon EventBridge または AWS Health API で既に使用している可能性のある変更管理や ITSM ツール ([Jira](https://docs.aws.amazon.com/smc/latest/ag/cloud-sys-health.html)、[ServiceNow](https://docs.aws.amazon.com/smc/latest/ag/sn-aws-health.html) など) と統合することで、アクションを必要とするヘルスイベントの進捗状況を計画および追跡します。
1. AWS Organizations を使用する場合は、[AWS Health の組織ビュー](https://docs.aws.amazon.com/health/latest/ug/aggregate-events.html)を有効にして、アカウント間をまたいで AWS Health イベントを集約します。
1. **Amazon CloudWatch アラームを Incident Manager と統合する:** CloudWatch アラームを設定して、[AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html) でインシデントを自動的に作成します。
1. **Amazon EventBridge を Incident Manager と統合する:** [EventBridge ルール](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)を作成してイベントに対応し、定義された対応計画を使用してインシデントを作成します。
1. **Incident Manager でのインシデントへの準備:**
+ Incident Manager で、アラートのタイプごとに詳細な[対応計画](https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html)を作成します。
+ [Amazon Q Developer in chat applications](https://docs.aws.amazon.com/incident-manager/latest/userguide/chat.html) を通じてチャットチャネルを確立し、Incident Manager のレスポンスプランに接続することで、インシデント発生時に Slack、Microsoft Teams、Amazon Chime などのプラットフォーム間でのリアルタイムコミュニケーションを促進します。
+ Incident Manager 内に [Systems Manager Automation ランブック](https://docs.aws.amazon.com/incident-manager/latest/userguide/runbooks.html)を組み込み、インシデントへの自動応答を促進します。
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 主要業績評価指標を特定する](ops_observability_identify_kpis.md)
+ [OPS08-BP04 実践的なアラートを作成する](ops_workload_observability_create_alerts.md)
**関連ドキュメント:**
+ [AWS Cloud Adoption Framework: オペレーションのパースペクティブ - インシデントと問題管理 ](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/incident-and-problem-management.html)
+ [Amazon CloudWatch でのアラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [AWS Systems Manager Incident Manager のセットアップ](https://docs.aws.amazon.com/incident-manager/latest/userguide/setting-up.html)
+ [ Incident Manager でのインシデントへの準備 ](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-response.html)
**関連動画:**
+ [ Top incident response tips from AWS](https://www.youtube.com/watch?v=Cu20aOvnHwA)
+ [ re:Invent 2023 \$1 Manage resource lifecycle events at scale with AWS Health](https://www.youtube.com/watch?v=VoLLNL5j9NA)
**関連する例:**
+ [AWS ワークショップ - AWS Systems Manager Incident Manager - セキュリティイベント対応の自動化 ](https://catalog.workshops.aws/automate-incident-response/en-US/settingupim/onboarding)
# OPS10-BP03 ビジネスへの影響に基づいて運用上のイベントの優先度を決定する
運用上のイベントに迅速に対応することは重要ですが、すべてのイベントが同じというわけではありません。ビジネスへの影響に基づいて優先順位を付けて、安全性、財務上の損失、規制違反、評判の低下など、重大な結果を招く可能性のあるイベントも優先的に対処します。
**期待される成果:** 運用上のイベントへの対応に、ビジネスの運用や目標への潜在的な影響に応じて優先順位が付けられます。これにより、効率的かつ効果的に対応できます。
**一般的なアンチパターン:**
+ すべてのイベントが同じ緊急度で扱われるため、混乱が生じ、重大な問題への対処が遅れる。
+ 影響の大きいイベントと小さいイベントの区別がつかず、リソースの誤配分につながる。
+ 組織に明確な優先順位付けのフレームワークがないため、運用上のイベントへの対応に一貫性がなくなる。
+ イベントの優先順位が、ビジネス成果への影響ではなく、報告された順序で決まる。
**このベストプラクティスを活用するメリット:**
+ 重要なビジネス機能が最初に注目されるようにし、潜在的な損害を最小限に抑えます。
+ 複数のイベントが同時に発生した際のリソース配分が改善されます。
+ 組織の信頼を維持し、規制要件を満たす能力を高めます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
複数の運用上のイベントに直面した際には、影響と緊急性に基づいて優先順位を決める体系的なアプローチが重要です。このアプローチは、情報に基づいた意思決定を行い、最も必要なところに努力を振り向け、事業継続に対するリスクを軽減するのに役立ちます。
### 実装手順
1. **影響を評価する:** ビジネスの運用や目標への潜在的な影響の観点からイベントの重大度を評価するための分類システムを開発します。次の例は、影響のカテゴリを示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **緊急度を評価する:** 安全性、財務上の影響、サービスレベル契約 (SLA) などの要素を考慮して、イベントにどれだけ迅速に対応する必要があるかを示す緊急度を定義します。次の例は、緊急度のカテゴリを示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **優先順位付けのマトリクスを作成する:**
+ マトリクスを使用して影響と緊急性を相互参照し、さまざまな組み合わせに優先度を割り当てます。
+ 運用上のイベント対応を担当するチームメンバー全員がマトリクスにアクセスし、理解できるようにしてください。
+ 次のマトリクスの例は、緊急性と影響に応じたインシデントの重大度を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **トレーニングとコミュニケーションを行う:** 優先順位付けのマトリクスと、イベント発生時にそれに従うことの重要性について、対応チームにトレーニングを行います。優先順位付けのプロセスをすべてのステークホルダーに伝え、明確な期待値を設定します。
1. **インシデント対応に統合する:**
+ 優先順位付けのマトリクスをインシデント対応計画とツールに組み込みます。
+ 可能な場合は、イベントの分類と優先順位付けを自動化して、対応時間を短縮します。
+ エンタープライズサポートのお客様は、[AWS Incident Detection and Response](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/) を使用できます。これにより、24 時間 365 日の本番ワークロードのプロアクティブモニタリングとインシデント管理が可能になります。
1. **見直して適応させる:** 優先順位付けプロセスの有効性を定期的に見直し、フィードバックやビジネス環境の変化に応じて調整します。
## リソース
**関連するベストプラクティス:**
+ [OPS03-BP03 エスカレーションが推奨されている](ops_org_culture_team_enc_escalation.md)
+ [OPS08-BP04 実践的なアラートを作成する](ops_workload_observability_create_alerts.md)
+ [OPS09-BP01 メトリクスを使用して業務目標と KPI を測定する](ops_operations_health_measure_ops_goals_kpis.md)
**関連ドキュメント:**
+ [ Atlassian - インシデントの重大度レベルの把握 ](https://www.atlassian.com/incident-management/kpis/severity-levels)
+ [ IT プロセスマップ - インシデント優先度のチェックリスト ](https://wiki.en.it-processmaps.com/index.php/Checklist_Incident_Priority)
# OPS10-BP04 エスカレーション経路を決定する
インシデント対応プロトコル内に明確なエスカレーション経路を確立して、タイムリーかつ効果的に対応できるようにします。そのためには、エスカレーションのプロンプトを指定し、エスカレーションプロセスを詳述し、意思決定を早めて解決までの平均時間 (MTTR) を短縮するためにアクションを事前承認します。
**期待される成果:** インシデントを適切な担当者にエスカレーションし、対応時間と影響を最小限に抑えるための、構造化された効率的なプロセス。
**一般的なアンチパターン:**
+ 復旧手順が明確でないため、重大なインシデントが発生した際の対応がその場しのぎになる。
+ 権限と所有権が定義されていないため、緊急の対応が必要な状況で対応が遅れる。
+ ステークホルダーや顧客への情報提供が期待にそっていない。
+ 重要な決断が遅れる。
**このベストプラクティスを活用するメリット:**
+ 事前定義されたエスカレーション手順により、インシデント対応が合理化されます。
+ 事前に承認されたアクションと明確な所有権により、ダウンタイムを短縮できます。
+ インシデントの重大度に応じて、リソース配分とサポートレベルの調整を改善できます。
+ ステークホルダーや顧客とのコミュニケーションが改善されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
迅速なインシデント対応には、適切に定義されたエスカレーション経路が不可欠です。AWS Systems Manager Incident Manager は、構造化されたエスカレーション計画とオンコールスケジュールの設定をサポートします。これにより、適切な担当者にアラートが送信され、インシデントが発生したときにすぐに対応できるようになります。
### 実装手順
1. **エスカレーションプロンプトを設定する:** [CloudWatch アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)を設定して、[AWS Systems Manager Incident Manager](https://docs.aws.amazon.com//incident-manager/latest/userguide/incident-creation.html) でインシデントを作成します。
1. ** オンコールスケジュールを設定する:** エスカレーションパスに沿った[オンコールスケジュール](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-on-call-schedule-create.html)を Incident Manager で作成します。オンコール担当者が即座に行動できるように、必要な権限とツールを提供します。
1. ** エスカレーション手順を詳述する: **
+ インシデントをエスカレーションすべき具体的な条件を決定します。
+ Incident Manager で[エスカレーション経路](https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html)を作成します。
+ エスカレーションチャネルは、連絡先またはオンコールスケジュールで構成する必要があります。
+ 各エスカレーションレベルにおけるチームの役割と責任を定義します。
1. **軽減アクションを事前承認する:** 意思決定者と協力して、予想されるシナリオに対するアクションを事前に承認しておきます。Incident Manager と統合された [Systems Manager Automation ランブック](https://docs.aws.amazon.com//incident-manager/latest/userguide/tutorials-runbooks.html)を使用して、インシデント解決を高速化します。
1. **所有権を指定する:** エスカレーション経路の各ステップにおける内部の所有者を明確に指定します。
1. **サードパーティーエスカレーションについて詳述する:**
+ サードパーティーのサービスレベルアグリーメント (SLA) を文書化し、社内の目標とすり合わせます。
+ インシデント発生時のベンダーとのコミュニケーションに対し、明確なプロトコルを設定します。
+ ベンダーの連絡先をインシデント管理ツールに統合し、直接アクセスできるようにします。
+ サードパーティーによる対応シナリオを含む定期的な訓練を実施します。
+ ベンダーのエスカレーション情報を明確に文書化し、簡単にアクセスできるようにします。
1. **エスカレーション計画のトレーニングとリハーサルを行う:** エスカレーションプロセスについてチームをトレーニングし、インシデント対応訓練やゲームデーを定期的に実施します。エンタープライズサポートのお客様は、[インシデント管理ワークショップ](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)をリクエストできます。
1. **継続的に改善する:** エスカレーション経路の有効性を定期的に見直します。インシデントの事後分析と継続的なフィードバックから学んだ教訓に基づいてプロセスを更新します。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS08-BP04 実践的なアラートを作成する](ops_workload_observability_create_alerts.md)
+ [OPS10-BP02 アラートごとにプロセスを用意する](ops_event_response_process_per_alert.md)
+ [OPS11-BP02 インシデント後の分析を実行する](ops_evolve_ops_perform_rca_process.md)
**関連ドキュメント:**
+ [AWS Systems Manager Incident Manager エスカレーション計画 ](https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html)
+ [ Incident Manager でのオンコールスケジュールの操作 ](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-on-call-schedule.html)
+ [ ランブックの作成と管理 ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [AWS IAM アイデンティティセンター での一時的な昇格アクセス管理](https://aws.amazon.com/blogs/security/temporary-elevated-access-management-with-iam-identity-center/)
+ [ Atlassian - 効果的なインシデント管理のためのエスカレーションポリシー ](https://www.atlassian.com/incident-management/on-call/escalation-policies)
# OPS10-BP05 サービスに影響するイベント発生時の顧客コミュニケーション計画を定義する
顧客との信頼関係を維持し、透明性を確保するためには、サービスに影響を及ぼすイベントが発生した際の効果的なコミュニケーションが不可欠です。コミュニケーション計画が明確に定義されていれば、インシデントの発生時に組織内外で迅速かつ明確に情報を共有することができます。
**期待される成果:**
+ サービスに影響を及ぼすイベントが発生した際に顧客やステークホルダーに効果的に情報を伝えるための、確固たるコミュニケーション計画。
+ 透明性が高いコミュニケーションを通じて、信頼を築き、顧客の不安を解消する。
+ サービスに影響を及ぼすイベントがカスタマーエクスペリエンスや事業運営に与える影響を最小限に抑える。
**一般的なアンチパターン:**
+ コミュニケーションの不足や遅延が、顧客の混乱や不満につながる。
+ メッセージが技術的すぎる、またはあいまいなせいで、ユーザーへの実際の影響を伝えることができない。
+ コミュニケーション戦略が事前に定義されていないため、メッセージが一貫性を欠き、事後対応的になる。
**このベストプラクティスを活用するメリット:**
+ 予防的かつ明確なコミュニケーションを通じて、顧客の信頼と満足度が高まります。
+ 顧客の不安に先回りして対応することで、サポートチームの負担が軽減します。
+ インシデントを効果的に管理し、復旧する能力が向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
サービスに影響を及ぼすイベントに備えた包括的なコミュニケーション計画の策定には、適切なチャネルの選択からメッセージやトーンの作成まで、さまざまな側面が関与します。適応性と拡張性に優れ、さまざまな障害シナリオに対応できる計画を用意する必要があります。
### 実装手順
1. **役割と責任を定義する:**
+ インシデント対応活動を監督する重大インシデントマネージャーを任命します。
+ 外部および内部のすべてのコミュニケーションの調整を担当するコミュニケーションマネージャーを指名します。
+ サポートマネージャーを関与させ、サポートチケットを通じて一貫したコミュニケーションを実現します。
1. **コミュニケーションチャネルを特定する:** 職場のチャット、E メール、SMS、ソーシャルメディア、アプリ内通知、ステータスページなどのチャネルを選択します。これらのチャネルには、耐障害性があること、サービスに影響を及ぼすイベントが発生した場合でも独立して動作できることが求められます。
1. ** 顧客に迅速、明確、定期的に伝える: **
+ 重要な詳細情報を簡潔に伝えることに重点を置いて、さまざまなサービス障害シナリオ用のテンプレートを作成します。サービスの障害、想定される解決時間、影響に関する情報を含めてください。
+ Amazon Pinpoint を使用して、プッシュ通知、アプリ内通知、E メール、テキストメッセージ、音声メッセージ、カスタムチャネル経由のメッセージで顧客に警告します。
+ Amazon Simple Notification Service (Amazon SNS) を使用して、プログラムによって、または E メール、モバイルプッシュ通知、テキストメッセージで、サブスクライバーに警告します。
+ Amazon CloudWatch ダッシュボードをパブリックに共有して、ダッシュボードを通じて状況を伝えます。
+ ソーシャルメディアでのエンゲージメントを促す:
+ ソーシャルメディアを積極的に監視して、顧客の感情を把握します。
+ ソーシャルメディアプラットフォームに投稿して、最新情報を公開し、コミュニティに参加します。
+ 一貫性のある明確なソーシャルメディアコミュニケーションのためのテンプレートを用意します。
1. **内部コミュニケーションを調整する:** Amazon Q Developer in chat applications などのツールを使用して、チームの調整やコミュニケーションのための内部プロトコルを実装します。CloudWatch ダッシュボードでステータスを知らせます。
1. ** 専用のツールとサービスでコミュニケーションを調整する:**
+ AWS Systems Manager Incident Manager と Amazon Q Developer in chat applications を使用して、インシデント発生時にリアルタイムで内部コミュニケーションと調整を行うための専用チャットチャネルを設置します。
+ AWS Systems Manager Incident Manager ランブックを使用して、インシデントの発生時に Amazon Pinpoint、Amazon SNS、またはソーシャルメディアプラットフォームなどのサードパーティーツールを通じて顧客への通知を自動化します。
+ ランブックに承認ワークフローを組み込んで、すべての外部コミュニケーションを送信前に任意で確認し、承認できます。
1. ** 実践して改善する: **
+ コミュニケーションツールと戦略の利用に関するトレーニングを実施します。インシデントの発生時にチームがタイムリーな意思決定を行えるようにします。
+ 定期的な訓練やゲームデーを設けて、コミュニケーションプランをテストします。これらのテストを基にメッセージを改良し、チャネルの有効性を評価してください。
+ インシデント発生時のコミュニケーションの有効性を評価するためのフィードバックメカニズムを実装します。フィードバックと変化するニーズに応じて、コミュニケーションプランを継続的に進化させます。
**実装計画に必要な工数レベル:** 高
## リソース
**関連するベストプラクティス:**
+ [OPS07-BP03 ランブックを使用して手順を実行する](ops_ready_to_support_use_runbooks.md)
+ [OPS10-BP06 ダッシュボードでステータスを知らせる](ops_event_response_dashboards.md)
+ [OPS11-BP02 インシデント後の分析を実行する](ops_evolve_ops_perform_rca_process.md)
**関連ドキュメント:**
+ [ Atlassian - インシデントコミュニケーションのベストプラクティス ](https://www.atlassian.com/incident-management/incident-communication)
+ [ Atlassian - 効果的なステータスアップデートの記述方法 ](https://www.atlassian.com/blog/statuspage/how-to-write-a-good-status-update)
+ [ PagerDuty - インシデントコミュニケーションガイド ](https://www.pagerduty.com/resources/learn/a-guide-to-incident-communications/)
**関連動画:**
+ [ Atlassian - 独自のインシデントコミュニケーションプランの作成: インシデントテンプレート ](https://www.youtube.com/watch?v=ZROVn6-K2qU)
**関連する例:**
+ [AWS Health ダ ッシュボード ](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/)
# OPS10-BP06 ダッシュボードでステータスを知らせる
ダッシュボードを戦略的なツールとして使用して、内部の技術チーム、経営陣、顧客など、さまざまな対象者にリアルタイムの運用状況と主要なメトリクスを伝えます。これらのダッシュボードでは、システムの状態とビジネスパフォーマンスを一元的に視覚化できるため、透明性と意思決定の効率が向上します。
**期待される成果:**
+ ダッシュボードには、さまざまなステークホルダーに関連するシステムとビジネスのメトリクスが包括的に表示されます。
+ ステークホルダーは運用情報に積極的にアクセスできるため、状況確認のリクエストを頻繁に行う必要がなくなります。
+ 通常運用中やインシデント発生時には、リアルタイムの意思決定が強化されます。
**一般的なアンチパターン:**
+ インシデント管理の会議に参加するエンジニアが、最新状況を把握するために、状況確認のリクエストをしなければならない。
+ 管理面は手作業による報告に頼っているため、遅延が起きたり正確さを欠いたりする可能性がある。
+ インシデント発生時に、運用チームが最新の状況確認のために頻繁に中断される。
**このベストプラクティスを活用するメリット:**
+ ステークホルダーが重要な情報にすぐにアクセスできるようになり、情報に基づいた意思決定が促されます。
+ 手作業による報告や頻繁なステータス照会を最小限に抑えることで、運用上の非効率性が軽減されます。
+ システムのパフォーマンスとビジネスのメトリクスをリアルタイムで可視化し、透明性と信頼性を高めます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
ダッシュボードは、システムのステータスやビジネスメトリクスを効果的に伝え、さまざまな対象者グループのニーズに合わせてカスタマイズできます。Amazon CloudWatch ダッシュボードや Amazon Quick などのツールを使用すれば、システムモニタリングやビジネスインテリジェンスを目的としたインタラクティブなリアルタイムダッシュボードを作成できます。
### 実装手順
1. **ステークホルダーのニーズを特定する:** 技術チーム、経営陣、顧客など、さまざまな対象者グループの特定の情報ニーズを判断します。
1. **適切なツールを選択する:** システムモニタリング用の [Amazon CloudWatch ダッシュボード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)、インタラクティブなビジネスインテリジェンス用の [Amazon Quick](https://aws.amazon.com/quicksight/) などの適切なツールを選択します。[AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) は、[AWS Health Dashboard](https://health.aws.amazon.com/health/home) でのすぐに役立つエクスペリエンスを提供します。または、Amazon EventBridge や AWS Health API で Health イベントを使用して独自のダッシュボードを補強できます。
1. **効果的なダッシュボードを設計する:**
+ 関連するメトリクスと KPI をわかりやすく提示するダッシュボードを設計し、それらの情報が理解しやすく、すぐに行動に結び付くようにします。
+ 必要に応じて、システムレベルとビジネスレベルのビューを組み込みます。
+ 高レベル (大まかな概要用) と低レベル (詳細な分析用) のダッシュボードの両方を含めます。
+ 重大な問題を強調するため、自動アラームをダッシュボードに統合します。
+ ダッシュボードに重要なメトリクスのしきい値と目標を示す注釈を付け、すぐに視認できるようにします。
1. **データソースを統合する:**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) を使用すると、さまざまな AWS サービスのメトリクスを集約して表示したり[他のデータソースのメトリクスをクエリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/MultiDataSourceQuerying.html)したりして、システムの正常性とビジネスメトリクスを一元的に把握できます。
+ [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) のような機能を使用して、さまざまなアプリケーションやサービスのログデータをクエリしたり可視化したりすることを可能にします。
+ AWS Health イベントを使用して、[AWS Health API](https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html) または [Amazon EventBridge の AWS Health イベント](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)により、AWS サービスの運用ステータスや確認された運用上の問題に関する最新情報を入手します。
1. **セルフサービスアクセスを可能にする:**
+ 関連するステークホルダーと CloudWatch ダッシュボードを共有し、[ダッシュボード共有機能](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html)を使ってセルフサービスで情報にアクセスできるようにします。
+ ダッシュボードに簡単にアクセスできるようにし、リアルタイムで最新情報が提供されるようにします。
1. **定期的に更新して改良する:**
+ 進化するビジネスニーズとステークホルダーのフィードバックに応じて、ダッシュボードを継続的に更新し、改良していきます。
+ ダッシュボードを定期的に見直し、必要な情報を伝えるために適切かつ効果的であり続けるようにします。
## リソース
**関連するベストプラクティス:**
+ [OPS08-BP05 ダッシュボードを作成する](ops_workload_observability_create_dashboards.md)
**関連ドキュメント:**
+ [運用を可視化するためのダッシュボードの構築](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [ダッシュボード変数を使用して柔軟なダッシュボードを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html)
+ [CloudWatch ダッシュボードの共有](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html)
+ [他のデータソースにあるメトリクスへのクエリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/MultiDataSourceQuerying.html)
+ [CloudWatch ダッシュボードにカスタムウィジェットを追加する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_custom_widget_dashboard.html)
**関連する例:**
+ [1 つのオブザーバビリティワークショップ - Dashboards](https://catalog.us-east-1.prod.workshops.aws/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/en-US/aws-native/dashboards)
# OPS10-BP07 イベントへの対応を自動化する
イベントへの対応を自動化することは、迅速で一貫性があり、ミスのない運用処理を実現するために不可欠です。プロセスを合理化し、ツールを使用してイベントを自動的に管理および対応することで、手作業による介入を極力なくし、運用効率を高めます。
**期待される成果:**
+ 自動化を通じて、ヒューマンエラーを抑制し、解決所要時間を短縮できる。
+ 一貫性があり信頼できる運用上のイベント処理。
+ 運用効率とシステムの信頼性が向上する。
**一般的なアンチパターン:**
+ 手作業によるイベント処理は、遅延やミスにつながりやすい。
+ 反復的でありながら重要なタスクに対し、自動化が見過ごされる。
+ 繰り返しのタスクを手作業で行うと、アラート疲労が起きやすく、重大な問題を見逃しかねない。
**このベストプラクティスを活用するメリット:**
+ イベントへの対応を迅速化し、システムのダウンタイムを短縮する。
+ 自動化された一貫したイベント処理による、信頼性の高い運用。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
自動化を組み込んで運用ワークフローを効率化し、手作業による介入を極力抑えます。
### 実装手順
1. **自動化の機会を特定する:** 問題の修正、チケットの強化、容量管理、スケーリング、デプロイ、テストなど、自動化の余地がある反復的なタスクを判断します。
1. **自動化のプロンプトを特定する:**
+ 自動応答の契機となる特定の条件やメトリクスを [Amazon CloudWatch アラームアクション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)を使用して評価し、定義します。
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/) を使用して、AWS サービス、カスタムワークロード、SaaS アプリケーションでイベントに対応します。
+ AWS リソースでの[特定のログエントリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)、[パフォーマンスメトリクスのしきい値](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)、[状態の変化](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)など、契機となるイベントを検討します。
1. **イベント駆動型の自動化を実装する:**
+ AWS Systems Manager オートメーションランブックを使用して、メンテナンス、デプロイ、修正のタスクを簡素化します。
+ [Incident Manager でインシデントを作成](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)して、関連する AWS リソースに関する情報を自動的に収集し、インシデントに追加します。
+ [AWS のクォータモニタ](https://aws.amazon.com/solutions/implementations/quota-monitor/)を使用してクォータをプロアクティブにモニタリングします。
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) を使用して容量を自動的に調整し、可用性とパフォーマンスを維持します。
+ [Amazon CodeCatalyst](https://codecatalyst.aws/explore) を使用して開発パイプラインを自動化します。
+ [合成モニタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)を使用して、エンドポイントと API をスモークテストするか継続的にモニタリングします。
1. **自動化を通じてリスクを軽減する:**
+ リスクに迅速に対処するため[自動化されたセキュリティ対応](https://aws.amazon.com/solutions/implementations/automated-security-response-on-aws/)を実施します。
+ [AWS Systems Manager State Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html) を使用して設定のドリフトを減らします。
+ [AWS Config ルール を使用して非準拠のリソースを修復します。](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**実装計画に必要な工数レベル:** 高
## リソース
**関連するベストプラクティス:**
+ [OPS08-BP04 実践的なアラートを作成する](ops_workload_observability_create_alerts.md)
+ [OPS10-BP02 アラートごとにプロセスを用意する](ops_event_response_process_per_alert.md)
**関連ドキュメント:**
+ [Incident Manager での Systems Manager Automation ランブックの使用](https://docs.aws.amazon.com/incident-manager/latest/userguide/tutorials-runbooks.html)
+ [Incident Manager でのインシデントの作成](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)
+ [AWS サービスクォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [リソース使用状況のモニタリングとクォータ間近の通知の送信](https://docs.aws.amazon.com/solutions/latest/quota-monitor-for-aws/solution-overview.html)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [Amazon CodeCatalyst とは](https://docs.aws.amazon.com/codecatalyst/latest/userguide/welcome.html)
+ [Amazon CloudWatch アラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon CloudWatch でのアラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)
+ [AWS Config ルール による非準拠リソースの是正](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [フィルターを使用したログイベントからのメトリクスの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [AWS Systems Managerステートマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html)
**関連動画:**
+ [Create Automation Runbooks with AWS Systems Manager](https://www.youtube.com/watch?v=fQ_KahCPBeU)
+ [How to automate IT Operations on AWS](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS Security Hub CSPM automation rules ](https://www.youtube.com/watch?v=XaMfO_MERH8)
+ [Start your software project fast with Amazon CodeCatalyst blueprints](https://www.youtube.com/watch?v=rp7roaoPzFE)
**関連する例:**
+ [Amazon CodeCatalyst Tutorial: Creating a project with the Modern three-tier web application blueprint](https://docs.aws.amazon.com/codecatalyst/latest/userguide/getting-started-template-project.html)
+ [1 つのオブザーバビリティワークショップ](https://catalog.us-east-1.prod.workshops.aws/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/en-US)
+ [Respond to incidents using Incident Manager](https://catalog.workshops.aws/getting-started-with-com/en-US/operations-management/incident-manager)