至少可以说，冗余方面的行业标准相当高。为了说明我的观点，这是我当前的设置（我正在运行金融服务）。
每台服务器都有一个 RAID 阵列，以防一个硬盘出现问题
....如果服务器出现问题，它会被另一台相同的备用服务器镜像
...并且两台服务器不能同时关闭，因为我有冗余电源和冗余网络连接等
...而且我的托管中心本身与两个不同的能源供应商有双重电力连接，以及冗余网络连接和冗余厕所，以防两个保安（抱歉，四个）需要同时使用它
...万一出现问题（核弹？想不出别的），我在另一个国家有另一个相同的托管设施，设置完全相同。
- 如果下降 = 非常高的声誉损失成本
- 我的设置出现硬件故障的可能性：<<1%
- 较少偏执设置的硬件故障概率：<<1% ASWELL
- 我们的应用程序代码中出现软件故障的概率：>>1%（如果您的软件从未因为错误而停机，那么我建议您仔细检查您的报告/监控系统是否没有停机。甚至 SQLServer - 可以说是由聪明的开发和测试的具有强大方法论的人-有时会失败）
换句话说，我觉得我可以在我母亲的公寓里放置一台便宜的笔记本电脑，而人为/软件问题仍然是我面临的更高风险。
当然，还有其他一些事情需要考虑，例如：
- 可扩展性
- 数据安全
- 客户期望您符合行业标准
但是，在两个不同的数据中心托管两台服务器（没有额外的备用服务器，除了我的托管设施提供的设备之外，也没有双倍的网络设备）将为我提供我需要的可扩展性和物理安全性。
我觉得我们已经到了冗余只是一种沟通工具的地步。老实说，99.999% 的正常运行时间和 99.9999% 的正常运行时间之间有什么区别，当你知道你会因为软件错误而停机 1% 的时候？
你把你的冗余疯狂推到了多远？
当冗余的成本高于停机的成本，而曾经损坏的东西正在被替换时，那就是冗余。
这一切都与风险管理有关。即使是所有东西的 2 倍，您仍然会因不可预见的问题而停机。
例如。我的托管服务提供商与上游互联网有双重冗余连接。因此，在他们的一根电缆被一些建筑承包商切断的那一天，他们的上游供应商将另一根电缆停机进行维护。不仅如此，因为所有的电话都是 SIP，没有人可以打电话说没有连接，而且他们很久没有意识到有问题。
现在这是百万分之一的错误，并且可以通过增加更多的冗余或管理监督来防止它......但它发生的机会是如此渺茫，你永远不会想到会有成为一个问题，因此不值得为防止它发生而付出代价。
另一个例子：我们在救护车 999 控制室实现了 SQL Server 镜像，镜像的 DB 应该意味着没有问题。.. 除了我们在 SQLServer 中发现了一个错误，它冻结了主 DB 并阻止它故障转移到镜像。因此，尽管我们尽了最大努力确保持续正常运行，但在 DB 问题得到解决时，我们仍然不得不转移到手动接听电话。在这种情况下，我们有我们可以合理实施的最佳解决方案，以及一个备用计划，以防“最佳解决方案”失败。试图确保“最佳解决方案”的总体 100% 正常运行时间保证根本不具有成本效益，而且可能仍然无法为我们提供 100% 的保证。
同样，另一个故事：我们拥有一个覆盖欧洲的复制 Active Directory 服务器网络，在任何国家/地区发生故障时都有备用。因此，当某个管理员不小心删除了太多记录时，解决方案是停止服务器并让人们沿下一个国家/地区进行身份验证。只有复制首先到达那里，并且已删除的记录也开始从其他服务器中删除......花了一周时间，在 Microsoft 专家的帮助下完全解决了问题。
所以 - 这一切都取决于风险/成本。你决定你愿意承担多少风险，并为此付出代价。它很快就达到了降低风险进一步成本过高的地步，此时您应该找到替代策略来应对停机时间。
你在做我做的事——我不认为这很疯狂。
正如其他人所指出的：这只是一个商业案例。所需的冗余级别直接取决于您的客户/用户的要求和期望。如果他们为 5-9 秒的正常运行时间付费并期望正常运行时间，那么您需要提供。如果他们不这样做，那么您应该将其作为业务战略来解决。
简单的回答：这必须通过程序来解决。不是通过物理冗余。
如果人为错误导致您停机，那么您需要加强在人为干预时执行的错误检查。这可能意味着所有平台修改都作为变更请求出票并由辅助人员签署。或者这些变更请求包含有关要执行的任务的更多详细信息，并且不能采取任何偏差。或者，员工只是需要更多关于如何在生产环境中谨慎工作的培训。
如果软件错误导致您停机，那么您可能需要加强您的分段程序。确保您有一个良好的暂存环境，该环境很可能完全虚拟化以降低硬件要求，但仍尽可能与您的生产环境匹配。任何软件更改都应在暂存环境中经过指定时间段的测试，然后才能进行一般部署。
每个设计和架构都应该是需求驱动的。良好的系统工程要求定义设计的约束并实施满足该约束的解决方案。如果您的客户有一个要求 .99999 的 SLA，那么您的 N+N 冗余解决方案应该考虑所有可能发生故障的 LRU（线路可更换单元）。RAID、PS 和 COOP 计划都应该考虑到这一点。此外，您与供应商的 SLA 应该是 4 小时响应时间类型或考虑大量现场备件。
可用性（Ao from here out）就是那个研究。如果你做所有这些事情是因为这似乎是正确的事情，那么你就是在浪费你的时间和你的客户的钱。如果按下，每个人都会想要 5x9，但很少有人买得起。从成本的角度诚实地讨论数据和系统的可用性。
迄今为止提出的问题和答案并未考虑要求。该链假设硬件和策略的 N+N 冗余是关键。相反，我会说让您的客户和 SLA 的要求来驱动设计。也许你妈妈的公寓和你的旧笔记本电脑就足够了。
我们这些极客有时会去寻找一个问题，以便我们可以实施一个很酷的解决方案。
你的声望要花多少钱？如果您的软件出现故障，您会尽最大努力保护客户的数据，提供最佳的硬件/集群冗余。如果您达到了最佳状态，那么是时候为您的变更/质量保证管理投入更多预算了。
如果您有适当的预算并且您的托管对您很重要（就像对金融机构一样），您应该继续前进。我注意到你没有谈论你的备份......也许可以在那里进行一些改进？我从未见过任何如此棒的设置，我觉得它不需要额外的工作（有时这只是修复程序）。
我会用输入进行计算：
然后您可以计算财务风险：
潜在中断成本 = 每小时中断成本 * 恢复时间 * 中断概率
然后简单地权衡冗余成本与该成本。
我希望我不必提醒您有几种类型的中断，例如：
磁盘故障（很可能，非常致命，但冗余很便宜）
电源故障
失败的服务器
网络连接失败
上行失败...
无论如何，首先进行风险分析，因为它为您提供了基线。
数据中心发生火灾可能会将其关闭（去年不是发生在一个共享 DC 上吗？）但是中心内部存在大量冗余。
两个 DC 可以提供帮助，但即使在这里，单个事件也可以将它们都带走。例如，在美国的龙卷风盟友中，两个足够接近暗光纤的 DC 很容易被来自同一个超级细胞系统的龙卷风击中。这种风险可以通过仔细的相对地理定位来减轻（从检查历史风暴轨迹开始），但不能完全消除。
正如其他人所说，这完全取决于停电成本与冗余成本，而且许多停电成本是无形的（失去客户信任）。
很高兴你有预算做正确的事。
同时，您的软件更新程序现在可能需要一些工作。