ベストプラクティス 4.3 – 事業継続性計画と障害復旧を定期的にテストする
SAP システムは、通常、ビジネスクリティカルで、主要なお客様向けトランザクションに依存します。IT オペレーションの迅速な再開を可能にし、障害または災害の状況でのデータ損失を最小限にすることは、運用上の優秀性に重要です。オペレーションチームとシステムが、何をいつなすべきかを知り、障害発生時には、ただちにワークロードサービスを再開できるようにするには、業務継続計画 (BCP) と障害復旧手順が必要です。
サービスを正常に再開するのに重要なことは、BCP 手順と障害復旧計画を定期的にテストし、システムとサポートチームの進化に合わせて改善し、洗練することです。本当の危機的状況ではないときに BCP と回復計画をテストすると、現実のシステム障害や災害が発生したとき、サービスを正常に再開し、目標復旧時間 (RTO) と 目標復旧時点 (RPO) に間に合わせる能力に自信を持つことができます。
提案 4.3.1. - BCP および障害回復テストカレンダーを作成する
SAP ワークロードの定期的な (少なくとも手動) BCP と障害復旧テストのスケジュールを設定するカレンダーを作成します。テクノロジー運用チーム、サポートスタッフとビジネスステークホルダーをテストに参加させて、手順が理解され、期待が一致するようにします。できる限りリアルな状況でテストすることを目標にします。
以下のシナリオをテストしてそれぞれの回復メトリクスを検証することを検討してください。
-
SAP アプリケーションサービス障害
(例えば、設定変更のために SAP アプリケーションサービスがスタートできない)
-
シングルインスタンスホスト障害
(例えば、SAP アプリケーションサーバー EC2 インスタンスに到達できなくなる)
-
単一ストレージボリューム障害
(例えば、1 つの EBS ボリュームに到達できなくなる)
-
ネットワーク障害と冗長接続への切り替え
(例えば、オンプレミス Direct Connect 接続に到達できない)
-
プライマリとセカンダリのクラスター化されたコンポーネント間での自動フェイルオーバー
(例えば、SUSE HAE クラスターが、プライマリ HANA データベースを代替アベイラビリティーゾーンにあるセカンダリデータベースに移行させる)
-
プライマリコンポーネントとセカンダリコンポーネント間でのマニュアルフェイルオーバー
(例えば、Oracle DataGuard をマニュアルで呼び出すと、代替アベイラビリティーゾーンにあるセカンダリデータベースに切り換わる)
-
複数の冗長化されたコンポーネント間でのロードバランシング
(例えば、プライマリウェブディスパッチャーがアベイラビリティーゾーンの高可用性ペアで失敗する)
-
代替 AWS リージョンでの SAP アプリケーションの回復 (必要な場合)
-
ランサムウェアの被害を受けた場合にバックアップから回復する
(例えば、Simple Storage Service (Amazon S3) WORM バックアップから SAP ERP システム全体を回復する)
提案 4.3.2 - ワークロード変更の一環として定期的に BCP と障害回復手順を見直す
時間の経過に伴い、ワークロードが進化し変化するとき、BCP と回復手順がこれらの変更で考慮されていることを確認します。コードまたはインフラストラクチャの変更が RTO または RPO に影響する可能性がある場合、ドキュメントと設定が更新されていること、および新しい BCP と回復プロセスが、リリースプロセスまたは定期的なテストカレンダーの一環としてテストされることを確認します。
