从光大证券交易系统 8.16 事件说起

8 月 18 日，中国证监会新闻发言人通报了 8 月 16 日上午的“光大证券交易异常”事件的初步核查情况，认为问题源于光大证券自营策略交易系统存在缺陷。

8 月 16 日 11 时 5 分左右，上证综指突然上涨 5.96%，中石油、中石化、工商银行和中国银行等权重股均触及涨停。证监会核查发现：主要买入方为光大证券自营账户。后光大证券申请：午后暂停其股票的交易。

事件发生后，多方认为此次事件是一次“乌龙指”事件，也就是说可能是股票交易员、操盘手、股民等在交易的时候，不小心敲错了价格、数量、买卖方向等。

8 月 18 日，证监会初步核查的结果显示：光大证券自营的策略交易系统包含订单生成系统和订单执行系统两个部分，存在程序调用错误、额度控制失效等设计缺陷，并被连锁触发，导致生成巨量市价委托订单，直接发送至上交所，累计申报买入 234 亿元，实际成交 72.7 亿元。此外，在核查中尚未发现人为操作差错，但光大证券该项业务内部控制存在明显缺陷，信息系统管理问题较多。

证券金融机构的系统事故近年来在国内外时有发生。

• 2008 年 9 月 8 日，伦敦证券交易所当天却因为网络连接技术故障停盘近 7 个小时，令不少投资者痛失大好时机。有人推测是因为微软平台的缘故。一年半之后，伦敦证交所将系统切换到 Linux 平台之上。在 2011 年 2 月 25 日上午，伦敦证交所在当天早晨开盘竞价时发现“市场数据”部分出现故障，因此又停盘处理这一问题。他们使用的“千年信息技术”交易系统于 2 月 14 号刚刚启用。
• 2012 年 2 月 2 日，东京证券交易所系统开盘前出现故障，导致 241 只股票停止交易。东京证交所表示，这次出现故障的是传递交易信息的系统。投资者在发出交易请求后，即使交易成功，股价也无法传递到投资者那里。进入午盘，东京证交所的系统得到恢复。
• 2012 年 3 月，美国第三大证券交易所运营商 BATS 在上市当日经历一次严重技术故障后宣布取消上市。随后，由于纳斯达克的系统瘫痪，社交网络巨头 Facebook 股票上市当天开盘时间被推迟了 30 分钟，交易故障给投资者造成了前所未有的困惑和混乱。
• 2012 年 8 月，骑士资本由于技术故障在 45 分钟内损失 4.4 亿美元。
• 2012 年 8 月 6 日，由于技术故障，西班牙股票交易所被迫暂停交易近 5 个小时。
• 2012 年 11 月 28 日，瑞典斯德哥尔摩证券交易所因为程序 bug，导致交易系统中断了数小时。自动交易系统发出了 4,294,967,290 指数期货购买指令，每份价值约等于 16,000 美元，总价值 69 万亿美元，是瑞典 GDP 的 131 倍。这项交易后被废止，但它的后遗症导致交易系统中止了数小时。

不仅是证券行业，银行业今年在国内也颇不平静。

之前，InfoQ曾就去年中国银行 IBM 大型机宕机事件，采访了兴业银行的系统分析师周伟然和支付宝的应用运维架构师。

优秀的金融系统，需要设计、开发、测试、运维等多个环节的配合与反馈。不妨回顾一下这些环节的优秀内容，希望其中的观点和实践能为广大读者提供有价值的参考。

兴业银行的系统分析师周伟然曾在 InfoQ 中文站主办的全球架构师峰会上做《联机服务平台的安全运行设计》的演讲，其中以几个基于商业中间件的架构、以及轻量级联机服务的架构为例，从不间断运行、流量控制、故障隔离、交易运行时间控制、系统超时等方面对 Native Code 联机服务系统的高可用性架构设计进行讨论。

中文站还曾有一篇文章——《关注网银系统：安全模型和架构设计》，简要描述了网上银行普遍采用的安全系统架构以及相关技术。文章在分析安全性需求的基础上，引入了目前网上银行最为著名的安全系统架构模型——PPDRR 模型，即策略 (Policy)、防护 (Protection)、检测 (Detection)、响应 (Response) 和恢复 (Recovery)，并认为这是“一种动态的、自适应的安全模型，可适应安全风险和安全需求的不断变化，提供持续的安全保障“。

平安科技应用开发支持部门的测试工程师刘毅，在自己的博客中撰写了一篇文章——《紧耦合金融系统群的测试自动化策略（一）》，其中讲到了单元测试、环境监控、测试数据和持续集成方面的方针和策略。文中的背景部分提到：

科技子公司或者 IT 部门在一个大金融团体里面只能算是个成本中心，对 IT 团队来说，核心使命就是稳定运营、降低成本。这对于自动化测试来说，意味着非常有限的资源预算、不稳定的测试环境、复杂的系统耦合关系、严苛的测试数据要求，还有那近乎无理的信息安全规范。如此种种，让我们并不能按照自己想象的那样去实施自己的规划，以致会走很多弯路；而再回首你会觉得，有时候只是方法欠妥而不是资源不够，有时候只是导向错误而非技术不够高。

除了技术方面，应用好的项目管理的框架与实践重要，InfoQ 中文站曾经发布过一篇虚拟座谈会——《 Scrum 是否适用于金融电信行业？ 》，其中对如何在金融行业应用 Scrum 等框架有深入讨论，时任上海惠普资深敏捷顾问的徐毅提到：

金融电信业相对目前蓬勃发展的互联网行业而言，采用的技术相对落后，多采用重型软件开发方法，产品开发所涉及的人员为数众多，这恰恰需要敏捷来解除束缚释放出潜藏的巨大生产力。

当今这个高速发展的全球化和信息社会，金融行业发挥了心脏的作用，不停为其他行业造血——提供资金，而金融行业的 IT 系统又相当于他们自己的心脏，是重中之重，这也使得金融一直走在 IT 技术和系统的前列。然而，这些时常出现在耳边的故障，却总令社会公众有种种担心。作为 IT 从业者，我们有责任、有义务将自己的事情做得更好、更完善、更到位，从而尽可能避免类似问题发生。