Coinbase 发布了一份关于 2026 年 5 月 7 日服务中断事件的详细事后分析报告，揭示了 AWS 数据中心内一次局部制冷故障如何演变为持续数小时的中断，导致该加密货币交易所几乎所有的交易活动都陷入了停滞。虽然事件最初是源于单个可用区内的 AWS 过热事件，但 Coinbase 的调查发现，其自身系统的架构依赖关系（包括与受影响可用区紧密耦合的匹配引擎，以及消息传递基础设施的连锁故障）显著延长了恢复时间。
这次故障始于 US-East-1 区域内某个 AWS 数据中心机房的多台冷却装置同时发生故障，导致受影响的机架被迫进行过热关机，并使 EC2 实例和 EBS 卷离线。Coinbase 用户在数小时内无法进行资产的买卖、存入、提取或转账，而机构客户的订单路由和交易服务也普遍受到了干扰。完全恢复几乎用了次日一整天的时间，交易功能通过“仅取消”和“拍卖”模式逐步恢复，随后才恢复正常运营。
据 Coinbase 称，导致系统恢复延迟的最主要因素是其交易所匹配引擎的设计。为了满足高频交易所需的超低延迟要求，该系统是作为一个基于 Raft 的集群，运行于单个 AWS 集群放置组内。这种架构通过有意将节点集中部署，最大限度地降低了共识成员之间的网络延迟。然而，当 AWS 服务中断导致该集群的五个节点中有三个瘫痪时，系统无法满足 Raft 共识所需的法定节点数，从而无法再处理交易。
该公司承认，虽然该架构优化了性能，但缺乏向另一个可用区进行故障转移的自动化机制。恢复过程需要紧急修改代码、手动重建集群，并在交易能够安全恢复之前谨慎地恢复法定节点数。这次事件暴露了一个典型的工程权衡：优化延迟和性能有时会牺牲掉基础设施故障期间的弹性。
Coinbase 的事后分析报告还指出了另一个涉及其事件流基础设施的问题。负责分发运营数据的 Kafka 工作负载在受影响的可用区中陷入停滞，导致大量数据积压，甚至在核心交易系统开始恢复之后还延迟了服务的恢复。工程师最终不得不手动迁移分区并重新平衡工作负载，这才恢复了整个平台的正常数据流。
匹配引擎故障与消息积压的双重影响，将原本仅限于局部云基础设施的问题演变为整个平台的故障。Coinbase 指出，如果其中任何一个问题单独出现，原本都是可以应对的，但两者叠加导致恢复过程的复杂度远超预期。
对于云服务集中化的风险以及在超大规模基础设施上构建关键金融服务时所面临的现实运营问题，这次服务中断再次引发了相关的讨论。尽管 AWS 的区域设计基于多个可用区，但 Coinbase 事件表明，应用程序仍然可能对特定的位置产生隐性依赖，尤其是在性能要求促使其采用紧耦合架构的情况下。亚马逊云科技这次制冷系统故障还波及了在该区域内运营的其他主要平台和服务。
行业观察人士指出，这一事件凸显了云原生企业面临的一个日益严峻的挑战：仅仅在云服务提供商的基础设施上进行部署，并不能自动保证系统的弹性。在决定实际可用性方面，系统架构、工作负载部署、故障转移自动化以及运维假设往往比底层云平台本身发挥的作用更大。
Coinbase 的经历与其他大型科技公司近期发生的系统中断事件及工程事后分析如出一辙。在经历了几起可用性事件后，GitHub 强调了消除隐藏的基础设施假设的重要性，这些事件暴露了系统之间意想不到的依赖关系。Discord 近期在 ScyllaDB 运维自动化方面开展的工作，同样侧重于通过编排和自动化来降低恢复复杂性，并将基础设施故障的影响降至最低。与此同时，Netflix 在发现基础设施故障往往源于微妙的架构耦合而非单点故障后，已经在投入大量资源开展韧性工程和工作负载隔离。
这些事件的共同点在于，现代分布式系统很少因为单个组件出问题而发生故障。相反，服务中断通常发生在多个原本可单独处理的故障以意想不到的方式相互作用时。Coinbase 的事故分析报告再次印证了这一教训：亚马逊云科技的制冷系统故障是直接诱因，但服务中断的持续时间和影响，最终是由那些此前从未在实际故障条件下经过测试的架构假设所决定的。
对此，Coinbase 概要介绍了多项整改措施，包括为其匹配引擎配备跨区域自动恢复功能、改进 quorum 恢复流程、构建更具韧性的消息传递基础设施，以及扩大灾难恢复测试范围。该公司强调，虽然预防服务中断还是很重要，但加快从不可避免的故障中恢复同样至关重要。
原文链接：https://www.infoq.com/news/2026/06/stack-overflow-for-agents/
