至less从冗余来看，行业标准是相当高的。 为了说明我的观点，这里是我目前的设置（我正在运行一个金融服务）。
每个服务器都有一个RAIDarrays，以防万一某个硬盘出现问题
….如果服务器出现问题，则由另一台备用的相同服务器进行镜像
…而且两台服务器不能同时关机，因为我有冗余的电源和冗余的networking连接等
…和我的托pipe中心本身有两个电力连接到两个不同的能源供应商，冗余的networking连接和冗余的厕所，以防万一两个安全卫士（对不起，四）需要在同一时间使用
…万一出了什么问题（一个核武器？不能想到其他任何东西），我有另一个完全相同的设置在另一个国家相同的托pipe设施。
换句话说，我觉得我可以在我母亲的公寓里安置一台便宜的笔记本电脑，而人力/软件问题仍然是我的风险较高。
当然，还有其他的事情要考虑，比如：
但是，将两台服务器托pipe在两个不同的数据中心（没有额外的备用服务器，除了我的托pipe设施提供的networking设备之外，还要增加一倍的networking设备），将为我提供所需的可扩展性和物理安全性。
我觉得我们正在达到一个冗余只是一个沟通工具的地步。 老实说，99.999％的正常运行时间和99.9999％的正常运行时间之间的差别是什么，当你知道由于软件错误你会下降1％的时间？
你多大程度上把你的冗余疯狂？
当冗余成本更高时，被破坏的成本被取代，这是很多的冗余。
它的一切都靠风险pipe理。 即使是2倍的东西，由于未解决的问题，您仍然可能会宕机。
例如。 我的托pipe服务提供商具有到上游互联网的双重冗余连接。 所以，当他们的一条电缆被某些build筑承包商切断的时候，他们的上游供应商就把另一个电缆拆下来进行维护。 不仅如此，因为所有的电话都是SIP，所以没有人可以打电话说没有连接，他们也没有意识到这个问题已经存在了很长时间了。
现在这个数字是百万分之一，而且可能是因为增加了更多层次的冗余或pipe理疏忽而被阻止了……但是它发生的机会非常渺茫，你永远不会想到成为一个问题，所以它是不值得的，以防止它发生的成本。
另一个例子：我们在救护车999控制室实施了SQL Server镜像，镜像数据库应该意味着没有任何问题，除了我们在SQLServer中发现一个冻结主数据库的错误，并阻止它故障转移到镜像。 所以，虽然我们尽了所能确保连续的正常运行时间，但在数据库问题得到解决的同时，我们仍然不得不转移到手动调用。 在这种情况下，我们有最好的解决scheme，我们可以合理执行，并在“最佳解决scheme”失败的情况下，一个后备计划。 试图确保为“最佳解决scheme”提供100％的正常运行时间保证根本不会有成本效益，并且可能仍然不会给我们100％的保证。
另外，还有另一个故事：我们有一个复制的Active Directory服务器的欧洲networking，在任何国家出现故障的情况下都会回退。 所以当某个pipe理员意外删除了一些太多的logging时，解决方法就是停止服务器，让人们一起对下一个国家进行身份validation。 只有复制到达那里，被删除的logging也开始从其他服务器上删除….花了一个星期，与微软专家的帮助下，事情得到解决完全。
所以 – 所有的风险/成本。 你决定你愿意承担多less风险，并付出代价。 它很快就会降低风险，进一步花费太多，在这一点上，您应该find其他策略来应对停机时间。
你正在做我所做的 – 我不认为这是疯了。
…万一出了什么问题（一个核武器？不能想到其他任何东西），我有另一个完全相同的设置在另一个国家相同的托pipe设施。
正如其他人所指出的：这只是一个商业案例。 所需的冗余级别直接取决于客户/用户的要求和期望。 如果他们支付并预期在五点半左右的正常运行时间，那么你需要提供。 如果他们不这样做，那么你应该把它作为一个商业战略。
但是，如果我试图猜测另一个问题（软件或人类）的概率，我认为这比它高出几个数量级。
简单的答案：这必须通过程序解决。 不是通过物理冗余。
如果人为错误导致您停机，那么您需要加强每当人类介入时执行的错误检查。 这可能意味着所有的平台修改都会根据更改请求进行修改并由中间人签名。 或者这些变更请求包含更多关于要执行的任务的细节，并且不会有任何偏差。 或者工作人员只需要在生产环境中进行更多关于如何照顾工作的培训。
如果软件错误导致你停机，那么也许你需要加强你的分期程序。 确保您有一个良好的临时环境，可能完全虚拟化以降低硬件需求，但仍然尽可能与您的生产环境相匹配。 任何软件更改应在临时环境中进行一段指定时间的testing，然后才能进行常规部署。
每个devise和架构都应该以需求为导向。 良好的系统工程需要定义devise的约束条件，并实现一个满足这个要求的解决scheme。 如果您的客户的SLA要求.99999，那么您的N + N冗余解决scheme应考虑到可能会出现故障的所有LRU（线路可更换部件）。 RAID，PS和COOP计划都应该考虑到这一点。 另外，与供应商的SLA应该是4小时的响应时间types，或者是现场大量的备件。
可用性（从这里出来）是这项研究。 如果你正在做所有这些事情，因为它看起来是正确的做法，那么你正在浪费你的时间和你的客户的钱。 如果按下，每个人都希望5×9的，但很less能负担得起。 从成本angular度对数据和系统的可用性进行诚实的讨论。
迄今为止提出的问题和答案没有考虑到这些要求。 该链假定N + N冗余与硬件和策略是关键。 相反，我会说让你的客户和SLA的要求驱动devise。 也许你妈妈的单位和你的旧笔记本电脑就足够了。
我们极客有时会去找一个问题，所以我们可以实施一个很酷的解决scheme。
你的声誉多less钱？ 如果您的软件发生故障，您尽最大努力保护客户的数据，提供最佳的硬件/集群冗余。 如果你达到了最佳状态，那么是时候把更多的预算放在你的变更/质量pipe理上了。
如果你有适当的预算，你的托pipe对你来说很重要（就像金融机构那样），你应该继续。 我注意到你不谈论你的备份…也许可以在那里做一些改进？ 我从来没有见过任何设置是如此真棒，我觉得它不需要额外的工作（有时这只是修复程序）。
我会做input的计算：
那么你可以计算财务风险：
potential_outage_cost = hourly_outage_cost * recovery_time * outage_probability
然后简单地将冗余成本与这个成本进行加权。
我希望我不必提醒您，有几种types的中断，如：
失败的磁盘（很可能，非常致命，但冗余便宜）
供电失败
服务器故障
networking连接失败
失败的上行链路…
无论如何，首先要做风险分析，因为它给了你基线。
…万一出了什么事情（一个核武器？不能想到别的东西），
数据中心的火灾可能会导致数据中心closures（去年没有发生过一个共享数据中心？），但是中心内部存在很多冗余。
两个区议会可以提供帮助，但即使在这里，单一的事件也可能把两者都带走。 例如，在美国的龙卷风盟友，两个足够接近暗光纤的DC很容易被来自同一个超级单元系统的龙卷风击中。 这种风险可以通过谨慎的相对地理位置（从检查历史风暴轨迹开始）来缓解，但不能完全消除。
我在另一个国家有另外一个完全相同的主机设备。
正如其他人所说的那样，这全是关于中断的成本和冗余成本，而且中断的许多成本都是无形的（失去客户的信任）。
只是很高兴你有预算做正确的事情。
与此同时，您的软件更新程序可能现在可能会使用一些工作。
您对设置的“硬件”部分是正确的。 通过地理冗余来提供HA将使您的服务不太可能因为硬件故障而停止运行。
换句话说，我觉得我可以在我母亲的公寓里安置一台便宜的笔记本电脑，而人力/软件问题仍然是我的风险较高。
我完全不同意。 您错过了testing和发布pipe理的关键点。 还有一些策略可以确保软件永远不会让所有的客户都受到影响。
一些公司甚至不仅仅使用单一品牌的networking服务器，而是因为担心Apache中的一个bug可能会一次被触发，所以他们部署了多个Web服务器。
就testing而言：必须有一定程度的信任，即使系统完全访问所有的资源，你也不可能拥有testing所有资源的资源（或者如果testing是不够的话 – 正式certificate正确性）。
关键是你应该在软件投入生产之前进行testing。 这就像是：
就发布pipe理而言：如果您不希望新版本中的未知错误触发停机时间，则不要在任何地方发布新版本。 只有一小部分的客户才能接触到新版本。 如果这样做的话，好的迁移更多的客户（如5％，20％，50％，100％）。 请注意，您可以在这里进行滚动循环，如下所示：
因此，如果您的定义是在每批部署中运行两周，那么您的发布周期之间的时间间隔不会太长。
我发现问题并不在于创build这样的系统，而是将其出售给pipe理层。 因为这个过程要花费很多时间和金钱（至less在开始的时候），我发现它更便宜。 滚动发布也使得软件（也就是说最后一个例子中的版本5完全被破坏）完美的回退，只需要有一个机制来处理新旧数据，这又意味着：
你多大程度上把你的冗余疯狂？
就pipe理层而言，如果他们觉得值得付出，他们愿意付出代价，并认为中断的风险要比高可用性（随机水平）的成本要高得多。