至少可以说，冗余方面的行业标准相当高。为了说明我的观点，以下是我当前的设置（我经营一家金融服务公司）。
每台服务器都有一个 RAID 阵列，以防某个硬盘出现故障
.... 如果服务器出现问题，则由另一台备用的相同服务器进行镜像
... 并且两台服务器不能同时停机，因为我有冗余电源、冗余网络连接等
... 我的托管中心本身有双电源连接到两个不同的能源供应商，还有冗余的网络连接和冗余的厕所，以防两名保安（抱歉，是四名）需要同时使用
... 无论如何，如果出现问题（核弹？想不出其他什么了），我在另一个国家还有另一个完全相同的托管设施，设置也完全相同。
- 宕机造成的声誉损失成本非常高
- 我的设置发生硬件故障的概率：<<1%
- 使用不太复杂的设置时发生硬件故障的概率：<<1%艾斯威尔
- 我们的应用程序代码出现软件故障的概率：>>1％（如果您的软件从未因错误而宕机，那么我建议您仔细检查您的报告/监控系统是否宕机。即使是 SQLServer - 可以说是由聪明的人使用强大的方法开发和测试的 - 有时也会宕机）
换句话说，我觉得我可以在妈妈的公寓里放一台便宜的笔记本电脑，但人为/软件问题仍然是我面临的更高风险。
当然，还有其他事项需要考虑，例如：
- 可扩展性
- 数据安全
- 客户期望您符合行业标准
但是，在两个不同的数据中心托管两台服务器（没有额外的备用服务器，除了我的托管设施提供的网络设备之外也没有双倍的网络设备）可以为我提供所需的可扩展性和物理安全性。
我觉得我们已经到了冗余只是一种沟通工具的地步。说实话，当你知道由于软件错误会导致 1% 的时间停机时，99.999% 的正常运行时间和 99.9999% 的正常运行时间有什么区别？
你推多远你的冗余疯狂？
答案1
当冗余成本高于更换损坏部件时停机成本时，冗余就太多了。
答案2
一切都与风险管理有关。即使一切都是 2 倍，你仍然可能因为无法预见的问题而导致停机。
例如。我的托管服务提供商与上游互联网有双重冗余连接。因此，当他们的一条电缆被一些建筑承包商切断的那天，他们的上游提供商就将另一条电缆拆下进行维护。不仅如此，由于所有电话都是 SIP，所以没有人可以打电话说没有连接，他们很长时间都没有意识到有问题。
现在，这是百万分之一的失误，可以通过增加更多的冗余层或管理监督来避免......但发生这种情况的可能性非常小，你永远不会想到会出现问题，因此不值得花费成本去防止它发生。
另一个例子：我们在救护车 999 控制室实施了 SQL Server 镜像，镜像数据库本应意味着不会出现问题……但我们在 SQLServer 中发现了一个错误，该错误冻结了主数据库并阻止其故障转移到镜像。因此，尽管我们尽了最大努力确保持续正常运行，但在解决数据库问题期间，我们仍然必须转为手动接听电话。在这种情况下，我们有可以合理实施的最佳解决方案，以及在“最佳解决方案”失败的情况下的后备计划。试图确保“最佳解决方案”的 100% 正常运行时间保证根本不具有成本效益，而且可能仍然无法为我们提供 100% 的保证。
再说一遍：我们有一个覆盖整个欧洲的复制 Active Directory 服务器网络，如果任何一个国家出现故障，都可以进行回退。因此，当某个管理员意外删除了过多的记录时，解决方案是停止服务器，让人们根据下一个国家进行身份验证。只有复制首先到达那里，然后删除的记录也开始从其他服务器中删除......花了一周时间，在 Microsoft 专家的帮助下，问题才得到彻底解决。
所以 - 一切都取决于风险/成本。你决定愿意承担多少风险，并为此付出代价。很快就会达到一个点，即进一步降低风险的成本太高，此时你应该找到其他策略来应对停机时间什么时候它发生了。
答案3
你正在做我所做的事情 —— 我根本不认为这疯狂。
答案4
每种设计和架构都应以需求为导向。良好的系统工程要求定义设计的约束并实施满足该约束的解决方案。如果您与客户签订的 SLA 要求为 0.99999，那么您的 N+N 冗余解决方案应考虑所有可能发生故障的 LRU（线路可更换单元）。RAID、PS 和 COOP 规划都应考虑到这一点。此外，您与供应商签订的 SLA 应为 4 小时响应时间类型或考虑现场大量备件。
可用性（从现在开始为 Ao）就是这项研究。如果您做所有这些事情是因为这看起来是正确的事情，那么您就是在浪费时间和客户的金钱。如果迫不得已，每个人都会想要 5x9，但很少有人能负担得起。从成本的角度诚实地讨论数据和系统的可用性。
到目前为止提出的问题和答案都没有考虑到需求。该链假设硬件和策略的 N+N 冗余是关键。相反，我想说让客户的需求和 SLA 来驱动设计。也许你妈妈的公寓和你的旧笔记本电脑就足够了。
我们这些极客有时会去寻找问题只是为了能够实施一个很酷的解决方案。