ビジネスのニーズとその能力を関連付けます
災害復旧計画に関する以前の記事（ 1、2 ）で、組織のITインフラストラクチャに関する情報を収集および処理する手順が説明されており、以下に関する正確な情報が提供されています。
- 会社のビジネスに不可欠なITサービス、
- 障害発生時の現在の回復時間、
- 達成可能な最小の災害復旧時間、
- それらを達成するために必要なリソース。
また、組織の財政能力が限られていて、事業の回復に必要なすべての準備金を取得できない場合は、すべてうまくいきます。 このため、災害復旧計画の最終目標は、ビジネスのニーズと財務能力のバランスを見つけ、インシデントの除去に関するサービスレベル契約（SLA）の形でそれを統合することです。
この段階は、相互作用の以下の側面の会社の管理者との調整から完全に構成されています。
1.時間サポートビジネスの社内ITサービス
障害に関する情報を受け取った直後に災害復旧を開始する技術者の意欲は、サポートの時間を決定する主な要因です。 8時間の就業日、休日、病気、休日が自然にこの機会を制限します。 修復作業を実行するために必要な能力を備えた専門家がいない場合、またはエンジニアが時間内に1人も欠席している場合でも、エンジニアが十分に重複していない場合、ビジネスは24時間365日のスケジュールでサポートに頼るべきではありません。 専門家による現在の重複が9 * 5のスケジュールでも応答性を保証しない場合、次のオプションが可能です。
- インシデントが発生した瞬間からではなく、事故の専門家の作業の開始から回復時間を測定します。
- 能力の低い専門家によるユーザーサービスの復元の可能性について予備的な準備を行い、
- 予備のスペシャリストに必要なスキルを訓練するには、
- 必要なSLAパラメーターを満たした外部の請負業者に、障害点またはサービスの完全なユーザーサービスを転送します。
ただし、外部の請負業者では、すべてがそれほど明確ではありません。
2.外部請負業者とのSLA
外部の請負業者との協力の外部繁栄の背後に、ビジネスで必要な時間枠内でインシデントを解決できないことを隠している可能性があります。 必要なサービスのレベルについて外部プロバイダーが理解していないため、最初の問題では利便性と効率性が頭痛の種になります。
外部サプライヤのサービスレベルに関する既存の契約がビジネスに不十分な場合（または単に存在しない場合）、次のオプションが可能です。
- 既存の請負業者と条件の変更に同意します。 いくつかのランダムなSLAチェックに権利を割り当て、
- 請負業者を、標準SLAが要件を満たす請負業者に変更します。 そして再び実行を確認し、
- メインサービスで問題が発生した場合にバックアップサービスオペレーターを接続して、すぐに切り替えます。
- 請負業者が独占者である場合は、すべてを受け入れて変更しないでください。 この状況を会社の経営者にもたらし、それを会社と統合するには、
- このサービスを自分で整理します。
修復作業に携わる人や会社を決定したら、ユーザーサービスのサポートの時間を示すことができます。ユーザーサービスのサポートは、IT部門とビジネスの間のサービスレベル契約の枠組みで定めることができます。 彼らの回復の期限に同意することだけが残っており、このために議論する必要があります：
3.災害復旧に必要な予備を取得する
必要な備品の準備の存在は、サービスの運用復旧の可能性に直接影響します。 社内に物理サーバーが1つある場合、それが拒否されても、作業を復元することは何もありません（必要な予備の決定の詳細については、 前の記事を参照してください ）。 現時点で、修復作業に必要なすべての備品が会社にない場合は、次のオプションが可能です。
- ダウンタイムのコストが明らかにその価格を超える場合は、事前に機器を購入してください。 たとえば、冗長スイッチは、その取得期間中のダウンタイムが大幅に削減され、
- 「翌営業日交換」という条件がビジネスに受け入れられる場合、故障した機器の交換に関するサービス契約に署名します。
- ダウンタイムのコストが準備金要素に匹敵する場合、障害が発生した場合に必要な要素を取得するための資金の迅速な割り当てを調整するには、
- 機能不全や二次サービスの切断が発生した場合のシステムの品質低下を調整して、ビジネスに不可欠なシステムを起動するには、
- 品質パラメータがより低い、故障したサービスの一時的な立ち上げのための、より強力でない機器の購入のための資金の運用配分を調整すること。
原則として、この段階では、障害が発生した場合に特定のユーザーサービスを復元できる時間枠を既に指定できます。 条件が、すべての必要な埋蔵量が経営陣に満足していない場合でも、これは議論する機会です：
4.災害復旧を加速するプレハブ
これは、追加の監視およびバックアップシステム、またはホットスワップモードで構成され動作する追加のサーバーまたはネットワーク機器のいずれかです。 ユーザーサービスを少し速くローカライズおよび復元するために必要になる場合があります。
管理者に人、サービス契約、機器、ソフトウェアへの必要な投資をすべて承認したら、サポート時間に加えて、ユーザーサービスの復元期限に同意することができます。 しかし、これらの期限の達成を保証するには、もう少し小さなタッチが必要です。
5.日常業務の範囲
障害が発生した場合の回復を保証するには、緊急時に回復に必要なすべてのリソースを確保する必要があります。 このためには、その存在と正確さを常に監視する必要があります。 事前に合意された埋蔵量と資源に関する情報を使用して、必要な規制活動の正確なリストを作成できます。定期的な実施には、追加の技術専門家の関与が必要になる場合があります。 これは信頼性に必要な費用ですが、残念ながら、時には役に立たないこともあります。
6. SLAを超える状況。
回復のタイミングを予測することが困難であり、計画を超える状況があります。 これらは不可抗力の状況だけでなく、同じタイプの2つ以上の要素が同時に故障するイベントでもあり、その発生は確率理論によって許可されています。
多くの場合、ITインフラストラクチャとITスペシャリストが事故を迅速に排除できるように準備することは経済的に意味がありません。 場合によっては、ビジネスが発生した場合に備えて、ビジネス自体をアクションに備える方がはるかに安価で効率的です。 たとえば、コンピューターシステムの完全な障害が発生した場合の商品の手動クリアランスのための請求書フォームの準備、またはデータベースの最後の不可抗力バックアップの瞬間からビジネスオペレーションを復元するためのプライマリドキュメントの厳密な会計の編成は難しくありませんでした。 このような状況がビジネスに及ぼす悪影響を減らすための可能な技術的対策は以前に説明されています。
この段階では、調整段階は完了したと見なすことができます。わずかな手続きのみが残っています。
合意されたパラメーターを修正し、行動します
経営陣との交渉の結果は、紙に書き留めて、それに反映する必要があります。
- ユーザーサービスをサポートするためにビジネスで合意した時間、
- 障害が発生した場合の作業の復元の保証条件、
- お金（割り当てのタイミングを含む）および目標を達成するために必要な活動、
- 計画を超えた状況と、発生した場合の損害を軽減するための対策のリスト。
このドキュメントで修正された契約により、「ITインフラストラクチャが機能し、企業がそれに投資するふりをしている」状況から、企業がIT投資に応じてどのレベルのサービスを期待できるかを理解する状況に移行できます。
これにより、災害復旧計画は正常に完了したと見なすことができます。 確かに、時には、必要なすべての変更とそのコストを評価した後、既存のITインフラストラクチャを根本的に変更する方が安価であることが明らかになります。 しかし、これはまったく異なる話です。
頑張って！
イワン・コルマチェフ
IT部門会社
www.depit.ru