災害復旧計画の開発のベストプラクティスまたはリソース？
私は、古くてやや一方的な災害復旧計画の更新に関するプロジェクトを主導する任務を負っています。今のところ、DRのIT側を整理することだけを検討しています。彼らが最後にこれを行ったとき、彼らは単一の災害（データセンターが浸水した）を作り、他のすべての災害タイプを除外するように計画することによって範囲を設定しました。もっと丸みを帯びたアプローチを取りたいと思います。私はこれが解決された問題であることを知っています、他の組織はDR計画を書きました。
私たちの計画は、IT DR計画を進めて、「これがITのDR計画に必要なものです。これは、大学の他の部門が行っていることと一致しますか？サービスの優先順位を復元しましたか？変更したいですか？」私たちは計画の残りの部分が何であるかについてかなり良い考えを持っており、これがうまくいくことを期待しています。
私が探しているのは、DR計画のスコープを設定する方法と、どのような質問について考える必要があるかについてのガイダンスです。 DR計画の開発に関連するお気に入りのリソース、書籍、トレーニングはありますか？
優れた情報源は Disaster Recovery Journal （ about ）です。
利用可能なコミュニティリソースには、 Generally Accepted Practices（GAP） ドキュメントの現在のドラフトが含まれます。これは、堅実な事業継続計画とプロセスを構成するプロセスと成果物の優れた概要を提供します。また、いくつかの ホワイトペーパー さまざまなDR/BCトピックをカバーしています。
このプロセスは困難に思えますが、最終的に行きたい場所の概要を体系的に（DRJ GAPドキュメントのように）アプローチすれば、投資時間を最適化し、最終製品の価値を最大化することができます。
彼らの季刊誌も面白くて有益だと思います（ subscribe ）。
緊急連絡先名簿があることを確認してください。別名リコール名簿
木のように見え、誰が誰に連絡するかを示す必要があります。ブランチの終わりに、最後の人が最初の人に電話して、連絡が取れなかった人を報告する必要があります。
（これはHRを通じて調整でき、あらゆる種類の災害に使用できます）
DRの場合、基本的なことはRTO（目標復旧時間）とRPO（目標復旧時点）です。これらは、「復旧に費やすのに許容できる時間と、失う余裕のあるデータの量」と大まかに解釈されます。理想的な世界では、答えは「なし」ですが、DRシナリオは例外的な状況です。これらは実際には顧客が主導する必要がありますが、ITの観点から始めているため、最善の推測を行うことができますが、必要に応じて上下に調整する準備をしてください。合理的に得ることができる限り「なしとなし」に近いことを目指すことは良いことですが、収穫逓減のポイントがいつ入るかを認識できる必要があります。
これらの2つの要因は、1年の時期によって異なり、システムによって異なる場合があります。
私はよりバランスの取れたアプローチが好きです。 DRシナリオにつながる可能性のあるイベントをリストアップするのは魅力的ですが、これらは実際にはリスク分析/軽減の演習に属します。 DRの場合、インシデントはすでに発生しており、その詳細はあまり関連性がありません（DR施設の可用性に影響を与えるという点を除いて）。サーバーを紛失した場合は、落雷に見舞われたか、誤ってフォーマットされたかなどに関係なく、サーバーを元に戻す必要があります。災害の規模と広がりに焦点を当てたアプローチは、結果をもたらす可能性が高くなります。
顧客が関与することに消極的であることがわかった場合に顧客に使用する1つのアプローチは、IT以外の角度からDRの質問をすることです。すべての紙のファイルが炎上した場合、彼らの計画は何かを尋ねることは、ここでの例です。これは、彼らがより広範なDRに関与するのに役立ち、あなた自身の計画に役立つ情報を提供することができます。
最後に、計画を定期的にテストすることは成功に不可欠です。紙の上では見栄えがするが、その目的を達成できない美しいDR計画を立てることは良くありません。
アイデアを追加すると、全員が独自のアイデアを追加したら、この投稿から素敵なwikiを作成できます。従うべきことがたくさんあることは理解していますが、回復に関しては特定の優先事項を持っている人もいます。まず、私のものです：
ネットワークのオフライン/リモートドキュメントがあることを確認してください
実際、最初のステップとして、「単一インシデント」開発モデルは良い考えです。その理由の1つは、計画の実行をより現実的で焦点を絞ったものにすることです。ずっと洪水の計画を立ててください。次に、別のインシデント（たとえば、長期の停電）を想定し、その計画をそれに適用して、何が壊れているかを修正します。数回繰り返した後、計画は比較的堅牢になるはずです。
いくつかの考え...-利用できない人々を説明するようにしてください。洪水が発生した場合、関連するすべてのスタッフが対応可能であるとは限りません。誰かが休暇中、怪我をしている、または家族と接している可能性があります。
-コミュニケーションの問題と弱点を計画します。複数の番号と複数のモードがあります。
-DR計画には一連のコマンドが必要です。誰が決定を下すかを知ることは重要です。
-計画は、オフサイトやオフグリッドを含め、広く配布する必要があります。災害時にアクセス可能である必要があります！
私が働いている場所では、過去2年間のそれぞれで大規模なDRテストの実行に携わってきました。 「現実的な」状況でサービス、人、プロセスをテストすることが有用であることがわかりました。あなたがそれらが役に立つと思うことを願って、学んだいくつかの教訓（おそらく明白です）：
- テストされていないサービスは、DRドキュメントに記述されているにもかかわらず、通常、暗黙の、大惨事を引き起こす依存関係があります。現実的なテストでそれらを振り払うことは、DR準備プロセスの有用で測定可能な出力です。
- テストされていない人々は、自分のシステムは大丈夫だと思う傾向があり、災害時に「何をすべきかを知っている」でしょう。それらを振るp現実的なテストで1つか2つは素晴らしいです。
- テストされていないプロセスは、実際の緊急事態では急速に崩壊します。特に、複雑なエスカレーションプロセスは、主に上級管理職の休憩を壮観な方法で通知することに重点を置いていました。運用スタッフやその他の対応者のニーズに焦点を合わせた軽量プロセス、展開中の緊急事態に関する中心的な情報源、責任の明示的な移転、および「日常の」緊急対応手順が最も効果的です。
私が得ているのは、DR計画プロセスに関するすべてを理論的にしないようにする必要があるということだと思います。実際に物事を壊して、組織の準備に関する確かなデータを取得する許可を求めてください。もちろん、それには経営陣からの真剣なサポートが必要になりますが、最悪の事態に備えて実際に数日間リハーサルを行うことは、ビジネスにとって素晴らしい焦点となる可能性があります。
シアン
British Standards Institute （BSi）には、継続性管理と災害復旧に焦点を当てたいくつかの標準があります。
- BS 25999-1：2006 事業継続管理、パート1：行動規範
- BS 25999-2：2007 事業継続管理。仕様
- BS 25777：2008 情報通信技術の継続性管理。行動規範
当たり前のように思えるかもしれませんが、上記のオフサイトのドキュメントに沿って、オフサイト（できればリージョン外）のバックアップがあることを確認してください。これは、オンラインストレージサービスまたはテープを持って行く場所である可能性があります。
私は毎年自然災害が少ない地域から来ているので、地域外が望ましいと言いますが、自然災害が発生した場合は、大規模な破壊（地震、火山）を伴う地域規模です。銀行が液体の熱いマグマ（/Dr。EvilVoice）にさらされるまで、銀行の貸金庫にバックアップを置いておくことはすべて良いことです。
私が読んだことのあるものは、大きなサイトがヒットしたときのためにホットサイトを維持するコストを分担するエージェンシーです。彼らは、仮想化などを使用してホットサイトに不可欠な両社のミッションを復元する計画を制定し、その後、すべての光が点滅していることを確認するレベルでスタッフを共有します。ちょっとした考え。
ローラ、
これは、DRの基本を説明するSQLServerPediaからのリンクです。
http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/
「事業継続」もお読みください