思想领袖
现在开始为下一次云端中断做准备

像本周来自AWS的重大云端事故是不可避免的。以下四种方法可以帮助您的公司度过难关。
随着数小时的生产力损失,金融系统为数百万用户中断,并可能损失数百亿美元,本周的AWS中断无疑是全球IT团队的噩梦。当然,这也是自上一次事故以来最严重的全球云端灾难……直到下一次。
无论您使用AWS、GCP、Azure还是其他平台,重大中断都是云计算现实的组成部分。那么,您的公司可以采取什么措施来减轻打击?以下,我将提供四个步骤,供您的团队立即采取。
带着怀疑态度做好功课。
通常,团队会在云端安排中走向灾难的边缘,认为主要的云企业天生可靠。当然,获得最信任的公司是有原因的。同时,每个云和超级计算器提供了广泛的基础设施选项——仅AWS北美地区就有31个可用区和31个边缘网络位置——其中一些选项比其他选项可靠得多。
事实上,AWS的US-EAST-1区域,本周中断的原因,曾在2020年、2021年和2023年造成重大中断,并且在某些IT圈子中已知是最不可靠的区域。许多公司可能理解了这种情况,但由于该区域的低成本和丰富的服务而采取了计算风险。但是,考虑到中断的范围,不可能不考虑有多少公司完全被惊讶——并且如果他们知道权衡,肯定会选择更可靠的区域。我个人曾遇到过IT领导,他们只在过去与US-EAST-1有过糟糕的经历后才选择转移到其他AWS区域。
这里的教训是,在云端基础设施选项方面要做好功课,无论您使用哪个云端。开始的地方包括免费工具,如cloudprice、Cloudping和超级计算器提供的云服务健康工具的历史事件视图。
选择便携式而不是云端原生。
当您构建云端配置时,更简单的方法是选择云端原生。但是,虽然选择由云端提供商提供的应用程序很方便,但这些云端原生选项会在云端中断时使您更容易受到影响。
为了避免这种额外的云端依赖,尽可能选择独立和/或开源产品。以下是一些替代品的例子:
|
类别 |
原生产品示例 |
开源替代品包括… |
|
身份验证和身份 |
AWS Cognito |
Keycloak |
|
搜索 |
Azure Monitor |
Elasticsearch |
|
关系数据库 |
Google Cloud SQL |
PostgreSQL |
|
NoSQL数据库 |
AWS DynamoDB |
MongoDB |
|
容器编排 |
Azure Kubernetes Service (AKS) |
Kubernetes |
|
监控和可观察性 |
Google Cloud Monitoring |
Prometheus + Grafana |
|
消息队列 |
AWS SQS/SNS |
Apache Kafka |
|
对象存储 |
Azure Blob Storage |
MinIO |
|
API网关 |
Google Cloud API Gateway |
Kong |
当然,从头开始构建更多的云端栈意味着您的团队需要更多的工作。然而,一旦基础设施运行起来,我认为在既有的基础设施上添加工作量和在云端原生基础设施上运行之间几乎没有区别。而且,独立选项在可靠性方面带来的好处——以及减少云端锁定的好处——使其非常值得。
为失败而设计。
鉴于云端故障会发生,请确保在设计产品时考虑云端故障。一个值得关注的例子是Datadog:在2023年的事件中,该公司突然失去了对生产环境中超过一半Kubernetes节点的访问权限并完全重新设计了其灾难方法。更改包括删除架构瓶颈和解决技术债务,以便部分故障不会在系统中蔓延,改善数据摄取和存储以提高数据可用性,以及构建系统以自动在规模上恢复。一个很好的开始是遵循Datadog的建议,先从“对最终用户重要的内容”开始,构建安全措施来保护最重要的内容。
至少运行两个云端。
当然,不受云端故障束缚的最佳方法是多云端冗余。实现真正的多云端流动性对于许多公司来说是一项巨大的任务,因为将基础设施从一个云端转移到另一个云端极其困难。但是,在仅两个云端上构建基础设施是一个强有力且通常可行的起点。要使其生效,必须有一个团队,其中包括每个云端的专家。
当然,什么都不能完全保护公司免受像本周看到的那样大规模中断的影响。但是,通过适当的尽职调查、云端便携式方法、为故障而设计以及使用“双云端”作为实现真正多云端的垫脚石,公司可以在下一次(不幸的是不可避免的)重大云端事件发生时更加灵活地应对。












