对FT证券系统故障的分析与思考

富途证券因系统故障导致交易中断 创始人发文道歉
安全学习那些事儿 5天前

2021年10月9日凌晨，富途证券被爆因网络异常出现系列故障，包括资产清零、无法交易、甚至出现了资产清零的状态。在富途APP的交流板块中也看到，在大约10月9日凌晨1时左右，不少用户开始反映富途无法交易，看不到自己的资产等情况。

图片

2021年10月11日，富途创始人李华以“叶子哥”的身份在富途APP的社区“牛牛圈”中发布《关于2021.10.9凌晨交易中断事故的道歉和回复》文章，以下为全文。

关于2021.10.9凌晨交易中断事故的道歉和回复

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相关的表现上作出改进。

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

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

对富途证券系统故障的分析与思考
藍藝的科技创新实验室 今天
图片

2021年10月9日凌晨，富途证券被爆因网络异常出现系列故障，包括资产清零、无法交易等。根据富途10月10日晚间回应，此次事故主要原因，是富途在香港将军澳的托管机房电力闪断导致的多机房网络故障。

一

事故原因
图片

对于资产清零的问题，富途创始人解释，实际情况是因为故障导致了牛牛app跟后台数据的断开。在他看来，这是富途在产品设计上的一些不足，有改进空间。

在系统容灾的问题上，富途明确表示其系统是有作容灾设计的，从行情到交易，从服务器到交易网关到网络传输都有作双路或多路的冗余设计，不同的子系统的设计会有所不同。不考虑其他的冗余设计，光是因为行情源的冗余，一年增加的成本过千万港元。

但交易系统比较特殊，对时延有着非常高的要求。

“有客户问，你们是不是不愿意投入啊，才会有这个事故发生。”对此，富途表示不是投入的问题，是选择的问题，在实时热备的多路冗余交易系统的设计上会面临着两种选择：

一是较差的交易性能和更大的订单延时，但更好容灾能力的跨IDC多路冗余方案；

二是更好的交易性能和较小的订单提交延时但单一IDC的多路冗余方案，这使IDC本身有可能会成为故障的单点。

经过综合推演之后，富途选择了更好性能的方案二作为系统设计，也因此留下了IDC的单点故障隐患,这次事故恰恰就是IDC出了问题。

二

分析与思考
图片

对于上述事故，笔者想分享一下自己的分析和思考：

笔者以往曾在国内五大行、三大运营商以及欧美跨国企业中做过灾备，此次富途的服务中断事故，笔者以旁观者的身份，基于目前有限的信息推测，富途对此可能会花费较多时间对产品设计架构与灾备方案适配性进行底层较大改动和调整。

此次事故对于金融企业的业务连续性和风险是一个重要启发：灾备有着不可或缺的重要性，但灾备不是万能的，关键还要依据业务侧的善后处理的及时性与公关策略做补充配套。

1

灾备不是万能的，但没有灾备万万不能
图片

灾备中心的设立实质上是对极端灾难情况下科技风险的一种技术应对措施，可能在现实中大多数的生产中心在其生命周期内都不见得会遇到一次灾难事件，但是只要这种风险存在，那么灾备中心就要具备随时可切可用的能力。如同军队在无仗可打时要通过军事演习保持战斗力一样，定期的切换演练同样是保持和验证灾备中心可靠性、可用性的主要方法。

在军队训练中有句名言“如战斗般训练，如训练般战斗”，将领们发现在真实战场上完成任务的难度实际往往小于训练场的模拟，其高水平训练出高素质作战单位正是士兵们在多场战争中战损率之低的主要原因之一。这个道理其实可以完全移用到我们对待灾备演练的认识上。

2

灾备建设需要考虑循序渐进，量力而行
图片

在进行灾备数据中心的建设时，需要从大规模灾难的影响度，业务策略，成本，技术可用性，数据中心的环境，当地法律法规和审计的要求，以及和政府、服务商的关系等方面进行全面考量。

许多企业组织机构一味盲目地追求业务系统的连续性，购买最先进的设备和采用最先进的技术来创建灾备中心，浪费了很多资金。

灾备建设的投入巨大，不能一蹴而就一步到位，需要的是一个循序渐进的过程。灾难备份建设不是一个简单的技术方案，而是一项系统工程，灾备中心的基础建设、IT系统需要一个逐步建设的过程，运行维护团队、技术支持力量需要长期培养锻炼才能具备理想的应急能力。用户需要根据自身的实际需求量身打造，而在实际建设中，许多用户的灾备站点也都是经过长期积累、多次改造后形成的。

3

灾备准备和实施中，需要注意三个要点
图片

重视业务部门与IT部的协同联动

灾备建设最需避免的误区就是仅局限于科技侧。每一阶段中业务、风控、IT部门应彼此配合，分析当前正处于业务连续性计划建设的哪个阶段以及后备支援，根据实际情况的变更，即时调整公关策略与安抚受损客户，将风险有效的分散与化解

灾备需要依靠甲方自身团队能力

切换演练以什么形式切，切多少次，达到什么目标结果，需要灾备方法论结合实践经验。切换演练方案设计是项目切换演练阶段的核心任务，它涉及了应急预案、场景设计、切换步骤、演练组织等多个方面，依靠定期的演练与团队长期技能的培养。

灾备的核心目的

灾备中心能够实现业务系统的切换还只是成功了一半，真正业务能否正确运行并且对外服务一定时间，才能说明灾备中心的切换是成功的。灾备的核心目的不是阻止风险，而是降低危害程度，确保关键业务可维持，不致时间中断。

总结：

灾备建设是一个庞大的系统工程，从资金到人员的投入成本都很大，对于企业来说，灾备很重要，但平时的演练也十分重要。企业用户需要做好十全准备，经常演练，就不怕灾难发生后恢复不了数据，造成不必要的生产风险和浪费，不打无把握之战。