# ベストプラクティス 10.1 – ビジネス要件に合った SAP ワークロードの可用性目標について合意する
<a name="best-practice-10-1"></a>

可用性目標を理解することは、組織にとって重要な要素に注意を向けるための最初のステップです。これは、アーキテクチャパターンの評価に使用できる条件を定義する上で役立ちます。

 **提案 10.1.1 – 範囲内の SAP アプリケーションとそれらの相互依存関係を特定する** 

AWS にデプロイした、またはデプロイする予定の SAP アプリケーションを特定します。場所に関係なく、これらのアプリケーションの依存関係を理解します。

 **提案 10.1.2 – 障害の影響に基づいてシステムを分類する** 

 計画された可用性と障害のリスクに応じたシステム分類について、公開されているスタンダードはありません。「ミッションクリティカル」や「非常に重要」などの用語を使用したシステムの定義は、パターンの定義、アプリケーショングループの識別、およびコストの正当化に役立ちます。生産アプリケーションは、停止によって異なる影響を受ける可能性があります。考慮すべき要素は、次のとおりです。 
+ 収益創出または収益報告
+ 外向きまたは内向き
+ コアビジネス対技術サポート
+ 他のシステムとの密結合対疎結合

非生産環境もビジネスの間接的なサポートにおいて重要な役割を果たすことがあります。これらはプロジェクトのフェーズとスケールに従って分類する必要があり、トランスポートパス (通常営業とプロジェクトなど) やサポートの役割 (開発、ユニットテスト、生産コピー、トレーニングなど) を考慮に入れる必要があります。

 **提案 10.1.3 – 停止によるビジネスへの影響を評価する** 

影響は測定可能でなければならず、停止の期間を考慮する必要があります。影響分野の例としては、健康と安全性、財務、法務、規制、ブランドなどがあります。

 **提案 10.1.4 – コンプライアンスおよび規制要件を理解する** 

データレジデンシーと場所間の距離に関するコンプライアンスまたは規制要件を理解することは、事業継続性の確保に役立ちます。

 **提案 10.1.5 – 最小許容稼働率を定義する** 

 各システムまたは各システムグループについて、ビジネス要件に応じた許容可能稼働率を合意し、文書化します。このコンテキストでは、以下の用語が使用されます。 
+ MTTR – 平均復旧時間
+ RTO – 目標復旧時間
+ RPO – 目標復旧時点

 用語の詳しい説明については、「Well-Architected Framework [信頼性]」を参照してください。 [可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) .SAP における信頼性の詳細については、次のホワイトペーパーを参照してください。 
+  AWS ドキュメント: [Architecture Guidance for Availability and Reliability of SAP on AWS (SAP on AWS の可用性と信頼性のためのアーキテクチャガイダンス)](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html)