最近几个星期以来，我们已经陆续听到了不少关于数据中心中断事故影响到一些具有较高知名度的美国企业的报道，包括华尔街日报、纽约证券交易所和美国联合航空公司在一周内均受到不同程度的影响。尽管想要百分百的防止每一次停机中断事件的发生是不可能的，但这些被媒体高度宣传的问题可能会花费大量的资金成本，并会显著影响到客户如何看待一家企业，进而影响到企业形象和声誉。为此，我们特地采访了业界的专家们，向他们咨询了一系列的问题：包括企业应该做些什么工作，以便能够维持高水平的正常运行时间?导致停机中断的原因都包括了哪些常见的错误?以及客户对于数据中心的安全性和弹性的平均期望如何?或者说偶尔的停机中断事故是企业正常运维的现实?

　　密尔沃基地区技术学院Brian Kirsch

　　可用性和其他一切之间的平衡是IT的基石之一。我们都希望我们的系统在我们需要时均能够保持正常运行，为我们所用。而当您需要在系统的可用性与需要做哪些工作以获得这种可用性之间进行平衡时，问题就出现了。您所需关注的问题不仅仅是简单的只是成本方面的问题，其复杂性和测试才是促使一切协同工作的关键。仅仅由某一款单一的硬件或软件产品就能够提供可用能力的理念在今天已经不存在了。虽然我们今天所使用的备份和灾难恢复产品已经变得更加广泛且有效，但相应的应用程序也已经变得更加复杂了。

　　这种应用程序及其可用性之间的不断竞争，会在当企业所使用的灾难恢复产品无法跟上的应用程序的需求和设计时，造成大范围的停机中断事故。

　　然而，硬件和软件也仅仅只是停机中断事故难题的一小部分。许多停机中断的发生是由于系统故障和变化所造成的。我们通过设计以防止发生故障失败;我们的安全系统防止未经授权的变化。然而，所有这一切在前端的努力都不能百分百的防止每一次停机中断的发生。我们仍要积极探索和寻找处理灾难恢复和停机中断的新方法。让我们秉承着企业必将发生停机中断，而不是试图简单地阻止他们的理念来设计我们的系统。积极的面对故障和运行失败能够给我们真正的应用程序弹性，因为故障保护不再仅仅是表面的事情了。然后，我们可以测试并证明我们有能力处理故障失败。

　　在这方面，没有比Netflix及其Chaos Monkey工程团队更明显的了。Netflix面临大规模的亚马逊EC2云重新启动，同时还需要保持其在线服务的正常运转。对于许多公司来说，EC2云的重启会为他们带来一些他们认为永远不会看到且很少有针对性的进行计划以防止出现停机中断的东西。另一方面，Netflix及其独特命名的Chaos Monkey工程团队则有一项计划。在Netflix，Chaos Monkey的作用是定期反复针对故障失败进行测试锻炼。通过不断的测试、和在问题造成大规模停机中断事故之前对其进行修正，Netflix公司已经创建了一项专门处理故障运行失败的服务设计，来确保可用性。

　　LogicNow公司戴夫·索贝尔

　　对于像纽约证券交易所、华尔街日报和美国航空公司这样的企业和机构而言，出现任何形式的停机中断事故几乎都可以说是一种耻辱。停机中断事故所造成的成本损失可能是极其昂贵的，而鉴于计算资源又相对低廉，先进的规划则可以确保将停机中断事故发生的几率降低到最低限度。对于那些有关键需求的企业而言，他们现在可以很容易地在云中建立备份系统，而且只有在紧急情况下使用。例如，微软的Windows Azure，仅针对活跃计算负载收取费用，这意味着整个备份网络可以在冷待机等待处理问题。热备份也可以设置最小的使用水平，确保为故障转移做好准备。监控和管理软件则应该始终被使用，继续获得更先进的预测分析，以预测分析可能的停机事故。

　　但是，沟通是缓解停机中断事故影响的最重要的部分。对于一名因美国联合航空公司发生停机中断事故而被滞留的乘客来说，最令人沮丧的无疑是缺乏透明有效的信息。企业不得主动不承认相关问题，然后再根据承诺进行交付。在社交媒体保持沉默和员工之间缺乏信息沟通可能是造成客户服务体验最糟糕的原因之一。

　　Volanto公司吉姆·奥赖利

　　安全系统怎么会发生运行失败?这看起来似乎是一种矛盾，但对于美国联合航空公司、纽约证券交易所和其他企业而言，最近都纷纷出现了状况。他们的IT基础设施到底有什么问题?

　　不断增强的复杂性肯定是问题原因的一部分。通常，企业已经有一些被修补和扩展过多次的旧系统。这导致了硬件和软件的漏洞。美国联合航空公司的问题则要归咎于一个路由器的运行失败，但这有引出了一个高度冗余的系统如何会有一个单点故障的问题。

　　当然，通信问题并不是美国航空公司所独有。云计算巨头亚马逊网络服务(AWS)在当一款路由器的软件被错误的更新时，也失去了几个区。这样的故障失败往往是由糟糕的操作程序，缺乏制衡的配置或糟糕的安装所造成的。

　　像AWS一样，在混乱的纽约证券交易所发生停机中断，起因于一个糟糕的软件更新——在这种情况下，“匹配引擎”将连接买卖交易指令。

　　尽管硬件或软件方面的原因已倍受指责，但所有这些问题的真正的罪魁祸首是人为错误。在高度进化的系统中，故障是可以预料的，管理员必须进行相应的改变，以处理不同的平台和应用程序的方法。糟糕的网络拓扑，未经测试的更新，更新被误用都是可以避免的错误。现在的问题是如何避免它们，同时也不会产生其他恶果。

　　自动化操作是解决更新问题的答案。任何使用Windows的人都熟悉其升级方法。有时它是在后台自动进行的，有时也需要用户回答一些问题，但大部分的工作和任何重新配置的新代码都是由软件处理的。

　　另一方面，Linux在最好的传统命令行界面，通常需要系统管理员输入惊人的速率来执行更新。其脚本被认为是最先进的。不过，脚本总是需要调整才能正常工作。

　　高水平的人工交互系统本身故障频发，AWS和纽约证券交易所的事件是典型的结果。联合航空公司则有着不同的问题。显然是一个单一的故障点造成的。防止这种故障不是研究火箭般的高精尖科学。仅仅只需对路由结构进行人工审查应该就能够确定一个路由器可以使系统瘫痪的问题的症所在。坦白说，当应用程序套件的拓扑结构和底层平台总是在不断变化时，人工检查是不容易的。

　　一些软件将能够在系统中检测问题点时发挥其价值。企业倾向于通过连续性软件解决配置问题。大数据分析的方法可能会增加方法的复杂性。

　　即便如此，糟糕的应用程序设计，特别是弹性较小的传统遗留系统仍然是一个问题，将继续困扰我们。解决这一类问题的答案是“沙箱测试”和“更严格的测试”。

　　无停机中断故障的数据中心究竟是否能够存在?答案是，我们距离实现这一理想还很远，但我们可以做得更好。