信頼性目標を定義するためのレコメンデーション
この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:04 | コンポーネント、フロー、ソリューション全体に対して、信頼性と復旧の目標を定義します。 目標を視覚化することで、交渉し、合意を得て、期待を設定し、理想的な状態を達成するためのアクションを推進します。 定義された目標を使用して正常性モデルを構築します。 正常性モデルでは、正常な状態、低下した状態、異常な状態を定義します。 |
|---|
このガイドでは、重要なワークロードとフローの可用性と復旧目標のメトリックを定義するためのレコメンデーションについて説明します。 ビジネス利害関係者とのワークショップ演習から信頼性ターゲットを導き出す必要があります。 その後、ワークロードを監視およびテストして、これらのターゲットを絞り込みます。
ワークロードの信頼性について、内部の利害関係者と現実的な期待を設定します。 その後、契約合意を使用して、それらの期待を顧客に伝えることができます。 現実的な期待を設けると、利害関係者がアーキテクチャ設計の決定を理解してサポートし、合意したターゲットを最適に満たすよう設計を行っていることを認識することができます。
ビジネス要件を定量化するには、次のメトリックを使用することを検討してください。
| 任期 | 定義 |
|---|---|
| サービス レベル目標 (SLO) | ワークロードまたはアプリケーションのパフォーマンスと信頼性の尺度。 SLO は、特定の顧客との対話に対して設定する、測定可能な個別のターゲットです。 これは、顧客が受け取ることを期待する QoS に基づいて、ワークロードまたはアプリケーションに設定するターゲットです。 |
| サービス レベル指標 (SLI) | サービスのパフォーマンスが持つ特定の側面についての定量的な測定。 SLI を使用して、SLO に対するワークロードのコンプライアンスを測定できます。 |
| サービス レベル アグリーメント (SLA) | サービス プロバイダーとサービス顧客の間の契約合意。 契約が満たされない場合、サービス プロバイダーに財務上の影響が生じることがあります。 |
| 平均復旧時間 (MTTR) | 故障が検出された後にコンポーネントを復元するのにかかった時間。 |
| 平均故障間隔 (MTBF) | ワークロードが失敗するまで、中断することなく期待される機能を実行できる期間。 |
| 目標復旧時間 (RTO) | インシデントの発生後にアプリケーションを使用不可状態にできる最大許容時間。 |
| 目標復旧時点 (RPO) | インシデント中のデータ損失の許容される最大期間。 |
主要な設計戦略
信頼性ターゲットは、ユーザーとビジネス利害関係者に約束されているような、ワークロードの望ましい品質目標を表します。 その目標には、ワークロードの可用性と回復可能性の両方が含まれます。 信頼性ターゲットはパフォーマンス ターゲットとは異なることに注意が必要ですが、信頼性ターゲットにパフォーマンス ターゲットを含める必要があります。 次の信頼性ターゲットを検討してください。
可用性ターゲットは、システムがアクセシビリティと機能を維持するための品質基準を定義します。 これらの基準を満たしていない場合、システムは信頼性が低いと見なされます。 SLO を使用して、システムがこれらの基準を満たしているかどうかを確認します。 ビジネス利害関係者と技術関係者が協力して、現実的な SLO を設定し、比較分析、ユーザー エクスペリエンス、ワークロード プロファイルなどの要因を考慮します。
正確性ターゲットは、ワークロードが一貫した品質でその機能を適切に実行することを保証します。 正確性を測定するには、ワークロードのインジケーターを定量化して、それらを統合された目標スコアにまとめられるようにします。
復旧ターゲットは、RTO、RPO、MTTR、MTBF のメトリックに対応しており、計画の有効性と、事業継続とディザスター リカバリーのテストを定量化します。
信頼性ターゲットを設定するために、ビジネス利害関係者は広範な要件を定義します。 その後、技術専門家はワークロードの現在の状態を評価し、監視とアラートを通じてターゲットの達成と維持に向けて取り組みます。 両当事者が現実的なターゲットに同意する必要があります。
ビジネス要件に対する重要度に基づいて、ユーザー フローとシステム フローを特定してスコア付けします。 これらのスコアを使用して、ワークロードの設計、レビュー、テスト、インシデント管理をガイドします。 これらのフローの信頼性ターゲットを設定し、これらのターゲットを満たさなかったことがビジネスに大きな影響を与える可能性があることを理解します。
トレードオフ: システムの技術的な制限とビジネスへの影響の間にギャップがある可能性があります (例: 1 秒あたりのスループットとトランザクションの関係など)。 このギャップがなかなか埋まらない場合があります。 オーバーエンジニアリングに陥ることなく、実用的でコスト効率の高いソリューションを目指しましょう。
可用性の目標を設定する
ワークロードの全体的な SLO には、すべての依存関係を含む包括的な品質が反映されます。成熟した SLO を宣言する際には、それらの依存関係を複合するだけではなく、そのワークロードの全体的なビジネス ターゲットを示す必要があります。 たとえば、顧客が 99.99% の可用性を期待している場合、1 つの部分で 99.80% しか達成していなくても、SLO 全体でその目標を目指す必要があります。
利害関係者はカスタマー エクスペリエンスを評価し、ダウンタイムが収益にどのように影響するかを検討します。 この損失を、ビジネス フローの設計と運用のコストと比較します。 その後、意思決定者は、収益の損失を回避し、評判を維持するために、信頼性により多くのコストを費やす必要があるかどうかを判断します。
ワークロード所有者は、財務目標を使用して目標を決定します。ビジネス要件を測定可能なメトリックにマップします。 目標は、カスタマー エクスペリエンスの品質に影響を与える一連の要因を特定することです。
ワークロード アーキテクトは、SLO に基づいて多くの技術的な決定を行います。SLO では次のことが可能です。
他の依存関係を考慮するときに、アーキテクチャに関する決定に対してクリティカルな情報を提供します。
ほぼリアルタイムのビューを提供し、ワークロードの正常性に対する解釈を共有して、客観的な議論を可能にします。 また、ワークロード チームが信頼性を向上させ、新機能を開発するための取り組みに優先順位を付けるのに役立ちます。
デプロイ操作の主要なシグナルとして機能します。これは、問題が発生した場合に自動ロールバックを実行し、変更によってカスタマー エクスペリエンスに期待される改善が実現されることを検証します。
目標に焦点を当てることで修復と復旧を高速化し、顧客への問題の自動通知を促進し、組織内のチーム間に信頼を構築します。
重要
SLA と SLO の違いを知る必要があります。 SLA と SLO は、同様のデータを使用したり、提示したりする場合もありますが、その意図が異なります。 SLA は、組織とその顧客との間の正式な契約であり、組織が約束を果たせない場合は、財務および法的に直接的な影響を及ぼします。 組織では、SLO を使用して、潜在的なダウンタイムが許容できる制限内にあるかどうかを評価します。
SLO と SLA は取引関係を共有しながら、個別に制御する必要があります。 SLA がビジネス戦術として機能する場合、組織では、ビジネス所有者の目標に基づいて、SLA を意図的に高い値に設定する可能性があります。 逆に、SLO の方が高くなる可能性もあります。 ミッション クリティカルなワークロードを例として考えてみましょう。 このワークロード クラスでは、財務上の損失や人間の安全に対する脅威といった甚大な影響があるため、長時間のダウンタイムを許容することはできません。 そのため、SLO は通常、99.999% のアップタイムをターゲットとします。これは、一般的に「ファイブ ナイン」と呼ばれます。 SLO がこれらの目標を満たしていない場合、組織は迅速に対応して障害を軽減し、SLA 違反の結果を防ぐ必要があります。
この記事の例では、ビジネス目標をサポートするために高い SLA が設定されています。
クラウド プラットフォームとテクノロジ プロバイダーは、そのオファリングに SLA を発行します。 SLA は SLO 計算の一部として考慮する必要がありますが、SLA の対象範囲を理解せずにそのまま使用することがないようにする必要があります。 詳細については、Microsoft SLA の影響評価に関する説明を参照してください。
一般的な SLO と影響を与える要因を検討する
各 SLO は、特定の品質基準を目標としています。 次に挙げる、信頼性のための一般的な SLO を検討します。 このリストは、包括的ではありません。 自分のビジネス要件に基づいて SLO を追加します。
成功率は、成功した要求およびプロセスを、エラーを返したりタスクを失敗させたりした要求およびプロセスと比較して測定します。
待機時間は、操作の要求が開始されてから、結果が使用可能になるか、プロセスが完了するまでの時間を測定します。
容量は、調整ベースの応答の数など、同時使用量を測定します。
可用性は、顧客の観点からのアップタイムを測定します。
スループットは、一定の時間内の最小データ転送速度を測定します。 スループットは、1 秒あたりのトランザクション数 (TPS) や 1 秒あたりの要求数 (RPS) など、データ速度単位として測定されます。
Azure でのワークロードのシナリオと許容範囲について理解します。 Azure サービスとアプリケーション コンポーネントの両方がワークロードの SLO に影響します。 次の表の応答を組み合わせて、SLO 全体を導き出します。 これらの質問を例として使用して、ワークロード コンポーネントのユーティリティを評価します。
| コンポーネントの特性 | 顧客の操作 | 他の要因 |
|---|---|---|
| - 要求 API または応答 API は公開されますか? - クエリ API はありますか? - コンピューティング コンポーネントですか? - ジョブ処理コンポーネントですか? |
一般向けの Azure サービスの- コントロール プレーンと管理プレーン アクセス。 作成、読み取り、更新、削除 (CRUD) 操作などの- データ プレーン アクセス。 |
- リリース プロセスにダウンタイムが含まれますか? - バグを発生させる可能性はどれくらいですか? ワークロードを他のシステムと統合する場合は、統合によるバグを考慮する必要があります。 - 修正プログラムの適用などの日常的な操作は可用性ターゲットにどのように影響しますか? パートナーの依存関係を考慮しましたか? - 継続的な緊急事態および緊急時バックアップのオンコール ローテーションをサポートするためのスタッフ配置が十分ですか? - アプリケーションに、中断の原因となる可能性があるノイジー ネイバーが制御の範囲外にありますか? |
SLO の範囲を決定する
SLO は、システム内でアプリケーションごと、ワークロードごと、特定のフローごとなど、さまざまなレベルで設定できます。 各コンポーネントの重要度に基づいて SLO をカスタマイズできるように、レベル固有の SLO を設定します。
サービスとしてのソフトウェア (SaaS) ソリューションでは、顧客ごとに SLO を測定して、各顧客のエクスペリエンスを最適化します。 顧客は、セグメントごとに異なるインフラストラクチャ リソースを持っている可能性があります。 このような場合は、顧客のセグメントにわたる全リソースを集計する、システム全体の SLO は意味をなさない可能性があります。 代わりに、各顧客の特定のコンテキストに合わせて SLO を測定します。 詳細については、「マルチテナント ソリューションのテナント モデル」を参照してください。
複合 SLO ターゲットを定義する
SLO は、測定可能であり、監視ウィンドウ内で測定する必要があります。
SLO は多くの場合、99.90% のようなパーセンテージですが、ステートメントにすることもできます。 両方のメソッドを使用して、すべての要因を含む数値を取得します。
SLO は、許容される要因を定義する測定可能な SLI で構成されます。 SLI は、アラートを生成できるしきい値が設定されたメトリックです。 プラットフォームまたはアプリケーションから収集できます。 それぞれのコンポーネントに関連する SLI があります。 SLI を選択する場合は、SLO に影響を与える要因を考慮してください。
たとえば、応答 API と要求 API を使用するフローの SLO を計算するには、サーバーの待機時間と要求処理時間を測定します。 スループットとエラー率は、仮想マシン (VM)、スケール セット、Azure Batch などの継続的なコンピューティング環境には適用されません。
コントロール プレーン アクセスの場合、API 応答やリソースの作成などの実行時間の長い操作には、エラー率と待機時間を検討します。 データ プレーン アクセスは、使用される API に依存し、それぞれに独自の SLO ターゲットがあります。
優れた SLI は、SLO に違反する可能性があるタイミングを示します。 通常はパーセンタイルで測定されます。 一般的に使用されるパーセンタイルと、予想される可用性に対して非準拠になる推定時間を次に示します。
| 目的 | 1 週間あたりのコンプライアンス違反 | 1 か月あたりのコンプライアンス違反 | 1 年あたりのコンプライアンス違反 |
|---|---|---|---|
| 99% | 1.68 時間 | 7.20 時間 | 3.65 日 |
| 99.90% | 10.10 分 | 43.20 分 | 8.76 時間 |
| 99.95% | 5 分 | 21.60 分 | 4.38 時間 |
| 99.99% | 1.01 分 | 4.32 分 | 52.56 分 |
| 99.999% | 6 秒 | 25.90 秒 | 5.26 分 |
重要
複合 SLO 値は、影響を与える要因の製品の配布です。
複合 SLO の例は、99.95% × 99.99999% = 約 99.95% です。
さまざまなフローに対して複合 SLO を作成する場合は、それぞれの重要度と関連性を考慮してください。 フローには、重要でないと見なされ、計算から除外されるコンポーネントが含まれる場合があります。 短時間使用できないことが顧客のエクスペリエンスに影響するかどうかに基づいて、除外の正当性を確認できます。 場合によっては、コンポーネントが SLO で考慮するユース ケースに関連しない場合があります。 計算からこれらのコンポーネントを除外することもできます。
同じ原則が操作にも適用されます。 一部の操作ではリスクが発生したり、SLO に影響を与えたりする可能性がありますが、他の操作では重要でない場合があります。 決定は明確に、合意に基づいて構築する必要があります。
SLO と SLI を定義および測定する方法の例については、「例」のセクションを参照してください。
Microsoft SLA の影響を評価する
Microsoft SLA は、Microsoft がコミットする領域の可用性に関する分析情報を提供します。 SLA は、オファリング全体を保証するものではありません。 SLA を評価するときは、公開されたパーセンタイルに関して提供されるカバレッジについて十分に理解してください。
Azure App Service の機能である Web Apps について考えてみましょう。 この機能は、特定のユース ケースで「200 OK」状態を返すと、使用可能と見なされます。 その特定のコンテキストと時間枠内では、Easy Auth やスロット切り替えなどの機能の可用性に関する金銭的な補償は含まれません。 契約で明示的に言及されていない領域は、プラットフォームのベスト エフォートで利用可能であると見なす必要があります。
そのため、ワークロードがデプロイ スロットに依存している場合は、SLO を App Service SLA からのみ派生させることはできません。 ワークロード チームとして、アップタイムの可用性についてリスクを回避し、予測する必要があります。 ただし、この予測は不確定な場合があります。そのため、SLO をプラットフォームの SLA に密接に結びつけると問題が発生する可能性があります。
別の例を考えてみましょう。 Azure Front Door の可用性が 99.99% の場合、設計は契約で公開されている特定の条件に従う必要があります。 たとえば、バック エンドにストレージを含める必要がある場合、少なくとも 50 KB のサイズのファイルを取得できる GET 操作が必要な場合、地理的に異なる少なくとも 5 か所の複数の場所にエージェントをデプロイする必要がある場合などがあります。 この Azure Front Door の限られた範囲のユース ケースでは、キャッシュ、ルーティング規則、Web アプリケーション ファイアウォールなどの機能は保証されません。 これらの側面は、SLA の範囲には含まれません。
マルチリージョン ターゲットを実装する
信頼性の観点から見ると、マルチリージョン デプロイは冗長性の原則を実装する 1 つの形です。 目標は、リージョンの停止やパフォーマンス低下のリスクを軽減することです。 この戦略が適切に設計されていると、フェールオーバーのためにセカンダリ リージョンが追加されるため、SLO を改善できます。
主に次の 2 つのユース ケースがあります。
高可用性パターン。リージョン間で負荷を分散して容量を増やします。 高可用性では、ワークロード ユーザーが 1 つのリージョンに制限されることがなく、システム全体のパフォーマンスが SLO に貢献します。
バルクヘッド パターン。顧客を特定のリージョンに制限してセグメント化します。 このケースでは、複数リージョンのデプロイを、各リージョンの個別のデプロイ (スタンプ) として扱います。 ワークロードに適した SLA を使用して、各スタンプの正常性を個別に測定します。 各スタンプの正常性に基づいて、ワークロード全体の SLO を検討します。 スタンプ間でフェールオーバーできる場合は、1 つのスタンプの障害が別のスタンプへのフェールオーバーによって復旧できるため、ワークロード全体の SLO が高くなります。
高い SLO を満たすために必要な冗長性に注意してください。 たとえば、Microsoft では、Azure Cosmos DB のマルチリージョン デプロイでは、単一リージョンのデプロイよりも高い SLA を保証しています。
復旧メトリックを定義する
RTO、RPO、MTTR、MTBF などの復旧ターゲットの現実的な定義は、障害モードの分析と、事業継続とディザスター リカバリーの計画とテストに依存します。 これらのターゲットを定義するときは、プラットフォームによって提供される復旧の保証を考慮します。 Microsoft では、Azure SQL Database などの一部の製品に対してのみ RTO と RPO の保証を公開しています。
この作業を完了する前に、利害関係者とターゲットについて話し合い、アーキテクチャ設計が復旧ターゲットを理解できる範囲でサポートしていることを確認します。 復旧メトリックについて十分にテストされていないフローまたはワークロード全体には SLA が保証されていないことを利害関係者に明確に伝えます。 ワークロードが更新されると、復旧ターゲットが時間の経過と同時に変化する可能性があることを利害関係者が理解していることを確認します。 顧客を追加したり、新しいテクノロジを採用してカスタマー エクスペリエンスを向上させたりすると、ワークロードがより複雑になる可能性があります。 これらの変更により、復旧メトリックが増減する可能性があります。
Note
MTBF の定義と保証は困難な場合があります。 サービスとしてのプラットフォーム (PaaS) モデルまたは SaaS モデルは、クラウド プロバイダーからの通知なしに障害が発生して復旧する可能性があり、そのプロセスはユーザーや顧客に完全に透過的です。 このメトリックの目標を定義する場合は、制御下にあるコンポーネントのみを対象とします。
復旧ターゲットを定義する場合は、復旧を開始するためのしきい値を定義します。 たとえば、Web ノードが 5 分以上使用できない場合に、新しいノードがプールに自動的に追加されます。 他のコンポーネントや依存関係への影響など、特定のコンポーネントに対してどのような復旧が必要かを考慮して、すべてのコンポーネントのしきい値を定義します。 しきい値の定義では、復旧アクションを早く開始しすぎないように、一時的な障害も考慮する必要があります。 顧客のデータ損失やセッションの中断など、復旧操作の潜在的なリスクを文書化し、利害関係者と共有します。
ターゲットを監視して視覚化する
信頼性ターゲット用に収集したデータを使用して、各ワークロードおよび関連する重要なフローの正常性モデルを構築します。 正常性モデルは、フローとワークロードの正常な状態、低下した状態、異常な状態を定義します。 状態が変わったときに、責任者に警告されるモデルにする必要があります。 設計上の考慮事項と推奨事項の詳細については、正常性モデリング ガイダンスを参照してください。
運用チームとワークロードの利害関係者に情報を提供し続けるために、ワークロード正常性モデルのリアルタイムの状態と全体的な傾向を反映した視覚化を作成します。 視覚化ソリューションについて利害関係者と話し合い、価値があり、活用しやすい情報を確実に提供できるようにします。 また、生成されたレポートを毎週、毎月、または四半期ごとに表示することもできます。
Azure ファシリテーション
Azure SLA は、アップタイムと接続に関する Microsoft のコミットメントについて説明しています。 サービスによって SLA が異なり、サービス内の製品によっても SLA が異なる場合があります。 詳細については、「オンライン サービス の SLA」を参照してください。
Azure SLA には、ワークロードが SLA を満たしていない場合にサービス クレジットを取得する手順と、各サービスの可用性の定義が含まれます。 SLA のこの側面は、強制ポリシーとして機能します。
視覚化システムの Azure Monitor ダッシュボードを確認します。
例
Contoso, Ltd. は、イベント チケット発行システム用の新しいモバイル エクスペリエンスを設計しています。 アーキテクチャの全体像を次に示します。
Grafana ロゴは、各社の商標です。 このマークを使用することは、保証を意味するものではありません。
コンポーネント
次に、SLO 定義の概念を示すいくつかのコンポーネントを示します。 このアーキテクチャには、次の一覧に含まれていないコンポーネントがあります。 たとえば、Key Vault は重要な要求フローの一部ですが、応答ユース ケースには含まれません。 Key Vault が使用できない場合、アプリケーションは起動中に読み込まれるシークレットを使用して引き続き機能します。 ただし、アプリケーションをスケーリングする必要がある場合は、シークレットを使用して新しいノードを読み込む必要があるため、Key Vault の可用性が重要になります。 この例では、スケーリング操作は考慮されません。 簡潔にするために、他のコンポーネントは省略しています。
Azure Front Door は、顧客が要求の送信に使用する API を公開する単一のエントリ ポイントです。
Azure Container Apps は、ワークロード チームが所有し、アプリケーションのビジネス ロジックを実行するために使用する環境です。
SQL Managed Instance は別のチームによって所有および管理されている、ワークロードの重要な依存関係です。
Azure Private Link は、Azure Front Door デプロイと Container Apps デプロイ間のプライベート接続を提供します。 SQL Managed Instance は、プライベート エンドポイントを介してアプリケーションにも公開されます。
このアーキテクチャでは、API チームは、アプリケーション内の重要なフローの初期 SLO ターゲットを定義します。 SLO に影響を与える要因の説明に記載されている戦略を採用します。 補足機能を過度に強調することなく、コア機能をカバーする目的を定義することを目標としています。 3 つの重要なユーザー フローの正常性を測定します。これには、すべてのコア クラウド機能が含まれ、デプロイ全体でコードが実行されます。 ただし、これらのフローは、すべてのコードまたはデータ アクセスをカバーしているわけではありません。 影響を与える要因を次に示します。
複合 SLO を計算する
Azure 可用性 SLO: Azure の財務コミットメント SLA は、プラットフォームの信頼性を評価するためのプロキシとして機能します。
Azure のコンポーネント 適用される SLA カバレッジ SLA の対象外 調整後の SLO Azure Front Door 99.99%、HTTP GET操作成功キャッシュ、ルール エンジン 99.98% コンテナー アプリ 99.95%、組み込みのイングレスによって到達可能なデプロイ済みアプリに基づく 自動スケーリング、トークン ストア機能 99.95% SQL Managed Instance 99.99%、SQL Server インスタンスへの接続に基づく パフォーマンス、データ保持期間 99.80% Private Link 99.99%、プライベート エンドポイント ネットワークがトラフィックを受け入れなかった場合、またはエンドポイントと Private Link サービスの間でトラフィック フローがなかった場合の整数の分単位 個々の障害が 1 分未満続く 99.99% この調整は、ワークロード チームの目標に対する約束に依存するいくつかの要因に基づいています。 1 つの要因は、以前の経験に基づくプラットフォームの機能に対する信頼度です。 たとえば、Container Apps と Private Link については、SLA の値をそのまま使用することに問題を感じません。
微妙な要因もあります。 たとえば、チームは、スキーマの変更やバックアップの作成など、データ操作の潜在的なエラーを考慮して、SQL Managed Instance の SLO 値を 99.80% に下げます。
チームは、調整した個々の SLO 値の影響を計算して、複合 SLO を設定します。 この値は 99.72% です。
他にも要因があります。 このアーキテクチャは、公開された SLA を持たない仮想ネットワークやネットワーク セキュリティ グループ (NSG) などの Azure ネットワーク コンポーネントに依存しています。 ワークロード チームは、各コンポーネントについて、可用性を 99.99% としてこれらの要因を考慮することにしました。
予測されるプラットフォームの可用性に基づく複合 SLO: 1 か月あたり 99.68%。
アプリケーション コード SLO: チームは、アプリケーション コードまたはストアド プロシージャのバグがシステムの可用性に影響を与える可能性があることを認識し、コード関連のエラーを考慮して毎月 1 時間のダウンタイムを割り当てます。
一般的なダウンタイム パーセンタイルを使用して、コードの欠陥、スケーリングの問題、その他のコード関連の考慮事項などの個々の要因について SLO を見積ります。
コードとデータの可用性に基づく複合 SLO: 1 か月あたり 99.86%。
リソースとアプリケーションの構成 SLO: チームは、クラウド リソースとアプリケーション コードを適切に構成する必要があることを認識します。 このターゲットには、自動スケール ルールの設定、NSG ルールのデプロイ、SKU の適切なサイズの選択が含まれます。 構成エラーを考慮するために、毎月 10 分のダウンタイムを見込みます。可用性は約 99.98% になります。
構成の可用性に基づく複合 SLO: 1 か月あたり 99.95%。
運用 SLO: ワークロード チームは、オペレーショナル エクセレンスのため Azure Well-Architected フレームワークの原則に従って、優れた DevOps カルチャを開発します。 クラウド リソース、構成、コードをすべてのスプリントにデプロイします。
チームは、実行中のシステムを不安定化させる可能性があるため、デプロイをリスクと見なします。 TLS 証明書の更新、DNS の変更、またはツール エラーの結果としてエラーが発生する可能性があります。 チームは、緊急対応の修正によって発生する可能性のあるダウンタイムも考慮します。 毎月のダウンタイムの合計は 20 分と見込んで、可用性は約 99.95% になります。
メンテナンス期間は、システムのメンテナンスまたは更新が行われる指定された期間です。 API は、毎日約 4 時間、ほとんど使用されません。 利用できないリスクを軽減するために、チームは、あまりアクティブでない時間帯にメンテナンス タスクをスケジュールできます。 このアプローチにより SLO が高くなりますが、チームは SLO にメンテナンス期間を含めないことを決定します。
運用の可用性に基づく複合 SLO: 1 か月あたり 99.95%。
外部依存関係 SLO: チームは、SQL Managed Instance をプライマリ依存関係と見なします。これについては、プラットフォーム全体の可用性に 99.80% の可用性として既に考慮されています。 他の外部依存関係は考慮されません。
外部依存関係に基づく複合 SLO: 該当なし。
複合 SLO の全体的な結果を決定する
全体的な複合 SLO ターゲットは 99.45% に設定されます。これは、1 か月あたり約 4 時間のダウンタイムに相当します。
1 か月あたりの利用不可期間を 4 時間に設定する SLO ターゲットを満たすために、ワークロード チームはオンコール ローテーションを確立します。 カスタマー サポートと代理トランザクションの監視の両方で、オンコール サイト信頼性エンジニアリング (SRE) サポートを呼び出して、SLO の問題に対処するための復旧手順を迅速に開始できます。
ワークロードの SLA を設定する
ワークロードの SLA は、1 か月あたり 99.90% の可用性です。
ワークロード チームの法務部門と財務部門は、ワークロードの SLA を 1 か月あたり 99.90% の可用性に設定します。これは、SLO 目標の 99.45% を超えています。 この決定は、魅力的な SLA に基づいて財務上の支払いと予想される顧客の成長を比較して分析した後に行われます。 SLA には、2 つのコア ユーザー フローが含まれており、可用性だけでなくパフォーマンスに関する考慮事項も含まれています。 これは、ビジネスに利益をもたらすためにビジネス チームが計算に基づいて取るリスクであり、エンジニアリング チームはコミットメントを認識しています。
正確性 SLO を設定する
アプリケーションのコア ユーザー フローは、使用可能で、使いやすく、あるいは競争力のある応答性を備える必要があります。 チームは、クライアントの処理時間とインターネット ネットワーク トラバーサルを除き、API 専用の応答時間 SLO を設定します。 この SLO は、可用性の期間中にのみ評価されます。 SLO ターゲットとパフォーマンス測定の両方として 75 パーセンタイルを選択します。これは、一般的なカスタマー エクスペリエンスをキャプチャし、最悪のシナリオを除外します。
関連リンク
Azure でのミッション クリティカルなワークロードの正常性モデリングと監視
信頼性チェックリスト
レコメンデーションの完全なセットを参照してください。