前言

数据对当今商业社会来说已经成为核心，因为企业必须要收集和分析有关企业运营、消费者行为和环境状况等每一个环节，并加以利用。然而，虽然数据崇拜势头愈演愈烈，但作为保存数据的方式——存储却仍止步不前。虽然虚拟化等技术已经彻底转变了计算和网络功能的交付方式，但存储在很大程度上仍然摆脱不了在专用物理机器上运行专用软件的传统模式。

当然，存储供应商和服务供应商都在不断改进产品，以满足企业所需的更快速度、更大容量和更简捷操作。近年来，领先的存储厂商，包括EMC、HPE、IBM、戴尔、和NetApp已经在其产品上推出了大量创新技术，例如闪存技术、融合和超融合的基础架构，甚至软件定义等功能。此外，云服务提供商已经应用了基于云的数据库和对象存储服务，并高速增长。

然而，如果要应用这些创新性的存储解决方案，企业就必须被迫放弃他们的传统环境，并开始执行令人畏惧的“升级和转换”。其结果是，企业的存储负责人要鼓起勇气抛开现有的存储，为企业的新应用部署新一代的产品。但是传统存储架构依旧要继续运行。于是，每一个新加入的独立系统都会不断增加存储环境的复杂性，增加管理负担，继而阻碍跨存储方案的效率和一致性。

作为回应，软件供应商都开始开发基于软件的管理解决方案，提供用于管理异构存储环境的工具。其中，飞康公司的FreeStor平台作为一款先进的软件定义存储平台，使企业能够从存储中获得最大的价值。

存储问题

数据存储的基本问题可归结为物理问题。早在2010年，Dave McCrory（目前任分布式数据库提供商芭蕉科技CTO）就提出了“数据引力”的概念，McCrory写道：

将数据比作是一个具有足够质量的行星或其他对象。随着数据的积累（增加质量），额外的服务和应用就很有可能被吸引到这个数据中…

服务和应用可以有自己的引力，但数据是最庞大、最密集的，因此它的引力最大。数据如果足够大，其自身几乎不可能移动 。

McCrory给出的这一恰当的比喻认为数据应放置于访问它的应用程序附近，而不是放置在一个集中的云数据库 中。但数据引力同样也解释了在迁移和复制存储数据时企业所面临的挑战 - 为什么他们不愿意改变他们现有的存储，即使一个新系统能够为其带来更大的利益。数据引力可以解释为什么企业不愿意将数据存储到云而更愿意选择其他业务工作负载：57%接受Stratecast调查的IT决策者将“数据迁移带来的挑战”作为采用云存储的主要障碍。

移动存储数据需要花费大量的精力、成本以及带宽，而且肯定会打乱正常运营。随着数据量的增加，所面临的挑战也会加剧。因此，数据创建或最初存储的地方往往是它最应该被保存的地方。

一方面，企业不愿移动现有存储，另一方面，企业又没有足够的迁移解决方案，这些问题为IT部门和企业整体带来了更多的挑战。从战术层面来看，存储管理员面临着以下挑战：

· 部署和管理多个异构存储系统的管理复杂性
· 存储资源流通的效率低
· 跨存储的可视性和性能报告不一致

更令人担忧的是：随着企业准备在快节奏的数字经济中竞争，存储很可能成为实现战略业务目标的阻碍。例如，异构的、不灵活的存储环境会有以下问题：

· 不能够充分支持高可用性以及始终在线的要求
· 降低应用程序的性能（通过每秒I/O和吞吐量来衡量）
· 阻碍新的应用程序部署和扩展
· 备份和恢复不完备导致的业务风险
· 阻碍搭建混合的IT环境，包括物理、虚拟环境，应用跨越本地和云

虚拟化和软件定义存储技术的有限杠杆

如前所述，存储可能是传统IT的最后一个堡垒，由搭载专有软件的专用物理设备主导，不容易与其他系统和模型融合。实际上在底层，大多数存储厂商已经大量使用了革新过的其他IT组件的技术和模型，比如服务器和网络。

这并不是说存储厂商已经停止了对创新的投入：事实上，他们正在积极为其产品开发更强大的功能，旨在使存储速度更快，效率更高，成本效益更大，存储环境更灵活。

在过去的几年中，存储厂商推出了虚拟化技术，使得有越来越多的功能从硬件平台转移到软件平台。利用存储虚拟化，软件层（功能就像一个虚拟服务器上虚拟机管理程序）可从数据平面将存储控制平面抽象化，使网络存储设备整合起来并集中化管理。

最近，一些厂商已经开始把他们的产品描述为“软件定义的存储”。尽管该术语有时与存储虚拟化可互换使用，但软件定义存储通常代表可以通过中央控制平台、跨所有网络连接的集群的一种更高级别的功能。例如，传统上重复数据删除和复制的服务，通常依赖于硬件，但在软件定义存储解决方案中，可能是基于软件的。软件定义存储经常与超融合解决方案相关联。在超融合解决方案中，存储、计算和网络组件预包装在一起；软件定义的组件融合到一起以进行操作和扩展。

具有讽刺意味的是，对于大多数软件定义存储系统而言，他们依赖于特定厂商的硬件。而供应商并没有完全去耦硬件逻辑，也不支持用户使用任何他们选择的硬件。相反，他们的软件只能控制、整合和管理厂商自己的硬件设备。这限制了它在实际环境中的应用。

FreeStor:中立的软件定义存储平台

飞康公司作为一家基于软件的存储服务长期供应商，提出了一个新的解决方案。该公司的FreeStor平台是一个复杂的、软件定义的存储解决方案，也就是说，它能够将底层存储硬件中的控制逻辑抽象化。此外，该平台还是一个智能的“数据服务”层。

FreeStor与其他软件定义存储解决方案的供应商之间的首要区别是：FreeStor与硬件无关。该功能使用户能够保留他们现有的多供应商的异构存储环境，并通过“智能抽象平台”将其集中到一起。

由于它是第三方的独立产品，因此该平台非常适合现代IT常见的混合环境。FreeStor不仅实现了数据的存储，它还方便了应用程序和不同IT平台（基于云和本地；开放和专有；物理、虚拟和混合）与各种存储资源（基于云和本地；闪存、磁盘驱动器和磁带；物理、虚拟和混合）之间的数据流动和服务。随着企业收集、共享和使用数据的部署模式和环境不断增加和变化，一个孤立的、只能面向某个特定厂商的存储管理方式将难以为继。

FreeStor基础架构

FreeStor解决方案的工作原理是：在应用服务器和存储硬件之间的数据路径中插入一个智能层。如图1所示，FreeStor要部署使用两种类型的服务器：

· FreeStor存储服务器，（可以是虚拟或物理服务器）安装在存储系统前面。这些服务器实现数据抽象（虚拟化）功能，并将数据服务（例如快照、复制）应用到存储系统中。
· FreeStor管理服务器，用于管理资源整合、控制数据服务。管理服务器连接到至多128个 FreeStor存储服务器，并对他们集中管理。

将这样一个服务器插入到数据路径中，并不会显著增加时延；该公司表示，时延负担大约在130-150微秒之间。尽管该解决方案需要企业在存储环境中部署额外的硬件组件，但增加几台廉价服务器，或者利用虚拟机并不会增加多少投资。此外，FreeStor还可以把FreeStor管理虚机部署到云上，例如AWS S3和Azure StorSimple，以及基于OpenStack的云服务。

挑战数据引力：简单、无中断的迁移和复制

FreeStor基础架构和其强大的软件平台解决了许多与数据引力相关的问题。使用统一的FreeStor控制平台，可以很容易实现抽象（虚拟化）数据的迁移、备份、复制，或跨位置或跨部署模型或跨硬件恢复，而且没有数据移动的风险。因此，企业能够非常灵活地部署和管理跨多个存储平台和位置的存储资源，并由一个单一管理平台来进行集中管理。

更重要的是，FreeStor可以进一步通过双活架构提升异构硬件管理的高可用性。这种高可用架构的最小单元是1 + 1的集群对，两个节点可以部署在本地，也可以拉长到不同位置。如果需要进一步扩展，FreeStor还可以支持2+2的4节点集群或更多点集群，同样可以部署在本地或远程扩展(见图2右下角所示)。集成的广域网优化功能，将复制的网络时延减小到最少。此外，用户可以选择使用重复数据删除功能，提升效率。

高可用性的能力使得用户可以轻松地删除或增加硬件；迁移至云存储；建立高可用或容灾环境， 而所有这些的恢复时间目标（RTO）均为0。

以下是是用户4种高可用性方案：

· 从原有硬件迁移到新的存储硬件。
· 高可用性方案，其中存储和应用均被复制。
· 管理服务商(MSP) 的备份即服务(BUaaS)方案，服务商利用FreeStor 平台为用户提供高可用性服务。
· 远程多点集群方案，让不同地理位置之间实现镜像，而每个地理位置均可以是多点集群。

全存储池的数据服务

高可用性引擎只是内嵌FreeStor平台的功能之一，在后台运行。而在前端，用户可以看到整个虚拟存储池的数据服务或功能，可以轻松地通过单一界面，跨所有存储基础架构，对它们进行部署和管理。

平台支持的服务包括：

· 迁移服务
· 备份
· 灾难恢复
· 数据归档

最近，飞康引入“云连接器”功能，这是为将原来本地存储的数据迁移至云端，如亚马逊AWS、微软Azure以及OpenStack 的环境而特别设计的。这一功能还支持使用云进行备份和恢复。它又被称为“穿云飞行”，也就是说，对用户而言，这一功能使得他们可以轻松地在不同云服务商之间，迁移工作负载）。

虽然该平台包含了所有服务，但飞康为用户提供经济型选择，他们只需为激活的服务支付费用。

跨异构存储环境应用智能和预测分析功能

对IT的高层领导而言，FreeStor最有价值的功能或许就是它的预测功能。平台通过单一界面跨所有存储平台进行监控和报告。详细的设备级性能和健康监测数据可以让用户：

· 基于实时趋势数据，实现资源最优配置——如获取、转化、重置、预测未来容量消耗
· 根据需要对存储扩展进行规划
· 监视存储设备运行，以便维护
· 确保存储性能（IOPS、时延和吞吐量）满足应用需求
· 确保对内（企业用户）对外（管理服务商）的服务等级协议（SLA）得以实现

最近，飞康在其智能平台上添加了预测分析功能。利用历史数据和趋势数据，此功能可以让用户跨整个存储基础架构环境预测容量利用率。下面的图3就是一份报告中的例子。

对企业而言，真正的价值是，通过监测和分析功能展示的洞察力可以让他们立即采取行动。例如：

· 如果管理仪表板显示某个特定设备的吞吐量突然降低，那么可以启动此设备的镜像设备，同时安排本地人员进行维修和排查。
· 如果存储经理想知道企业是否应该采用闪存技术，那么他们可以在一个或多个工作负载上尝试这项技术，得到测试结果。
· 如果管理服务商想要开发新的增值服务，需要特定存储满足特定应用的需求，他们可以利用FreeStor来监测和管理结果。

直观的管理门户在移动版和网页版上均可以使用，对存储经理而言，这让他们很容易看到基于仪表板数据或警报的存储环境的变化。也许同样重要的是，在一个快节奏的商业环境中，管理人员可以尝试各种选择，在今天做出一个决策，明天又试一试新的做法，却不会浪费时间或破坏环境。

写在最后的话

凭借FreeStor平台，飞康可使得企业用户和服务商精简、优化存储环境，与此同时，也可以使他们更轻易地从存储当中获取价值。通过FreeStor平台，用户可以：

·统一存储环境，集中管理资源池，为应用服务，而无需考虑底层硬件或部署模式
·在不干扰运行也不损失数据的情况下，对存储进行部署、迁移和复制
·通过基于详细的性能数据和预测分析，采取应对措施，优化存储和应用性能
·引入新的存储技术和部署模式（如闪存和云存储）时，不会破坏现有架构
·通过高可用功能，保护数据和应用
·优化存储利用率，控制资本成本
·解锁厂商锁定，并利用单一平台进行管理，减轻存储管理负担。

随着混合环境成为常态，企业用户越来越没有耐心去继续伺候数据中心里那些不灵敏的、独立的系统平台。总而言之，虽然在迎接软件定义和基础架构中立管理工具方面，存储已经远远落后于服务器、网络等构件，但飞康已经凭借其FreeStor平台弥补了这一差距。

Lynda Stadtmueller
云计算服务副总裁

There was a time, not so long ago, that a company could afford to be an “<Insert Vendor Name Here> company.” There was a go-to supplier, go-to VAR, and a go-to product line. The go-to company provided training and lunches, and that built up loyalty. In all of that loyalty, the hope is that the go-to company innovates regularly enough to continue providing value, and maintaining goodwill even after the sale. However, what I believe the consumer space is discovering is that trusted vendors didn’t live up to their end of the bargain. Perhaps it’s not the vendors themselves , but industry practices that need to change?

When I was running datacenters, and being entertained by vendors who wanted to sell me things, the big differentiator was always the extra-mile folks. Usually, technical resources who improved my craft a bit – and didn’t just rest with teaching me about their product. I worked for an aerospace contractor who had to follow government rules about three-bids, single-source, and diverse vendor strategies – mostly for security reasons. I was able to buy technology based on my business needs and trade technology coaching for purchasing tips with my preferred vendors –This practice helped me to vet out vendors very quickly into “providers” and “partners.”

Now that I’m out of that role, I see things a little differently. I know now, why long-term vendor affinity can crush innovation. Without explicitly naming names, take one of the best-known technology providers of the past decade. Most of their revenue has traditionally been tied to years 4-5(+) of maintenance on a CAPEX basis. Typically, your initial investment is discounted, upgrades and expansions are at a premium (to make up for the discount on initial purchase), and maintenance runs at least 20% of initial purchase price annually for as long as you want support. If you do the math, you actually re-purchase your product every 5 years. This should not be an epiphany to anyone as it has been a standard practice in the technology sector for decades.

Financials aside, this kind of practice causes some trickle-down effects on product innovation. If I stand to make 60-70% of my revenue in years 4+, why would I destabilize that base by asking a customer to upgrade or switch product lines sooner rather than later? My goal is to keep my customer happy on their current portfolio as long as possible. So how do I do this if I have to keep my hardware somewhat “flat” in capabilities? Software, of course. I can innovate all day long in my software as long as I only allow my software to speak with my hardware. Software also requires training and has both soft and hard loyalty due to skill, process, and product affinity. The effect of this practice is that you keep my hardware for years past its prime and lock deeper into my revenue stream. So now, instead of using technology to support my business, I change my business to support my technology.

I believe that today, this paradigm is being rejected more and more, causing an interesting reaction in the client and vendor landscape. The CIO cries out from the wilds and shouts: “I have too many silos, too many processes, too many people, too many moving parts!! I need simplicity!!” And the industry reacts with glee: Let’s give them convergence. So now the big companies band together to hold onto market share and bundle up end-to-end solutions with “cross-platform” orchestration. Datacenter in a box, we were promised. That’s all fine and dandy as long as you like and only use their boxes. Now we are even MORE tied into the revenue stream – and that one throat to choke requirement ends up being yours, Mr. CEO as you allow your business to slowly get muscled by your technology providers.

We followed this trend with Hyperconvergence which took out the multiple vendors, and built a consolidated, optimized reference architecture of best-in-class capabilities and built little tiny boxes of lock-in. As long as we like the hypervisor, and don’t mind the restrictions of scale, and the lack of mobility, and have the ability to toss our whole old datacenter (admittedly not a bad choice for many…), then Hyperconvergence is a great concept. But that’s a lot of very important “as long as you...” caveats.

Now we see the growth of open-source in the crazy juggernaut of OpenStack. Let’s get all the big players in the industry to contribute their best-in-breed feature differentiators to a “free” platform that gives everyone of any size an amazing platform of features and capabilities that will completely remove the need for your commercial software, and will tend to commoditize the value proposition of your hardware further into the ground. “[throat clears] sure. I’ll give you my best! [rolls eyes].” Technology socialism, for sure, but it does have lots of promise.

While I’m partially bashing on everything else, I have to make sure I include the cloud in my rant, right? Let’s get this definition crystal clear: the cloud is somewhere else, with some other technology, who I pay to maintain my data for the lowest possible cost and lots of contractual assurances. Heh. Yes, some clouds are puffier than others, but at some point, financials and competition will require cloud providers to push prices to the floor – and force lower standards. Am I saying you tend to get what you pay for? Yes. Yes, I am. The great thing, though, about the cloud providers is that they can be a greenfield technology transition without that investment on the part of the customer and it is about as simple as it gets to consume.

So the echo in the wind back to the CIO is this: “Now that you’ve asked, we’ve provided very little of value other than to offer you a place to offload the responsibility to someone else!!” And now the cloud provider has to deal with the vendor-lock-in and silos and cost fighting, and the CIO fidgets at her desk with almost zero control over what happens to her business’s critical data.

What is it that we need, then? There is something of value going on here, even if you can’t see it under my somewhat cynical overview: there is something happening . Movement is taking place. New technologies are creeping in that change the paradigm of consumption and bring cloud-like models into on-premise IT. What convergence taught us is that orchestration across storage, networking, and compute are critical for IT operations. What hyper-convergence is teaching us is that focusing down into workload-optimized topologies and optimizing operations through analytics-infused automation is critical to IT operations. OpenStack is answering the call for hardware-agnostic, agile platforms that leverage software to provide the right personality of services for a given workload at a given stage of a workload’s requirements. The cloud is teaching us that perceived simplicity and optimizing efficiency for cost is possible and viable. And we’ve proven once and for all that the old way of vendor “techstortion” (technical extortion, anyone?) is finally not welcome in business anymore.

What is the direction things are moving, then? Unless your business is simply hobbled by indecision and freezing all technical assets until something makes sense again we feel ya! You aren’t alone by any stretch; you have been looking at everything I have mentioned in this rant (er… blog!). You have small SAN, mid-SAN, server-san, all-flash array, good-old’-boy vendors, NKOTBs (New Kids on the Block), hypervisor-based, containerized, SDS, SDx, traditional, modern, memory-resident, SaaS, Cloud-enabled, gateway-ed, referenced, marketed, funded, and struggling vendors knocking on your door all day long asking you to listen. And you are listening, and making your choices. You are buying something, even if it’s only time. In the end, you will dabble. IT always has. We take bits of all the cookies on the plate and spit out the bad tasting tech. We keep a handful of old standards and some of the weirder cookies we didn’t think we’d ever like.

What I’m saying is that you will end up buying or trying some of almost everything I have mentioned. Your gut is telling you that something needs to change – and I think I’ve shown you what is broken. The industry will react to what you keep and what you spit out. What you will need is a way to protect your data assets while you test drive and kick tires. You need subscription-based purchase plans that do not obligate you to a return-on-investment time. If a technology does not provide value, you will simply stop using it and your money will go elsewhere. In order to facilitate this, you will need a platform that allows you to bridge your infrastructure across locations, form-factors, vendors, technologies, providers, company names, and other traditional barriers – all while maintaining your processes, skills, and guarantees of service levels to your business. Yep, you need a chaos platform – a middleware between the uncomfortable known and the exciting unknown.

Some of you may be forced into a multi-vendor strategy for compliance or procurement practices, but all of us will be goaded into it simply because the old model is broken and there is simply too much to choose from these days that tangibly helps your business.

I was this customer. I had all these challenges, I saw these changes coming. I embraced a variable technology architecture with multiple locations, and chose a platform to bring it all together and solve the challenges of shrinking budgets, compliance issues, reductions in force, changes in IT leadership, mergers and acquisitions, migrations of technology, consolidations of infrastructure, monolithic vendor platform overturn, and other challenges.

With all the chaos you will be finding in your technology options today, I would highly recommend kicking the tires a bit on a product that will help you to make better sense of what you have, and enable you to safely constrain the chaos of what is to come. 

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年以上的系统管理和基础架构构筑经验，通过走访世界各地，他与企业一同探讨企业级数据中心优化和业务连续性解决方案等问题。