計画を立てる

どのような危機を乗り越えるにもストレスはつきものであり、災害も同様である。 災害時には、ビジネス・クリティカルなサービスを再開しようとしている可能性が高く、それを迅速に行う必要に迫られているため、ミスを犯す可能性がある。 万が一災害が発生した場合でも、明確に定義された計画があれば、予測可能な方法でビジネスを復旧させることができるため、ストレスを軽減し、ミスを減らすことができる。 災害復旧計画の作成についての詳細は、 災害復旧計画 を参照してください。

優先順位の決定

災害復旧計画を作成する際には、組織がその計画に賛同し、理解し、資金を提供できることを確認してください。 幅広いステークホルダーの賛同が得られれば、災害が発生した場合のビジネスの優先順位を把握することができる。 こうすることで、包括的かつビジネスの期待に見合った計画となる。 定期的に組織で計画を見直し、優先事項の変化を把握し、必要に応じて計画を更新する。

ゾーン間の容量をバランスさせる

リージョン内の複数のアベイラビリティゾーンにワークロードを分散配置することで可用性が向上しますが、特に IBM Cloud® Virtual Servers for Virtual Private Cloud （VSI）を使用する場合は、ゾーン間の不均衡に注意する必要があります。 ワークロードが各ゾーンに分散されていることを確認してください。そうすることで、あるゾーンに障害が発生しても、ワークロードは引き続き実行され続けます。 また、残りのゾーンがワークロード全体を処理するのに十分な処理能力を備えていることを確認してください。 3つのゾーンにまたがって展開する場合は、ゾーンの障害発生時に生じる33%の容量損失を補うため、ゾーンごとに約17%の余剰VSI容量を確保するように設計してください。

何が災害として認められるかを理解する

ディザスターリカバリープランを実行するためには、今起きていることがディザスター（災害）であることを確認する必要がある。 そうでなければ、災害が発生したときに、誤った警報を発したり、何も行動を起こさなかったりする危険性がある。 災害を構成するいくつかの異なるシナリオを定義し、事業がそれらにどのように対応できるか、そしてどの程度迅速に対応できるか。 また、影響の範囲も考慮する。 ワークロードの1つのコンポーネントが災害に見舞われた場合、すべてが故障した場合と対応は異なるのでしょうか？

コミュニケーションが鍵

災害状況では、チーム間の効果的なコミュニケーションが重要である。 計画には、どのような個人が災害を呼び出せるかを明記しておく。 組織や災害復旧計画を実施するために必要な人々とどのようにコミュニケーションをとるかを明確にする。 重要なメッセージを聞き逃さないよう、電話やEメールなど、連絡手段を明確にする。 プライマリ・チャンネルが影響を受けた場合に備えて、バックアップのコミュニケーション・チャンネルを考えておく。 計画では、状況の最新情報を把握するために行わなければならない特定の会議も規定されているかもしれない。

計画をテストする

実際の災害に反応することは、計画を初めてテストする理想的なタイミングではない。 定期的にプランをテストし、プランが確実に機能することを確認する。 他の職員が関与している場合、計画をテストすることで、その職員は自分の役割をよりよく理解することができる。 テスト後、学んだ教訓は必ずプランに反映させること。 災害復旧計画のテストの詳細については、 災害復旧テスト を参照してください。

自分の責任を理解する

IBM Cloud サービスには、 IBM®の責任、顧客の責任、およびバックアップ、リカバリ、災害に関する責任などの共有責任を定義した役割と責任のマトリックスがあります。 サービス・インスタンスをうまくリカバリーするためのアクションを決定し、計画を立てるのに役立つので、使用する各サービスの責任の所有権を完全に理解していることを確認してください。

データ回復力とデータ常駐の要件を考慮する

データ回復力とは、障害や災害が発生した場合にデータにアクセスし、維持し、迅速に回復する能力のことである。 これは、高可用性、災害復旧、サイバー回復力の概念に関連している。 データ回復力の詳細については、 IBM 優れたフレームワーク を参照してください。

考慮すべきもう一つの重要な側面は、データレジデンシーと、データの物理的な場所に関する制限や要件である。

ワークロードにHAとDRを設計する

クラウドで展開するワークロードを設計する際には、要件収集の段階で高可用性とディザスタリカバリについて考えておく。 設計プロセスの早い段階で、ワークロードの弾力性を理解することで、アーキテクチャを左右する決定を下し、リカバリを容易にすることができる。 たとえば、ワークロードの復旧時間の目標を理解していれば、利用可能なサービスの機能を使用して、その目標を達成するためにワークロードをどのように展開するかを決定できる。 同様に、リカバリーポイントの目的を理解すれば、データについて、どのようにバックアップするか、どのようにレプリケートするかについて、より適切な判断を下すことができる。 早い段階からこのような設計を行うことで、事業者は作業量にかかるランニングコストをよりよく理解することができる。

災害復旧サイトへの切り替えを容易にするために、アプリケーションコードをどのように開発できるかを検討する。 例えば、接続文字列や、代替リソースへの接続によって変更される可能性のあるその他の設定をハードコーディングすることは避けてください。

適切な道具を選ぶ

IBM Cloudは、ワークロードのデプロイと実行に使用できる一連のツールやサービスを備えたツールボックスだと考えてほしい。 どんな道具でも、それを正しく使うには、何ができて何ができないのかを理解し、正しいものを選ぶ必要がある。 設計されていない仕事に道具を使おうとすると、何か問題が起こる可能性がある。 耐障害性計画を策定する際には、ワークロードが使用するサービス、その機能、およびその限界をできるだけ詳細に理解すること。 あるサービスがRTOやRPOの目標を達成できない場合、そのギャップを埋めるのに役立つ他のサービスやツールを検討する。 また、設定した目標が現実的かどうか、あるいはわずかな利益のためにソリューションに過度な複雑さやコストを導入していないかどうかも検討する。

変更を加える前にバックアップを取る

ITシステムの運用にリスクはつきものであり、ワークロード環境に変化をもたらすことは、リスクが増大するポイントである。 環境に加えた変更を管理するために、変更リリース計画とバックアウト計画を立てる。 変更リリース計画の最初のステップとして、データと構成のバックアップを取ることを含める。 リリース中やリリース直後に何か問題が発生しても、バックアップからリカバリーすることができます。

カスタム画像の作成

ブート・ボリュームからカスタム・イメージ を作成し、アプリケーションと構成をプリインストールしたゴールデン・イメージとして使用することで、DRサイトの IBM Cloud® Virtual Servers for Virtual Private Cloud インスタンスのプロビジョニング時間を短縮します。 カスタムイメージを作成するには、ブートボリュームを停止した仮想サーバーインスタンス（VSI）にアタッチする必要があります。

サブネットにホスト名を使用

IPアドレスの代わりにホスト名とDNSを使用することで、特にVSIを含むVPCインスタンスで、DRサイトにアプリケーションを再展開するために必要な変更を最小限に抑えることができます。 サブネットはゾーン固有であり、ゾーンをまたいで拡張されることはない。 新しいサービスインスタンスには新しいIPアドレスが割り当てられますが、これにより、セキュリティルールやアプリケーション設定ファイルなどの既存の設定が破損する可能性があります。

災害復旧のための鍵管理サービスの設定

Key Protectについては、プライマリ サイトのサービスをDRリージョンでフェイルオーバーできるように構成し、リージョンでサービスが停止した場合に Key Protect 要求の自動再ルーティングを可能にします。 災害復旧手順の一環として、 Key Protect サービスにアクセスするための仮想プライベートエンドポイント（VPE）の設定（特にInternet Protocol （IP）アドレス）を更新するスクリプトを作成します。

HPCSの場合、DRリージョンにフェールオーバークリプトユニットを構成する。 災害が発生する前に、フェイルオーバー暗号化ユニットを運用暗号化ユニットと同じように 初期化および構成する

観測可能性への投資

Observabilityには、 IBM Cloud Logs や IBM Cloud Monitoring などのツールがあり、システムで何が起きているかを知ることができ、障害やサービスの低下が発生した場合、根本原因を迅速に特定、緩和、修復するのに役立ちます。 これは、故障が避けられず、コンポーネント間の依存関係を追跡したり相関させたりするのが非常に困難な、複雑な分散システムで特に必要とされる。 さらに、 Activity Tracker イベント・ルーティング・ サービスにより、イベントの監査、システムに対する変更の記録と監視が可能になります。 Flow Logs for VPC は、VPC 内のネットワーク・インターフェイスを行き来する IP トラフィックを可視化し、他の方法では観察が困難なネットワーキングや接続性の問題のトラブルシューティングを可能にします。

クラウド用に構築されたレジリエントなアプリケーションと、それをサポートするプロセスは、これらの機能を効果的に活用する必要がある。 例えば、アプリケーションは、そのコンポーネントとサブシステムの健全性に関するメトリクスを公開すべきである。 すべての IBM Cloud サービスは、 プラットフォーム・メトリクスの 収集をサポートし、 ロードバランサーについては このように、個別に文書化された詳細なメトリクスを公開する。 それらをサポートするために構築されたアプリケーションや ダッシュボードは、業務効率を改善するためにこれらの指標を活用すべきである。

IBM Cloud ログは、ログ量とそのコストを管理しながら、アプリケーションによって生成されたログのリッチ化、クエリ、アラートを行う高度な 機能を 提供する。 異なる アラート・タイプは、システムを効果的に監視するためのより高度な機能を可能にする。

IBM Cloudの通知で常に最新の状態に保つ

災害が発生し、 IBM Cloud サービスまたはリージョンに影響が出た場合、 IBM Cloudからアカウントまたは電子メールで通知が届きます。 [通知を見る]](/docs/support?topic=support-viewing-notifications#subscribe-email-notifications) をクリックして、アカウントに通知を登録します。 また、 IBM Cloudも表示できます。 ステータスの概要 ページ。