# 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)