ベストプラクティス 11.4 – 定期的な回復力テストの実施 - SAP Lens

ベストプラクティス 11.4 – 定期的な回復力テストの実施

ソフトウェアと手順が予測可能な結果をもたらすことを証明するために、重要な障害シナリオに対する回復性を定期的にテストします。アーキテクチャ、ソフトウェア、サポート担当者の変更について評価し、追加テストが必要かどうかを判断します。

提案 11.4.1 – ビジネス要件に基づき、対象範囲内の重要な障害シナリオを定義します。

ビジネス要件に合わせて、テストできる重大な障害シナリオを定義する必要があります。以下は、分析の指針として使用できる障害シナリオの例です。シナリオ、分類、および影響の詳細度や範囲は、要件とアーキテクチャによって異なります。

障害シナリオの例 発生リスクの比較
計画/管理保守 計画
リソースの枯渇または侵害 (高い CPU 使用率/ファイルシステムがいっぱい/メモリ不足/ストレージの問題) ミディアム
分散ステートレスコンポーネントの障害 (ウェブディスパッチャーなど) ミディアム
分散ステートフルコンポーネントの障害 (アプリケーションサーバーなど) ミディアム
単一障害点 (データベース/SAP セントラルサービス) ミディアム
AZ/ネットワーク障害 低
コアサービスの障害 (DNS/Amazon EFS/API コール) 低/中
破損/過失による削除/悪意のあるアクティビティ/コードデプロイの誤り 低
リージョン障害 非常に低い

提案 11.4.2 – 重大な障害をシミュレートするためのテストケースを定義する。

SAP のワークロードに影響を与える重要な障害シナリオをシミュレートするために、完全なテストセットを定義しておく必要があります。

障害のシナリオによっては、シミュレーションが実際に発生する障害を完全に表現できない場合があることを認識しておく必要があります。例えば、ハードウェアの問題をシミュレートするために、EC2 インスタンスの障害を引き起こすことはできませんが、Nitro ベースのインスタンスでは、インスタンスを再起動させるためにカーネルパニックを発生させることができます。

加えて、 AWS Fault Injection Simulation は、 お客様の AWS リソース内の障害をシミュレートするのに役立つように設計されています。

提案 11.4.3 – 各テストケースに期待される動作を定義する

テストのベースラインを作成するには、期待される結果のセットを文書化する必要があります。

提案 11.4.4 – 変更の影響を評価するためのアプローチと、その後に必要なテストを定義する

変更が環境に与える影響を評価するためのアプローチと、その変更の一部として必要なテストを定義して、可用性と信頼性に対するアプローチを無効にしないように支援する必要があります。例えば、ソフトウェアのアップグレード、パッチ、パラメータの変更などです。

提案 11.4.5 – テストスケジュールを定義する

初期実装、変更点のテスト、環境の定期的な検証をカバーするテストスケジュールを確実に立ててください。

提案 11.4.6 – テスト結果を確認する

テスト結果に基づいて、テストケース、設定、またはアーキテクチャの改善点を特定します。

提案 11.4.7 – テスト前の状態に戻すために必要なアクティビティを定義する

各テストの一環として、テスト前の状態に戻すために必要なアクティビティを定義する必要があります。これは、各テストケースを他のテストから分離し、テストが本番稼働システムの可用性と信頼性に影響を与えないようにするためです。