たとえ洪水であっても、1Cは機能するはずです！ DR に関するビジネスに同意します

想像してみてください。あなたは大規模なショッピング センターの IT インフラストラクチャにサービスを提供しているとします。街に雨が降り始める。雨が屋根を突き破り、小売店の敷地内が足首までの深さまで水で満たされます。サーバー ルームが地下にないことを願っています。そうでない場合、問題は避けられません。  

説明されている物語はファンタジーではなく、2020 年のいくつかの出来事をまとめて説明したものです。大企業では、この場合に備えて災害復旧計画 (DRP) が常に用意されています。企業では、これは事業継続専門家の責任です。しかし、中小企業では、このような問題の解決は IT サービスにかかっています。ビジネス ロジックを自分で理解し、何がどこで失敗する可能性があるかを理解し、保護を考え出して実装する必要があります。 

IT スペシャリストが企業と交渉し、保護の必要性について話し合うことができれば素晴らしいことです。しかし、私は、企業が災害復旧 (DR) ソリューションを冗長であると考えて、そのソリューションを軽視した様子を何度も見てきました。事故が発生すると、回復に時間がかかり損失が発生する恐れがあり、事業の準備が整っていませんでした。 「言ったでしょ」と好きなだけ繰り返すことができますが、それでも IT サービスはサービスを復元する必要があります。

建築家の立場から、この状況を回避する方法を説明します。記事の最初の部分では、準備作業、つまりセキュリティ ツールを選択する際の 3 つの質問についてお客様と話し合う方法について説明します。 

• 私たちは何を守っているのでしょうか？
• 私たちは何から守っているのでしょうか？
• 私たちはどこまで守るのでしょうか？ 

後半では、自分自身を守る方法という質問に答えるための選択肢について話します。さまざまな顧客がどのように保護を構築するかの例を示します。

私たちが守るもの: 重要なビジネス機能の特定 

企業顧客と緊急事態後の行動計画について話し合うことから準備を始めることをお勧めします。ここでの主な困難は、共通言語を見つけることです。通常、顧客は IT ソリューションがどのように機能するかを気にしません。彼は、サービスがビジネス機能を実行し、収益をもたらすことができるかどうかを気にしています。たとえば、サイトは機能しているが、支払いシステムがダウンし、クライアントからの収入がなく、「過激派」は依然として IT スペシャリストである場合です。 

IT プロフェッショナルは、次のような理由から、このような交渉が難しい場合があります。

• IT サービスは、ビジネスにおける情報システムの役割を完全には理解していません。たとえば、ビジネス プロセスや透明性のあるビジネス モデルの説明が利用できない場合です。 
• プロセス全体が IT サービスに依存しているわけではありません。たとえば、作業の一部が請負業者によって実行され、IT 専門家が請負業者に直接影響を及ぼさない場合などです。

私なら会話を次のように構成します。 

1. 事故は誰にでも起こり、復旧には時間がかかることを事業者に説明しています。最善のことは、状況、これがどのように起こり、どのような結果が起こり得るかを示すことです。
2. すべてが IT サービスに依存しているわけではありませんが、自分の責任分野でのアクション プランを支援する準備ができていることを示します。
3. 私たちは企業顧客に、「黙示録が起こった場合、どのプロセスを最初に復元する必要があるか?」と答えてもらいます。誰がどのように参加するのでしょうか? 

   たとえば、コールセンターはアプリケーションを 24 時間年中無休で登録し続ける必要があるなど、企業からは簡単な回答が求められます。

4. システムのユーザー 1 人または 2 人に、このプロセスを詳しく説明してもらいます。 
   会社にアナリストがいる場合は、アナリストに協力してもらうことをお勧めします。

   まず、説明は次のようになります。コールセンターは、電話、メール、Web サイトからのメッセージを通じてリクエストを受け取ります。次に、Web インターフェイスを介してそれらを 1C に入力し、本番環境がこの方法でそこからそれらを取得します。

5. 次に、そのプロセスをサポートするハードウェアおよびソフトウェア ソリューションを検討します。包括的な保護のために、次の 3 つのレベルが考慮されます。 
   • サイト内のアプリケーションとシステム (ソフトウェア レベル)、   
   • システムが実行されるサイト自体 (インフラストラクチャ レベル)、 
   • ネットワーク（彼らはしばしばそれを忘れます）。

6. 潜在的な障害点、つまりサービス運用が依存するシステムノードを特定します。また、通信事業者などの他社がサポートするノードも特定します。 ホスティングプロバイダー、データセンターなどです。これを念頭に置き、ビジネス顧客に戻って次のステップに進みます。

私たちが守るもの: リスク

次に、最初にどのようなリスクから身を守るかを企業顧客から聞き出します。すべてのリスクは 2 つのグループに分類できます。 

• サービスのダウンタイムによる時間の損失。
• 物理的衝撃や人的要因などによるデータの損失。

企業はデータと時間の両方を失うことを恐れています。これはすべて金銭の損失につながります。そこで、それぞれのリスクグループについて再度質問します。 

• このプロセスで、データ損失と時間損失がどれくらいの金額になるかを見積もることはできますか? 
• 失われないデータは何ですか? 
• ダウンタイムを許容できないのはどこでしょうか? 
• 私たちにとって最も可能性が高く、最も脅威となる出来事は何ですか?

ディスカッションの後、障害ポイントの優先順位を決定する方法がわかります。 

どれだけ保護するか: RPO と RTO 

重大な障害点が明確になったら、RTO 指標と RPO 指標を計算します。 

私がいることを思い出す RTO (目標復旧時間) — これは、事故の瞬間からサービスが完全に復旧するまでの許容時間です。ビジネス用語では、これは許容できるダウンタイムです。プロセスによってもたらされた金額がわかれば、ダウンタイムごとに損失を計算し、許容可能な損失を計算できます。 

RPO (目標復旧時点) — 有効なデータ回復ポイント。データが失われる可能性がある期間が決まります。ビジネスの観点から見ると、データ損失は罰金などにつながる可能性があります。このような損失はお金に換算することもできます。 

エンド ユーザーがシステムにログインできるまでの時間を計算する必要があります。そこで、まずチェーン内のすべてのリンクの回復時間を合計します。ここでよくある間違いは、SLA からプロバイダーの RTO を取り上げ、残りの条件を無視することです。

具体的な例を見てみましょう。ユーザーが 1C にログインすると、システムが開き、データベース エラーが発生します。彼はシステム管理者に連絡します。データベースはクラウドにあり、システム管理者は問題をサービス プロバイダーに報告します。すべての通信に 15 分かかるとします。クラウドでは、このサイズのデータ​​ベースはバックアップから 15 時間で復元されるため、サービス プロバイダー側​​の RTO は XNUMX 時間になります。ただし、これはユーザーにとっての最終期限ではなく、問題を検出するために XNUMX 分が追加されます。 
 
次に、システム管理者はデータベースが正しいことを確認し、データベースを 1C に接続してサービスを開始する必要があります。これにはさらに 2 時間かかります。つまり、管理者側の RTO はすでに 15 時間 15 分になっています。ユーザーにはさらに 2 分かかります。ログインして、必要なトランザクションが表示されていることを確認します。この例では、サービスの合計復旧時間は 30 時間 XNUMX 分です。

これらの計算により、ビジネスが回復期間がどのような外部要因に依存するかがわかります。たとえば、オフィスが浸水した場合、まず漏水箇所を見つけて修理する必要があります。 ITに依存しない時間はかかります。  

保護方法: さまざまなリスクに対応するツールの選択

すべての点について話し合った後、顧客はすでに企業にとっての事故のコストを理解しています。これで、ツールを選択し、予算について話し合うことができます。お客様の事例をもとに、さまざまな業務に合わせて当社が提供するツールをご紹介します。 

最初のグループのリスク、つまりサービスのダウンタイムによる損失から始めましょう。この問題の解決策は、良好な RTO を提供する必要があります。

1. クラウドでアプリケーションをホストする 

   まず、単純にクラウドに移行できます。プロバイダーは高可用性の問題をすでに検討しています。仮想化ホストはクラスターに組み立てられ、電力とネットワークは予約され、データはフォールト トレラント ストレージ システムに保存され、サービス プロバイダーがダウンタイムに対する経済的責任を負います。

   たとえば、クラウド内のデータベースを備えた仮想マシンをホストできます。アプリケーションは、確立されたチャネルを介して外部から、または同じクラウドからデータベースに接続します。クラスター内のいずれかのサーバーで問題が発生した場合、VM は 2 分以内に隣接するサーバーで再起動します。その後、DBMS が起動し、数分でデータベースが使用可能になります。

   RTO: 分単位で測定されます。これらの条件はプロバイダーとの契約で指定できます。
   のコスト: アプリケーションのクラウド リソースのコストを計算します。 
   それがあなたを守ってくれないもの: 都市レベルでの事故などによる、プロバイダーのサイトでの大規模な障害によるもの。

2. アプリケーションをクラスター化する  

   RTO を改善したい場合は、前のオプションを強化して、クラスター化されたアプリケーションをすぐにクラウドに配置できます。

   クラスターはアクティブ/パッシブ モードまたはアクティブ/アクティブ モードで実装できます。ベンダーの要件に基づいて複数の VM を作成します。信頼性を高めるために、それらをさまざまなサーバーとストレージ システムに分散させます。いずれかのデータベースを備えたサーバーに障害が発生した場合、バックアップ ノードが数秒以内に負荷を引き継ぎます。

   RTO: 秒単位で測定されます。
   のコスト: 通常のクラウドよりわずかに高価であり、クラスタリングには追加のリソースが必要になります。
   それがあなたを守ってくれないもの: それでも、オンサイトの大規模な障害からは保護されません。しかし、局地的な混乱はそれほど長くは続かないでしょう。

   練習から: この小売会社は、いくつかの情報システムと Web サイトを持っていました。すべてのデータベースは会社のオフィス内のローカルに配置されました。オフィスが数回連続して停電になるまで、DR については考えられませんでした。顧客はウェブサイトのクラッシュに不満を抱いていました。 
    
   サービスの可用性の問題は、クラウドに移行したことで解決されました。さらに、ノード間のトラフィックのバランスをとることで、データベースの負荷を最適化することができました。

3. 災害に強いクラウドへの移行

   メイン サイトで自然災害が発生しても業務に支障をきたさないようにする必要がある場合は、このオプションでは、プロバイダーが仮想化クラスターを 2 つのデータ センターに分散させます。データセンター間で XNUMX 対 XNUMX で常時同期レプリケーションが行われます。データセンター間のチャネルは予約されており、異なるルートに沿って移動するため、このようなクラスターではネットワークの問題を心配する必要はありません。 

   RTO：0になる傾向があります。
   のコスト: 最も高価なクラウド オプション。 
   それがあなたを守ってくれないもの: データ破損や人的要因による影響は避けられないため、バックアップも同時に作成することをお勧めします。 

   練習から: 当社のクライアントの 1 つは、包括的な災害復旧計画を策定しました。彼が選んだ戦略は次のとおりです。 

   • 災害に強いクラウドは、インフラストラクチャ レベルでの障害からアプリケーションを保護します。 
   • 2 レベルのバックアップにより、人的エラーが発生した場合に保護が提供されます。バックアップには「コールド」と「ホット」の 2 種類があります。 「コールド」バックアップは無効な状態にあるため、展開に時間がかかります。 「ホット」バックアップはすでに使用できる状態になっており、より速く復元されます。特別に専用のストレージ システムに保存されます。 3 番目のコピーはテープに記録され、別の部屋に保管されます。 

   クライアントは週に 1 回、保護をテストし、テープからのバックアップを含むすべてのバックアップの機能をチェックします。同社は毎年、災害に強いクラウド全体をテストしています。 

4. 別のサイトへのレプリケーションを整理する 

   メイン サイトでのグローバルな問題を回避する方法に関するもう 1 つのオプションは、地理的予約を提供することです。つまり、別の都市のサイトにバックアップ仮想マシンを作成します。これには、DR 用の特別なソリューションが適しています。当社では VMware vCloud Availability (vCAV) を使用しています。これを利用すると、複数のクラウド プロバイダー サイト間で保護を構成したり、オンプレミス サイトからクラウドに復元したりできます。 vCAV を使用するスキームについてはすでに詳しく説明しました。 ここで. 

   RPO と RTO：5分から。 

   のコスト: 最初のオプションより高価ですが、災害に強いクラウドでのハードウェア レプリケーションよりは安価です。価格は、vCAV ライセンスのコスト、管理料金、クラウド リソースのコスト、および PAYG モデルに基づく予約リソース (スイッチオフされた VM の作業リソースのコストの 10%) で構成されます。

   練習から: クライアントは、モスクワにある当社のクラウドに、異なるデータベースを持つ 6 台の仮想マシンを保持していました。当初、保護はバックアップによって提供されていました。バックアップ コピーの一部はモスクワのクラウドに保存され、一部はサンクトペテルブルクのサイトに保存されました。時間の経過とともにデータベースのサイズが大きくなり、バックアップからの復元に時間がかかるようになりました。 
    
   VMware vCloud Availability に基づくレプリケーションがバックアップに追加されました。仮想マシンのレプリカはサンクトペテルブルクのバックアップ サイトに保存され、5 分ごとに更新されます。メイン サイトで障害が発生した場合、従業員は独自にサンクトペテルブルクにある仮想マシンのレプリカに切り替えて作業を続けます。 

検討されているすべてのソリューションは高可用性を提供しますが、ランサムウェア ウイルスや従業員の偶発的なミスによるデータ損失を防ぐことはできません。この場合、必要な RPO を提供するバックアップが必要になります。

5. バックアップを忘れないでください

たとえ最も優れた耐災害ソリューションを持っていたとしても、バックアップを作成する必要があることは誰もが知っています。そこで、いくつかのポイントを簡単に思い出させていただきます。

厳密に言えば、バックアップは DR ではありません。だからこそ: 

• 久しぶり。データがテラバイト単位である場合、回復には 1 時間以上かかります。復元し、ネットワークを割り当て、電源が入っていることを確認し、データが正常であることを確認する必要があります。したがって、データが少ない場合にのみ、良好な RTO を提供できます。 
• データは最初は復元できない可能性があるため、アクションを繰り返す時間を考慮する必要があります。たとえば、データがいつ失われたのか正確にわからない場合があります。紛失が 15.00 時に認識され、コピーが 15.00 時間ごとに作成されたとします。 14:00 から、13:00、XNUMX:XNUMX などのすべての回復ポイントを調べます。システムが重要な場合、復旧ポイントの経過期間を最小限に抑えるよう努めます。ただし、新しいバックアップに必要なデータが含まれていない場合は、次の点に進みます。これには追加の時間がかかります。 

この場合、バックアップ スケジュールは必要なスケジュールを提供できます。 RPO。バックアップの場合は、メイン サイトに問題が発生した場合に備えて地理的予約を提供することが重要です。いくつかのバックアップ コピーを個別に保存することをお勧めします。

最終的な災害復旧計画には、少なくとも 2 つのツールが含まれている必要があります。  

• オプション 1 ～ 4 の XNUMX つ。システムを障害や落下から保護します。
• データを損失から守るためのバックアップ。 

主要なインターネットプロバイダーがダウンした場合に備えて、バックアップ通信チャネルを用意しておくことも価値があります。そして、出来上がり！ —最低賃金でのDRはすでに準備が整っています。 

出所： habr.com