富途证券因数据中心故障导致交易中断，创始人发文道歉

10 月 9 日凌晨，互联网券商富途出现故障，用户无法登录 App 进行交易，甚至出现了资产清零的状态。

9 日下午，富途证券发布相关说明并致歉。富途表示，事故原因为“运营商机房电力闪断导致的多机房网络故障”，公司已于第一时间联系运营商进行修复，并在 2 小时内陆续恢复核心服务。后续富途表示将进一步提升多运营商多机房的网络容灾能力，提升核心服务的稳定性，避免类似问题的再次发生。

富途证券一向以“技术”为豪，和传统券商不同，富途没有线下营业部，用户只通过线上开户进行交易。但全部业务依托线上通道完成，就意味着富途对技术的依赖比传统券商高。其创始人兼董事长李华是腾讯第 18 号员工，同时也是 QQ 产品重要参与者和腾讯视频创始人之一，领导过腾讯视频产品设计和开发。在李华看来，富途之所以能弯道超车，花 3 年到达传统券商 10 多年积累才能达到的高度，技术是最重要的一环。

10 月 11 日中午，技术出身的富途创始人李华再发 2000 字长文道歉和回复，引起市场关注。

有关系统容灾的问题，李华表示，富途的系统是有做容灾设计的，从行情到交易，从服务器到交易网关到网络传输都有做双路或多路的冗余设计。不同的子系统设计会有所不同。

以行情为例，单向传输为主、对时延的敏感度也不是那么高，富途很早就作了多区域多 IDC 的容灾设计；尤其像美股行情，涉及到越洋传输，为避免中断，富途选择了全球顶级的两家行情供应商分别提供行情源，分别从美国、香港多地多点接入，当这些都不可用时，富途还保留了富途美国 IDC 直传的能力。不考虑其他的冗余设计，光是因为行情源的冗余，富途一年增加的成本过千万港元。

李华指出，在实时热备的多路冗余交易系统的设计上会面临着两种选择。一是较差的交易性能更大的订单延时但更好容灾能力的跨 IDC 多路冗余方案，二是更好的交易性能较小的订单提交延时单一 IDC 的多路冗余方案，但 IDC 本身会成为故障的单点。

这也间接导致了一定要做出选择。在李华看来，考虑到 IDC 的建设标准，IDC 的大级别事故是罕见的，尤其是在电力故障方面。经过综合推演之后，富途选择了更好性能的方案二，也因此留下了 IDC 的单点故障隐患。这次事故恰恰就是 IDC 出了问题，而且是最不应该出现问题的电力系统出了问题，不间断电源和柴油发电机都没能发挥应有的作用。

附：李华回应全文

10 月 9 日凌晨 1 点 26 分，事故发生后不少客户 at 我，有批评、有建议、有鼓励，由于 9 号早晨还要去出差，会有几个小时在飞机上，就没来得及一一回复。不论如何都要谢谢你们，因为你们，我才觉得富途所作的事情格外有意义，我们可以去努力和改善的地方还有非常多。

 

首先我要向大家郑重及诚恳地道歉：真的很对不起，让你们失望了，我们虚心接受所有的批评和建议，并会立即着手相应的改进。

 

虽然几次影响大、耗时长的事故都与不可控的外部依赖有着直接的关系，但给到客户的感受都是一样的，那就是富途的服务不可用了。因此，我们责无旁贷，也不会把应该我们解决的问题推到外部，只会看在我们可控的范围内如何可以做得更好。

 

1、末日期权价值归零的补偿问题。

 

有购买了末日期权因故障未能及时平仓导致价值归零的客户在问是否会补偿，从周末开始针对这类客户我们的客服已经在逐一联系，会根据具体的情况沟通对应的补偿方案。

 

2、有关系统容灾的问题。

 

首先可以确定的是，富途的系统是有作容灾设计的，从行情到交易，从服务器到交易网关到网络传输都有作双路或多路的冗余设计。不同的子系统的设计会有所不同。

 

富途的客户中不乏技术达人，这次事故后，不少有技术背景的客户针对系统的容灾给了各种的建议，尤其是有关多区域多 IDC 的容灾建议。在此表示感谢！

 

以行情为例，单向传输为主、对时延的敏感度也不是那么高，我们很早就作了多区域多 IDC 的容灾设计；尤其像美股行情，涉及到越洋传输，为避免中断，我们选择了全球顶级的两家行情供应商为我们分别提供行情源，分别从美国、香港多地多点接入，当这些都不可用时，我们还保留了富途美国 IDC 直传的能力。不考虑其他的冗余设计，光是因为行情源的冗余，一年增加的成本过千万港元。

 

交易系统比较特殊，对时延有着非常高的要求。所有的多路冗余热备系统都存在时延大小和数据一致性的冲突；物理位置越分散，比如跨 IDC、跨区域，为确保数据一致性，时延就会越大。跨 IDC、跨区域的数据一致性的时延问题好解决吗？不好解决。因为在我们生活的这个宇宙，光速或电子流动的速度每秒钟 30 万公里就已经是极限，这也意味着在理论状态下物理位置每间隔 300 公里的网络传输就会存在 1 毫秒的时延；这还仅仅是在理论状态下，实际上如果加上光电转换、加上路由跳转，300 公里的传输能作到不超过 5 毫秒已是优秀。那么 5 毫秒算长吗？5 毫秒从一般的认知来看也不算长，但对于数据一致性来说就算很长了，光一个网络传输一来一回就是 10 毫秒；就具体的交易场景来说，你可能啥也没作，只是因为热备的数据一致性的需要，网络传输延时加上各类写操作的延时和同步确认的延时，你的订单还没有提交出去可能就消耗掉了几十毫秒，且这还只是理论值，实际上有机会更多。

 

基于上边的描述，在实时热备的多路冗余交易系统的设计上会面临着两种选择。一是较差的交易性能更大的订单延时但更好容灾能力的跨 IDC 多路冗余方案，二是更好的交易性能较小的订单提交延时单一 IDC 的多路冗余方案，但 IDC 本身会成为故障的单点。有客户问，你们是不是不愿意投入啊，才会有这个事故发生；看到这里，你会发现其实不是投入的问题，是选择的问题。

 

考虑到 IDC 的建设标准，IDC 的大级别事故是罕见的，尤其是在电力故障方面。经过综合推演之后，我们选择了更好性能的方案二作为我们的系统设计，也因此留下了 IDC 的单点故障隐患。这次事故恰恰就是 IDC 出了问题，而且是最不应该出现问题的电力系统出了问题。

 

供电网络一个几秒钟的电压抖动，IDC 一堆网络 IT 设备跟着关机或重启，实在是难以想象，说好的不间断电源和柴油发电机去哪了？不间断电源和柴油发电机竟然都没能发挥应有的作用，要知道电力保障是一个 IDC 之所以是 IDC 的最基础能力。另一方面也暴露了我们的系统在这种情况下的脆弱。

 

这次事故的恢复时间以小时计，给我们的教训和启发都非常大。两害相权取其轻，相对于小时级的故障时间，假如我们可以接受一个分钟级的故障时间，那么在方案二的基础上是不是可以有一个兼顾交易性能低订单延时又支持跨 IDC 的准热备方案呢？答案是有的，接下来我们就会对这里作进一步的研究和推进。

 

3、有关资产显示的问题。

 

这次事故让我看到了我们在产品设计上的一些欠周到。事故发生时，有客户发现自己的持仓和资产数据都没了，这让人感到非常惊悚，马上就有人在牛牛圈上问“富途是不是卷款跑路了？”。实际情况是因为故障导致了牛牛 app 跟后台数据的断开；既然只是断开，那前端 app 的表现为何是作清空的处理？显然以最后可以正常显示的数据快照继续展示会是更好的实现方案；虽然数据不会作实时更新了，但给到人的心理感觉会安定很多。在这里我要给受到惊吓的客户们道歉，接下来也会在 app 相关的表现上作出改进。

 

以上是我想要重点回复的三个问题。

 

这次事故值得我和团队们总结和反思地方非常多，教训和警示也都非常深刻。我们不会去做无意义的辩解，立足当下作好改进会来得更重要；我们也从未因为富途有了一点体量和成绩就感到自大和自满，只期望通过我们的持续努力不辜负您们的信任。

 

再次道歉并感谢！