像达美航空(Delta Air Lines)这样的大公司发生宕机时，我们有话要讲
2016年8月8日，达美航空公司出现了一个重大的计算机系统停机事故，导致航班大面积延误，这个问题以及后续措施对达美航空的运行影响了很多天。
2016年8月8日，达美航空公司出现了一个重大的计算机系统停机事故，导致航班大面积延误，这个问题以及后续措施对达美航空的运行影响了很多天。这一次故障造成的财务损失极为广泛，不仅严重影响了达美航空的运营和客户服务成本，而且还要对错失航班的客户、未运输的货物等进行一系列的赔偿。
来自CNN的记者Thom Patterson在他的文章中指出，（http://money.cnn.com/2016/08/08/technology/delta-airline-computer-failure/index.html?iid=ob_homepage_tech_pool），此类事件发生的原因是由于“老套的砸锅问题”(“Good old-fashion screw-up”)。对此，我完全赞同。我的第一反应是，“我恰好知道有那么一款产品，它完全可以避免此类事件的发生”。仿佛只要他们使用了某种产品，某种技术，就能避免这种情况的发生。当然，这都是瞎扯。发生这类事故，往往是由于企业系统、基础架构以及各种相互孤立的技术和服务过于复杂，这使得企业几乎不可能进行系统性的测试并制定防范措施。
Patterson在文章中引用了“航空业专家”的话，他们声称，系统停机的原因有如下三个：缺少冗余、黑客行为及人为错误。我认为，只看到这三个原因，说明这些专家们对问题的理解还是比较肤浅的。而且，我想特别声明一点：当今的每个系统都有冗余性或高可用性的设计。问题在于，要么这些功能并没有真正使用，要么没有进行充分测试，要么由于削减预算没有了必要的人力资源。那么，咱们是不是要把所有这些问题都归结到“人为错误”这一条里呢？
那么，我们应该如何应对呢？我认为，在IT界目前有一种趋势，正在从总体上促使灾难性事件的发生。让我们先谈谈财务：我们一直在追求尽可能降低成本，这迫使那些原本可靠的供应商不断降低产品质量。云提供商声称可以保证基础架构的服务级别，却从不告诉你他们是怎么实现的。 在IT圈里，我们很多资深人士对于传统老方法的顽固态度，使得运营方法和产品选择上难以创新。
我曾为一个火箭发动机制造商工作。我们的灾难应急方案就是一条：“快跑，别回头，不然你的脸也要被烧到了。”理论上我们应该每周对数据的可恢复性进行测试，每月对关键系统的系统可恢复性进行检测，每年对数据中心故障进行全面演练。至少，这是我的流程文档是这么要求的。 我是不是真的这样做了呢？当然，我得说我做了！！在实施飞康软件之前，我们只能在灾难发生的时候再演练。我们没法承担时间、资源、金钱的损失和对生产系统的影响，这才是操作手册无法执行的真正原因。
这也才是我们实施FreeStor的主要原因：它可以在不影响生产系统的前提下，处理各种灾难恢复的执行与测试。FreeStor让我可以对灾难恢复方案进行测试、记录和自动化操作，而所有这些都不会影响我的生产过程。直到现在，在企业级市场，FreeStor仍然是具备此能力的唯一平台。
为避免航空公司今后再次发生此类事件，文章的结论是：“他们应该部署更多的自动检测系统。这些系统可以在低流量时期让系统下线，借助于辅助和备份系统进行应急演练，从而确保运行良好”。
看来我需要跟这些“专家”好好交流一下。据我所知，目前市场上还没有这种所谓“自动化检测系统”。对于现在无比复杂的企业级IT架构来说，依靠某种神奇的系统实现全面检测，这简直就是一个幻想。
我很喜欢专家们提到的应急演练的概念，但是该如何控制演练对生产系统的影响呢？我知道大部分企业可能有办法针对某一台单独设备进行有限的故障接管测试，但是如果是针对灾难的全面测试，会是一个无比复杂而且高风险的流程。我有一个朋友的关键系统已经积累了4PB的数据，他私下里告诉我一旦出现灾难，这个系统要多长时间才能恢复，甚至到底能不能恢复，他完全没有概念。
另外，文章中提到了一个概念“低流量时期”。事实上，现代企业并没有什么低流量时期。达美航空的灾难发生在凌晨2:30，这算不算是“低流量时间”呢？航空公司和大部分现代企业都是24小时×7天不间断的业务。演练时关闭系统，以检测将会发生的事情，这对于大部分现代企业简直无法想象。
因此，如果达美航空公司打电话给我，请求我分享一些经验并提供建议（我一直守候在电话旁……），我将会与他们做如下分享：
1. 请以开放的思想和态度重新审查现有的产品和技术：它是否真的能够实现了你想要的灾备效果？如果不能，就应该赶快去寻找新的供应商或换一种方式来达到你所需要的效果。
2. 寻找一个平台，能够通过统一管理优化互操作性和操作一致性。
3. 寻找一个平台，能够用来测试数据恢复、系统恢复、服务恢复和数据中心恢复且不影响生产。如果你不能测试你的灾难恢复，那么你的SLA就只是空中楼阁。
4. 使用一个能够记录历史和实时数据的操作平台，通过现代化的分析技术，找出薄弱环节，从而得到你真实的SLA水平，与你真实的业务需求作比对。
5. 寻找一个IT分析平台，这个平台能够跨所有的基础架构系统进行关联，从而能够使您从整体上了解您的存储环境。
6. 不要在不充分了解供应商的情况下，盲目选择成本最低的供应商，包括云：如果你对你的存储没办法找到一个好的灾难恢复计划，那么，很可能云供应商其实也没有什么很好的方案。
7. 复制和冗余并不能完全解决高可用性。复制，甚至同步复制，往往会连同故障一直复制。冗余意味着你可能有机会比别人多失败一次（或几次）。如果你的系统需要永远在线，你就需要去找一个永远在线的技术。
8. 最后一条，假如你手里已经有一个工具，就用好它。如果这个工具不能满足要求，那就赶快去寻找新的工具。我已经无数次从朋友和客户那里听到，“我们依据标准化要求安装了这个工具，但其实它不能用。”我想提醒大家的是：请冲破办公室政治带来的阻力，承认有时先前的选择并不太合理。要通过正确的解决方案来支持你的业务，而不是通过你的愿望和关系。
当看到像达美航空这样的大型企业发生真正的系统中断，可能每个人都被吓了一跳。 我们购买技术并把它当做一项保险。但是只有当灾难发生时，我们才发现我们的技术其实并不能在所有的场景下保护所有的系统。对于在机场等航班时写博客的我们来说，我们应做的是：重新思考。打破传统的思维模式。找到并实施真正能够支持你业务的技术。最重要的是：定期检测这项保险策略，只有这样，你才会知道在最糟糕的情况下你面临的风险是什么。因为这个中断既然能够在达美航空发生，那么你将来也可能会遇到。
关于作者
Peter McCallum是一个企业解决方案的专家和技术创新者，自2011年起，他一直担任飞康软件公司数据中心解决方案架构的董事。他曾在企业数据中心优化、业务发展、战略规划和服务交付等方面担任过各种领导职务。Peter拥有15年以上的系统管理和基础架构构筑经验，通过走访世界各地，他与企业一同探讨企业级数据中心优化和业务连续性解决方案等问题。
