Coinbase 事后分析报告揭示：AWS 局部故障如何导致了持续数小时的交易中断

日程已上线 100%！6.26-27 AICon 上海站： 13大专题+1个动手实验室、近60场重磅议题，集结清华、复旦等知名高校教授及阿里、腾讯、字节、小红书、Google Cloud等头部企业技术专家，围绕Agent工程化落地等相关议题展开分享， 点击了解详情

这次故障始于 US-East-1 区域内某个 AWS 数据中心机房的多台冷却装置同时发生故障，导致受影响的机架被迫进行过热关机，并使

据 Coinbase 称，导致系统恢复延迟的最主要因素是其交易所匹配引擎的设计。为了满足高频交易所需的超低延迟要求，该系统是作为一个

该公司承认，虽然该架构优化了性能，但缺乏向另一个可用区进行故障转移的自动化机制。恢复过程需要紧急修改代码、手动重建集群，并在交易能够安全恢复之前谨慎地恢复法定节点数。这次事件暴露了一个典型的工程权衡：优化延迟和性能有时会牺牲掉基础设施故障期间的弹性。

Coinbase 的事后分析报告还指出了另一个涉及其事件流基础设施的问题。负责分发运营数据的

匹配引擎故障与消息积压的双重影响，将原本仅限于局部云基础设施的问题演变为整个平台的故障。Coinbase 指出，如果其中任何一个问题单独出现，原本都是可以应对的，但两者叠加导致恢复过程的复杂度远超预期。

对于云服务集中化的风险以及在超大规模基础设施上构建关键金融服务时所面临的现实运营问题，这次服务中断再次引发了相关的讨论。尽管 AWS 的区域设计基于多个可用区，但 Coinbase 事件表明，应用程序仍然可能对特定的位置产生隐性依赖，尤其是在性能要求促使其采用紧耦合架构的情况下。亚马逊云科技这次制冷系统故障还波及了在该区域内运营的其他主要平台和服务。

行业观察人士指出，这一事件凸显了云原生企业面临的一个日益严峻的挑战：仅仅在云服务提供商的基础设施上进行部署，并不能自动保证系统的弹性。在决定实际可用性方面，系统架构、工作负载部署、故障转移自动化以及运维假设往往比底层云平台本身发挥的作用更大。

Coinbase 的经历与其他大型科技公司近期发生的系统中断事件及工程事后分析如出一辙。在经历了几起可用性事件后，GitHub

这些事件的共同点在于，现代分布式系统很少因为单个组件出问题而发生故障。相反，服务中断通常发生在多个原本可单独处理的故障以意想不到的方式相互作用时。Coinbase 的事故分析报告再次印证了这一教训：亚马逊云科技的制冷系统故障是直接诱因，但服务中断的持续时间和影响，最终是由那些此前从未在实际故障条件下经过测试的架构假设所决定的。

对此，Coinbase 概要介绍了多项整改措施，包括为其匹配引擎配备跨区域自动恢复功能、改进 quorum 恢复流程、构建更具韧性的消息传递基础设施，以及扩大灾难恢复测试范围。该公司强调，虽然预防服务中断还是很重要，但加快从不可避免的故障中恢复同样至关重要。