许多公共云提供商在日常运营中通常不可避免地会遇到灾难性的中断，IT经理需要从云平台的失败和教训中吸取教训，并将其应用于内部基础设施。云平台，尤其是大型公共云，具有多级冗余，但都无法避免意外停机。云计算平台，如数据中心，会遇到导致停机的问题。本地硬件故障和软件错误是不可避免的，但公共云为IT经理提供了解决这些问题的方法。公共云具有可用性池、冗余数据中心、可用性区域和云区域，使管理人员能够在发生中断时更好地规划业务运营。这些策略很重要，但管理员必须设计可靠的应用程序以利用公共云冗余。组织IT资产的弹性更多地取决于应用程序而非基础设施的想法与传统思维方式背道而驰。在过去的二十年里，管理员通过备份、复制和其他以基础设施为中心的技术来保持弹性。但对于绝大多数公有云平台来说，这种策略已经不再有效。近年来，云计算提供商遭受的损失超出了他们的承受能力。当云计算提供商提供的云服务中断时，行业供应商和用户似乎正在学习如何设计原生云冗余，管理者希望将这些教训应用到传统的虚拟化数据中心冗余中。重新思考数据中心冗余对于大多数传统组织而言，一些基本服务旨在防止停机。网络时间协议和网络路由等服务通常设计为高度冗余。然而，仅仅因为一个系统应该是冗余的并不意味着它的配置已经完全准备好利用自然冗余。一些核心服务没有高可用性选项。IT部门几乎总是面临必须处理的技术债务，需要对表现不佳的遗留系统提供支持。例如，一些遗留的应用认证系统只能存在于服务器端，这就限制了数据中心的冗余能力。管理者不应该把所有的鸡蛋都放在一个篮子里。对于大多数传统部署，最好在数据中心内使用冗余硬件。管理员可以通过使用不共享系统的冗余虚拟化集群，将此策略更进一步，类似于可以提供多个可用性区域的云计算提供商。这会使应用程序依赖于数据中心更高级别的冗余，但只有在业务需求保证该级别的冗余保护时才有价值。通过跨云平台和数据中心并行实施这些策略，在采用类似的遗留基础设施时，使用公共云提供商概念（例如可用性区域）可能会有所帮助。该术语使开发人员更容易理解基础架构概念，因为他们可能熟悉类似的云概念。云计算中的冗余并不完美，停机中断提供了经验教训高度冗余的系统无法避免性能下降。在最近的公共云中断期间，其目录服务无法保持服务从一个区域运行到另一个区域。重定向的流量超过了其他区域的容量，导致服务跟不上需求。当管理人员设计数据中心冗余时，他们必须计划在发生中断时的负载。管理员可能有两台服务器来支持数据中心冗余，但一台服务器可能无法处理全部负载。关键是要设计一个在正常和异常状态下都能满足业务需求的系统。许多组织假设如果配置正确，在中断期间会发现其他情况。Netflix的ChaosMonkey系统以模拟中断而闻名，它提供的教训是，如果管理人员不练习处理实际中断，他们将永远不知道IT系统将如何反应。虽然没有系统是孤岛，但每个应用程序和服务都具有使测试进一步复杂化的依赖关系。停机中断在私有数据中心和公共云中并不少见，但在数据中心内，管理人员通常需要了解和理解系统的内部运作。当云提供商出现中断时，您可能会觉得您没有从停机时间中学到任何东西，但事实并非如此。虽然公共云提供商使用与传统数据中心不同的工具和方法，但有关构建和调整冗余的经验教训是普遍的。
