信頼性テスト戦略を設計するためのレコメンデーション
この Power Platform Well-Architected Reliabilityチェックリストの推奨事項に適用されます:
| RE:06 | カオス エンジニアリングの原則をテスト環境と運用環境に適用して、復元力と可用性のシナリオをテストします。 アクティブな障害テストとシミュレートされた負荷テストを実行して、正常な劣化の実装戦略が有効であることを確認するためのテストを実行します。 |
|---|
このガイドでは、ワークロードの信頼性を検証および最適化するための信頼性テスト戦略を設計するためのレコメンデーションについて説明します。 信頼性テストは、ワークロードの回復力と可用性、特にソリューションの設計時に特定する重要なフローに焦点を当てます。 このガイドには、一般的なテスト ガイダンスと、障害インジェクションおよびカオス エンジニアリングに固有のガイダンスが含まれています。
定義
| 任期 | 定義 |
|---|---|
| 在庫状況 | アプリケーション ワークロードが重大なダウンタイムなしで正常な状態で実行される時間の長さ。 |
| カオス エンジニアリング | アプリケーションやサービスを現実世界のストレスや障害にさらすプラクティス。 カオス エンジニアリングの目標は、信頼性の低い条件や欠落した依存関係に対する回復力を構築し、検証することです。 |
| フォールト挿入 | システムの回復力をテストするためにシステムにエラーを導入する行為。 |
| 復元性 | 回復性の同義語。 |
| 回復性 | アプリケーションのワークロードが障害モードに耐え、障害モードから回復する能力。 |
主要な設計戦略
ワークロードが信頼性の目標を満たし、障害を適切に処理できることを確認するには、テストが不可欠です。 フォールト挿入は、実際のシナリオをシミュレートするために、システムに意図的に障害やストレスを導入するタイプのテストです。 フォールト挿入とカオス エンジニアリングの手法を使用することで、問題が運用環境に影響する前に、問題を積極的に検出して修正できます。 このセクションでは、ワークロードのテスト、フォールト挿入、カオス エンジニアリングに関する一般的なガイダンスを提供します。
一般的なテストのガイダンス
定期的にテストを実行して、既存のしきい値、目標、仮定を検証します。 ワークロードに大きな変更が発生した場合は、定期的にテストを実行してください。 ほとんどのテストをテスト環境とステージング環境で実行します。 運用システムに対してテストのサブセットを実行することも有益です。
テストを自動化して、一貫したテスト範囲と再現性を確保します。 一般的なテスト タスクを自動化し、ビルド プロセスに統合します。 ソフトウェアを手動でテストするのは面倒でエラーが発生しやすいですが、手動で探索的テストを実行することは可能です。 自動テストを開発する必要がある場合は、手動テストを使用して、開発するテストの範囲を決定します。
シフトレフト テスト アプローチを採用して、開発サイクルの早い段階で回復力と可用性のテストを実行します。
シンプルなドキュメント形式を採用して、定期テストのプロセスと結果を誰もが簡単に理解できるようにします。
文書化された結果を、運用チーム、テクノロジ リーダー、ビジネス関係者、ディザスター リカバリー関係者などの適切なチームと共有します。 結果は、サービス レベル目標 (SLO)、サービス レベル契約 (SLA)、復旧時間目標 (RTO)、復旧ポイント目標 (RPO) などの信頼性目標の改善に役立ちます。
バックアップの定期的なテスト周期を作成します。 データを隔離されたシステムに復元すると、バックアップが有効であり、復元が機能することを確認できます。
復旧時間のメトリックを文書化し、ディザスター リカバリー関係者と共有して、復旧に対する期待が適切であることを確認します。
業界標準の展開テスト手順を使用して、展開プロセスが自動化され、予測可能で効率的であることを確認します。
一時的な障害に耐えるワークロードの能力をテストします。 詳細については、一時的なエラーへの対処に関するレコメンデーションを参照してください。
フォールト挿入を使用して、ワークロードが依存サービスまたは他の依存関係の障害をどのように処理するかをテストします。
ディザスター リカバリー計画 をテストして、致命的な障害や他の重大なインシデントに対応します。
フォールト挿入を使用して、ワークロードが正常に機能を低下させ、コンポーネントの誤動作の被害範囲を最小限に抑える能力をテストします。
計画された停止と計画されていない停止を活用する
計画メンテナンスや計画外の停止によりワークロードがオフラインになったときは、テストを実行してワークロードに対する理解を深める絶好の機会です。 以下のセクションで、各シナリオのレコメンデーションを提供します。
計画メンテナンス
更新またはパッチの計画メンテナンス期間では、メンテナンス作業に関係しないコンポーネントとフローをテストできます。 ワークロードが予期せず低下したり、完全にオフラインになったりする潜在的なリスクを回避してテストを実行します。 メンテナンス期間中に十分な時間があれば、メンテナンス作業の完了後に、メンテナンスに関連するコンポーネントとフローをテストすることもできます。
計画外の停止
すべての停止インシデントを、ワークロードについて詳しく学び、次の手順に従って優先度順に回復力を向上させる機会として利用してください。
ユーザーのワークロードをオンラインに戻します。 問題の回避策を実行したり、問題を解決したり、回復プロセスを開始したりする必要がある場合があります。
停止の根本原因を特定して対処します。 調査の一環として根本原因を修正できる場合は、根本原因とそれを修正するために実行した対策を文書化します。 問題により後で別の メンテナンス ウィンドウを実行する必要がある場合は、緩和策を徹底的にテストして、予想される負荷を処理できることを確認してください。 緩和策をカバーするのに十分な監視が設定されていることを確認してください。
該当する場合は、ワークロード内のすべてのコンポーネントで、同じ問題や似た問題の影響を受ける可能性のある構成の弱点を探します。 この機会を利用して、これらのコンポーネントに積極的に対処してください。 インシデント履歴を調べて、ワークロード全体で同様の問題のパターンを検出します。
調査結果を使用してテスト戦略を改善します。 同じ障害を直接テストして、根本原因および同様の問題に正常に対処できたことを確認します。
フォールト挿入とカオス エンジニアリングのガイダンス
フォールト挿入テストは、コンポーネントの障害に対応するワークロードの能力を強調して、カオス エンジニアリングの原則に従います。 運用前の環境および運用環境で、フォールト挿入テストを実行します。 障害モード分析の実行 から得た情報を適用して、優先順位をつけた障害のみをテストし、障害に対処する緩和策があることを確認します。
カオス エンジニアリングの主要なガイドラインは次のとおりです。
積極的な態度。 失敗が起こるのを待たない。 カオス実験を実施して障害を予測し、運用環境に影響を与える前に問題を発見して修正するようにする。
失敗を受け入れる。 システムで発生する障害を受け入れ、そこから学ぶ。 障害を複雑なシステムの自然な一部分であると考え、システムの信頼性を学び、向上させる機会として利用する。
システムに侵入する。 システムに意図的に障害やストレスを与えて、回復力をテストする。 実際の障害や中断をシミュレートして、ワークロードの回復機能をテストし、改善する。
免疫力を高める。 カオス エンジニアリング実験を使用して、ワークロードの障害の防止と障害からの回復の能力を向上させます。
カオス エンジニアリングは、ワークロード チームの文化に不可欠な一部であり、継続的な実践であり、一回の停止に対応する短期的な戦術的な取り組みではありません。 カオス実験を設計するときは、次の標準の方法に従ってください。
仮説から始めます。 各実験には、特定のコンポーネントの損失に耐えるフローの能力をテストするなど、明確な目標が必要です。
ベースライン動作を測定します。 実験を行うときに、劣化状態と比較するために、実験に関係するフローとコンポーネントの一貫した信頼性とパフォーマンスのメトリックがあることを確認します。
障害を挿入します。 実験では、迅速に回復できる特定のコンポーネントを意図的にターゲットにする必要があります。実験の被害範囲の制御に役立つように、フォールト挿入が引き起こす影響に関する十分な情報に基づいて期待する必要があります。
結果として生じる動作を監視します。 障害の影響を適切に理解するために、実験の対象となる個々のフロー コンポーネントとエンドツーエンドのフロー動作に関するテレメトリを収集します。 収集したメトリックをベースライン メトリックと比較して、フォールト挿入結果の全体像を把握します。
プロセスと観察結果を文書化します。 実験の詳細な記録を保持しておくことは、ワークロード設計に関する将来の決定に情報を提供し、時間の経過とともに明らかになったギャップに確実に対処できるようにします。
結果を特定し、それに基づいて行動します。 改善としてワークロード バックログに追加できる修復手順を計画します。 設計改善計画が、他の展開と同じプロセスに従って非運用環境でレビューおよびテストされていることを確認します。
プロセス、アーキテクチャの選択、コードを定期的に検証して、技術的負債を迅速に検出し、新しいテクノロジを統合して、変化する要件に適応します。
フォールト挿入の実験を実施するときは、次の作業を行います。
監視とアラートが設定されていることを確認します。
インシデントの所有権を取得する直接責任者 (DRI) を割り当てるプロセスを検証します。
ドキュメントと調査プロセスが最新であることを確認してください。
次のレコメンデーションと考慮事項を統合して、カオス テスト戦略を最適化します。
システムの仮説に疑問を投げかけます。 テストでは、ワークロードの回復力とワークロード設計戦略を改善しようとします。 過去の経験に基づいて信頼できると想定されるコンポーネントとフローに障害を加える機会を探します。 新しいワークロードでは信頼できない可能性があります。
変更を検証します。 フォールト挿入テストを含む徹底的なテストを行わないと、変更後のワークロードの全体像が不完全になる可能性があります。 たとえば、すぐにはわからない新しい依存関係が導入される場合があります。
SLA バッファーを使用します。 SLA 内に収まるようにカオス テストを制限し、停止による潜在的な悪影響を回避します。 フローおよびコンポーネントの回復ターゲットは、テストの範囲を定義するのに役立ちます。
カオスとフォールト挿入への投資としてエラー予算を確立します。 エラー予算は、SLO を 100% 達成することと、合意された SLO を達成することの差です。
範囲を超えた場合は実験を停止します。 不明な結果は、カオス実験の予想結果です。 大量の結果データの収集と、影響を受ける運用ユーザーをできるだけ少なくすることとの間で、バランスをとるように努めてください。
開発チームと緊密に連携して、挿入された障害の関連性を確認します。 過去の出来事や問題をガイドとして使用してください。 依存関係を調べ、それらの依存関係を削除したときの結果を評価します。
カオス テストを通じて明らかになった、ワークロード内のさまざまなコンポーネント間にある、これまで発見されていなかった依存関係を特定して文書化します。
カオス テスト中に検出された依存関係を考慮して、必要に応じて復旧計画を調整します。
実験やテストの結果を新しい実験やテストの基礎として使用します。 予期しない動作が発生した場合、新しいテストはその動作を直接ターゲットにし、その動作に対する修復戦略を設計する機会を提供する可能性があります。
トレードオフ: 運用環境でのフォールト インジェクション テストは混乱を招き、ダウンタイムを引き起こす可能性があります。 この可能性について関係者に明確に説明し、実験を終了し、発生した障害を迅速に元に戻すロールバック計画を実行するための安全策を講じていることを確認してください。
Power Platform の促進
静的結果 Power Automate を使用して、固定された結果を返すことでワークロードをテストできます。
Power Apps テスト エンジン (プレビュー) は、 Power Platform スタンドアロン キャンバス アプリをテストするために使用できるCLIコンポーネントです Power Apps。
Azure Test Plans は、計画された手動テスト、ユーザー受け入れテスト、探索的テスト、関係者からのフィードバックの収集に必要なすべての機能を提供する、使いやすいブラウザーベースのテスト管理ソリューションです。
ワークロードに Azure リソースが含まれている場合は、カオス エンジニアリングを使用してクラウド アプリケーションとサービスの回復力を測定、理解、改善するのに役立つマネージド サービスである Azure Chaos Studio を使用できます。
ワークロードに Microsoft Copilot Studio 副操縦士が含まれている場合は、 Power CAT Copilot Studio キット を使用して副操縦士とテストを構成できます。 Copilot Studio API (Direct Line) に対して個別のテストを実行することにより、副操縦士の応答が予想される結果に対して評価されます。
信頼性チェックリスト
完全なレコメンデーションのセットを参照してください。