我们有一个生产SQL Server数据库服务器将事务日志备份传送到两台备用服务器。 灾难恢复计划已经完成：我们有一个很好的文档化程序，并且经过培训的人员可以将备用服务器投入生产，并以最less的停机时间启动复制，启用作业等。
获得讨论的问题不是应急计划本身，而是决定将备用服务器投入生产和丢失，最坏的情况是12分钟的信息（事务日志备份每10分钟运行一次，速度非常快复制到其他服务器）。
这个决定可能是困难的，因为我们可能会浪费时间来确定问题。 另一方面，这个问题可能很容易解决，我们可以将服务器投入生产而不使用其他服务器。
我们知道，在系统出现故障的情况下，情况会变得非常紧张，我们认为在这种情况下，最好有一个标准的程序和最less的决定。
所以，我们有一个困境。 在主服务器出现问题时更换服务器，还是更好地尝试识别并解决主服务器中的问题，更好吗？ 你们怎么看待这个？
您可能想要使用的框架是两个时间窗口，用于在问题发生时决定这个框架。 第一个时间窗口的结束将是一个软限制，第二个将是什么时候切换的硬限制。
软限制将是第一个切入点。 如果你一直在试图解决这个问题，但是距离开始的时候还没有接近解决问题的时候，你就可以在软限制下进行切换。 如果你认为你已经接近于在软限制下解决问题，那么你会一直持续到硬限制。 因此，软限制将是5分钟，而硬限制可能是从尝试解决问题开始的8分钟。 在硬性限制下，你切换什么都没有。
你使用的窗户的长度将不得不自己决定。 你还必须弄清楚，如果你想包括在你真正开始看问题之前花费的时间。
你当然也可以把它做出来，做你认为当时最好的东西 – 很可能没有计划每一个细节。
这全是关于成本的。 尝试解决X分钟/小时问题需要花费多less钱？ 是否less于切换到备份服务器的成本，丢失了一些date，并最终返回到主生产服务器？
一旦尝试修复的成本超过了切换的成本，就做出决定，切换。 在你处理成本之前，你怎么定义一个“灾难”？