这是每个工程师的噩梦：云服务提供商突然终止，造成系统缺点、产品缺点，愤怒的客户埋怨服务中止。这或许会对企业信用形成重大影响，并使产品的牢靠性遭到质疑。
AWS首席技术官WernerVogels谈到了针对缺点的设计架构，他示意，无论你或你的云供应商在数据核心运营方面有多杰出，数据核心总有一天会终止。
即使是规模最大、最成功的公司也会成为缺点的受益者——Facebook、Slack和AWS最近就是例子。只管并非一切的停机都是云形成的，但AWS最近的一个例子曾经证实，有可行的、被动的业务延续性(BCP)和劫难复原(DR)方案，以及每一个方案的运转手册，都能带来不同。
只管BCP和劫难复原通常被归为一类，但业务延续性往往比劫难复原更经常出现，休息强度也更低。BCP通常指的是典型的云终止，而DR指的是由于恶意行为或其余破坏性事情造成一切数据完全销毁的状况。关于BCP方案，数据和主机的多个正本通常就足够了，而劫难复原方案要求有更多的备份和协定。
另一个须要确定的关键方面是复原点指标(RPO)和复原时期指标(RTO)。RTO是指在从劫难中复原时，企业能够接受的断开衔接的时期量，而RPO是指在不侵害企业声誉或违犯服务级别协定(SLA)的状况下，你在劫难中或许失落的数据量(例如，24小时)。
既然曾经确定了这些关键起因，那么在出现另一次性云终止或任何其余或许出现的疑问时，如何包全你的组织?以下是在最坏状况出现后预备和复原服务的一些步骤。
创立多可用性区域部署
BCP最便捷、最经常出现的架构是在同一区域内至少经常使用两个可用性区域(AZ)。例如，在AWS上，每个区域由三个AZ组成，它们彼此相对接近，经过公用光纤和低提前衔接衔接。这可以坚持服务反常运转，以便在一个AZ出现缺点时继续为客户提供服务。
云提供商偏差于将其服务散布在多个AZ(例如Amazon S3、Amazon DynamoDB、Google CloudSpaner等)。因此，它们被设计用来处置AZ缺点。
留意，须要思考到此类架构或许触及设计阶段须要思考的外部老本。
在多区域部署中经常使用单个AZ
在这个场景中，你将在两个不同区域的一个AZ上成功运行程序和数据库。这使你能够在一个地域出现停机时提供服务。
这两个AZ可以经过以下几种模式部署：
经常使用多AZ和多区域部署
最近一次性AWS大缺点出当初北弗吉尼亚州(US-East-1)地域，由于网络影响，影响了整个地域。假设你一切的基本上班负载都在该地域运转，那么你的服务将无法防止地遭到影响。这象征着在该地域的AWS服务复原之前，你的一切服务都将暂停——你把一切的鸡蛋放在一个篮子里!这是一种稀有的状况，网络缺点会影响多个AZ。
关于这种状况，最好的包全措施是在不同的位置运转不同的上班负载和备份，这样，假设一个地域出现缺点，你可以继续为来自不同地域的客户提供服务。
当然，运转的区域越多，环境就越复杂，云账单也就越低廉。因此，思考到你的产品实践上有多关键，在哪里和多少地域建设业务时要有战略。你将须要付出额外的致力，以确保你的产品在所无状况下都能施展作用，从而保证尽或许成功地域多元化。
在多云或混合部署上运转
在多个云提供商上运转曾经变得越来越盛行。但事实是，保养多个云环境十分艰巨，当你经常使用托管服务时，这一应战变得愈加艰巨。例如，假设你经常使用的是AmazonDynamoDB，则其余云提供商无法提供相似的处置方案。
因此，行业趋向是在一个特定的云上(在一个多AZ或多地域架构上)运转每个上班负载，但准许不同的上班负载在不同的其余云上运转——这象征着你可以在两个不同的云提供商之间拆分局部服务。在这种状况下，出现停机时并非一切系统都停机。
或许，另一种经常出现做法是在外部设置DR站点。当客户将其上班负载迁徙到云端时，他们偏差于将本地作为劫难复原站点经常使用，因此假设出现疑问，他们将能够在本地运转一些关键服务。当公司的云成熟度处于初始阶段，并且没有经常使用托管服务时，这是一个很好的通常。
创立备份
只管上述一切处置方案都是BCP的理想处置方案，但在数据被加密或删除的状况下，它们行不通，须要牢靠的劫难复原战略。因此，除了为你的服务提供多个实施之外，你或许还须要一个牢靠的备份方案，以满足公司的RPO和RTO要求。
有许多第三方备份处置方案和云备份服务可用，例如AWSBackup，它们可以协助你成功备份智能化，并将备份保留到独自的账户和区域。你应该像包全金库一样包全备份账户，这样它就可以抵御攻打，将数据加密。
假设出现此类攻打，备份账户上的数据将用于复原服务，以便继续为客户提供服务。
曾经引见了为云环境构建BCP和DR方案的最罕用方法，让咱们探讨一下可用于成功这些方法的工具：
应用基础设备即代码
基础设备即代码(IaC)可以成功环境的智能性能。一旦性能了要经常使用的参数，它将被保留到主文件中，也就是清单。从那里，你的环境可以智能从新创立，用于测试、劫难复原或各种其余状况。
对容器经常使用缩放规定
假设你经常使用的是容器，那么基于各种度量成功缩放规定会十分有协助。可以向上缩放以参与同一块中的簇，也可以向外缩放，这将复制实例。经过实施裁减规定，你可以轻松备份和复原基于容器的运行程序，以便在出现停机时检索一切关键的上班负载。理想状况下，你须要在容器和实例级别上启动缩放，以使其最有效。
从新路由DNS恳求
假设一个位置的主机封锁，你可以将一切恳求从新路由到运转服务的其余位置。可以将Cloudflare等DNS提供商性能为检测系统何时封锁，并智能执行基于天文位置的从新路由。
雷同，你还可以设置容器编排器来定义和智能化各种从新路由恳求的规定。咱们倡导同时成功智能缩放以确保可用性，并经常使用AmazonECS来成功重路由恳求。
设置批示灯以在多个位置运转
另一个介绍的业务延续性战略是运转试点灯，它实质上是在不同区域备用运转的上班负载的复制版本。假设出现劫难，一切数据都将保留在那里，随时预备启动设置。只有在事情出现后部署基础设备并裁减资源，产品就应该立刻启动并运转。
假设不能有任何停机时期，你或许须要思考运转热备用。依据AWS的说法，“热备用方法包含确保在另一个地域有一个增加的、但性能完全的消费环境正本。这种方法裁减了批示灯概念，增加了复原时期，由于上班负载总是在另一个地域。”
只管老本要高得多，但热备用的启动和运转速度将比批示灯快，由于不须要基础设备设置。
总结
在劫难复原方面，抱最好的宿愿，做最坏的计划才是最关键的规定之一。云终止或许会出当初任何人身上，不会有任何事前通知。
经过遵照上述战略，你可以确保服务在多个位置可用，可以轻松地将流量转移到未受影响的区域，并在劫难出现时做好备份和执行预备。最好的是，你可以放轻松，企业的性能和信用坚持在最高规范。