最近几周，我们听到了一些关于数据中心中断的报告，影响了一些知名的美国公司，包括华尔街日报、纽约证券交易所和联合航空公司。都受到不同程度的影响。虽然不可能完全避免每次停电事件，但这些广为人知的问题可能会花费大量资金，并显着影响客户对企业的看法，进而影响企业形象和声誉。为此，我们采访了行业专家并向他们提出了一系列问题：企业应该怎么做才能保持高水平的正常运行时间？停机的常见原因有哪些？错误？客户对数据中心安全性和弹性的平均期望是什么？或者偶尔的中断是正常业务运营的现实吗？BrianKirsch，密尔沃基地区技术学院可用性与其他一切之间的平衡是IT的基石。我们都希望我们的系统能够在我们需要时启动并可供我们使用。当您需要平衡系统的可用性与实现该可用性需要做的事情时，就会出现问题。您不仅需要关注成本，还需要考虑复杂性和测试才能使一切协同工作。单一硬件或软件产品即可提供可用功能的想法如今已不复存在。在我们今天使用的备份和灾难恢复产品变得更加广泛和有效的同时，相应的应用也变得更加复杂。当企业使用的灾难恢复产品跟不上应用程序的需求和设计时，应用程序及其可用性之间的这种持续竞争可能会导致大范围中断。然而，硬件和软件只是停机中断难题的一小部分。许多中断是由于系统故障和更改而发生的。我们故意失败以防止失败；我们的安全系统可防止未经授权的更改。然而，所有这些前端工作并不能完全防止每次中断的发生。我们仍在积极探索和寻找新的方法来处理灾难恢复和中断中断。让我们设计我们的系统时考虑到企业必然会遇到中断，而不是试图简单地阻止它们。主动应对故障和运行故障为我们提供了真正的应用程序弹性，因为故障保护不再只是表面现象。然后我们可以测试并证明我们处理故障的能力。这一点在Netflix及其ChaosMonkey工程团队中表现得最为明显。Netflix面临大规模的AmazonEC2云重启，同时还需要保持其在线服务正常运行。对于许多公司来说，EC2云的重启将带来他们认为永远不会看到并且很少为中断中断做计划的事情。另一方面，Netflix及其独特的ChaosMonkey工程团队有一个计划。在Netflix，ChaosMonkey的职责是定期针对故障进行重复测试。通过在问题导致大规模中断之前不断测试和修复问题，Netflix创建了一种服务设计来处理故障以确保可用性。DaveSobel，LogicNow对于像纽约证券交易所、华尔街日报和美国航空公司这样的企业和机构来说，任何形式的中断几乎都是一种耻辱。停机时间的代价可能是极其昂贵的，并且考虑到相对便宜的计算资源，提前规划可以确保停机时间最小化。对于有关键需求的企业，他们现在可以轻松地在云端建立备份系统，仅在紧急情况下使用。例如，Microsoft的WindowsAzure仅对活动计算负载收费，这意味着整个备份网络可以处于冷备用状态以处理问题。热备用还可以设置最低使用级别，确保为故障转移做好准备。应始终使用监控和管理软件，继续获得更高级的预测分析，以预测可能的停机事件。但是，通信是减轻中断影响的最重要部分。对于因联合航空公司停机中断而滞留的乘客来说，最令人沮丧的事情之一是缺乏透明度和有效信息。企业不得主动不承认相关问题，然后按承诺交付。社交媒体上的沉默和员工之间缺乏沟通可能是客户服务体验最糟糕的原因之一。Volanto的JimO'Reilly安全系统怎么会失败？这可能看起来有点矛盾，但最近美国联合航空公司、纽约证券交易所和其他公司都在发生这种情况。他们的IT基础设施出了什么问题？增加的复杂性一定是问题的一部分。通常，企业已经拥有经过多次修补和扩展的遗留系统。这会导致硬件和软件漏洞。美国联合航空公司的问题被归咎于无法正常工作的路由器，但这引发了一个问题，即高度冗余的系统怎么会出现单点故障。当然，沟通问题并非美国航空公司独有。云计算巨头亚马逊网络服务(AWS)也因路由器软件更新不当而失去了多个选区。此类故障通常是由于操作程序不当、配置缺乏制衡或安装不当造成的。与AWS一样，混乱的纽约证券交易所的中断是由错误的软件更新引起的——在这种情况下，是连接买卖订单的“匹配引擎”。虽然硬件或软件原因受到指责，但所有这些问题的真正罪魁祸首是人为错误。在高度发展的系统中，故障是意料之中的，管理员必须做出相应的改变以处理不同的平台和应用程序方法。糟糕的网络拓扑、未经测试的更新、误用的更新都是可以避免的错误。现在的问题是如何在不产生其他不良后果的情况下避免它们。自动化操作是更新问题的答案。用过Windows的人都熟悉它的升级方式。有时它会在后台自动发生，有时需要用户回答一些问题，但大部分工作和新代码的任何重新配置??都由软件处理。另一方面，Linux在Windows上的传统命令行界面通常需要系统管理员以惊人的速度输入以执行更新。它的脚本被认为是最先进的。然而，脚本总是需要调整才能正常工作。高层人机交互系统本身故障频发，AWS、纽交所事件就是典型结果。联合航空公司有一个不同的问题。显然是单点故障导致的。防止此类故障不是火箭科学。只需对路由结构进行手动检查，就应该能够识别可能导致系统崩溃的路由器的症状。坦率地说，当应用程序套件的拓扑结构和底层平台总是在变化时，人工检查并不容易。一些软件将能够在检测系统中的问题点方面提供其价值。企业倾向于通过持续的软件来解决配置问题。大数据分析的方法可能会增加方法的复杂度。即便如此，糟糕的应用程序设计，尤其是弹性较差的遗留系统，仍然是一个将继续困扰我们的问题。这类问题的答案是“沙盒测试”和“更严格的测试”。完全没有停机和中断的数据中心是否存在？答案是我们离实现这个理想还很远，但是我们可以做得更好。
