信頼性の準備状況をテストするテストを定期的に実行して、既存のしきい値、ターゲット、前提条件を検証します。ワークロードで大きな変更が発生した場合は、定期的なテストを実行します。テスト環境とステージング環境でほとんどのテストを実行します。運用システムに対してテストのサブセットを実行することも有益です。パリティを計画します。カバレッジと再現性を確保します。プロセスに統合します。ソフトウェアを手動でテストするのは面倒で、エラーの影響を受けやすくなりますが、手動の探索的テストは実施しても構いません。自動テストを開発する必要がある場合は、手動テストを使用して、開発するテストの範囲を決定します。アプローチを採用して、開発サイクルにおける早い段階で回復性と可用性のテストを実行します。簡単なドキュメント形式を適応させて、すべてのユーザーがすべての定期的なテストのプロセスと結果を簡単に理解できるようにします。リカバリーの利害関係者など、適切なチームと共有します。信頼性目標の改善に反映させる必要があります。バックアップの定期的なテスト頻度を作成します。バックアップが有効であり、復元が機能していることを確認するために、分離されたシステムにデータを復元します。リカバリーの利害関係者と共有して、復旧に対する期待値が適切であることを確認します。プロセスを確保します。一時的な障害に耐えるワークロードの能力をテストします。詳細については、「一時的な障害を処理するための推奨事項」を参照してください。負荷パターンにおける変化と、使用量におけるスパイクに対応するワークロードの能力をテストします。この情報を使用して、スケーリング戦略をテストするのに役立てます。テストの詳細については、テストに関する推奨事項を参照してください。フォールト挿入を使用して、依存サービスまたはその他の依存関係内のエラーをワークロードで処理する方法をテストします。自己修復および自己保存の設計が、誤動作にどのように対応するかをテストして検証します。自動および手動の復旧操作をテストします。リカバリー計画をテストします。フォールト挿入を使用して、段階的に機能を低下させ、コンポーネント誤動作の影響範囲を最小限に抑えるワークロードの能力をテストします。計画および計画外の停止を活用する計画メンテナンスまたは計画外の停止によってワークロードがオフラインになっている場合には、テストを実行し、ワークロードの理解を深める、またとない機会があります。次のセクションでは、各シナリオに関する推奨事項を示します。定期的なメンテナンス更新プログラムまたはパッチの計画メンテナンス期間がある場合、そのメンテナンス作業に関係のないコンポーネントとフローをテストできます。ワークロードが予期せず機能低下したり、完全にオフラインになったりする潜在的なリスクを負わずにテストを実行します。メンテナンス期間中に十分な時間がある場合は、メンテナンス作業の完了後に、メンテナンスに関係するコンポーネントとフローもテストできます。計画外の停止すべての停止インシデントを、ワークロードの詳細を確認し、優先順位と次の手順に従って、その回復性を向上させる機会として使用します。顧客のためにワークロードをオンラインに戻します。これを行うには、問題の回避策を実行する、問題を解決する、または復旧プロセスを開始する場合があります。停止の根本原因を特定し、それに対処します。調査の一環として根本原因を修正できる場合は、その根本原因と、それを修正するために行った対策を文書化します。その問題に、後で追加のメンテナンス期間が必要な場合は、綿密にテストすることで、その軽減策が予想される負荷を処理できることを確認します。軽減策を扱うのに十分な監視が設定されていることを確認します。該当する場合は、ワークロード内のすべてのコンポーネントにわたって、同じ問題、または同様の問題により影響を受ける可能性がある構成の弱点を探します。この機会を利用し、事前対策的にそれらのコンポーネントに対処します。インシデント履歴を調べて、ワークロード全体で同様の問題のパターンを検出します。調査結果を使用して、テスト戦略を改善します。同じ障害を直接テストして、根本原因と同様の問題に正常に対処したことを確認します。エンジニアリングの原則に従います。運用前および運用環境内で、フォールト挿入テストを実行します。テストはインフラストラクチャおよびアプリケーションのレイヤーに適用されます。「障害モード分析を実行するための推奨事項」で学習した情報を適用して、優先順位を付けた障害のみをテストし、障害に対処する軽減戦略があることを確認します。エンジニアリングの主なガイドラインは次のとおりです。プロアクティブに行う。障害が発生するまで待つ必要はありません。カオス実験を実施して障害を予測し、運用環境に影響を与える前に問題を検出して修正します。システム内で発生した障害を受け入れて、そこから学びます。障害を複雑なシステムの自然な部分とみなし、それをシステムの信頼性を学習して向上させる機会として使用します。システム内に意図的に障害またはストレスを挿入して、その回復性をテストします。実際の障害や中断をシミュレートし、ワークロードの復旧機能をテストして改善します。単一障害点を早期に特定して対処する。テストする際に、障害モード分析を調べて更新し、ドキュメント内の障害を検証して対処します。冗長性やセグメント化などの信頼性アプローチを適用し、ワークロードの可用性を向上させて、ダウンタイムを最小限に抑えます。ガードレールとグレースフルな軽減策を導入する。パターンまたは調整パターンなどの安全対策を実装して、可用性を高めます。デグラデーションのアプローチを実装します。爆発半径を最小限に抑える。障害分離戦略を実装して、たとえ障害が発生した場合でも、その範囲が制限されることを確認します。システムは、顧客に対する影響を最小限に抑えながら、引き続き機能します。エンジニアリング実験を使用して、障害を防ぎ、障害から復旧するワークロードの能力を向上させます。チームの文化と継続的なプラクティスの不可欠な部分です。カオス実験を設計する際は、次の標準的な方法に従います。各実験には、特定のコンポーネントの損失に耐える特定のフローの能力をテストする、などの明確なゴールが必要です。ベースラインの動作を測定します。実験の実行時に機能低下状態と比較するために、特定の実験に関係するフローとコンポーネントの、信頼性およびパフォーマンスのメトリックが一貫していることを確認します。複数の障害を挿入します。この実験では、迅速に回復できる固有のコンポーネントを意図的にターゲットにする必要があり、実験の影響範囲の制御に役立つ、フォールト挿入によって引き起こされる影響について、十分な情報に基づいて予測する必要があります。結果として発生する動作を監視します。コンポーネントと、実験がターゲットとするエンドツーエンドのフロー動作に関するテレメトリを収集して、障害の影響を適切に理解します。メトリックと比較して、フォールト挿入結果の全体像を確認します。プロセスと観測された内容を文書化します。実験の詳細な記録を保持することで、ワークロードの設計に関する将来の決定に反映させ、時間の経過と共に明らかになったギャップに確実に対処します。結果を特定し、対応します。改善点として、ワークロードのバックログに追加できる修復手順を計画します。他のデプロイと同じプロセスに従って、非運用環境内で設計改善計画がレビューおよびテストされていることを確認します。プロセス、アーキテクチャの選択、コードを定期的に検証し、技術的負債をすばやく検出して、新しいテクノロジを統合し、変化する要件に適応します。フォールト挿入実験を実施する場合は、次の手順を実行します。監視が実施され、アラートが設定されていることを確認します。割り当てるプロセスを検証します。ドキュメントおよび調査プロセスが最新であることを確認します。テスト戦略を最適化します。システムの想定に挑戦する。テストでは、ワークロードの回復性とワークロード設計戦略を改善しようとします。過去の経験に基づいて、信頼性が高いと推測されるコンポーネントとフローの中に障害を挿入する機会を探します。新しいワークロードでは信頼できない可能性があります。トポロジ、プラットフォーム、リソースなどの変更を検証します。フォールト挿入テストを含む綿密なテストを行わないと、変更が加えられた後にワークロードが不完全な状態になる場合があります。わからない方法で、誤って新しい依存関係を導入してしまう、または既存の依存関係を壊してしまう場合があります。バッファーを使用します。内に留まるようにし、停止による評判や財務上への潜在的な影響を回避します。フローとコンポーネントの復旧目標は、テストの範囲を定義するのに役立ちます。バジェットを設定します。達成する場合の差です。範囲を超えた場合は実験を停止します。不明な結果が、カオス実験の予想される結果です。影響を受ける運用ユーザー数を可能な限り抑えながら実質的な結果データを収集できるようにうまく調整します。開発チームと緊密に連携して、挿入された障害の関連性を確認します。過去のインシデントまたは問題をガイドとして使用します。依存関係を調べて、それらの依存関係を削除する際に結果を評価します。テストによって明らかにされたワークロード内のさまざまなコンポーネント間で、以前に検出されなかった依存関係を特定して文書化します。テスト中に検出された依存関係を考慮して、必要に応じて復旧計画を調整します。実験とテストの結果を、新しい実験とテストの基礎として使用します。予期しない動作が発生すると、新しいテストでそれらの動作を直接ターゲットとし、それらの修復戦略を設計する機会を得られる場合があります。運用環境内でのフォールト挿入テストは中断を招き、ダウンタイムを発生させる可能性があります。この可能性について、利害関係者に対して透明性を保ち、実験を終了するためのセーフガードが講じられていること、および導入した障害を迅速に元に戻すためのロールバック計画があることを確認します。運用環境内での意図しない停止を防ぐには、十分な冗長性を計画すること、および利害関係者がトレードオフのコストを理解することを確認します。計画的な手動テスト、ユーザー受け入れテスト、探索的テスト、利害関係者からのフィードバックの収集に必要なすべての機能を提供する、使いやすいブラウザーベースのテスト管理ソリューションです。インフラストラクチャを使用してアプリケーションのフォールト挿入と回復性テストを開始するのに役立つ多くの機能を備えています。信頼性テストのチェックリストアプリケーションの可用性と回復性をテストする信頼性チェックリストレコメンデーションの完全なセットを参照してください。