# 運用
**Topics**
+ [OPS 8 ワークロードの正常性はどのように把握するのですか?](w2aac19b5b9b5.md)
+ [OPS 9 オペレーションの正常性をどのように把握するのですか?](w2aac19b5b9b7.md)
+ [OPS 10 ワークロードと運用イベントはどのように管理するのですか?](w2aac19b5b9b9.md)
# OPS 8 ワークロードの正常性はどのように把握するのですか?
ワークロードメトリクスの定義、キャプチャ、分析をすると、適切なアクションを取れるようにワークロードイベントの可視性を高めることができます。
**Topics**
+ [OPS08-BP01 主要業績評価指標 (KPI) を特定する](ops_workload_health_define_workload_kpis.md)
+ [OPS08-BP02 ワークロードのメトリクスを定義する](ops_workload_health_design_workload_metrics.md)
+ [OPS08-BP03 ワークロードメトリクスを収集および分析する](ops_workload_health_collect_analyze_workload_metrics.md)
+ [OPS08-BP04 ワークロードメトリクスのベースラインを設定する](ops_workload_health_workload_metric_baselines.md)
+ [OPS08-BP05 ワークロードに対して予想されるアクティビティのパターンを知る](ops_workload_health_learn_workload_usage_patterns.md)
+ [OPS08-BP06 ワークロードの結果にリスクがある場合に警告する](ops_workload_health_workload_outcome_alerts.md)
+ [OPS08-BP07 ワークロードの異常が検出された場合に警告する](ops_workload_health_workload_anomaly_alerts.md)
+ [OPS08-BP08 KPI とメトリクスの成果の達成度と有効性を検証する](ops_workload_health_biz_level_view_workload.md)
# OPS08-BP01 主要業績評価指標 (KPI) を特定する
希望するビジネス上の業績 (注文率、顧客定着率、営業費用に対する利益など) と顧客に関する成果 (顧客満足度など) に基づいて、主要業績評価指標 (KPI) を特定します。KPI を評価して、ワークロードの成功を判別します。
**一般的なアンチパターン:**
+ あなたは、ビジネスリーダーから、ワークロードがビジネスニーズにどのように寄与したかを尋ねられますが、寄与度を判断するための基準となる枠組みがありません。
+ あなたは、組織で運用している商用オフザシェルフのアプリケーションの費用対効果が高いかどうかを判断することはできません。
**このベストプラクティスを活用するメリット:** ワークロードの正常性と成功のテストとして、主要業績評価指標を特定することで、ビジネス成果を達成できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 主要業績評価指標 (KPI) を特定する: ビジネスおよび顧客が求める成果に基づいて、主要業績評価指標 (KPI) を特定します。KPI を評価して、ワークロードの成功を判別します。
# OPS08-BP02 ワークロードのメトリクスを定義する
KPI の達成度を測定するワークロードメトリクスを定義します (たとえば、中止されたショッピングカート、注文数、コスト、価格、配分されたワークロード費用)。ワークロードの正常性 (インターフェイスの応答時間、エラー率、リクエスト数、完了したリクエスト、使用率など) を測定するワークロードのメトリクスを定義します。メトリクスを評価して、ワークロードが必要な成果に達しているかを判定し、ワークロードの正常性を把握します。
CloudWatch Logs などのサービスにログデータを送信し、必要なログコンテンツの観察からメトリクスを生成する必要があります。
CloudWatch には、 [.NET や SQL Server のための Amazon CloudWatch Insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/appinsights-what-is.html) および [Container Insights などの専門的な機能があり、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) サポートされている特定のアプリケーションリソースやテクノロジースタック全体で重要なメトリクス、ログ、アラームを特定して設定するのに役立ちます。
**一般的なアンチパターン:**
+ あなたは、KPI に関連付けられていない、またはワークロードに合わせて調整されていない「標準」のメトリクスを定義しました。
+ メトリクスの計算にエラーがあり、無効な結果が生成されます。
+ あなたは、ワークロードに対して定義されたメトリクスを備えていません。
+ あなたは可用性のみを測定します。
**このベストプラクティスを活用するメリット:** ワークロードメトリクスを定義して評価することで、ワークロードの状態を判断し、ビジネス成果の達成を測定できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ ワークロードのメトリクスを定義する: KPI の達成度を測定するため、ワークロードのメトリクスを定義します。ワークロードとその個々のコンポーネントの正常性を測定するため、ワークロードのメトリクスを定義します。メトリクスを評価して、ワークロードが必要な成果に達しているかを判定し、ワークロードの正常性を把握します。
+ [カスタムメトリクスをパブリッシュする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [ログデータの検索およびフィルタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Amazon CloudWatch のメトリクスとディメンションのリファレンス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch のメトリクスとディメンションのリファレンス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [カスタムメトリクスをパブリッシュする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [ログデータの検索およびフィルタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
# OPS08-BP03 ワークロードメトリクスを収集および分析する
メトリクスのプロアクティブなレビューを定期的に行うと、傾向を把握し、適切な対応が必要な領域を特定できます。
アプリケーション、ワークロードコンポーネント、サービス、および CloudWatch Logs などのサービスへの API 呼び出しのログデータを集約する必要があります。必要なログコンテンツの観測からメトリクスを生成して、運用アクティビティのパフォーマンスを把握できるようにします。
AWS では、 [Amazon DevOps Guru の機械学習機能を使用して、ワークロードのメトリクスを分析し、運用の問題を特定できます。](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)AWS DevOps Guru は、問題を解決しアプリケーションの状態を良好に保つための [対象を定めたプロアクティブな推奨事項を含む](https://docs.aws.amazon.com/devops-guru/latest/userguide/view-insights.html) 運用の問題に関する通知を提供します。
AWS の責任共有モデルでは、モニタリングの一部が [AWS Health Dashboard を通じて提供されます](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/)。このダッシュボードは、お客様に影響を与える可能性があるイベントが AWS で発生した場合に、アラートと修正ガイダンスを提供します。ビジネスサポートとエンタープライズサポートのサブスクリプションをご利用のお客様は、 [AWS Health API にアクセスすることもでき、](https://docs.aws.amazon.com/health/latest/ug/getting-started-api.html)イベント管理システムとの統合が可能になります。
AWS では、 [ログデータを Amazon S3 に](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) エクスポートしたり、 [ログ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) を [Amazon S3 に直接送信して、](https://aws.amazon.com/s3/) 長期保存したりできます。分析のために、 [AWS Glue](https://aws.amazon.com/glue/)を使用すると、Amazon S3 でログデータを検出して準備し、関連するメタデータを [AWSAWS Glue Data Catalog に保存できます](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)。 [Amazon Athena ](https://aws.amazon.com/athena/)では、AWS Glue とのネイティブな統合により、ログデータを分析し、標準 SQL を使用してクエリを実行できます。Quick などのビジネスインテリジェンスツールを [使用して、](https://aws.amazon.com/quicksight/) データを可視化、調査、分析することができます。
代替 [ソリューション](https://aws.amazon.com/solutions/centralized-logging/?did=sl_card&trk=sl_card) は、 [Amazon OpenSearch Service ](https://aws.amazon.com/elasticsearch-service/) および [OpenSearch Dashboards ](https://aws.amazon.com/elasticsearch-service/the-elk-stack/kibana/) を使用して、複数のアカウントと AWS リージョン にわたる AWS のログを収集、分析、表示することです。
**一般的なアンチパターン:**
+ あなたは、ネットワーク設計チームから現在のネットワーク帯域幅使用率について尋ねられています。あなたは、現在のメトリクスを提供します。ネットワーク使用率は 35% です。当該チームは、コスト削減手段として回路容量を削減します。あなたのポイントインタイム測定では利用率の傾向が反映されず、接続に関する問題が広がってしまいます。
+ ルーターに障害が発生しました。これまでに、重大ではないメモリエラーがログ記録されていました。その頻度はますます多くなり、ついには完全な障害となりました。あなたは、この傾向に気付かなかったため、ルーターがサービスの中断を引き起こす前に、障害のあるメモリを交換しませんでした。
**このベストプラクティスを確立するメリット:** ワークロードメトリクスを収集して分析することで、ワークロードの状態を把握し、ワークロードやビジネス成果の達成に影響を与える可能性のある傾向について洞察を得ることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ ワークロードのメトリクスを収集および分析する: メトリクスのプロアクティブなレビューを定期的に行うと、傾向を把握し、適切な対応が必要な領域を特定できます。
+ [Amazon CloudWatch メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Amazon CloudWatch のメトリクスとディメンションのリファレンス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
## リソース
**関連するドキュメント:**
+ [Amazon Athena](https://aws.amazon.com/athena/)
+ [Amazon CloudWatch のメトリクスとディメンションのリファレンス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWSAWS Glue Data Catalog に保存できます](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)
+ [Amazon OpenSearch Service](https://aws.amazon.com/elasticsearch-service/)
+ [AWS Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/)
+ [Quick](https://aws.amazon.com/quicksight/)
+ [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)
# OPS08-BP04 ワークロードメトリクスのベースラインを設定する
メトリクスにベースラインを設定し、パフォーマンスの低いコンポーネントと高いコンポーネントを比較、特定するためのベースラインとして期待値を提供します。改善、調査、および介入のしきい値を特定します。
**一般的なアンチパターン:**
+ サーバーが 95% の CPU 使用率で実行されており、あなたは、それが良いのか悪いのかを尋ねられています。そのサーバーの CPU 使用率がベースライン化されていないため、あなたは、それが良いのか悪いのかがわかりません。
**このベストプラクティスを確立するメリット:** ベースラインメトリクス値を定義することで、現在のメトリクス値とメトリクスの傾向を評価し、アクションが必要かどうかを判断できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ワークロードメトリクスのベースラインを設定する: ワークロードメトリクスのベースラインを設定し、比較の基準となる期待値を提供します。
+ [Amazon CloudWatch でのアラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch でのアラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
# OPS08-BP05 ワークロードに対して予想されるアクティビティのパターンを知る
ワークロードアクティビティのパターンを確立して異常な動作を識別し、必要に応じて適切に対応できるようにします。
CloudWatch Anomaly Detection 機能を使用した [CloudWatch は、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 統計および機械学習アルゴリズムを適用して、通常のメトリクスの動作を表す予想値の範囲を生成します。
[Amazon DevOps Guru を使用して、](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) イベントの関連性、ログ分析、ワークロードテレメトリー分析への機械学習の適用によって、異常な動作を検出できます。予期しない動作が検出された場合、 [当該動作に対処するためのレコメンデーションを含む](https://docs.aws.amazon.com/devops-guru/latest/userguide/understanding-insights-console.html) 関連メトリクスとイベントを提供します。
**一般的なアンチパターン:**
+ あなたは、ネットワーク使用率のログを確認しています。このとき、ネットワーク使用率が午前 11 時 30 分から午後 1 時 30 分まで増加し、午後 4 時 30 分から午後 6 時 00 分まで再び増加していることに気づきます。あなたには、これを正常とみなすべきかどうかがわかりません。
+ ウェブサーバーは、毎日午前 3 時に再起動します。あなたには、これが予期される動作であるかどうかがわかりません。
**このベストプラクティスを活用するメリット:** 動作パターンを学習することで、予期しない動作を認識し、必要に応じてアクションを実行できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ワークロードに対して予想されるアクティビティのパターンを知る: ワークロードアクティビティのパターンを確立すると、行動が期待値から外れるタイミングを把握し、必要に応じて適切に対応できるようになります。
## リソース
**関連するドキュメント:**
+ [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [CloudWatch Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
# OPS08-BP06 ワークロードの結果にリスクがある場合に警告する
ワークロードの結果にリスクがある場合、必要に応じて適切な対応ができるよう、アラートを発生させます。
理想的には、警告の対象となるメトリクスのしきい値、または自動応答をトリガーするために使用できるイベントを前もって指定しておきます。
AWS では、 [Amazon CloudWatch Synthetics を使用して](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 顧客と同じアクションを実行することで、エンドポイントと API をモニタリングするための Canary スクリプトを作成できます。生成されたテレメトリーと [得られたインサイトを使用して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_Details.html) 顧客が影響を受ける前に問題を特定できます。
また、 [CloudWatch Logs Insights を使用して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 専用のクエリ言語によりログデータをインタラクティブに検索および分析することもできます。CloudWatch Logs Insights は、 [AWS のサービスおよび JSON のカスタムログイベントからの](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData-discoverable-fields.html) ログのフィールドを自動的に検出します。ログボリュームとクエリの複雑さに応じてスケールし、数秒で回答が得られるため、インシデントの原因となる要因の検索に役立ちます。
**一般的なアンチパターン:**
+ ネットワーク接続がありません。誰も気づいていません。理由を特定しようとしたり、接続を復元するためのアクションを採ろうとしたりする人はいません。
+ パッチの適用後、永続的なインスタンスが使用できなくなり、ユーザーの操作を中断します。ユーザーがサポートケースをオープンしました。誰にも通知されていません。アクションを採ろうとしている人はいません。
**このベストプラクティスを活用するメリット:** ビジネス上の成果にリスクがあることを特定し、アクションが実行されるべきことをアラートすることで、インシデントの影響を防止または軽減する機会を得られます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ワークロードの結果にリスクがある場合にアラートを出す: ワークロードの結果にリスクがある場合、必要に応じて適切な対応ができるよう、アラートを発生させます。
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Amazon CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon SNS 通知を使用した Lambda 関数の呼び出し](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Amazon CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon SNS 通知を使用した Lambda 関数の呼び出し](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS08-BP07 ワークロードの異常が検出された場合に警告する
ワークロードの異常が検出された場合、必要に応じて適切な対応ができるよう、アラートを発生させます。
時間をかけてワークロードメトリクスを分析すると、イベントを定義したり、それに応じてアラームを発生させるために十分に定量化できる行動パターンが確立されることがあります。
トレーニングが完了すると、 [CloudWatch Anomaly Detection ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 機能を使用して、 [検出された異常を警告したり、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html) メトリクスデータのグラフに重ねて [予想値を渡して](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html#create-metric-graph) 継続的な比較を行うことができます。
**一般的なアンチパターン:**
+ 小売業のウェブサイトの売上が急激かつ劇的に増加しました。誰も気づいていません。誰もこの急増の原因を特定しようとしていません。負荷が増える中で、質の高いカスタマーエクスペリエンスを確保するための措置を講じている人はいません。
+ パッチの適用後、永続的なサーバーが頻繁に再起動し、ユーザーの操作を中断します。サーバーは通常、最大 3 回まで再起動しますが、それを超えては再起動しません。誰も気づいていません。これが生じている理由を誰も特定しようとしていません。
**このベストプラクティスを活用するメリット:** ワークロードの動作パターンを理解することで、予期しない動作を特定し、必要に応じてアクションを実行できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ ワークロードの異常が検出された場合にアラートを出す: ワークロードの異常が検出された場合、必要に応じて適切な対応ができるよう、アラートを発生させます。
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Amazon CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon SNS 通知を使用した Lambda 関数の呼び出し](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [CloudWatch Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [Amazon SNS 通知を使用した Lambda 関数の呼び出し](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS08-BP08 KPI とメトリクスの成果の達成度と有効性を検証する
ワークロードオペレーションに対するビジネスレベルの視点を確立すると、ニーズを満足しているかどうかを判断したり、ビジネス目標を達成するために改善が必要な領域を特定したりできます。KPI とメトリクスの有効性を検証し、必要に応じて修正します。
また、AWS は、AWS のサービス API や SDK を介してサードパーティーのログ分析システム (Grafana、Kibana、Logstash など) やビジネスインテリジェンスツールもサポートしています。
**一般的なアンチパターン:**
+ これまで、ページの応答時間は、顧客満足度に対する貢献要因であると考えられたことはありません。あなたは、ページの応答時間のメトリクスまたはしきい値を確立したことがありません。顧客は、「遅さ」について苦情を申し立てています。
+ あなたは、最小応答時間の目標を達成したことはありません。あなたは、応答時間を短縮するために、アプリケーションサーバーをスケールアップしました。応答時間の目標を大幅に超過することになり、また、支払っている容量の未使用部分も大幅に増加しました。
**このベストプラクティスを活用するメリット:** KPI とメトリクスを確認して修正することで、ワークロードがビジネス成果の達成をどのようにサポートしているかを理解し、ビジネス目標を達成するために改善が必要な場所を特定できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ KPI とメトリクスの成果の達成度と有効性を検証する: ワークロード運用に対するビジネスレベルの視点を確立すると、ニーズを満たしているかどうかを判断したり、ビジネス目標を達成するために改善が必要な領域を特定したりできます。KPI とメトリクスの有効性を検証し、必要に応じて修正します。
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [ログ分析とは](https://aws.amazon.com/log-analytics/)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [ログ分析とは](https://aws.amazon.com/log-analytics/)
# OPS 9 オペレーションの正常性をどのように把握するのですか?
オペレーションメトリクスを定義し、キャプチャし、分析することで、オーペレーションイベントの可視性を高め、適切なアクションがとれるようになります。
**Topics**
+ [OPS09-BP01 主要業績評価指標 (KPI) を特定する](ops_operations_health_define_ops_kpis.md)
+ [OPS09-BP02 運用メトリクスを定義する](ops_operations_health_design_ops_metrics.md)
+ [OPS09-BP03 運用メトリクスを収集し、分析する](ops_operations_health_collect_analyze_ops_metrics.md)
+ [OPS09-BP04 運用メトリクスの基準値を設定する](ops_operations_health_ops_metric_baselines.md)
+ [OPS09-BP05 運用に対して予想されるアクティビティのパターンを知る](ops_operations_health_learn_ops_usage_patterns.md)
+ [OPS09-BP06 オペレーションの結果にリスクがある場合に警告する](ops_operations_health_ops_outcome_alerts.md)
+ [OPS09-BP07 運用の異常が検出された場合に警告する](ops_operations_health_ops_anomaly_alerts.md)
+ [OPS09-BP08 KPI とメトリクスの成果の達成度と有効性を検証する](ops_operations_health_biz_level_view_ops.md)
# OPS09-BP01 主要業績評価指標 (KPI) を特定する
希望するビジネスの成果 (新機能など) とお客様の成果 (カスタマーサポートケースなど) に基づいて、主要業績指標 (KPI) を特定します。KPI を評価して、オペレーションの成功を判別します。
**一般的なアンチパターン:**
+ あなたは、ビジネスリーダーから、オペレーションがビジネス目標をどのように達成したかを尋ねられますが、寄与度を判断するための基準となる枠組みがありません。
+ あなたは、メンテナンスウィンドウがビジネスの成果に影響しているかどうかを判断できません。
**このベストプラクティスを活用するメリット:** オペレーションの正常性と成功のテストとして、主要業績評価指標を特定することで、ビジネス成果を達成できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 主要業績評価指標 (KPI) を特定する: ビジネスおよび顧客が求める成果に基づいて、主要業績評価指標 (KPI) を特定します。KPI を評価して、オペレーションの成功を判別します。
# OPS09-BP02 運用メトリクスを定義する
運用メトリクスを定義して、KPI の達成度 (デプロイの成功、失敗したデプロイなど) を測定します。運用アクティビティの正常性を測定する運用メトリクスを定義します (たとえば、インシデントを検出する平均時間 (MTTD)、インシデントからの平均復旧時間 (MTTR) など)。メトリクスを評価して、運用アクティビティが必要な成果に達しているかを判定し、運用の正常性を把握します。
**一般的なアンチパターン:**
+ 運用メトリクスは、チームが合理的であると考える内容に基づいています。
+ メトリクスの計算にエラーがあり、誤った結果が生成されます。
+ あなたは、運用アクティビティに対して定義されたメトリクスを備えていません。
**このベストプラクティスを活用するメリット:** 運用メトリクスを定義して評価することで、運用アクティビティの状態を判断し、ビジネス成果の達成を測定できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 運用メトリクスを定義する: KPI の達成度を測定するため、運用メトリクスを定義します。運用メトリクスを定義して、運用とそのアクティビティの正常性を測定します。メトリクスを評価して、オペレーションが必要な成果に達しているかを判定し、オペレーションの正常性を把握します。
+ [カスタムメトリクスをパブリッシュする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [ログデータの検索およびフィルタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Amazon CloudWatch のメトリクスとディメンションのリファレンス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
## リソース
**関連するドキュメント:**
+ [AWS Answers: 集中ログ記録](https://aws.amazon.com/answers/logging/centralized-logging/)
+ [Amazon CloudWatch のメトリクスとディメンションのリファレンス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Amazon CloudWatch Events を使用してパイプラインの状態変化を検出し対処する](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html)
+ [カスタムメトリクスをパブリッシュする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [ログデータの検索およびフィルタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
**関連動画:**
+ モニタリング計画を立てる
# OPS09-BP03 運用メトリクスを収集し、分析する
メトリクスのプロアクティブなレビューを定期的に行うと、傾向を把握し、適切な対応が必要な領域を特定できます。
運用アクティビティと運用 API コールの実行から、CloudWatch Logs などのサービスにログデータを集約する必要があります。必要なログコンテンツの観測からメトリクスを生成して、運用アクティビティのパフォーマンスのインサイトを得られるようにします。
AWS では、 [ログデータを Amazon S3 に](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) エクスポートしたり、 [ログ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) を [Amazon S3 に直接送信して、](https://aws.amazon.com/s3/) 長期保存したりできます。分析のために、 [AWS Glue](https://aws.amazon.com/glue/)を使用すると、Amazon S3 でログデータを検出して準備し、関連するメタデータを [AWSAWS Glue Data Catalog に保存できます](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)。 [Amazon Athena ](https://aws.amazon.com/athena/)では、AWS Glue とのネイティブな統合により、ログデータを分析し、標準 SQL を使用してクエリを実行できます。Quick などのビジネスインテリジェンスツール [を使用して、](https://aws.amazon.com/quicksight/) データを可視化、調査、分析することができます。
**一般的なアンチパターン:**
+ 新機能の継続的な提供は、主要業績評価指標とみなされます。あなたは、デプロイの発生頻度を測定する方法を備えていません。
+ あなたは、デプロイ、ロールバックされたデプロイ、パッチ、およびロールバックされたパッチをログに記録して、運用アクティビティを追跡しますが、メトリクスを確認する人はいません。
+ あなたは、システムがデプロイされ、ユーザーがいないときに、15 分間の復旧時間以内に失われたデーベースを復旧することを目標として課せられました。このシステムは 2 年間運用されており、現在 10,000 人のユーザーがいます。最近の復旧には 2 時間以上かかりました。これは記録されておらず、誰も認識していません。
**このベストプラクティスを活用するメリット:** 運用メトリクスを収集して分析することで、運用の状態を把握し、運用やビジネス成果の達成に影響を与える可能性のある傾向について洞察を得ることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 運用のメトリクスを収集および分析する: メトリクスのプロアクティブなレビューを定期的に行うと、傾向を把握し、適切な対応が必要な領域を特定できます。
+ [Amazon CloudWatch メトリクスの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Amazon CloudWatch のメトリクスとディメンションのリファレンス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [CloudWatch エージェントを使用した Amazon EC2 インスタンスとオンプレミスサーバーからのメトリクスとログの収集](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
## リソース
**関連するドキュメント:**
+ [Amazon Athena](https://aws.amazon.com/athena/)
+ [Amazon CloudWatch のメトリクスとディメンションのリファレンス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Quick](https://aws.amazon.com/quicksight/)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWSAWS Glue Data Catalog に保存できます](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)
+ [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)
# OPS09-BP04 運用メトリクスの基準値を設定する
運用アクティビティのパフォーマンスを比較し、過不足を特定する基準となる期待値として、メトリクスに対する基準値を設定します。
**一般的なアンチパターン:**
+ あなたは、デプロイに必要な時間について尋ねられました。あなたは、デプロイにかかる時間を測定しておらず、予想時間を判断できません。
+ あなたは、アプリケーションサーバーの問題から復旧するまでにどれくらいの時間がかかるかを尋ねられました。あなたは、顧客の最初の連絡から復旧までの時間についての情報を持っていません。あなたは、モニタリングを通じて問題を最初に特定した時点から復旧までの時間についての情報を持っていません。
+ あなたは、週末に必要となるサポート担当者の数を尋ねられました。あなたは、週末に発生するサポートケースの一般的な数がわからず、予測を示すことができません。
+ あなたは、システムがデプロイされ、ユーザーがいないときに、15 分間の復旧時間以内に失われたデーベースを復旧することを目標として課せられました。このシステムは 2 年間運用されており、現在 10,000 人のユーザーがいます。あなたは、データベースの時間がどのように変化してきているかについての情報を持っていません。
**このベストプラクティスを活用するメリット:** ベースラインメトリクス値を定義することで、現在のメトリクス値とメトリクスの傾向を評価し、アクションが必要かどうかを判断できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 運用に対して予想されるアクティビティのパターンを知る: 運用アクティビティのパターンを確立すると、動作が期待値から外れるタイミングを把握し、必要に応じて適切に対応できるようになります。
# OPS09-BP05 運用に対して予想されるアクティビティのパターンを知る
運用アクティビティのパターンを確立して異常なアクティビティを識別し、必要に応じて適切に対応できるようにします。
**一般的なアンチパターン:**
+ あなたのデプロイ失敗率は、最近大幅に増加しました。あなたは、各障害に個別に対処しています。あなたは、失敗が、デプロイ管理システムに慣れていない新入社員によるデプロイに原因があることに気づいていません。
**このベストプラクティスを活用するメリット:** 動作パターンを学習することで、予期しない動作を認識し、必要に応じてアクションを実行できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 運用に対して予想されるアクティビティのパターンを知る: 運用アクティビティのパターンを確立すると、動作が期待値から外れるタイミングを把握し、必要に応じて適切に対応できるようになります。
# OPS09-BP06 オペレーションの結果にリスクがある場合に警告する
オペレーションの結果にリスクがある場合は、アラートを送信し、それに対処する必要があります。オペレーションの結果とは、本番稼働のワークロードをサポートするすべてのアクティビティを指します。これには、アプリケーションの新しいバージョンのデプロイから障害の復旧に至るまで、すべてのアクティビティが含まれます。オペレーションの結果は、ビジネスの成果と同等の重要度で対応する必要があります。
ソフトウェアチームは、主要なオペレーションメトリクスとアクティビティを特定し、それらに対するアラートを構築する必要があります。適切なタイミングでアラートを送信し、アラートは実行可能なものである必要があります。アラートを送信する際は、対応するランブックまたはプレイブックへの参照を含める必要があります。対応するアクションがないアラートは、以下につながる可能性があります。
**期待される成果:** オペレーションのアクティビティにリスクがある場合、アクションを促すためのアラートが送信されます。このアラートにはアラートが送信された理由のコンテキストが含まれます。また、調査を行うためのプレイブック、またはアラートを緩和するためのランブックへの参照が含まれます。可能な場合、ランブックは自動化し、通知を送信します。
**一般的なアンチパターン:**
+ インシデントの調査が行われ、サポートケースが作成されています。サポートケースはサービスレベルアグリーメント (SLA) に違反していますが、アラートは送信されていません。
+ 本番稼働へのデプロイは深夜に予定されていましたが、直前の変更によりデプロイが遅れました。アラートは送信されず、デプロイは完了しませんでした。
+ 本番稼働に障害が発生しましたが、アラートは送信されませんでした。
+ デプロイ時間には頻繁に遅延が生じています。調査は行われていません。
**このベストプラクティスを活用するメリット:**
+ オペレーションの結果にリスクがある場合にアラートを送信することで、問題が発生する前にワークロードをサポートする能力を高めることができます。
+ 正常なオペレーションの結果によって、ビジネス成果を改善できます。
+ オペレーションの問題の検出と問題への対応を改善できます。
+ 全体的なオペレーションの正常性が向上します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 中
## 実装のガイダンス
オペレーションの結果に関するアラートを送信する前に、オペレーションの結果を定義する必要があります。組織にとって最も重要なオペレーションアクティビティを定義することから始めます。それは、本番稼働へのデプロイを 2 時間以内に終えることでしょうか？それとも、決められた時間内にサポートケースに対応することでしょうか？ 組織は、主要なオペレーションアクティビティを監視、改善、およびそれらに関するアラートを送信するために、主要なオペレーションアクティビティとそれらを計測する方法を定義する必要があります。ワークロードとオペレーションのテレメトリを保存し分析するための、一元的な場所が必要です。同じ仕組みを使用して、オペレーションの結果にリスクがある場合に、アラートを送信します。
**顧客の事例**
AnyCompany Retail のルーティンデプロイ中に CloudWatch アラームがトリガーされました。デプロイのリードタイムは予定を超えてしまい、Amazon EventBridge によって AWS Systems Manager OpsCenter で OpsItem が作成されました。クラウドオペレーションチームは、プレイブックを使用して問題を調査し、スキーマの変更が想定よりも長くかかっていることを特定しました。彼らはオンコール開発者にアラートを送信し、デプロイの監視を続けました。デプロイの完了後、クラウドオペレーションチームは OpsItem を解決しました。チームは事後分析でインシデントを分析する予定です。
## 実装手順
1. オペレーションの KPI、メトリクス、およびアクティビティを特定していない場合、この質問に対するベストプラクティスを採用します (OPS09-BP01 から OPS09-BP05)。
+ エンタープライズサポートのある サポート カスタマーは、 [テクニカルアカウントマネージャーから](https://aws.amazon.com/premiumsupport/plans/enterprise/) オペレーション KPI ワークショップを [リクエストできます](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) 。このコラボレーティブワークショップは、ビジネス目標に沿ったオペレーション KPI やメトリクスの定義に役立ちます。追加の費用はありません。詳細については、担当のテクニカルアカウントマネージャーにお問い合わせください。
1. オペレーションアクティビティ、KPI、メトリクスの確立後、可観測性プラットフォームでアラートを構成します。プレイブックやランブックと同様に、アラートには関連するアクションが必要です。アクションを伴わないアラートは避けてください。
1. 時間の経過とともに、オペレーションメトリクス、KPI、アクティビティを評価し、改善の領域を特定します。フィードバックをオペレーターからのランブックとプレイブックに反映し、アラートへの対応を改善できる領域を特定します。
1. アラートには、アラートを誤検出としてフラグを付けるための仕組みを含める必要があります。これは、メトリクスのしきい値のレビューにつながります。
**実装計画に必要な工数レベル:** 中。このベストプラクティスを採用する前に、採用が必要ないくつかのベストプラクティスがあります。オペレーターアクティビティを特定し、オペレーション KPI を確立したら、アラートを作成します。
## リソース
**関連するベストプラクティス:**
+ [OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する](ops_ops_model_def_activity_owners.md): すべてのオペレーションアクティビティおよび結果に対して責任を持つ所有者を特定する必要があります。オペレーションの結果にリスクがある場合、アラートは所有者に送信されます。
+ [OPS03-BP02 チームメンバーに、結果にリスクがあるときにアクションを実行する権限が付与されている](ops_org_culture_team_emp_take_action.md): チームは、アラートが送信された際に問題に対応するエージェンシーを用意する必要があります。
+ [OPS09-BP01 主要業績評価指標 (KPI) を特定する](ops_operations_health_define_ops_kpis.md): オペレーションの結果に関するアラートは、オペレーション KPI を特定することから開始されます。
+ [OPS09-BP02 運用メトリクスを定義する](ops_operations_health_design_ops_metrics.md): アラートを生成し始める前に、このベストプラクティスを確立します。
+ [OPS09-BP03 運用メトリクスを収集し、分析する](ops_operations_health_collect_analyze_ops_metrics.md): アラートを構築するには、オペレーションメトリクスを一元的に収集する必要があります。
+ [OPS09-BP04 運用メトリクスの基準値を設定する](ops_operations_health_ops_metric_baselines.md): オペレーションメトリクスは、アラートを調整しアラート疲れを防ぐための基準を提供します。
+ [OPS09-BP05 運用に対して予想されるアクティビティのパターンを知る](ops_operations_health_learn_ops_usage_patterns.md): オペレーションイベントのアクティビティパターンを理解することで、アラートの精度を高められます。
+ [OPS09-BP08 KPI とメトリクスの成果の達成度と有効性を検証する](ops_operations_health_biz_level_view_ops.md): オペレーションの結果の成果を評価して、KPI とメトリクスが正しいことを確認します。
+ [OPS10-BP02 アラートごとにプロセスを用意する](ops_event_response_process_per_alert.md): すべてのアラートには関連するランブックまたはプレイブックが必要で、アラートを受け取る担当者にコンテキストを提供する必要があります。
+ [OPS11-BP02 インシデント後の分析を実行する](ops_evolve_ops_perform_rca_process.md): アラート後の事後分析を実施し、改善の領域を特定します。
**関連するドキュメント:**
+ [AWS デプロイパイプラインリファレンスアーキテクチャ: アプリケーションパイプラインアーキテクチャ](https://pipelines.devops.aws.dev/application-pipeline/)
+ [GitLab: アジャイル/DevOps メトリクスの使用を開始する](https://about.gitlab.com/handbook/marketing/strategic-marketing/devops-metrics/)
**関連動画:**
+ [AWS Systems Manager OpsCenter を使用したオペレーションの問題の収集と解決](https://www.youtube.com/watch?v=r6ilQdxLcqY)
+ [AWS Systems Manager OpsCenter と Amazon CloudWatch アラームの統合](https://www.youtube.com/watch?v=Gpc7a5kVakI)
+ [Amazon EventBridge を使用して AWS Systems Manager OpsCenter にデータソースを統合する](https://www.youtube.com/watch?v=Xmmu5mMsq3c)
**関連サンプル:**
+ [Automate remediation actions for Amazon EC2 notifications and beyond using Amazon EC2 Systems Manager Automation and AWS Health](https://aws.amazon.com/blogs/mt/automate-remediation-actions-for-amazon-ec2-notifications-and-beyond-using-ec2-systems-manager-automation-and-aws-health/)
+ [AWS 管理とガバナンスツールワークショップ - オペレーション 2022](https://mng.workshop.aws/operations-2022.html)
+ [AWS の DevOps モニタリングダッシュボードでメトリクスの取り込み、分析、視覚化を行う](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/welcome.html)
**関連サービス:**
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [サポート プロアクティブサービス - オペレーション KPI ワークショップ](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
+ [CloudWatch イベント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS09-BP07 運用の異常が検出された場合に警告する
運用の異常が検出された場合、必要に応じて適切な対応ができるよう、アラートを発生させます。
時間をかけて運用メトリクスを分析すると、イベントを定義したり、それに応じてアラームを発生させるために十分に定量化できる動作パターンが確立される可能性があります。
トレーニングが完了すると、 [CloudWatch Anomaly Detection ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 機能を使用して、 [検出された異常を警告したり、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html) メトリクスデータのグラフに重ねて [予想値を渡して](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html#create-metric-graph) 継続的な比較を行うことができます。
[Amazon DevOps Guru を使用して、](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) イベントの関連性、ログ分析、ワークロードテレメトリー分析への機械学習の適用によって、異常な動作を検出できます。取得した [インサイトは、](https://docs.aws.amazon.com/devops-guru/latest/userguide/understanding-insights-console.html) 関連データとレコメンデーションとともに表示されます。
**一般的なアンチパターン:**
+ あなたは、インスタンスのフリートにパッチを適用しようとしています。テスト環境では、パッチが正常にテストされました。フリート内のインスタンスの大部分でパッチが失敗しています。あなたは、何らのアクションも行っていません。
+ あなたは、金曜日の終わりから始まるデプロイがあることに気づいています。組織は、火曜日と木曜日のメンテナンスウィンドウを事前定義しています。あなたは、何らのアクションも行っていません。
**このベストプラクティスを活用するメリット:** 運用の動作パターンを理解することで、予期しない動作を特定し、必要に応じてアクションを実行できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ 運用の異常が検出された場合にアラートを出す: 運用の異常が検出された場合、必要に応じて適切な対応ができるよう、警告を発生させます。
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Amazon CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon SNS 通知を使用した Lambda 関数の呼び出し](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
## リソース
**関連するドキュメント:**
+ [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [CloudWatch Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [Amazon CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon CloudWatch Events を使用してパイプラインの状態変化を検出し対処する](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html)
+ [Amazon SNS 通知を使用した Lambda 関数の呼び出し](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS09-BP08 KPI とメトリクスの成果の達成度と有効性を検証する
オペレーションアクティビティに対するビジネスレベルの視点を確立すると、ニーズを満足しているかどうかを判断したり、ビジネス目標を達成するために改善が必要な領域を特定したりできます。KPI とメトリクスの有効性を検証し、必要に応じて修正します。
また、AWS は、AWS のサービス API や SDK を介してサードパーティーのログ分析システム (Grafana、Kibana、Logstash など) やビジネスインテリジェンスツールもサポートしています。
**一般的なアンチパターン:**
+ 開発チームの数が増えるにつれて、デプロイの頻度が増加しています。定義された予想デプロイ数は 1 週間に 1 回です。あなたは、毎日定期的にデプロイしています。デプロイシステムに問題があり、デプロイが不可能な場合、それが検出されるのは数日後です。
+ 以前、あなたの会社では、月曜日から金曜日までの営業時間中にのみサポートを提供していました。あなたは、インシデントについて、「翌営業日」の応答時間の目標を設定しました。最近、あなたは、2 時間の応答時間の目標で 24 時間年中無休のサポートを提供し始めました。夜勤のスタッフは対応しきれておらず、顧客は不満を感じています。報告は「翌営業日」のターゲットに対して行われているので、インシデントへの応答時間に問題があることは示唆されていません。
**このベストプラクティスを活用するメリット:** KPI とメトリクスを確認して修正することで、ワークロードがビジネス成果の達成をどのようにサポートしているかを理解し、ビジネス目標を達成するために改善が必要な場所を特定できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ KPI とメトリクスの成果の達成度と有効性を検証する: 運用に対するビジネスレベルの視点を確立すると、ニーズを満たしているかどうかを判断したり、ビジネス目標を達成するために改善が必要な領域を特定したりできます。KPI とメトリクスの有効性を検証し、必要に応じて修正します。
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [ログ分析とは](https://aws.amazon.com/log-analytics/)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [ログ分析とは](https://aws.amazon.com/log-analytics/)
# 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 イベント、インシデント、問題管理のプロセスを使用する
組織には、イベント、インシデント、問題を扱うためのプロセスがあります。*イベント* は、ワークロードで発生しますが、必ずしも介入を必要としない出来事です。*インシデント* は、介入を必要とするイベントです。 *問題* は、介入しなければ解決できない、繰り返し発生するイベントです。これらのイベントがビジネスに与える影響を軽減し、適切に対応できるようにするためのプロセスが必要です。
ワークロードにインシデントや問題が発生したとき、それらを処理するためのプロセスが必要です。イベントの状況を関係者にどのように伝えますか。 対応をだれが監督しますか。 イベントの緩和に使用するツールは何ですか。 これらは、確実な対応策を講じるために必要な質問の一例です。
プロセスは一元的に文書化し、ワークロードに関わる誰もが利用できるようにする必要があります。もし、一元的な Wiki や ドキュメントの保管場所がない場合は、バージョン管理リポジトリを使用することができます。プロセスの進化につれて、これらのプランを最新に保ちます。
問題は、オートメーションの候補です。これらのイベントが発生すると、イノベーションにかける時間が奪われます。問題を軽減するための繰り返し可能なプロセスから始めましょう。時間をかけて、軽減策のオートメーション化または根本的な問題の解決に注力します。そうすることで、ワークロードの改善に充てる時間を確保することができます。
**期待される成果:** 組織には、イベント、インシデント、問題を扱うためのプロセスがあります。これらのプロセスは文書化され、一元的に保管されます。プロセスの変化につれて更新されます。
**一般的なアンチパターン:**
+ インシデントが週末に発生すると、オンコールエンジニアはどうしてよいかわかりません。
+ 顧客からアプリケーションがダウンしたという E メールが送られてきます。修正するためにサーバーを再起動します。これが頻繁に起きます。
+ 複数のチームが解決のために個別に取り組んでいるインシデントがあります。
+ ワークロードで、記録されることなくデプロイが行われます。
**このベストプラクティスを活用するメリット:**
+ ワークロードのイベントの監査証跡ができます。
+ インシデントからの復旧時間が短縮されます。
+ チームメンバーは一貫した方法でインシデントと問題を解決できます。
+ インシデントを調査するときに、より総合的に取り組むことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
このベストプラクティスを実装すると、ワークロードイベントを追跡することになります。インシデントと問題を扱うためのプロセスができます。プロセスは文書化され、共有され、頻繁に更新されます。問題が特定され、優先順位が付けられ、修正されます。
**顧客の事例**
AnyCompany Retail では、社内 Wiki の一部がイベント、インシデント、問題管理のためのプロセス専用になっています。 すべてのイベントは以下に送信されます : [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html).問題は [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) で OpsItem として特定され、優先的に修正されるため、未分化な労力を削減することができます。プロセスが変化すると、社内 Wiki で更新されます。同社では、 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) を使用してインシデントを管理し、緩和の取り組みを調整しています。
## 実装手順
1. イベント
+ 人間の介入を必要としない場合でも、ワークロードで発生するイベントを追跡します。
+ ワークロードの関係者と協力して、追跡すべきイベントのリストを作成します。例えば、デプロイの完了やパッチ適用の成功などです。
+ また、 [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) または [Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) などのサービスを使用して、追跡するカスタムイベントを生成することができます。
1. インシデント
+ インシデント発生時の情報伝達プランを明確にすることから始めましょう。どのような関係者に通知する必要がありますか。 どのようにして情報を共有しますか。 誰が調整作業を監督しますか。 コミュニケーションと調整のために、社内チャットチャネルを立ち上げることをお勧めします。
+ 特にオンコールのローテーションがないチームの場合は、ワークロードをサポートするチームのエスカレーションパスを定義しておきましょう。サポートレベルに基づいて、サポート に申請を行うことも可能です。
+ インシデントを調査するためのプレイブックを作成します。これには、情報伝達プランや詳細な調査手順が含まれている必要があります。調査には、 [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) の確認を含めます。
+ インシデント対応計画を文書化します。インシデント管理計画を伝達し、社内外の顧客がエンゲージメントのルールと何を期待されているのかを理解できるようにします。使用方法について、チームメンバーをトレーニングします。
+ 顧客は [Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) を使用してインシデント対応プランを設定し、管理できます。
+ エンタープライズサポートのお客様は [インシデント管理ワークショップ](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) をテクニカルアカウントマネージャーからリクエストできます。このガイド付きワークショップでは、既存のインシデント対応計画をテストし、改善すべき点を明らかにすることができます。
1. 問題
+ ITSM システムで問題を特定して、追跡する必要があります。
+ 既知の問題をすべて特定し、修正作業とワークロードへの影響から優先順位を付けます。
![\[問題に優先順位を付けるためのアクション優先度マトリックス。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/impact-effort-chart.png)
+ 影響が大きく、労力が少なくて済む問題から解決します。そのような問題が解決したら、影響が少なく、労力が少なくて済む象限の問題に移ります。
+ 専用のインフラストラクチャで [Systems Manager OpsCenter](systems-manager/latest/userguide/OpsCenter.html) を使用して、これらの問題を特定し、ランブックをアタッチして、追跡します。
**実装計画に必要な工数レベル:** 中程度。このベストプラクティスを実装するには、プロセスとツールの両方が必要です。プロセスを文書化し、ワークロードに関わる誰もが使用できるようにします。頻繁に更新します。問題を管理し、問題を緩和または修正するためのプロセスがあります。
## リソース
**関連するベストプラクティス:**
+ [OPS07-BP03 ランブックを使用して手順を実行する](ops_ready_to_support_use_runbooks.md): 既知の問題には、緩和作業に一貫性を持たせるために、関連するランブックが必要です。
+ [OPS07-BP04 プレイブックを使用して問題を調査する](ops_ready_to_support_use_playbooks.md): インシデントはプレイブックを使用して調査する必要があります。
+ [OPS11-BP02 インシデント後の分析を実行する](ops_evolve_ops_perform_rca_process.md): インシデントからの復旧後は、必ず事後分析を実施します。
**関連するドキュメント:**
+ [Atlassian - DevOps 時代のインシデント管理](https://www.atlassian.com/incident-management/devops)
+ [AWS セキュリティインシデント対応ガイド](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [DevOps および SRE 時代のインシデント管理](https://www.infoq.com/presentations/incident-management-devops-sre/)
+ [PagerDuty - インシデント管理とは](https://www.pagerduty.com/resources/learn/what-is-incident-management/)
**関連動画:**
+ [AWS re:Invent 2020: 分散組織におけるインシデント管理](https://www.youtube.com/watch?v=tyS1YDhMVos)
+ [AWS re:Invent 2021: イベント駆動型アーキテクチャによる次世代アプリケーションの構築](https://www.youtube.com/watch?v=U5GZNt0iMZY)
+ [AWS Supports You \$1 インシデント管理の机上演習を試す](https://www.youtube.com/watch?v=0m8sGDx-pRM)
+ [AWS Systems Manager Incident Manager - AWS 仮想ワークショップ](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [AWS What's Next ft. Incident Manager \$1 AWS イベント](https://www.youtube.com/watch?v=uZL-z7cII3k)
**関連する例:**
+ [AWS 管理とガバナンスツールワークショップ - OpsCenter](https://mng.workshop.aws/ssm/capability_hands-on_labs/opscenter.html)
+ [AWS プロアクティブサービス - インシデント管理ワークショップ](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [Amazon EventBridge によるイベント駆動型アプリケーションの構築](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [AWS でのイベント駆動型アーキテクチャの構築](https://catalog.us-east-1.prod.workshops.aws/workshops/63320e83-6abc-493d-83d8-f822584fb3cb/en-US/)
**関連サービス:**
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
+ [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
# OPS10-BP02 アラートごとにプロセスを用意する
アラートを発生させるイベントすべてに対して具体的な対応策 (ランブックやプレイブック) を定め、所有者を明確に指定しておくようにします。こうすることで、運用上のイベントに対する効果的で迅速な対応が可能になり、アクションの必要なイベントが重要度の低い通知に埋もれてしまうことを避けられます。
**一般的なアンチパターン:**
+ モニタリングシステムは、他のメッセージとともに、承認された接続のストリームを表示します。メッセージの量が非常に大きいため、あなたは、介入を必要とする定期的なエラーメッセージを見逃します。
+ あなたは、ウェブサイトがダウンしている旨のアラートを受け取ります。このような状況が発生した場合のプロセスは定義されていません。あなたは、アドホックのアプローチで問題を診断して解決しなければなりません。対応に当たりながらこのプロセスを開発すると、復旧までの時間が長くなります。
**このベストプラクティスを確立するメリット:** アクションが必要な場合にのみアラートを出すことで、低い価値のアラートによって高い価値のアラートが見過ごされるのを防ぎます。アクション可能なアラートごとにプロセスを設定することで、環境内のイベントに対して一貫した迅速な対応を可能にします。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ アラートを発するイベントには、明確に定義された対応策 (ランブックまたはプレイブック) が必要であり、成功裏に完了する責任を負う所有者 (例えば、個人、チーム、役割) が明確に特定されていなければなりません。対応策が実際には自動で、または別のチームによって実行される場合でも、プロセスによって期待される成果を実現させる責任は所有者が持ちます。こうしたプロセスによって、運用上のイベントに対する効果的で迅速な対応が可能になり、アクションの必要なイベントが重要度の低い通知に埋もれてしまうことを避けられます。例えば、ウェブのフロントエンドをスケールする際にスケーリングが自動的に適用される場合でも、自動スケーリングのルールや制限をワークロードのニーズに適したものにすることは運用チームの責任になります。
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch の特徴](https://aws.amazon.com/cloudwatch/features/)
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
**関連動画:**
+ [モニタリング計画を立てる](https://www.youtube.com/watch?v=OMmiGETJpfU)
# OPS10-BP03 ビジネスへの影響に基づいて運用上のイベントの優先度を決定する
介入を必要とする複数のイベントが発生したときに、ビジネスにとって最重要なものから対応できるようにしておきます。影響の例として、死亡や傷害、経済的損失、評判や信用の低下などがあります。
**一般的なアンチパターン:**
+ あなたは、ユーザーのプリンター設定を追加するサポートリクエストを受け取ります。問題に対応している間に、あなたは、小売サイトがダウンしている旨のサポートリクエストを受け取ります。ユーザーのプリンター設定が完了したら、あなたは、ウェブサイトの問題の対応を開始します。
+ あなたには、小売ウェブサイトと給与システムの両方が停止していることが通知されます。あなたは、どちらを優先すべきかわかりません。
**このベストプラクティスを活用するメリット:** ビジネスに最も大きな影響を与えるインシデントへの対応に優先順位を付けることで、その影響を管理できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ビジネスへの影響に基づき、運用イベントの優先度を決定する: 介入を必要とする複数のイベントが発生したときに、ビジネスにとって最も重要なものから対応できるようにしておきます。影響の例として、死亡や傷害、経済的損失、規定違反、評判や信用の低下などがあります。
# OPS10-BP04 エスカレーション経路を決定する
ランブックとプレイブックで、エスカレーションをトリガーするものとエスカレーションの手順を含むエスカレーション経路を決定します。特に、各アクションの所有者を特定し、運用イベントに効果的かつすばやく対応できるようにします。
アクションを行う前に、人間による決定が必要なタイミングを特定します。意思決定者と協力して事前に決定を行い、アクションを事前に承認することで、MTTR が応答を長時間待機しないようにします。
**一般的なアンチパターン:**
+ あなたの小売サイトがダウンしています。あなたは、サイトを復旧するためのランブックを理解していません。あなたは、誰かがサポートしてくれることを願いながら、同僚に電話をかけ始めます。
+ あなたは、アクセス不能なアプリケーションのサポートケースを受け取ります。あなたには、システムを管理するためのアクセス許可がありません。あなたは、誰が管理しているかを知りません。ケースを開いたシステム所有者に連絡しようとしましたが、応答がありません。あなたはシステムに関する問い合わせ先を知らず、同僚はそれになじみがありません。
**このベストプラクティスを活用するメリット:** エスカレーション、エスカレーションのトリガー、エスカレーションの手順を定義することで、影響に対して適切な割合で、インシデントへの体系的なリソースの追加が可能となります。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ エスカレーションパスを定義する: ランブックとプレイブックで、何がエスカレーションをトリガーするかやエスカレーションの手順を含む、エスカレーション経路を決定します。例えば、ランブックで問題が解決できない場合や、一定期間が経過した場合にサポートエンジニアからシニアサポートエンジニアに向けた問題のエスカレーションがあります。また、プレイブックでは修正経路が特定できない場合や、一定期間が経過した場合に、ワークロードについてシニアサポートエンジニアから開発チームに向けたエスカレーションなども例として挙げられます。特に、各アクションの所有者を特定し、運用イベントに効果的かつすばやく対応できるようにします。エスカレーションには第三者が入る場合があります。例えば、ネットワーク接続プロバイダーまたはソフトウェアベンダーです。エスカレーションには、影響するシステムについて承認を受けた特定の意思決定者を含めることができます。
# OPS10-BP05 プッシュ通知を有効にする
ユーザーの使用するサービスに影響が生じたときに、ユーザーと直接通信し (E メールや SMS など)、再び通常運用状態に復帰したときに再度通信し、ユーザーが適切な対応アクションを起こせるようにします。
**一般的なアンチパターン:**
+ アプリケーションで分散型サービス拒否のインシデントが発生し、数日間応答がない状態になっています。エラーメッセージはありません。あなたは、通知 E メールを送信していません。あなたは、テキスト通知を送信していません。あなたは、ソーシャルメディアで情報を共有していません。お客様は不満を抱いており、サポートしてくれる他のベンダーを探しています。
+ 月曜日に、アプリケーションでパッチ適用後に問題が生じ、数時間停止しました。火曜日に、コードのデプロイ後にアプリケーションに問題が発生し、数時間にわたり信頼性が低下しました。水曜日に、失敗したパッチに関連するセキュリティの脆弱性を軽減するためコードをデプロイした後に、アプリケーションで問題があり、数時間使用できませんでした。木曜日に、不満を募らせたお客様が、サポートしてくれる他のベンダーを探し始めました。
+ アプリケーションは、今週末にメンテナンスのために停止します。あなたは、顧客に通知しません。一部の顧客は、アプリケーションの使用を要するアクティビティを予定していました。顧客は、アプリケーションが利用できないことを知ると、不満を爆発させます。
**このベストプラクティスを確立するメリット:** 通知、通知のトリガー、および通知の手順を定義することで、ワークロードに関する問題が顧客に影響した場合に、顧客に当該事実を伝え、対応できるようになります。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ プッシュ通知を有効にする: ユーザーが利用しているサービスに影響があった場合、またサービスが正常な動作状態に戻った場合、ユーザーが適切なアクションを起こせるように、E メールや SMS などで直接ユーザーに伝えます。
+ [Amazon SES の特徴](https://aws.amazon.com/ses/details/)
+ [Amazon SES とは](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Amazon SNS 通知の設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
## リソース
**関連するドキュメント:**
+ [Amazon SES の特徴](https://aws.amazon.com/ses/details/)
+ [Amazon SNS 通知の設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [Amazon SES とは](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
# OPS10-BP06 ダッシュボードでステータスを知らせる
対象となる利用者 (内部技術チーム、指導部、顧客など) に合わせたダッシュボードを用意して、現在の業務の運用状況と、相手が関心を持つメトリクスを知らせます。
コンソールのカスタマイズ可能なホームページで [Amazon CloudWatch ダッシュボードを使用して](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) コンソール CloudWatch でダッシュボードを作成できます。Quick のようなビジネスインテリジェンスサービスを [使用すると、](https://aws.amazon.com/quicksight/) ワークロードと運用状態 (注文率、接続ユーザー、トランザクション時間など) のインタラクティブなダッシュボードを作成して公開できます。メトリクスのシステムレベルおよびビジネスレベルのビューを表示するダッシュボードを作成します。
**一般的なアンチパターン:**
+ リクエストに応じて、あなたは、管理のためのアプリケーションの現在の使用状況に関するレポートを実行します。
+ インシデント中、あなたには、心配なシステム所有者から「修正状況」を知りたいという連絡が 20 分ごとにあります。
**このベストプラクティスを活用するメリット:** ダッシュボードを作成することで、情報へのセルフサービスアクセスが可能になり、顧客自身が情報を確認し、アクションが必要かどうかを判断できるようになります。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ダッシュボードで状態を知らせる: 対象となる利用者 (内部技術チーム、経営陣、顧客など) に合わせたダッシュボードを用意して、現在の業務の運用状況と、相手が関心を持つメトリクスを知らせます。ステータス情報のセルフサービスオプションによって、ステータスのリクエスト処理による運用チームの中断を減らすことができます。例として、Amazon CloudWatch ダッシュボードと AWS Health Dashboard が挙げられます。
+ [CloudWatch ダッシュボードを使ったカスタムメトリクスビューの作成と使用](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/)
## リソース
**関連するドキュメント:**
+ [Quick](https://aws.amazon.com/quicksight/)
+ [CloudWatch ダッシュボードを使ったカスタムメトリクスビューの作成と使用](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/)
# OPS10-BP07 イベントへの対応を自動化する
イベントへの対応を自動化し、手動プロセスによって発生するエラーを減らして、迅速かつ一貫した対応を実現します。
AWS には、ランブックやプレイブックのアクションを自動的に実行する複数の方法があります。AWS リソースの状態変化や独自のカスタムイベントからのイベントに対応するには、 [CloudWatch Events ルールを作成し、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) CloudWatch のターゲット (Lambda 関数、Amazon Simple Notification Service (Amazon SNS) トピック、Amazon ECS タスク、AWS Systems Manager Automation など) を通じて対応を起動します。
リソースのしきい値を超えるメトリクス (待機時間など) に応答するには、 [CloudWatch アラームを作成して ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) Amazon EC2 アクションや Auto Scaling アクションを使用して 1 つ以上のアクションを実行するか、Amazon SNS トピックに通知を送信します。アラームへの応答でカスタムアクションを実行する必要がある場合は、Amazon SNS 通知を通じて Lambda を呼びだします。Amazon SNS を使用して、イベント通知とエスカレーションメッセージを発行し、ユーザーに情報を提供します。
また、AWS は、AWS のサービス API と SDK を通じてサードパーティーシステムもサポートしています。AWS パートナーやサードパーティーでは、モニタリング、通知、応答を可能にするモニタリングツールを多数提供しています。これらのツールには、New Relic、Splunk、Loggly、SumoLogic、Datadog などがあります。
自動化された手順が失敗した場合に、手動でも重要な手順を実施できるようにしておく必要があります。
**一般的なアンチパターン:**
+ 開発者が自分のコードをチェックインします。このイベントは、ビルドを開始し、テストを実行するために使用することもできましたが、結局、何にも使用されていません。
+ アプリケーションが動作を停止する前に、特定のエラーをログ記録します。アプリケーションを再起動する手順はよく理解されており、スクリプト化することもできました。あなたは、ログイベントを使用して、スクリプトを呼び出し、アプリケーションを再起動することもできました。しかし、それらの対応を行わなかったため、日曜日の午前 3 時にエラーが発生し、あなたは、オンコールでシステムを修正する責任者として起こされます。
**このベストプラクティスを確立するメリット:** イベントへの対応を自動化することで、対応にかかる時間を短縮し、手作業によるエラーの発生を抑制することができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ イベントへの対応を自動化する: イベントへの対応を自動化し、手動プロセスによって発生するエラーを減らして、迅速かつ一貫した対応を実現します。
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [イベントでトリガーする CloudWatch Events のルールの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html)
+ [AWS CloudTrail を使用して AWS API コールでトリガーする CloudWatch Events ルールの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html)
+ [サポートされているサービスからの CloudWatch Events イベントの例](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch の特徴](https://aws.amazon.com/cloudwatch/features/)
+ [サポートされているサービスからの CloudWatch Events イベントの例](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html)
+ [AWS CloudTrail を使用して AWS API コールでトリガーする CloudWatch Events ルールの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html)
+ [イベントでトリガーする CloudWatch Events のルールの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html)
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
**関連動画:**
+ [モニタリング計画を立てる](https://www.youtube.com/watch?v=OMmiGETJpfU)
**関連する例:**