立即开始为下一次云服务中断做准备

像这周的AWS事件一样的重大云服务中断是不可避免的。以下四种方法可以帮助您的公司度过难关。

由于无数小时的生产力损失，金融系统被数百万用户破坏，并可能损失数百亿美元，这周的AWS中断使得全球IT团队度过了一个糟糕的日子。当然，这也是自上一次事件以来最严重的全球云灾难……直到下一次。

无论您使用的是AWS、GCP、Azure还是其他平台，重大中断都是云计算现实中的必然。那么，您的公司可以采取什么措施来减轻打击？下面，我将提供四个步骤，供您的团队立即采取。

带着怀疑态度并做好功课。

通常，团队会在云服务中走向灾难的边缘，认为主要的云公司天生可靠。当然，信誉最好的公司有其原因。但是，每个云服务和超级计算机都提供了广泛的基础设施选项——仅AWS北美地区就有31个可用区和31个边缘网络位置——有些选项比其他选项可靠得多。

事实上，AWS的US-EAST-1区域，这次中断的原因，在2020年、2021年和2023年都曾经历过重大中断，并且在某些IT圈子中已知是最不可靠的区域。许多公司可能已经了解了这种情况，但仍然冒着风险，因为该区域的成本较低，提供的服务也很多。但是，考虑到中断的范围，很难不去想有多少公司完全被惊讶到了——如果他们知道权衡，他们肯定会选择更可靠的区域。我个人曾经遇到过一些IT领导，他们在过去与US-EAST-1有过不好的经历后，选择将业务迁移到其他AWS区域。

这里的教训是，当谈到云基础设施选项时，无论您使用的是哪个云服务，都要做好功课。可以从以下免费工具开始，例如cloudprice、Cloudping和超级计算机提供的Cloud Service Health工具的历史事件视图。

选择可移植性而不是云原生。

当您设计云配置时，简单的方法是选择云原生。但是，虽然选择由云服务提供商为其云服务提供的应用程序很方便，但这些云原生选项会使您在云服务中断时更容易受到影响。

为了避免这种额外的云依赖，尽可能选择独立和/或开源产品。以下是一些替代选项的例子：

当然，使用更多的云原生组件来构建云栈意味着您的团队需要做更多的工作。然而，在我的经验中，一旦基础设施启动并运行，添加工作负载到自建基础设施或云原生基础设施之间的区别几乎可以忽略不计。并且，独立选项的好处在于提高了弹性——更不用说减少了云锁定——使得它们非常值得。

为失败而设计。

鉴于云服务中断将会发生，请务必设计您的产品以考虑到云服务中断。一个很好的例子是Datadog：在2023年的事件中，该公司突然失去了对生产环境中超过一半Kubernetes节点的访问权限并完全重新设计了其灾难应对方法。更改包括消除架构瓶颈和解决技术债务，以便在中断期间不会导致系统故障，改善数据摄取和存储以提高数据可用性，并构建系统以自动恢复。一个很好的起点是遵循Datadog的建议，先考虑对最终用户最重要的内容，并构建故障保护以保护最重要的内容。

至少在两个云服务上运行。

当然，避免受到云服务中断影响的最佳方法是多云冗余。实现真正的多云流动性对于许多公司来说是一项巨大的任务，因为将基础设施从一个云服务转移到另一个云服务极其困难。但是在两个云服务上构建基础设施是一个很好的起点。要使其生效，必须有一个团队，其中包括每个云服务的专家。

当然，什么都无法完全保护公司免受像本周看到的那样的大规模中断的影响。但是，通过适当的尽职调查、云可移植方法、为失败而设计以及使用“双云”作为实现真正多云的垫脚石，公司可以在下一次（不幸的是不可避免的）重大云事件发生时更加灵活地应对。