すべてが一度失敗します。 専用サーバーレンタルサービスのプロバイダーとして、さまざまなユーザーがサービスの機能の確保と復元に関連する問題をどのように解決するかを定期的に観察しています。 そして、私たちは悲しい結論を下しました：データと機器のバックアップのトピックについてどれだけ書かれ、述べられたにもかかわらず、いくつかのリソースはまだ十分に発達した回復戦略を持っていません。 何かが起こると、彼らは単に苦しみ始め、従業員をランダムに引っ張り、時にはすべての人とすべてを非難します。
「ビジネス継続性計画（ビジネス継続性および回復力計画とも呼ばれることもあります）は、組織が内部および外部の脅威にさらされる度合いを判断し、必要なハードウェアおよびソフトウェアツールを設定して、競争上の優位性とシステムの整合性を維持しながら、組織の正常な機能の効果的な対抗策と復元を確保します」 Elliot et al。1999）。
この用語は元々、より困難なケース-火災、自然災害、第三者の犯罪行為、および通常はハードディスクの故障よりもはるかに少ない頻度で発生するその他のケースに起因するオフィスまたはデータセンターの作業の中断のために導入されました。 British Standards Instituteは、ビジネス継続性管理のための特別な基準であるBS 25999を発行しました。しかし、それほど深くはしません。
何を失いますか？
ビジネスには特定のリスクが伴います。 そして、ビジネスが成功するためには、リスクはそれ自身で生きるものではなく、管理されなければなりません。 ネットワーク上に配置されたITプロジェクトおよびサービスの場合、プロジェクトの一時的な利用不能につながる特定の一連の特徴的なリスクがあり、それぞれが発生の確率、露出の期間、アクションの完全または部分的な平滑化/削除のコストなどのパラメーターによって数学的に特徴付けられます。
緊急の場合、「失われる」可能性のある3つの主要なパラメーターがあります：データ、時間、お金です。 評判の低下、利益の損失などの形で関連する問題 最終的には、この3つに減らすことができます。
パラメーター間には非常に微妙な関係があります。 たとえば、時間とデータを失う意思がないほど、容量と情報の確保に投資する必要があるお金が増えます。 復旧時間を維持しながらコストを削減しながら、データ損失が増加する可能性があります。 などなど。
あなたが猫の下を見る前でさえ、あなたがあなたのプロジェクトに許される最大のダウンタイムをすでに決定していることを望みます。 フォールトトレランス計画の用語では、このパラメーターは目標復旧時間（RTO）と呼ばれます。 これは、重大な結果を防ぐために、サービスまたはビジネスプロセスの通常の機能を復元する必要がある時間です。 当然、これはあなたにとって難しい結果であり、あなた自身で決定しなければなりません。
計画時に評価する必要がある2番目の重要なパラメーターは、目標復旧時点（RPO）です。 これは別の時間間隔です。 ITサービスのデータが失われる可能性がある最大許容時間を特徴付けます。 このパラメーターは、説明がやや困難です。 これは許容可能なデータ損失量であると言うことはできませんが、ゼロ次近似ではそのように考慮されます。 大まかに言えば、これは最後に利用可能なバックアップの開始から事故の時点までの時間制限です。
さらに2つのパラメーターがあります-現在の時間と回復ポイントですが、これらはシミュレーション中または事故の際に見つけることができます。
大企業では、ターゲットインジケーターはフォールトトレランスに関与する特別なアナリストによって決定され、特定のインジケーターのテクニカルサポートの専門家グループにタスクが転送されます。 次に、雨の日に保管、予約、保管する場所、量、量を決定します。
しかし、プロジェクトがあなたとあなたのプログラマーまたはシステム管理者で構成されている場合、これはそのような分析を完全に放棄し、これはあなたに関するものではないと言う理由はまったくありません。 私たちの実践では、パフォーマンスと回復を監視するための十分に考え抜かれた戦略が完全に欠如しているため、検索エンジンインデックスの沈下から金融商品やサービスの約半日アクセス不能に至るまで問題が発生したケースが複数ありました。 すべてのデータが1つのサーバーに保存され、現在のオンラインレプリケーションは実行されていません。
誰のせいですか？
まず第一に、プロジェクトマネージャーと彼の責任ある専門家。 プロバイダーは最大のアップタイムを確保するために全力を尽くしていますが、ほとんどすべてのオファー契約では、プロバイダーは何らかの理由で中断やデータ損失の責任を負わないことを書かれています（おそらく3番目のフォントで）。 酔っ払ったエンジニアが誤って間違ったサーバーをフォーマットした場合でも、高い確率で、誠実な謝罪と後悔よりも深刻なものに頼る必要はありません。 さらに、論文を思い出させてください：すべてが失敗します。 途切れることのないサービスとして位置付けられているものでさえも（Amazonクラウドの大規模なダウンタイムを思い出してください）。
データの安全性とサービスの有用性は、まずあなたに関係するはずです。 次の質問に答えなければならないのはあなたです。
どうする
できるだけ他の人の間違いから学びます。 最新の情報スペースにより、非常に多くの失敗の経験を分析し、プロジェクトの潜在的な弱点を評価できます。
作業の継続性を確保するための計画を作成する方法で最初に行う必要があるのは、幻想を取り除くことです。 ユーザーがバックアップを作成する必要性を無視しただけの場合がありました。 コントロールパネルの自動バックアップは正しく機能しませんでした。 彼はRAID1が彼を救うと本当に信じていました。 アレイの最初のディスクが大幅に劣化し、2番目のディスクがファイルテーブルに多くのエラーを抱えていたときの彼の驚きを想像してください。 最初のディスクをすばやく交換してアレイを再構築しようとしても、ご想像のとおり、何も良い結果にはなりませんでした。 私たちの管理者は、完全な障害の危機にonしているドライブを返さなければならず、そこからバイトごとに痛々しいほどデータを引き出す必要がありました。 ユーザーがバックアップを作成しなかった理由は、私たちを驚かせました。「6年間の仕事でこれを経験したことはありません。」 どうやら、管理者の生活の中で主要なデータ損失が早く発生するほど、彼の将来のプロジェクトにとっては良いことです。
第二に、潜在的な脅威、それらの可能性および暴露期間を特定します。 DDoSフィルタリングサービスに切り替えるにはどのくらい時間がかかりますか？ データセンターのディスク全体またはサーバーを交換するのにどれくらい時間がかかりますか？ 火災、洪水が発生した場合、またはプロバイダーが突然存在しなくなった場合、プロジェクトを別のデータセンターに展開するのにどれくらい時間がかかりますか？ それをどこに展開するか、新しい機器がどのくらいの期間提供されるかなど。 受信した数が予想されるRTOに適合しない場合は、インフラストラクチャが回復に役立つ他のプロバイダーを事前に探してください。 また、失われるデータの量を判断し、適切なバックアップスキームを選択します。
第三-カウント。 すでに書いたように、時間とデータの損失が少ないほど、費用がかかります。 必要な継続性指標を確保するために、1回限りの費用と定期的な費用を評価します。 受け取った金額を支払う準備はできていますか？ そうでない場合、データは以前考えていたほど重要ではありません。 再評価しますが、回復予算を念頭に置いてください。
4番目-実装します。 ただ数えて評価するだけでは十分ではありません。 実際に必要な対策を適用する必要があります。 必要なバックアップ機器とサービスを注文し、必要な契約に署名し、監視をオンにします。 テキストサービスで、どのサービスのどのケースに連絡するか、どのような手順を行うかをテキストドキュメントに書き留めてください。 特定の障害を一度シミュレートすることもできます。 明確で一貫性のある指示が存在するため、何かが起こったときに感謝します。 所定の回復計画を立てることで、多くの時間と多くの神経を節約できます。 予想外のカテゴリーからの状況は、単に緊急のカテゴリーに入ります。 盲目の子猫のように暗闇をさまよいません。
私たちの生活の中で何かの価値は、それを保存するためにどれだけ喜んで与えるかによって決まります。 あなたの仕事の結果に本当に感謝しているなら、彼らの安全の世話をすることを忘れないでください。 誰が、そうでないなら？