你的灾难恢复计划是否包括服务提供商中断的意外情况?我们知道理论上每台计算机系统都会发生故障。但是，我们有时需要经历中断，才能在更加内部的层面了解问题，并正确的进行计划。

你是否可以在2017年2月的Amazon Simple Storage Service(S3)故障期间有效的执行灾难恢复(DR)计划?也许你的灾难恢复计划是针对另一个云服务商，但你仍然需要从Amazon Web Services的故障中吸取教训。需要特别强调的是，你需要了解DR计划的每个元素的服务级别协议(SLA)，特别是在你控制之外的其它元素。

问题出在哪?

那次的AWS故障是源于一个相当简单的问题——一名进行日常维护的AWS工程师错误的输入了命令。这导致了管理和监控S3的AWS基础设施不能正常运行。在美国东部1区使用S3的所有应用程序都无法创建新对象。

对于DR应用程序来说，这次故障意味着新的备份无法被保存，这可能会违反客户恢复点目标(RPO)。 DR应用程序也无法从现有备份中进行任何恢复，从而影响恢复时间目标(RTO) 。

AWS用了大约6个小时才完全恢复服务。根据AWS的说法，S3每月的目标是提供 99.9%的可用性，这使得每月停机时间应该少于44分钟。显然，AWS应该偿还部分服务费用，因为他们在那个月似乎只达到了90%的可用性。所以如果你在AWS服务中断期间遇到了一个DR事件，那么这将是一个小小的安慰。你得等到故障恢复后才能使用上次完成的备份进行恢复。

我们应该如何应对?

从这次AWS故障中学到的第一课是你无法控制云服务。了解可用的服务级别将使你能够确定特定的云服务是否满足你的DR需求。

云服务商和你的主数据中心同时发生故障的概率很低。通过简单的Google搜索可以了解到，自亚马逊2006年推出服务以来，已发生大约三次重大的S3服务中断。在我看来，你的数据中心和AWS之间的网络链接相对于你的RPO / RTO更具风险。你的DR计划中是否列入了这些风险?使用灾难恢复服务(DRaaS)是否仍然具有商业意义?

如果这次故障让管理层对云端的DR感到不安的话，可以采取一些进一步的措施，例如使用更多的站点。举个例子来说，US-East-1区域(北弗吉尼亚州)的冬季风暴不会影响到EU-West-1 区域(爱尔兰)。通过将S3存储桶从US-East-1复制到EU-West-1，或者备份应用程序直接向两个区域发送备份数据，你应该可以免受AWS区域故障带来的影响。

你甚至可以选择在远程办公室部署与S3兼容的存储系统，并且让你的备份软件写入该站点。

对于还不信任云服务商的用户，您可以将备份发送到具有完全独立基础设施的两个不同的云提供商。不过这么做的缺点是将备份发送到两个位置意味着支付更多的存储和网络传输费用。另外还需要管理多个灾难恢复计划，每个站点都需要有一份。通过简单的数学计算你可能会发现为此付出的额外成本相对于得到的额外可用性来说是不划算的。

任何计算机系统都会有、并将会有停机时间。基于云的DRaaS也不例外。如果您的灾难恢复受到云端故障的影响，你的公司是否理解云端的DR故障(例如AWS服务中断)对于业务连续性可能造成的影响?

虽然大多数企业不愿意增加他们的开支来让DR获得更好的可用性，但仍然有少数企业愿意为此投入，以换取更可靠的灾难恢复系统。