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