メインサーバーに障害が発生した場合に緊急時対応計画を実行するのはいつですか？
トランザクションログのバックアップを2台のスタンバイサーバーに出荷する本番SQLServerデータベースサーバーがあります。ディザスタリカバリ計画はすでに完了しています。十分に文書化された手順と、スタンバイサーバーを本番環境に移行し、レプリケーションを開始し、ジョブを有効にするなどのトレーニングを受けたスタッフが、最小限のダウンタイムで対応します。
議論されている問題は、緊急時対応計画自体ではなく、スタンバイサーバーを本番環境に移行し、最悪の場合、12分の情報を失うという決定です（トランザクションログのバックアップは10分ごとに実行され、非常に高速です）他のサーバーにコピーされます）。
問題を特定するのに時間を浪費する可能性があるため、決定は難しい場合があります。一方、問題は簡単に解決でき、他のサーバーを使用せずにサーバーを本番環境に戻すことができます。
システム障害が発生した場合、状況は非常にストレスになることを理解しており、このような状況では、標準的な手順と最小限の決定を行う方がよいと考えています。
したがって、ジレンマがあります。メインサーバーに問題が発生したときにサーバーを変更する方がよいのでしょうか、それともメインサーバーの問題を特定して解決する方がよいのでしょうか。あなたたちはこれについてどう思いますか？
使用する可能性のあるフレームワークは、問題が発生したときにこれを決定するための2つの時間枠です。最初の時間枠の終わりはソフト制限になり、2番目の時間枠はいつ切り替えるかというハード制限になります。
ソフトリミットはカットオーバーの最初のポイントになります。問題を解決しようとしていたが、開始したときよりも解決に近づいていない場合は、ソフト制限で切り替えます。ソフト制限で問題の解決に近づいていると思われる場合は、ハード制限まで続行します。したがって、ソフト制限はたとえば5分になり、ハード制限は問題の修正を試み始めてからおそらく8分になります。ハードリミットでは、何の問題も切り替えません。
使用するウィンドウの長さは、自分で決める必要があります。また、実際に問題の調査を開始するまでにかかる時間を含めるかどうかを判断する必要があります。
もちろん、それを翼にして、その時点で最善だと思うことを実行することもできます。最後の細部まで計画しなくても大丈夫です。
コストがすべてです。 X分/時間で問題を解決しようとするとどのくらいの費用がかかりますか？バックアップサーバーに切り替えて日付を失い、最終的にメインの本番サーバーに戻るコストよりも少ないですか？
修正を試みるコストが切り替えのコストを超えると、決定が下され、切り替えます。コストを把握するまで、「災害」をどのように定義できますか？