此次事故暴露出部分交易所的安全水准较低，对紧急事故的处理效率低下，最终造成了事态的进一步恶化，也为整个交易所行业再次敲响了警钟。

作者|大文

头图|Unsplash

8月23日下午，亚马逊旗下Amazon Web Services (AWS)出现Bug，AWS状态页面显示其东京服务区存在问题。目前AWS表示已找到根本原因，正在进行恢复。受此影响，“Azulene”，“Grasma”等多款游戏出现故障，此外，受影响的还有加密货币交易所，甚至有投资者晒出了0.32美金的价格成交40个比特币的交易截图，引发了大量关注。

目前可以确认的是，大部分交易所仅受到了轻微的波及，如币安、Bithumb、Kucoin、追币等交易所，仅仅出现了短暂的掉线和服务不可用。但也有一部分交易所受到了较为严重的损害，CoinEgg进行了停机维护，Bitmax暂停了事发时段内交易账户的交易服务，BKEX则暂停了部分交易对。

事件发生后，链得得多方求证，还原了部分事故细节。

根据雅虎日本的消息，当地时间13：05（北京时间12：05），AWS东京地区的亚太服务器(ap-northeast-1)的通信部分出现了故障，部分EC2和redis不可用。10分钟后，AWS主控面板通知表示，部分用户受到影响。一个小时之后，服务器状态恶化，ap-northeast-1a服务器数据库受到影响，AWS 东京的 Redis 服务器的创建等服务全部宕机。受到轻微波及的追币交易所告诉链得得App，AWS东京业务区 1a、1b、1c 三个可用区中，1a区遭受较大的影响，1b和1c受影响轻微。

据安全机构PeckShield分析称，部分交易所使用的AWS日本机房缓存服务器出现问题，会导致用户端和服务器的实时数据同步出现错位，可能存在多种问题：

1.用户提交的订单没被及时受理，从而造成二次下单等影响用户使用体验；

2.用户看到的价格信息和真实的价格信息有出入，导致用户产生错误的下单判断，造成订单难以成就或者成交之后给一方造成损失。

总之，AWS服务器问题会影响用户的使用体验，而其它平台上看到的价格异常是由于他们在评估当前价格的机制决定的，并不能反映真实的成交价格，导致用户产生错误的交易判断。

安全专家认为，如果交易所受损严重，很可能会对交易进行回滚。回滚是交易所应对损失的方法之一，交易回滚后，之前的交易会全部作废。2018年3月，币安Binance被黑客攻击，大量用户发现自己的账户被盗，账户中大量代币被恶意抛售为比特币（BTC），盘面上绝大多数币种呈现快速下跌。对此异常，币安迅速暂停了其平台的所有提币行为，使黑客无法套现，并且对交易进行了回滚操作。

这并不是云服务第一次出现故障而导致用户遭受损失：去年8月，腾讯云用户北京清博数控科技有限公司所属“前沿数控”向腾讯云提出千万元的索赔要求，因其平台的操作系统云盘受所在物理硬盘固件版本bug导致的磁盘静默错误(写入数据和读取出来的不一致)影响，文件系统元数据损坏。

即使是全球最顶尖的云服务公司之一的谷歌，也难逃极小概率事件导致的数据丢失：2015年，谷歌位于比利时的数据中心由于遭遇了4次雷击而出现了部分数据丢失的情况。虽然谷歌尝试重新进入受到损害的磁盘，但一些谷歌用户的数据仍旧没能得到挽救。也就是说，他们将永远失去自己的部分个人数据。虽然谷歌特别强调，即便事态再严重丢失的数据仍非常非常地小，永久被删除的数据只占了该数据中心的0.000001%，并没有导致严重后果和损失。

但在区块链领域，尤其对于交易所来说，云服务的质量堪比命脉。由于加密钱包的特殊性，储存于云服务器上的数据哪怕仅有若干个字符丢失，都可能造成整个钱包中所有的加密货币丢失——而且完全无法找回。

云服务出现问题导致数字货币交易所出现问题并不是第一次发生。2012年，VPS服务提供商Linode发表声明，表示受到了攻击，攻击者未授权访问了受害者的客户服务门户，但只有8个客户受影响，且都是比特币相关客户。其中一名受害者是交易所Bitcoinica，据称攻击者窃取了超过4.3万个比特币，这次事件也直接导致了Bitcoinica的重组。一个月后，再次受到攻击的Bitcoinica最终销声匿迹。

通过对本次AWS宕机事件细节的回顾我们可以发现，本次事件并不是毫无预兆的。在服务器发生故障的初期，对交易所的影响非常小。最致命的故障发生在70分钟后，AWS 1a组机器的RDS（俗称数据库）部分开始宕机，这也直接导致了大量用户受到更严重的影响。

追币交易所告诉链得得App，在发现问题之后，他们紧急联系了AWS技术支持部门，并在事件发生后约5分钟启动了交易所数据安全紧急预案，及时修改可用区，并通过技术手段积极规避此次故障带来的继发影响。

作为亚马逊云计算服务平台的用户，追币交易所随后与AWS在台湾的技术团队沟通，寻求可靠的解决方案。在与其沟通中，追币与AWS台湾团队发现了更多的问题。如，1a 组由于机器硬件设备故障，导致AWS自己也无法连通。部分多可用区的服务只能勉强维持，随着影响范围地逐渐扩大，AWS东京的 Redis 服务器的创建等服务全部宕机。

因此，追币实际受影响服务在故障发生后15分钟左右即得到了有效的恢复。受影响较为严重的交易所，很可能没有在70分钟内及时将服务迁移到其他服务器上，最终不得不承受故障升级导致的严重后果。

作为区块链行业的核心之一，交易所毫无疑问需要更严苛的安全措施。此次事故暴露出部分交易所的安全水准较低，对紧急事故的处理效率低下，最终造成了事态的进一步恶化，也为整个交易所行业再次敲响了警钟。

来源：链得得