一家企业的边界，是以其核心能力为基础，在与市场的相互作用过程中形成的经营范围和经营规模，其决定因素是经营效率。——罗纳德·科斯
在文章一开始，我们有必要对灾备的概念做一个说明，这样做的好处是，可以保证我们接下来的沟通是在同一个层面。
灾备，主要是对数据进行备份，并且保证业务能够在发生意外的时候快速恢复。
所以多长时间可以恢复（RTO），故障期间丢失多少数据（RPO）是很重要的指标。与灾备相关的概念包括备份、容灾、业务连续性管理等等。
从定义上看，灾备肩负着“挽狂澜于既倒、扶大厦之将倾”的神圣使命，从这个元使命出发，我们试着探讨一下灾备边界的问题。
先说明笔者的观点：
灾备产品有边界吗？有。
灾备企业有边界吗？没有。
数据总是呈现一种流动性，但技术则不是，依托于技术而产生的产品呈现出的是一种点状的分布形态，比如针对操作系统、数据库、存储、网络等等不同层面的产品。
而灾备作为一种数据复制技术，一定是需要寄生于存储、网络、计算等层面而存在的，这就导致灾备产品也会呈现一种点状的分布形态。
从针对存储的灾备服务，到针对虚拟化的灾备服务，在IT技术的不断迭代中，灾备城头的大王旗也没有停止过变换。
这一次，数据开始流向云端，甚至已经有人断言，全面云化已经是一个必然趋势。只是这一次，不管是IT圈，还是DT圈，大家都已坚信，他们已经从青萍之末，看到了大风暴的来临。
在Gartner发布2017年存储技术成熟度曲线中，云备份这项新兴技术在曲线上显示出了快速移动，采用率不断上升，Gartner曾预言，2020年，使用云备份的用户将从现在的10%增长为20%。
另一方面，在Gartner发布的公有云关键能力报告中，灾备场景及数据复制及恢复能力并不在列，一些公有云服务商也没有完整的DR产品，而是仅以存储、网关等产品予以替代。
所以，如果云灾备希望在公有云不断同质化的今天有一个更好的前景，那么灾备企业则需要付出更多的努力。
举个例子，英方提出了“Hub”的云灾备产品理念，hub不是具体指某一款产品，而是一种服务理念，指在本地与云、云与云之间搭建一个连接器，这种形式，需要灾备企业表现的更为积极，需要灾备产品具有更好的通用性，需要与新技术的不断融合与创新，需要在数据恢复方面有更好的表现。
大脑进化出了这些认知捷径来帮助我们快速做决策，而无须使用太多的能量。这就是为什么我们喜欢“不费脑子”的事情。
如果可以让别人“不费脑子”的选择你，那么你就已经成功了。如果是C端产品，这样“无脑消费”认知打造是可以的。
但对于2B产品来说，场景是实际存在的。
我可以很容易告诉我老婆什么是灾备，但却很难告诉她灾备是用在什么具体的场景的。因为场景的确有点多。
而现在，在灾备的传统应用场景上逐渐出现了多个新生的业务场景，以至于连Gartner都必须推出针对DRaaS、数据中心备份与恢复软件等不同的魔力象限，而在不同的魔力象限中的玩家也大不相同。
任何一种灾备场景都不是独立存在的。从硬件存储到软件定义存储，再到对象存储管理，从本地数据上云，到不同云之间的数据迁移，从混合云应用场景到云原生应用场景……
由于灾备场景多样性的存在，用户灾备逐渐由数据层面的备份向业务层面、数据中心的高可用转移，从存储层面的双活、跨存储平台容灾，到数据中心层面的两地三中心，灾备的应用场景越来越广泛，这不仅对数据中心服务提出了更高的要求，同时也对灾备产品提出了更高的要求。
灾备不仅需要关注数据层面，还需要对与之配套的网络、机房服务具备更完善的适应能力。
在任何一种灾备场景中，企业总会追求最小的灾备窗口，这是人之常情。但在实际中，我们就需要考虑备份变化的数据量是多少？该变化时间内带宽成本是多少？
让我们从灾备的话题延伸到2B企业。任何一个产品都有其边界，尤其是企业级产品，这样的边界更为明显，所以企业级产品的天花板也会非常明显，当然，好处是企业级产品的篱笆历来是扎的最稳的。
但企业不同，一家企业的边界，是以其核心能力为基础，在与市场的相互作用过程中形成的经营范围和经营规模，其决定因素是经营效率。
而“开放”仍然是保证不同规模企业提升经营效率的不二法门。软件定义一切，而API定义软件，任何企业都可以在API的支持下，轻松实现一种“积木式”的创新。
另一方面，在企业的内部业务方面，由软件向硬件，甚至向服务的转变也是一个必然，而这种必然的动力依然取决于企业的经营效率，换句话说，就是企业的成本问题。
我们已经习惯了2C/2B的二分法来定义企业属性，但其实2C/2B更应该是一种产品的划分，而不是企业的划分，如果我们可以把2B的产品在应用层面做得更简单，更服务用户的使用习惯，是一定能影响到C端用户的。
值得庆幸的是，很多企业已经开始这么干了。
