这是每个工程师的噩梦：云服务提供商突然中断，导致系统故障、产品故障，愤怒的客户抱怨服务停止。这可能会对企业信誉造成严重影响，并使产品的可靠性受到质疑。
AWS首席技术官Werner Vogels谈到了针对故障的设计架构，他表示，无论你或你的云供应商在数据中心运营方面有多出色，数据中心总有一天会中断。
即使是规模最大、最成功的公司也会成为故障的受害者——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 Cloud Spaner等)。因此，它们被设计用来处理AZ故障。
注意，需要考虑到此类架构可能涉及设计阶段需要考虑的内部成本。
在多区域部署中使用单个AZ
在这个场景中，你将在两个不同区域的一个AZ上实现应用程序和数据库。这使你能够在一个地区出现停机时提供服务。
这两个AZ可以通过以下几种方式部署：
- 每个地区将使用负载均衡器或DNS(域名系统)路由为50%的工作负载提供服务。
- 主区域将为大部分或所有流量提供服务，第二个区域将在出现故障时为用户提供服务。如果选择此路线，可能需要自动执行此故障切换任务。
使用多AZ和多区域部署
最近一次AWS大故障发生在北弗吉尼亚州(US-East-1)地区，由于网络影响，影响了整个地区。如果你所有的基本工作负载都在该地区运行，那么你的服务将不可避免地受到影响。这意味着在该地区的AWS服务恢复之前，你的所有服务都将暂停——你把所有的鸡蛋放在一个篮子里!这是一种罕见的情况，网络故障会影响多个AZ。
对于这种情况，最好的保护措施是在不同的位置运行不同的工作负载和备份，这样，如果一个地区出现故障，你可以继续为来自不同地区的客户提供服务。
当然，运行的区域越多，环境就越复杂，云账单也就越昂贵。因此，考虑到你的产品实际上有多重要，在哪里和多少地区建立业务时要有策略。你将需要付出额外的努力，以确保你的产品在所有情况下都能发挥作用，从而保证尽可能实现地区多元化。
在多云或混合部署上运行
在多个云提供商上运行已经变得越来越流行。但现实是，维护多个云环境非常困难，当你使用托管服务时，这一挑战变得更加困难。例如，如果你使用的是Amazon DynamoDB，则其他云提供商无法提供类似的解决方案。
因此，行业趋势是在一个特定的云上(在一个多AZ或多地区架构上)运行每个工作负载，但允许不同的工作负载在不同的其他云上运行——这意味着你可以在两个不同的云提供商之间拆分部分服务。在这种情况下，发生停机时并非所有系统都停机。
或者，另一种常见做法是在内部设置DR站点。当客户将其工作负载迁移到云端时，他们倾向于将本地作为灾难恢复站点使用，因此如果出现问题，他们将能够在本地运行一些关键服务。当公司的云成熟度处于初始阶段，并且没有使用托管服务时，这是一个很好的实践。
创建备份
虽然上述所有解决方案都是BCP的理想解决方案，但在数据被加密或删除的情况下，它们行不通，需要可靠的灾难恢复策略。因此，除了为你的服务提供多个实施之外，你可能还需要一个可靠的备份计划，以满足公司的RPO和RTO要求。
有许多第三方备份解决方案和云备份服务可用，例如AWS Backup，它们可以帮助你实现备份自动化，并将备份保存到单独的账户和区域。你应该像保护金库一样保护备份账户，这样它就可以抵御攻击，将数据加密。
如果发生此类攻击，备份账户上的数据将用于恢复服务，以便继续为客户提供服务。
已经介绍了为云环境构建BCP和DR计划的最常用方法，让我们讨论一下可用于实现这些方法的工具：
利用基础设施即代码
基础设施即代码(IaC)可以实现环境的自动配置。一旦配置了要使用的参数，它将被保存到主文件中，也就是清单。从那里，你的环境可以自动重新创建，用于测试、灾难恢复或各种其他情况。
对容器使用缩放规则
如果你使用的是容器，那么基于各种度量实现缩放规则会非常有帮助。可以向上缩放以增加同一块中的簇，也可以向外缩放，这将复制实例。通过实施扩展规则，你可以轻松备份和恢复基于容器的应用程序，以便在出现停机时检索所有重要的工作负载。理想情况下，你需要在容器和实例级别上进行缩放，以使其最有效。
重新路由DNS请求
如果一个位置的服务器关闭，你可以将所有请求重新路由到运行服务的其他位置。可以将Cloudflare等DNS提供商配置为检测系统何时关闭，并自动执行基于地理位置的重新路由。
同样，你还可以设置容器编排器来定义和自动化各种重新路由请求的规则。我们建议同时实现自动缩放以确保可用性，并使用Amazon ECS来实现重路由请求。
设置指示灯以在多个位置运行
另一个推荐的业务连续性策略是运行试点灯，它本质上是在不同区域备用运行的工作负载的复制版本。如果发生灾难，所有数据都将保存在那里，随时准备进行设置。只需在事件发生后部署基础设施并扩展资源，产品就应该立即启动并运行。
如果不能有任何停机时间，你可能需要考虑运行热备用。根据AWS的说法，“热备用方法包括确保在另一个地区有一个缩小的、但功能齐全的生产环境副本。这种方法扩展了指示灯概念，减少了恢复时间，因为工作负载总是在另一个地区。”
虽然成本要高得多，但热备用的启动和运行速度将比指示灯快，因为不需要基础设施设置。
总结
在灾难恢复方面，抱最好的希望，做最坏的打算才是最重要的规则之一。云中断可能会发生在任何人身上，不会有任何事先通知。
通过遵循上述策略，你可以确保服务在多个位置可用，可以轻松地将流量转移到未受影响的区域，并在灾难发生时做好备份和行动准备。最好的是，你可以放轻松，企业的功能和信誉保持在最高标准。
