Define

The presented Microsoft Azure Well-Architected Framework recommendations in this guidance include Reliability Stage “1 - Define (Requirements)” and associated resources and their settings.

In this initial stage, the objectives and requirements for system reliability are established. This often involves specifying availability and recovery targets, latency tolerances, criticality classifications, and disaster recovery objectives.

可用性ターゲット (SLA、SLO、SLI) が適切に定義され、テストされ、監視され、ワークロードに取り組んでいるチーム間で伝達されていることを確認します。

サービス レベル アグリーメント (SLA) は、アプリケーションのパフォーマンスと可用性に関する約束を表す可用性目標です。信頼性の目標を定義するには、システム内の個々のコンポーネントの SLA を理解することが不可欠です。依存関係の SLA を把握しておくと、依存関係の可用性を高め、適切なサポート契約を結ぶ場合に追加費用を正当化することもできます。アプリケーションによって利用される依存関係の可用性目標を理解し、理想的にはアプリケーションの目標と整合することも考慮する必要があります。

可用性に対する期待を理解することは、アプリケーションの全体的な操作をレビューするために不可欠です。

たとえば、アプリケーションのサービス レベル目標 (SLO) 99.999% を達成しようとしている場合、アプリケーションに必要な固有の運用アクションのレベルは、SLO 99.9% が目標である場合よりもはるかに高くなります。

Enhances reliability and communication

回復目標が明確に定義され、ワークロードに取り組んでいるチーム全体に伝達されていることを確認します。
考慮すべき 2 つの重要な指標は、災害復旧に関係する目標復旧時間と目標復旧時点です。

- 目標復旧時間 (RTO) は、インシデント後にアプリケーションが使用できなくなるまでの最大許容時間です。 RTO が 90 分の場合、災害の開始から 90 分以内にアプリケーションを実行状態に復元できなければなりません。 RTO が非常に低い場合は、リージョンの停止から保護するために、2 番目のリージョン展開をスタンバイでアクティブ/パッシブ構成で継続的に実行し続けることができます。場合によっては、アクティブ/アクティブ構成を導入して、さらに低い RTO を達成することもあります。
- 目標復旧時点 (RPO) は、災害時に許容できるデータ損失の最大期間です。たとえば、他のデータベースへのレプリケーションを行わずにデータを 1 つのデータベースに保存し、1 時間ごとにバックアップを実行すると、最大 1 時間のデータが失われる可能性があります。
RTO と RPO はシステムの非機能要件であり、ビジネス要件によって決定される必要があります。これらの値を導き出すには、リスク評価を実施し、ダウンタイムやデータ損失のコストを明確に理解することをお勧めします。

アプリケーションの可用性を監視および測定することは、アプリケーション全体の健全性を評価し、定義された目標に向けた進捗を確認するために不可欠です。次のような主要な目標を必ず測定および監視してください。

- 平均故障間隔 (MTBF) — 特定のコンポーネントの平均故障間隔。
- 平均復旧時間 (MTTR) — 障害後にコンポーネントを復元するのにかかる平均時間。

Improved recovery times and data loss prevention