洪水にしましょう、しかし1Cはうまくいくはずです!DRについてビジネスと交渉します

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



説明されているストーリーは空想ではなく、2020年のいくつかのイベントの集合的な説明です。大企業では、この場合、災害復旧計画(DRP)が常に手元にあります。企業では、ビジネス継続性の専門家がこれに責任を負います。しかし、中小企業では、このような問題の解決策はIT部門にあります。あなたは自分でビジネスロジックを理解し、何がどこに落ちるのかを理解し、保護を考え出し、実装する必要があります。 



ITプロフェッショナルがビジネスと交渉し、保護の必要性について話し合うことができれば、それは素晴らしいことです。しかし、私は、会社が災害復旧(DR)ソリューションをどのように節約したかを繰り返し観察しました。事故が発生したとき、長い回復は損失を脅かし、ビジネスは準備ができていませんでした。「しかし、私はあなたに言った」-あなたは好きなだけ繰り返すことができます-ITサービスはまだサービスを復元する必要があります。







アーキテクトの観点から、この状況を回避する方法を説明します。記事の最初の部分では、準備作業を示します。保護ツールを選択するために顧客と3つの質問について話し合う方法: 



  • 私たちは何を保護していますか?

  • 私たちは何から保護していますか?

  • 私たちはどれくらい強力に保護していますか? 



第二部では、質問に答えるためのオプションについて話します:何で防御するか。さまざまな顧客がどのように保護を構築するかの例を示します。



私たちが保護するもの:重要なビジネス機能の明確化 



災害計画について事業者と話し合うことから準備を始めるのが最善です。ここでの主な難しさは、共通の言語を見つけることです。顧客は通常、ITソリューションがどのように機能するかを気にしません。彼は、サービスがビジネス機能を実行してお金を稼ぐことができるかどうかを気にします。たとえば、サイトが機能していて、支払いシステムが「嘘をついている」場合、顧客からの領収書はなく、「極端な」ものは依然としてITスペシャリストです。 



ITプロフェッショナルは、いくつかの理由で交渉が難しいと感じるかもしれません。



  • ITサービスは、ビジネスにおける情報システムの役割を十分に認識していません。たとえば、ビジネスプロセスや透過的なビジネスモデルの利用可能な説明がない場合です。 

  • プロセス全体がIT部門に依存しているわけではありません。たとえば、一部の作業が請負業者によって行われ、ITスペシャリストがそれらに直接影響を与えない場合です。



私はこのように会話を構成します: 



  1. 事故は誰にでも起こり、復旧には時間がかかることを企業に説明します。最良のことは、状況、それがどのように発生するか、そしてどのような結果が起こり得るかを示すことです。

  2. すべてがITサービスに依存しているわけではありませんが、責任のある分野での行動計画を支援する準備ができていることを示しています。

  3. 私たちはビジネス顧客に答えを求めます:黙示録が起こった場合、どのプロセスを最初に復元する必要がありますか?誰がどのように参加しますか? 



    ビジネスには簡単な答えが必要です。たとえば、コールセンターは24時間年中無休でアプリケーションの登録を継続する必要があります。

  4. - . 

    , .



    : - , . 1 -, .

  5. , . : 

    • ( ),   

    • , ( ), 

    • ( ).


  6. 考えられる障害のポイント、つまりサービスのパフォーマンスが依存するシステムのノードを見つけます。これとは別に、他の企業(通信事業者、ホスティングプロバイダー、データセンターなど)によってサポートされているノードにマークを付けます。これにより、次のステップのためにビジネス顧客に戻ることができます。



私たちが保護するもの:リスク



次に、ビジネス顧客から、最初にどのようなリスクから保護しているかを調べます。すべてのリスクを条件付きで2つのグループに分けます。 



  • サービスのダウンタイムによる時間の損失。

  • 物理的影響、人的要因などによるデータの損失。



ビジネスはデータと時間の両方を失うことを恐れています-これはすべてお金の損失につながります。したがって、ここでも、各リスクグループについて質問します。 

  • このプロセスで、どれだけのデータ損失と無駄な時間が価値があるかを見積もることができますか? 

  • どのようなデータを失うことはできませんか? 

  • どこでダウンタイムを許可できませんか? 

  • どのようなイベントが私たちにとって最も可能性が高く、より脅威的ですか?



話し合いの後、失敗点に優先順位を付ける方法を理解します。 



保護する量:RPOとRTO 



障害の重大なポイントが理解されたら、RTOおよびRPOメトリックを計算します。 RTO(回復時間目標)は、事故の瞬間からサービスが完全に回復するまでの許容時間である



ことを思い出してくださいビジネス言語では、これは許容可能なダウンタイムです。プロセスがもたらした金額がわかっている場合は、ダウンタイムの1分ごとの損失を計算し、許容損失を計算できます。 RPO(リカバリポイントの目的)は、有効なデータリカバリポイントです。データを失う可能性のある時間を決定します。ビジネスの観点からは、データの損失は、たとえば罰金につながる可能性があります。そのような損失はまたお金に変換することができます。 











回復時間は、エンドユーザーに対して計算する必要があります。システムへのログオンにかかる時間です。したがって、最初に、チェーン内のすべてのリンクの回復時間を追加します。ここで彼らはしばしば間違いを犯します:彼らはSLAからRTOプロバイダーを取得し、他の用語を忘れます。

具体的な例を見てみましょう。ユーザーが1Cを入力すると、システムが開き、データベースエラーが発生します。彼はシステム管理者に連絡します。ベースはクラウドにあり、sysadminは問題をサービスプロバイダーに報告します。すべての通信に15分かかるとしましょう。クラウドでは、このサイズのデータ​​ベースは1時間以内にバックアップから復元されるため、サービスプロバイダー側​​のRTOには1時間かかります。しかし、これは最終的な期限ではありません。ユーザーが問題を検出するために15分が追加されたためです。 

 

次に、システム管理者はデータベースが正しいことを確認し、データベースを1Cに接続して、サービスを開始する必要があります。さらに1時間かかります。つまり、管理者側のRTOはすでに2時間15分です。ユーザーはさらに15分必要です。ログインして、必要なトランザクションが表示されていることを確認してください。この例では、2時間30分がサービスの合計回復時間です。
これらの計算は、回復時間がどのような外部要因に依存するかについてビジネスを示します。たとえば、オフィスが浸水している場合は、最初にリークを検出して修正する必要があります。ITに依存しない時間はかかります。  



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



すべてのポイントを話し合った後、顧客はすでにビジネスの事故のコストを理解しています。これで、ツールを選択して予算について話し合うことができます。クライアントケースの例で、さまざまなタスクにどのツールを提供するかを示します。 



リスクの最初のグループであるサービスのダウンタイムによる損失から始めましょう。このタスクのソリューションは、優れたRTOを提供するはずです。



  1.  



    — . , , , - .



    , . . , 2 . , .



    RTO: . .

    : . 

    : , , - .

  2.   



    RTO, .



    active-passive active-active. , . . , .



    RTO: .

    : , .

    : - . .

    : - . . DR , . . 

     

    . .




  3. , ,   2 -. - , --. , . 



    RTO: 0.

    : . 

    : , , . 

    : . : 





    • . : «» «». «» , . «» . . . 



    , . . 
  4.  



    , : . , . DR: VMware vCloud Availability (vCAV). on-premise . vCAV



    RPO RTO: 5 . 



    : , , . vCAV, , PAYG (10% ).

    : 6 . : , — . , . 

     

    VMware vCloud Availability. - 5 . , - . 


検討されているすべてのソリューションは高い可用性を提供しますが、暗号化ウイルスや偶発的な従業員のエラーによるデータ損失からあなたを救うことはできません。この場合、必要なRPOを提供するバックアップが必要です。



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



最もクールな災害復旧ソリューションがあるとしても、バックアップを作成する必要があることは誰もが知っています。それで、私はいくつかのポイントを簡単に思い出します。



厳密に言えば、バックアップはDRではありません。そしてそれが理由です: 



  • 時間がかかる。データがテラバイト単位で測定されている場合、回復には1時間以上かかります。復元し、ネットワークを割り当て、何がオンになるかを確認し、データが正常であることを確認する必要があります。したがって、データが少ない場合にのみ、良好なRTOを達成できます。 

  • データは最初は回復されない可能性があり、2回目のアクションに時間をかける必要があります。たとえば、データがいつ失われたか正確にわからない場合があります。15.00に損失が発生し、1時間ごとにコピーが作成されたとします。15.00から、14:00、13:00などのすべてのリカバリポイントを監視します。システムが重要な場合は、復元ポイントの経過時間を最小限に抑えるように努めます。ただし、新しいバックアップで必要なデータが見つからなかった場合は、次のポイントに進みます。これは追加の時間です。 



そうは言っても、バックアップスケジュールは必要なRPOを提供できますバックアップの場合、メインサイトで問題が発生した場合に備えて、地理的な冗長性を提供することが重要です。一部のバックアップは個別に保持することをお勧めします。



最終的な災害復旧計画には、少なくとも2つのツールが必要です。  



  • クラッシュやクラッシュからシステムを保護するオプション1〜4の1つ。

  • データを損失から保護するためのバックアップ。 



メインのインターネットプロバイダーがクラッシュした場合に備えて、バックアップ通信チャネルを管理することも価値があります。そして出来上がり!-最低給与のDRはすでに準備ができています。 



All Articles