2016年8月8日，全球第二大航空公司美国达美航空（Delta Air Lines）发生重大计算机系统宕机事故，系统全面瘫痪，航班大面积延误，当天至少取消451趟航班。据了解，事故是由达美航空总部所在的亚特兰大地区停电导致。在停电约6 小时之后，航班才得以陆续恢复。

这一宕机事故令达美航空不得不“登榜”美国航空公司事故名单，美国西南航空公司（Southwest Airlines） 和美国航空（American Airlines）皆在榜单，在过去一年中，都因为数据系统故障而中断飞行。

宕机原因何在？航空业专家观点肤浅

CNN对此次达美航空事故进行了报道（http://money.cnn.com/2016/08/08/technology/delta-airline-computer-failure/index.html?iid=ob_homepage_tech_pool），并指出，此类事件发生的原因是由于“老套的砸锅问题”(“Good old-fashion screw-up”)。文章还引用“航空业专家”的观点，将造成系统宕机的原因归结为：缺少冗余、黑客行为及人为错误。

这样的认识过于肤浅。首先，当今的每个系统都会有冗余性或高可用性的设计。问题在于，这些功能有没有真正被使用，有没有进行充分测试，是否由于削减预算减少了必要的人力资源？发生这类事故，往往是由于企业系统、基础架构以及各种相互孤立的技术和服务过于复杂，使得企业几乎不可能进行系统性的测试并制定防范措施。目前在IT界有一种趋势，正在从总体上促使灾难性事件的发生：追求尽可能降低成本，这迫使那些原本可靠的供应商不断降低产品质量。云提供商声称可以保证基础架构的服务级别，却从不告诉你他们是怎么实现的。 在IT圈里，我们很多资深人士对于传统老方法的顽固态度，使得运营方法和产品选择上难以创新。

如何避免事故重演？专家支招再跌眼镜！

为避免航空公司今后再次发生此类事件，文章的结论是：“他们应该部署更多的自动化检测系统。这些系统可以在低流量时期让系统下线，借助于辅助和备份系统进行应急演练，从而确保运行良好”。

目前市场上存在这种所谓的“自动化检测系统”吗？对于当前无比复杂的企业级IT架构来说，依靠某种神奇的系统实现全面检测，这简直就是一个幻想。

专家们提到的“应急演练”概念，值得首肯。但是，该如何控制演练对生产系统的影响？大部分企业可能有办法针对某一台单独设备进行有限的故障接管测试，但是如果是针对灾难的全面测试，会是一个无比复杂而且高风险的流程。有一个朋友私下介绍，他所在公司的关键系统已经积累了4PB的数据，一旦出现灾难，这个系统要多长时间才能恢复，甚至到底能不能恢复，他完全没有概念。

CNN文章中还提到了一个概念“低流量时期”。事实上，现代企业并没有什么低流量时期。达美航空的灾难发生在凌晨2:30，这算不算是“低流量时间”？

对航空公司以及大部分现代企业而言，24小时×7天不间断业务是一种常态。演练时关闭系统，以检测将会发生的事情，这对于大部分现代企业简直无法想象。

图片来源网络

如何让灾难恢复的执行和测试不影响业务连续性？

当看到像达美航空这样的大型企业发生真正的系统中断，可能每个人都被吓了一跳。我们购买技术并把它当做一项万能保险。但是只有当灾难发生时，我们才发现，我们的技术其实并不能在所有的场景下保护所有的系统。对于企业来说真正应做的是：重新思考，打破传统的思维模式，找到并实施真正能够支持你业务的技术。最重要的是：定期检测这项保险策略。只有这样，你才会知道在最糟糕的情况下你面临的风险是什么。因为这个中断既然能够在达美航空发生，那么你将来也可能会遇到。

如何在不影响生产系统的前提下，处理各种灾难恢复的执行和测试？在目前的企业级市场，飞康的FreeStor是具备此能力的唯一平台。FreeStor可以对灾难恢复方案进行测试、记录和自动化操作，而所有这些都不会影响生产过程。
飞康对于达美航空宕机事故的思考

1. 以开放的思想和态度重新审查现有的产品和技术：它是否真的能够实现你想要的灾备效果？如果不能，就应该赶快去寻找新的供应商或换一种方式来达到你所需要的效果。
2. 寻找一个平台，能够通过统一管理优化互操作性和操作一致性。
3. 寻找一个平台，能够用来测试数据恢复、系统恢复、服务恢复和数据中心恢复且不影响生产。如果你不能测试你的灾难恢复，那么你的SLA就只是空中楼阁。
4. 使用一个能够记录历史和实时数据的操作平台，通过现代化的分析技术，找出薄弱环节，从而得到你真实的SLA水平，与你真实的业务需求作比对。
5. 寻找一个IT分析平台，这个平台能够跨所有的基础架构系统进行关联，从而能够使您从整体上了解您的存储环境。
6. 不要在不充分了解供应商的情况下，盲目选择成本最低的供应商，包括云：如果你对你的存储没办法找到一个好的灾难恢复计划，那么，很可能云供应商其实也没有什么很好的方案。
7. 复制和冗余并不能完全解决高可用性。复制，甚至同步复制，往往会连同故障一直复制。冗余意味着你可能有机会比别人多失败一次（或几次）。如果你的系统需要永远在线，你就需要去找一个永远在线的技术。
8. 最后一条，假如你手里已经有一个工具，就用好它。如果这个工具不能满足要求，那就赶快去寻找新的工具。