Coinbase 转向以人工智能为主导的运营进展不顺利

Coinbase（纳斯达克：COIN）再次向加密交易者证明：云端硬件的迟缓也能拖慢即便运行很快的交易所。看起来，这家公司的基于AI的运营转型策略可能是它迄今为止最糟糕的一次决策。

周五，该公司表示，Amazon Web Services（纳斯达克：AMZN）内部的一次冷却故障触发了持续数小时的停机，影响了其平台上的交易、交易所访问以及余额更新。

问题始于5月7日大约23:50（UTC）左右，当时内部监控发现公司系统内部出现了大范围的报价失败“爆发”。

当时，工程师已创建了多个Sev1事件，而客户的多项服务已受到影响，包括现货交易、Coinbase Prime、International、衍生品、Retail、Advanced以及Institutional等交易所相关服务。

Coinbase首席执行官Brian Armstrong在X上写道，公司“经历了一次停机”，而这种情况“绝不可以接受”。据他称，原因是“由于多台冷却器故障，AWS数据中心内的一个房间过热”。

根据Brian的说法，公司确保所有服务都以这样的方式进行设计：即使某个AWS可用区失败，也不会让服务下线。大多数服务都采用这种结构，唯独交易所因其高延迟要求而采用了不同的基础设施。

Coinbase将报价系统在午夜UTC前开始崩溃归咎于AWS冷却器故障

此前，Cryptopolitan报道称，Coinbase计划解雇700名员工，因为这约占其总员工数的14%。并且这样做的意图是用AI替代手动流程。

Coinbase平台负责人Rob Witoff就此提供了技术细节。根据他说法，此次停机持续了较长时间，并影响了“交易、交易所访问和余额更新”。

初始警报于23:50（UTC）左右发出，原因是来自内部系统的报价失败。随后立即进行了Sev1级别的分析。Rob表示，这次挑战的原因是AWS us-east-1某一设施中少量机架发生了“热事件”。

这种交易所基础设施的结构在关键时刻派上了用场。Rob说，Coinbase将其交易基础设施部署在单一可用区，因为行业看重速度。

此外，该公司还为此类情景准备了该交易基础设施的分布式备份副本。但此刻，所涉交易基础设施的某一部分故障并没有局限在其边界内，导致修复过程被拉长。

两个组件出现故障。匹配引擎下方的硬件发生了故障。因此，在任何其他操作之前，需要先执行恢复与故障转移（failover）操作。

同时，负责在组织内所有系统之间共享信息的分布式Kafka集群也宕机了。将Kafka分区恢复到新的硬件broker上，涉及TiBs级别的信息量。

工程师重建仲裁组，并通过仅取消订单和拍卖模式让Coinbase市场恢复

匹配引擎负责造成最大规模的交易中断。匹配引擎处理订单并维护订单簿。该系统在分布式集群中运行，在安全地选择领导者并进行交易之前，需要仲裁组（quorum）。

由于停机期间数据中心的约束条件导致并非所有节点保持健康，无法达成仲裁组，从而阻止了Retail、Advanced和Institutional等交易所的交易活动。

Rob提到，值班支持和工程团队不得不执行公司的灾难恢复程序，建立仲裁组，并在艰难的基础设施条件下评估系统健康状况。

根据他说法，团队需要在处理更大范围的停机的同时，开发、测试、部署并验证一个解决方案。由于其分区架构每天管理数千TB数据，Kafka本应需要进行大量手动恢复工作量。

由于Kafka落后，余额流出现了一些延迟问题。Rob表示，这些与余额相关的问题在复制变得同步之后消失。据Coinbase称，没有数据丢失。

当匹配引擎恢复到可用状态后，市场并未同时被重新启用。首先，Coinbase将所有产品切换到仅取消订单模式，检查产品状态；随后将所有市场切换到拍卖模式；最后在Coinbase Exchange上启用交易。

此外，Rob强调，客户不应在临时期间被锁在账户之外。Coinbase向所有人保证，公司将在数周内对本次事件提供详细说明。

不过，Josh Ellithorpe在读到Rob在Twitter上的帖子后反驳了相关传闻。正如他所说：“没有人写代码却导致了失败。一个‘非工程师’没有推送生产代码，也没有把交易引擎搞垮。这不是故意的，也不是因为Coinbase没有设计好故障转移系统。规模化环境下会发生事情，别让坐在橱柜椅子上的人编造故事来误导你。”

如果你想更平静地切入DeFi加密领域，而不被通常的炒作所裹挟，可以从这段免费的公开视频开始。