Disaster-Recovery
如果主伺服器出現故障，何時將應急計劃付諸實施？
我們有一個生產 SQL Server 數據庫伺服器將事務日誌備份傳送到兩個備用伺服器。災難恢復計劃已經完成：我們有完善的文件記錄程序和受過培訓的人員，可以將備用伺服器投入生產、啟動複製、啟用作業等，同時將停機時間降至最低。
正在討論的問題不是應急計劃本身，而是將備用伺服器投入生產並失去，在最壞的情況下，失去 12 分鐘的資訊（事務日誌備份每 10 分鐘執行一次，並且速度非常快）複製到其他伺服器）。
這個決定可能很困難，因為我們可能會浪費時間試圖找出問題。另一方面，問題可能很容易解決，我們可以在不使用其他伺服器的情況下將伺服器重新投入生產。
我們理解如果系統出現故障，情況會變得非常緊張，我們認為在這些情況下，最好有一個標準的程序和最少的決定。
所以，我們進退兩難。當主伺服器出現問題時更換伺服器更好，還是嘗試辨識和解決主伺服器中的問題更好？對此你們怎麼看？
您可能想要使用的框架是兩個時間視窗，用於在問題發生時決定這一點。第一個時間視窗的結束將是一個軟限制，第二個將是何時切換的硬限制。
軟限制將是第一個切入點。如果您一直在嘗試解決問題，但距離解決問題的距離遠不及開始時的距離，那麼您將在軟限制處切換。如果您認為您正在接近解決軟限制的問題，那麼您將繼續前進直到硬限制。例如，軟限制是 5 分鐘，硬限制可能是從嘗試解決問題開始的 8 分鐘。在硬限制下，無論如何你都會切換。
您使用的窗戶的長度必須自己決定。您還必須弄清楚是否要包括在實際開始查看問題之前所花費的時間。
當然，你也可以隨心所欲地做你當時認為最好的事情——不計劃每一個最後的小細節可能是可以的。