

# OPS 9 オペレーションの正常性をどのように把握するのですか?
<a name="w2aac19b5b9b7"></a>

 オペレーションメトリクスを定義し、キャプチャし、分析することで、オーペレーションイベントの可視性を高め、適切なアクションがとれるようになります。 

**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) を特定する
<a name="ops_operations_health_define_ops_kpis"></a>

 希望するビジネスの成果 (新機能など) とお客様の成果 (カスタマーサポートケースなど) に基づいて、主要業績指標 (KPI) を特定します。KPI を評価して、オペレーションの成功を判別します。 

 **一般的なアンチパターン:** 
+  あなたは、ビジネスリーダーから、オペレーションがビジネス目標をどのように達成したかを尋ねられますが、寄与度を判断するための基準となる枠組みがありません。 
+  あなたは、メンテナンスウィンドウがビジネスの成果に影響しているかどうかを判断できません。 

 **このベストプラクティスを活用するメリット:** オペレーションの正常性と成功のテストとして、主要業績評価指標を特定することで、ビジネス成果を達成できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  主要業績評価指標 (KPI) を特定する: ビジネスおよび顧客が求める成果に基づいて、主要業績評価指標 (KPI) を特定します。KPI を評価して、オペレーションの成功を判別します。 

# OPS09-BP02 運用メトリクスを定義する
<a name="ops_operations_health_design_ops_metrics"></a>

 運用メトリクスを定義して、KPI の達成度 (デプロイの成功、失敗したデプロイなど) を測定します。運用アクティビティの正常性を測定する運用メトリクスを定義します (たとえば、インシデントを検出する平均時間 (MTTD)、インシデントからの平均復旧時間 (MTTR) など)。メトリクスを評価して、運用アクティビティが必要な成果に達しているかを判定し、運用の正常性を把握します。 

 **一般的なアンチパターン:** 
+  運用メトリクスは、チームが合理的であると考える内容に基づいています。 
+  メトリクスの計算にエラーがあり、誤った結果が生成されます。 
+  あなたは、運用アクティビティに対して定義されたメトリクスを備えていません。 

 **このベストプラクティスを活用するメリット:** 運用メトリクスを定義して評価することで、運用アクティビティの状態を判断し、ビジネス成果の達成を測定できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  運用メトリクスを定義する: 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) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [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 運用メトリクスを収集し、分析する
<a name="ops_operations_health_collect_analyze_ops_metrics"></a>

 メトリクスのプロアクティブなレビューを定期的に行うと、傾向を把握し、適切な対応が必要な領域を特定できます。 

 運用アクティビティと運用 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 時間以上かかりました。これは記録されておらず、誰も認識していません。 

 **このベストプラクティスを活用するメリット:** 運用メトリクスを収集して分析することで、運用の状態を把握し、運用やビジネス成果の達成に影響を与える可能性のある傾向について洞察を得ることができます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  運用のメトリクスを収集および分析する: メトリクスのプロアクティブなレビューを定期的に行うと、傾向を把握し、適切な対応が必要な領域を特定できます。 
  +  [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) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [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 運用メトリクスの基準値を設定する
<a name="ops_operations_health_ops_metric_baselines"></a>

 運用アクティビティのパフォーマンスを比較し、過不足を特定する基準となる期待値として、メトリクスに対する基準値を設定します。 

 **一般的なアンチパターン:** 
+  あなたは、デプロイに必要な時間について尋ねられました。あなたは、デプロイにかかる時間を測定しておらず、予想時間を判断できません。 
+  あなたは、アプリケーションサーバーの問題から復旧するまでにどれくらいの時間がかかるかを尋ねられました。あなたは、顧客の最初の連絡から復旧までの時間についての情報を持っていません。あなたは、モニタリングを通じて問題を最初に特定した時点から復旧までの時間についての情報を持っていません。 
+  あなたは、週末に必要となるサポート担当者の数を尋ねられました。あなたは、週末に発生するサポートケースの一般的な数がわからず、予測を示すことができません。 
+  あなたは、システムがデプロイされ、ユーザーがいないときに、15 分間の復旧時間以内に失われたデーベースを復旧することを目標として課せられました。このシステムは 2 年間運用されており、現在 10,000 人のユーザーがいます。あなたは、データベースの時間がどのように変化してきているかについての情報を持っていません。 

 **このベストプラクティスを活用するメリット:** ベースラインメトリクス値を定義することで、現在のメトリクス値とメトリクスの傾向を評価し、アクションが必要かどうかを判断できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  運用に対して予想されるアクティビティのパターンを知る: 運用アクティビティのパターンを確立すると、動作が期待値から外れるタイミングを把握し、必要に応じて適切に対応できるようになります。 

# OPS09-BP05 運用に対して予想されるアクティビティのパターンを知る
<a name="ops_operations_health_learn_ops_usage_patterns"></a>

 運用アクティビティのパターンを確立して異常なアクティビティを識別し、必要に応じて適切に対応できるようにします。 

 **一般的なアンチパターン:** 
+  あなたのデプロイ失敗率は、最近大幅に増加しました。あなたは、各障害に個別に対処しています。あなたは、失敗が、デプロイ管理システムに慣れていない新入社員によるデプロイに原因があることに気づいていません。 

 **このベストプラクティスを活用するメリット:** 動作パターンを学習することで、予期しない動作を認識し、必要に応じてアクションを実行できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  運用に対して予想されるアクティビティのパターンを知る: 運用アクティビティのパターンを確立すると、動作が期待値から外れるタイミングを把握し、必要に応じて適切に対応できるようになります。 

# OPS09-BP06 オペレーションの結果にリスクがある場合に警告する
<a name="ops_operations_health_ops_outcome_alerts"></a>

 オペレーションの結果にリスクがある場合は、アラートを送信し、それに対処する必要があります。オペレーションの結果とは、本番稼働のワークロードをサポートするすべてのアクティビティを指します。これには、アプリケーションの新しいバージョンのデプロイから障害の復旧に至るまで、すべてのアクティビティが含まれます。オペレーションの結果は、ビジネスの成果と同等の重要度で対応する必要があります。 

ソフトウェアチームは、主要なオペレーションメトリクスとアクティビティを特定し、それらに対するアラートを構築する必要があります。適切なタイミングでアラートを送信し、アラートは実行可能なものである必要があります。アラートを送信する際は、対応するランブックまたはプレイブックへの参照を含める必要があります。対応するアクションがないアラートは、以下につながる可能性があります。

 **期待される成果:** オペレーションのアクティビティにリスクがある場合、アクションを促すためのアラートが送信されます。このアラートにはアラートが送信された理由のコンテキストが含まれます。また、調査を行うためのプレイブック、またはアラートを緩和するためのランブックへの参照が含まれます。可能な場合、ランブックは自動化し、通知を送信します。 

 **一般的なアンチパターン:** 
+ インシデントの調査が行われ、サポートケースが作成されています。サポートケースはサービスレベルアグリーメント (SLA) に違反していますが、アラートは送信されていません。
+ 本番稼働へのデプロイは深夜に予定されていましたが、直前の変更によりデプロイが遅れました。アラートは送信されず、デプロイは完了しませんでした。
+ 本番稼働に障害が発生しましたが、アラートは送信されませんでした。
+  デプロイ時間には頻繁に遅延が生じています。調査は行われていません。 

 **このベストプラクティスを活用するメリット:** 
+  オペレーションの結果にリスクがある場合にアラートを送信することで、問題が発生する前にワークロードをサポートする能力を高めることができます。 
+  正常なオペレーションの結果によって、ビジネス成果を改善できます。 
+  オペレーションの問題の検出と問題への対応を改善できます。 
+  全体的なオペレーションの正常性が向上します。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 中 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 オペレーションの結果に関するアラートを送信する前に、オペレーションの結果を定義する必要があります。組織にとって最も重要なオペレーションアクティビティを定義することから始めます。それは、本番稼働へのデプロイを 2 時間以内に終えることでしょうか？それとも、決められた時間内にサポートケースに対応することでしょうか？ 組織は、主要なオペレーションアクティビティを監視、改善、およびそれらに関するアラートを送信するために、主要なオペレーションアクティビティとそれらを計測する方法を定義する必要があります。ワークロードとオペレーションのテレメトリを保存し分析するための、一元的な場所が必要です。同じ仕組みを使用して、オペレーションの結果にリスクがある場合に、アラートを送信します。 

 **顧客の事例** 

 AnyCompany Retail のルーティンデプロイ中に CloudWatch アラームがトリガーされました。デプロイのリードタイムは予定を超えてしまい、Amazon EventBridge によって AWS Systems Manager OpsCenter で OpsItem が作成されました。クラウドオペレーションチームは、プレイブックを使用して問題を調査し、スキーマの変更が想定よりも長くかかっていることを特定しました。彼らはオンコール開発者にアラートを送信し、デプロイの監視を続けました。デプロイの完了後、クラウドオペレーションチームは OpsItem を解決しました。チームは事後分析でインシデントを分析する予定です。 

## 実装手順
<a name="implementation-steps"></a>

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 を確立したら、アラートを作成します。 

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [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 運用の異常が検出された場合に警告する
<a name="ops_operations_health_ops_anomaly_alerts"></a>

 運用の異常が検出された場合、必要に応じて適切な対応ができるよう、アラートを発生させます。 

 時間をかけて運用メトリクスを分析すると、イベントを定義したり、それに応じてアラームを発生させるために十分に定量化できる動作パターンが確立される可能性があります。 

 トレーニングが完了すると、 [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) 関連データとレコメンデーションとともに表示されます。 

 **一般的なアンチパターン:** 
+  あなたは、インスタンスのフリートにパッチを適用しようとしています。テスト環境では、パッチが正常にテストされました。フリート内のインスタンスの大部分でパッチが失敗しています。あなたは、何らのアクションも行っていません。 
+  あなたは、金曜日の終わりから始まるデプロイがあることに気づいています。組織は、火曜日と木曜日のメンテナンスウィンドウを事前定義しています。あなたは、何らのアクションも行っていません。 

 **このベストプラクティスを活用するメリット:** 運用の動作パターンを理解することで、予期しない動作を特定し、必要に応じてアクションを実行できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  運用の異常が検出された場合にアラートを出す: 運用の異常が検出された場合、必要に応じて適切な対応ができるよう、警告を発生させます。 
  +  [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) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [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 とメトリクスの成果の達成度と有効性を検証する
<a name="ops_operations_health_biz_level_view_ops"></a>

 オペレーションアクティビティに対するビジネスレベルの視点を確立すると、ニーズを満足しているかどうかを判断したり、ビジネス目標を達成するために改善が必要な領域を特定したりできます。KPI とメトリクスの有効性を検証し、必要に応じて修正します。 

 また、AWS は、AWS のサービス API や SDK を介してサードパーティーのログ分析システム (Grafana、Kibana、Logstash など) やビジネスインテリジェンスツールもサポートしています。 

 **一般的なアンチパターン:** 
+  開発チームの数が増えるにつれて、デプロイの頻度が増加しています。定義された予想デプロイ数は 1 週間に 1 回です。あなたは、毎日定期的にデプロイしています。デプロイシステムに問題があり、デプロイが不可能な場合、それが検出されるのは数日後です。 
+  以前、あなたの会社では、月曜日から金曜日までの営業時間中にのみサポートを提供していました。あなたは、インシデントについて、「翌営業日」の応答時間の目標を設定しました。最近、あなたは、2 時間の応答時間の目標で 24 時間年中無休のサポートを提供し始めました。夜勤のスタッフは対応しきれておらず、顧客は不満を感じています。報告は「翌営業日」のターゲットに対して行われているので、インシデントへの応答時間に問題があることは示唆されていません。 

 **このベストプラクティスを活用するメリット:** KPI とメトリクスを確認して修正することで、ワークロードがビジネス成果の達成をどのようにサポートしているかを理解し、ビジネス目標を達成するために改善が必要な場所を特定できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  KPI とメトリクスの成果の達成度と有効性を検証する: 運用に対するビジネスレベルの視点を確立すると、ニーズを満たしているかどうかを判断したり、ビジネス目標を達成するために改善が必要な領域を特定したりできます。KPI とメトリクスの有効性を検証し、必要に応じて修正します。 
  +  [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
  +  [ログ分析とは](https://aws.amazon.com/log-analytics/) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 
+  [ログ分析とは](https://aws.amazon.com/log-analytics/) 