AWS大规模故障后，CIO如何确保业务持续运营？

周一，数百万用户和超过1000家公司发现自己无法连接到互联网。社交媒体平台Reddit和Snapchat受到冲击，劳埃德银行和哈利法克斯银行也遭受影响。甚至连孩子们也受到了影响，热门游戏《堡垒之夜》和《Roblox》都离线了。参议员伊丽莎白·沃伦在X上发文，称这一事件"破坏了整个互联网"，并呼吁拆分大型科技公司。

"网络确实是AWS服务的基础组件，"DataStrike云技术总监、前AWS高级解决方案架构师科里·贝克说。"当它在US-East-1这样的区域出现问题时，影响远不止于此；它会波及EC2、S3、DynamoDB、RDS以及几乎所有依赖它们的服务。"

然而对于许多其他用户来说，这只是正常的一天。这是因为故障只影响了AWS客户——而且还是特定的客户。故障源于AWS数据中心集群US-EAST-1的DNS故障。这是该提供商最大的集群，为AWS的大部分互联网接入提供支持——但不是全部。任何运行微软或谷歌产品的企业或个人都完全不受影响。

这次故障引发了广泛讨论，从对单一提供商过度依赖的标准叙述到推出前需要更好测试协议的需求。在理想世界中，这种规模的中断永远不会再次发生。但CIO不能依赖交叉手指和梦想场景。他们需要确定在应对未来故障时自己肩负什么责任——并决定使用单一提供商的速度和效率优势是否会超过依赖该主要云供应商的集中风险。

冗余与风险

当政治家讨论垄断、用户抱怨网站无法访问时，IT领导者将此次故障视为改善冗余的警示。论点很明确：通过建立备份和故障转移能力，公司可以分散对基础设施任何一个点的依赖。一些专家认为，不这样做就是在边缘运营。

"赌徒可能会选择以危险的方式冒险核心业务能力，"Omdia数据保护、IT运营和可持续性高级分析师乔恩·布朗说。"就个人而言，我建议安全，因为保护不当、高知名度、关键任务应用程序的故障可能导致简历生成事件，这是我们大多数人试图避免的。没有什么比客户和交易数据更重要的了。"

这似乎很明显，但周一仍有一千家公司失去了数字功能。为什么他们没有更好的准备？一个答案是，虽然冗余并不新鲜，但它也不是很有吸引力。在一个充满创新和增长的领域，冗余意味着放慢速度、检查工作并选择最安全的路线。如果一些公司更愿意投资新的AI能力而不是实施故障安全协议，这并不令人惊讶。这也不一定是错误的。

"有时候，更明智的做法是接受有限的中断风险，将资源重新定向到创新，比如AI或数据现代化，"Hutchins数据策略咨询公司创始人兼CEO克里斯·哈钦斯认为。"但这必须是一个明智的风险，而不是假设的风险。"

据哈钦斯说，如果在罕见故障事件中CIO能够承受业务某些领域的暂停，那么单一采购的回报——成本节约、更紧密的集成和专业知识——可能超过运营风险。OutSystems CIO蒂亚戈·阿泽维多同意需要将此视为基于个别情况的财务计算。他说，他认为冗余是有针对性的弹性投资，而不是默认要求。只要关键领域得到大幅加强，CIO就不需要对其业务的每一寸都进行同等程度的保护。

"程度应该反映系统的关键性：生产或面向客户的系统值得多区域或多提供商覆盖，而开发和测试环境可以容忍短暂的停机时间，"他说。"目标不是消除所有风险，而是使弹性支出与中断的潜在成本保持一致。"

绘制关键任务地图

为了确定CIO应该将冗余工作重点放在哪里，IT领导者认为需要诚实和理解基础设施的哪些方面对业务运营真正重要。故障可能随时发生，无论是在内部系统内还是在任何第三方提供商，这意味着CIO不能延迟采取战略行动。

随着时间的推移，公司可能能够在所有基础设施的更全面层面引入冗余，但这可能在财务上不是最合理的。正如哈钦斯所描述的，"不与明确恢复目标挂钩的冗余很快就会成为技术债务。"因此，CIO必须对其业务依赖性进行审计，识别单点故障，并根据其对运营和信任的影响对系统进行排序。

"投资于故障会产生真正风险的地方很重要，而不仅仅是轻微的不便或噪音，"他补充说。

这对于不同规模的公司来说会有所不同，但对于不同行业的公司来说尤其如此。一些行业，如医疗保健或金融，需要全面更高水平的冗余，仅仅因为风险更大；无法访问患者记录或财务信息可能在安全和公众信任方面产生严重后果，远超不便或挫折。

布朗指出"云原生"组织特别脆弱，而阿泽维多表示他看到"永远在线"行业如电子商务面临更大压力。监管更严格的行业在弹性和冗余方面也可能需要面对更大期望；例如金融业。欧盟最近通过了DORA（数字运营弹性法案），以确保金融实体能够"承受、响应和恢复"技术中断。

单一提供商，但多样化依赖

在AWS故障之后，批评者迅速呼吁互联网合作伙伴的多样化，宣扬需要更强大、更多的AWS竞争对手。作为冗余策略的一部分，CIO需要调查他们对特定提供商的依赖程度，以便确定在故障事件中的风险。

但这并不像追踪第三方合同、计算一个名字出现的频率，并将一些操作从过于主导的提供商转移那样简单。如果一个组织主要与一个提供商合作，这可能是有充分理由的。正如哈钦斯解释的，与单一提供商合作可以加速创新并简化管理，提供可见性、原生集成和统一工具。

"好处是效率；风险是依赖性，"他说。

他补充说，他对CIO继续采用单一提供商策略没有问题——只要他们"睁大眼睛"管理它们。在实践中，这可能涉及在数据中建立可移植性，建立退出和故障转移计划，以及在生态系统外测试恢复。

布朗认为，这次故障实际上并不是对单一提供商问题的评论；如果组织在其单一提供商生态系统中建立了冗余，他们本可以避免大部分中断。这是因为单一提供商不需要等同于单一依赖。通过利用不同的区域和可用区，CIO可以分散风险。毕竟，AWS故障只影响了US-EAST-1。布朗表示，他相信这种方法能提供99%的弹性好处，同时也比多提供商策略更实用、更具成本效益。

"跨提供商故障转移在纸面上听起来很棒，但会引入大量复杂性，"他说。"关键是在你选择的生态系统内为故障进行架构设计。"

Q&A

Q1：AWS故障事件具体影响了哪些服务和公司？

A：此次故障源于AWS数据中心集群US-EAST-1的DNS故障，影响了数百万用户和超过1000家公司。受影响的包括社交媒体平台Reddit和Snapchat、劳埃德银行和哈利法克斯银行，以及热门游戏《堡垒之夜》和《Roblox》。然而，使用微软或谷歌产品的企业和个人完全不受影响。

Q2：企业应该如何平衡冗余投资和创新投资？

A：专家认为这应该是一个明智的风险决策，而不是假设的风险。CIO需要根据系统关键性进行有针对性的弹性投资：生产或面向客户的系统需要多区域或多提供商覆盖，而开发和测试环境可以容忍短暂停机。重要的是投资于故障会产生真正风险的地方，而不仅仅是轻微不便。

Q3：使用单一云提供商是否意味着更大的风险？

A：单一提供商不一定等同于单一依赖。通过利用不同的区域和可用区，CIO可以在单一提供商生态系统内分散风险。专家认为这种方法能提供99%的弹性好处，比多提供商策略更实用和具成本效益。关键是在选择的生态系统内为故障进行架构设计，同时建立数据可移植性和故障转移计划。