我们有一台生产 SQL Server 数据库服务器，将事务日志备份发送到两台备用服务器。灾难恢复计划已经完成：我们有一个记录良好的程序，并且训练有素的人员能够将备用服务器投入生产，启动复制、启用作业等，同时将停机时间降至最低。
正在讨论的问题不是应急计划本身，而是将备用服务器投入生产的决定，在最坏的情况下，将丢失 12 分钟的信息（事务日志备份每 10 分钟运行一次，并且可以非常快速地复制到其他服务器）。
做出决定可能很困难，因为我们可能会浪费时间试图找出问题所在。另一方面，问题可能很容易解决，我们可以将服务器重新投入生产，而无需使用其他服务器。
我们理解，一旦系统出现故障，情况就会变得非常紧张，我们认为，在这种情况下，最好有一个标准程序和最低限度的决策。
所以，我们陷入了两难境地。当主服务器出现问题时，是直接更换服务器更好，还是尝试在主服务器中找出并解决问题更好？你们对此有什么看法？
答案1
您可能想要使用的框架是两个时间窗口，用于在出现问题时做出决定。第一个时间窗口的结束将是软限制，第二个将是切换时间的硬限制。
软限制将是第一个切入点。如果您一直在尝试解决问题，但距离解决问题还差得远，那么您可以在软限制时切换。如果您认为在软限制下您已经接近解决问题，那么您将继续进行直到硬限制。因此，软限制可能是 5 分钟，而硬限制可能是从尝试解决问题开始的 8 分钟。在硬限制下，无论如何您都可以切换。
您必须自行决定所用窗口的长度。您还必须确定是否要包括实际开始查看问题之前所花费的时间。
当然，您也可以随机应变，做您认为当时最好的事情——不必计划好每一个细节，这很可能是可以的。
答案2
一切都与成本有关。尝试修复问题需要花费 X 分钟/小时，成本是多少？这是否低于切换到备份服务器、丢失一些数据并最终返回主生产服务器的成本？
一旦尝试修复的成本超过更换的成本，就会做出更换的决定。除非你控制了成本，否则你如何定义“灾难”？