# 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/2023-10-03/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 メール通知を送信しますが、サービス復旧のタイムラインが記載されていないため、ユーザーは停止を回避する計画を立てることができません。
+ システム停止の際のコミュニケーション計画はあっても、テストしたことがなく、テストしていれば明らかになっていた可能性のある重要なステップを見逃していたため、システム停止が発生すると、コミュニケーション計画は失敗に終わります。
+ システム停止中にユーザーに送信する通知には、過剰な技術的な詳細と AWS の NDA に基づく情報が記載されています。
**このベストプラクティスを活用するメリット:**
+ システム停止中にコミュニケーションを継続すると、問題に関する進捗状況と解決までの推定時間を顧客は確実に把握できます。
+ 明確に定義されたコミュニケーション計画を策定すると、顧客とエンドユーザーは、確実に十分な情報を入手でき、停止の影響を軽減するために必要となる追加の手順を実行できます。
+ 適切なコミュニケーションを行うと、計画されたシステム停止と計画外の停止に関する意識が向上するため、顧客満足度が向上し、意図せぬ反応を制限して、顧客維持を促進できます。
+ システム停止に関して、タイムリーかつ透明性が高いコミュニケーションを行うことにより、信頼性が高まり、顧客との関係を維持するうえで必要となる信頼が築かれることになります。
+ システム停止の際や危機的状況下で実証済みのコミュニケーション戦略を採用することで、復旧能力の妨害につながる憶測やゴシップを低減できます。
**このベストプラクティスを確立しない場合のリスクレベル:** 中
## 実装のガイダンス
システム停止中に顧客に情報を提供するコミュニケーション計画は包括的なものであり、顧客に表示されるエラーページ、カスタム API エラーメッセージ、システムステータスバナー、正常性ステータスページなど、複数のインターフェイスをカバーしています。システムに登録ユーザーが含まれている場合は、E メール、SMS、プッシュ通知などのメッセージチャネル経由でコミュニケーションを行い、パーソナライズしたメッセージコンテンツを顧客に送信することができます。
**顧客コミュニケーションツール**
防御の最前線として、ウェブアプリケーションとモバイルアプリケーションは、システム停止中にわかりやすく情報豊富なエラーメッセージを提供し、トラフィックをステータスページにリダイレクトする機能を備えている必要があります。[Amazon CloudFront](https://aws.amazon.com/cloudfront/) は、カスタムのエラーコンテンツを定義して提供する機能を含む、フルマネージドコンテンツ配信ネットワークです。CloudFront のカスタムエラーページは、コンポーネントレベルの停止に関する顧客メッセージの最初のレイヤーとして適しています。CloudFront は、ステータスページの管理とアクティベーションを簡素化し、計画された停止や計画外の停止中にすべてのリクエストをインターセプトすることもできます。
カスタム API エラーメッセージを使用すると、個別のサービスに分離されている場合に停止が起こった際に、影響を検出して軽減するうえで役立ちます。[Amazon API Gateway](https://aws.amazon.com/api-gateway/) を使用すると、REST API のカスタムレスポンスを設定できます。これにより、API Gateway がバックエンドサービスに到達できない場合に、API の利用者に明確かつ意味あるメッセージを提供できます。カスタムメッセージは、サービスレイヤーの停止により特定のシステム機能が低下した場合に、停止バナーコンテンツと通知のサポートにも使用できます。
ダイレクトメッセージは、最もパーソナライズされたタイプの顧客メッセージです。[Amazon Pinpoint](https://aws.amazon.com/pinpoint/) は、スケーラブルなマルチチャネルコミュニケーション向けのマネージドサービスです。Amazon Pinpoint を使用すると、SMS、E メール、音声、プッシュ通知、またはユーザー定義のカスタムチャネルを介して、影響を受ける顧客ベースに広範囲にわたりメッセージをブロードキャストするキャンペーンを構築できます。Amazon Pinpoint を使用してメッセージングを管理すると、メッセージキャンペーンを明確に定義し、テストでき、ターゲットを絞った顧客セグメントにインテリジェントに適用できます。設定したキャンペーンは、スケジュールしたり、イベントでトリガーしたりすることができ、簡単にテストを行うことができます。
**お客様事例**
AnyCompany Retail では、ワークロードで障害が発生すると、ユーザーに E メール通知を送信します。この E メールには、どのビジネス機能で障害が発生しているを説明し、サービスが復旧するタイミングについての現実的な見積りを提供します。さらに、ワークロードの正常性に関するリアルタイムの情報を表示するステータスページも提供しています。このコミュニケーション計画は、開発環境において年に 2 度テストし、効果的であることを確認しています。
**実装手順**
1. メッセージング戦略のコミュニケーションチャネルを決定します。アプリケーションのアーキテクチャの側面を考慮に入れて、顧客にフィードバックを提供するための最適な戦略を決定します。これには、エラーページとステータスページ、カスタム API エラーレスポンス、ダイレクトメッセージなど、概説したガイダンス戦略の 1 つ以上の戦略が含まれる場合があります。
1. アプリケーションのステータスページを設計します。ステータスページまたはカスタムエラーページが顧客に適していると判断した場合は、それらのページのコンテンツとメッセージを設計する必要があります。エラーページでは、アプリケーションが利用できない理由、再び利用できるようになるタイミング、その間にできることをユーザーに説明します。アプリケーションが Amazon CloudFront を利用している場合、[カスタムエラーレスポンス](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GeneratingCustomErrorResponses.html)を提供するか、Lambda at Edge を使用して[エラーを翻訳](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-update-error-status-examples)したり、ページのコンテンツを書き換えたりすることができます。CloudFront を使用すると、宛先をアプリケーションコンテンツからメンテナンスや停止のステータスページを含む静的な [Amazon S3](https://aws.amazon.com/s3/) コンテンツのオリジンに置換することもできます。
1. サービスの適正な API エラーステータスセットを設計します。バックエンドサービスにアクセスできない場合に API Gateway が生成するエラーメッセージやサービスティアの例外には、エンドユーザーへの表示に適したユーザーフレンドリーなメッセージが含まれていない場合があります。バックエンドサービスのコードを変更する必要なく、API Gateway [カスタムエラーレスポンス](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html)を設定して、キュレートした API エラーメッセージにHTTP レスポンスコードをマップできます。
1. システムのエンドユーザーに対して関連性が高い内容とし、過度に技術的な詳細が含まれないよう、ビジネスの観点からメッセージを設計します。対象ユーザーを考慮してメッセージを調整します。例えば、社内ユーザーに対しては、代替システムを活用する回避策や手動のプロセスに誘導することができます。外部ユーザーに対しては、システム復旧まで待つか、システム復旧時に通知を受け取るためのアップデートにサブスクライブするようお願いすることができます。予期せぬシステム停止、計画されたメンテナンス、特定機能の障害や利用できなくなるといった部分的なシステム障害など、複数のシナリオについて、事前承認されたメッセージングを定義します。
1. 顧客メッセージをテンプレート化して自動化します。メッセージのコンテンツを設定したら、[Amazon Pinpoint](https://docs.aws.amazon.com/pinpoint/latest/developerguide/welcome.html) またはその他のツールを使用して、メッセージングキャンペーンを自動化することができます。Amazon Pinpoint を使用すると、影響を受けた特定のユーザー向けに顧客ターゲットセグメントを作成し、メッセージをテンプレートに変換できます。メッセージングキャンペーンの設定方法については、「[Amazon Pinpoint チュートリアル](https://docs.aws.amazon.com/pinpoint/latest/developerguide/tutorials.html)」を確認してください。
1. メッセージング機能を顧客が使用するシステムに密結合することは避けてください。停止発生時にメッセージが正常に送信できることを確認するためには、メッセージング戦略がシステムデータストアやサービスに対して強制依存関係を持つべきではありません。メッセージングの可用性のために、[複数のアベイラビリティーゾーンまたはリージョン](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_multiaz_region_system.html)からメッセージを送信する機能を構築することを検討してください。AWS サービスを使用してメッセージを送信している場合は、[コントロールプレーンのオペレーション](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html)ではなくデータプレーンのオペレーションを活用して、メッセージを呼び出します。
**実装計画に必要な工数レベル:** 高。コミュニケーション計画とコミュニケーションを送信するメカニズムの開発には、かなりの労力が必要になる場合があります。
## リソース
**関連するベストプラクティス:**
+ [OPS07-BP03 ランブックを使用して手順を実行する](ops_ready_to_support_use_runbooks.md) - 担当者が対応方法を把握しておけるように、コミュニケーション計画にはランブックが関連付けられている必要があります。
+ [OPS11-BP02 インシデント後の分析を実行する](ops_evolve_ops_perform_rca_process.md) - 停止後にはインシデント後分析を実施し、今後の停止を防ぐメカニズムを特定します。
**関連するドキュメント:**
+ [ Error Handling Patterns in Amazon API Gateway and AWS Lambda](https://aws.amazon.com/blogs/compute/error-handling-patterns-in-amazon-api-gateway-and-aws-lambda/) (Amazon API Gateway と AWS Lambda のエラー処理パターン)
+ [ Amazon API Gateway responses ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html#supported-gateway-response-types) (Amazon API Gateway のレスポンス)
**関連する例:**
+ [AWS Health Dashboard](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/)
+ [ Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region ](https://aws.amazon.com/message/12721/) (バージニア北部 (US-EAST-1) リージョンにおける AWS サービスイベントの概要)
**関連サービス:**
+ [AWS サポート](https://aws.amazon.com/premiumsupport/)
+ [AWS カスタマーアグリーメント](https://aws.amazon.com/agreement/)
+ [ Amazon CloudFront ](https://aws.amazon.com/cloudfront/)
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [ Amazon Pinpoint ](https://aws.amazon.com/pinpoint/)
+ [ Amazon S3 ](https://aws.amazon.com/s3/)
# 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)
**関連する例:**