翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ステージ 4: 運用
「[ステージ 3: 評価とテスト](stage-3.md)」が完了したら、アプリケーションを本番環境にデプロイする準備が整います。「*運用*」ステージでは、アプリケーションを本番環境にデプロイし、カスタマーエクスペリエンスを管理します。 アプリケーションの設計と実装によって耐障害性の成果の多くが決まりますが、このステージでは、システムが耐障害性を維持および改善するために使用する運用プラクティスに焦点を当てます。オペレーショナルエクセレンスの文化を構築すると、これらのプラクティスに標準と一貫性が生まれます。
## オブザーバビリティ
カスタマーエクスペリエンスを理解する上で最も重要なのは、モニタリングとアラームを行うことです。アプリケーションの状態を理解するにはアプリケーションを計測する必要があり、多様な視点が必要となります。つまり、サーバー側とクライアント側の両方から、通常は Canary を使用して測定を行う必要があります。メトリクスには、アプリケーションの依存関係と[障害分離境界に沿ったディメンション](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/multi-az-observability.html)による操作に関するデータが含まれている必要があります。また、アプリケーションによって実行されるすべての作業単位に関して追加の詳細を提供するログも作成する必要があります。[Amazon CloudWatch の埋め込みメトリクス形式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html)などのソリューションを使用して、メトリクスとログを組み合わせることを検討できます。常にオブザーバビリティを高める必要があることがわかるため、必要なレベルの計測を実装するために必要なコスト、労力、複雑さのトレードオフを検討してください。
以下のリンク先では、アプリケーションを計測し、アラームを作成するためのベストプラクティスについて提供しています。
+ [Monitoring production services at Amazon](https://youtu.be/hnPcf_Czbvw) (AWS re:Invent 2020 プレゼンテーション)
+ [Amazon Builders' Library: Operational Excellence at Amazon](https://youtu.be/7MrD4VSLC_w) (AWS re:Invent 2021 プレゼンテーション)
+ [Observability best practices at Amazon](https://youtu.be/zZPzXEBW4P8) (AWS re:Invent 2022 プレゼンテーション)
+ [運用の可視性を高めるために分散システムを装備する](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) (Amazon Builders' Library 記事)
+ [運用を可視化するためのダッシュボードの構築](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/) (Amazon Builders' Library 記事)
## イベント管理
アラーム (またはさらに悪いケースでは顧客) が何か問題があることを知らせたときは、障害を処理するイベント管理プロセスを用意する必要があります。このプロセスには、オンコールオペレーターの関与、問題のエスカレーション、人為的ミスの排除に役立つトラブルシューティングへの一貫したアプローチのためのランブックの確立を含める必要があります。ただし、障害は通常、単独では発生しません。単一のアプリケーションが、それに依存する他の複数のアプリケーションに影響を与える可能性があります。影響を受けるすべてのアプリケーションについて理解し、複数のチームのオペレーターを 1 回の電話会議で招集することで、問題に迅速に対処できます。ただし、組織の規模と構造によっては、このプロセスに一元的な運用チームが必要になる場合があります。
イベント管理プロセスの設定に加えて、ダッシュボードを通じたメトリクスの定期的なレビューが必要になります。定期的なレビューは、アプリケーションのパフォーマンスにおけるカスタマーエクスペリエンスと長期的な傾向を理解するのに役立ちます。これにより問題やボトルネックを、それらが本番環境に重大な影響を与える前に特定できるようになります。一貫性のある標準化された方法でメトリクスをレビューすることには大きな利点がありますが、トップダウンの賛同と時間の投資が必要です。
以下のリンク先では、ダッシュボードの構築と運用メトリクスのレビューに関するベストプラクティスを示しています。
+ [運用を可視化するためのダッシュボードの構築](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/) (Amazon Builders' Library 記事)
+ [Amazon's approach to failing successfully](https://youtu.be/yQiRli2ZPxU) (AWS re:Invent 2019 プレゼンテーション)
## 継続的な耐障害性
「[ステージ 2: 設計と実装](stage-2.md)」、「[ステージ 3: 評価とテスト](stage-3.md)」では、アプリケーションを本番環境にデプロイする前にレビューとテストアクティビティを開始しました。「*運用*」ステージでは、本番環境でこれらのアクティビティを継続的に実行する必要があります。[AWS Well-Architected フレームワークのレビュー](https://aws.amazon.com/architecture/well-architected/)、[運用準備状況レビュー (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)、および[耐障害性分析フレームワーク](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)を通じて、アプリケーションの耐障害性体制を定期的にレビューする必要があります。これにより、アプリケーションが確立されたベースラインや標準からドリフトしないようにし、新規または更新されたガイダンスを最新の状態に保つことができます。これらの継続的な耐障害性アクティビティは、これまで予期されなかった中断を発見し、新しい軽減策を考えるのに役立ちます。
また、本番前環境で[ゲームデー](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.gameday.en.html)と[カオスエンジニアリング](https://aws.amazon.com/blogs/architecture/chaos-engineering-in-the-cloud/)実験を正常に実行した後、本番環境でもそれらを実行することを検討することもできます。ゲームデーでは、軽減するための耐障害性メカニズムを構築した既知のイベントをシミュレートします。例えば、ゲームデーで AWS リージョンサービスの障害をシミュレートし、マルチリージョンフェイルオーバーを実装する場合があります。これらのアクティビティの実装には相当量の労力が必要になる可能性がありますが、どちらのプラクティスも、システムが耐障害性を設計した障害モードに対して回復力があることを確信するのに役立ちます。
アプリケーションを運用し、運用イベントが発生し、メトリクスをレビューし、アプリケーションをテストすることで、さまざまな対応と学習の機会が得られます。