自动化部署与持续交付：骑士资本集团45分钟内的破产警示录

在一场技术大会上，我曾以一次真实的金融灾难为例，深入剖析了DevOps、配置即代码以及持续交付中自动化、可重复部署的重要性。该故事引起了广泛兴趣，因此在此通过博客详述整个事件。请注意，这不是虚构，而是真实发生的历史一幕。

故事背景

曾经的骑士资本集团（Knight Capital Group），这家坐拥4亿美元资产，在纽交所和纳斯达克市场占有率均高达17%左右的全球金融服务巨头，其电子交易部门日均交易额更是超过210亿美元。2012年8月1日，纽约证券交易所计划启动一项零售流动性计划，为了适应这一变化，骑士决定升级自家的核心系统——自动化高速算法路由器SMARS，该系统负责拆分并执行从交易平台传来的“父”订单为多个“子”订单，实现高效撮合买卖双方。

然而，这次更新过程牵涉到了一段废弃长达8年的老旧代码"Power Peg"，尽管它早已被弃用且原因不明，但新版本却错误地保留了一个能激活该功能的旧标志。经过全面测试后，团队认为新代码运行稳定可靠。

然而，黑天鹅事件悄然降临，短短45分钟内，这个看似无害的疏漏竟将一家行业巨擘推向了破产边缘。

问题症结

在2012年7月27日至31日期间，骑士采取手动方式每天将新版本部署到八台服务器上，这是美国证券交易委员会文件揭示的手动部署环节，往往预示着潜在的重大失误。

根据美国证券交易委员会2013年10月16日第70694号文件透露，一名技术人员在部署过程中犯下致命错误，未将新代码复制到所有服务器上，其中一台服务器遗漏了更新。更为严重的是，没有任何其他技术人员对部署过程进行复核，导致那台遗留了Power Peg旧代码且未部署新代码的第八台服务器成为了危机爆发点。

僵死代码引发的风暴

被意外激活的Power Peg代码原本设计用于跟踪父订单执行情况，并在完成时停止发送子订单。然而，由于早于2005年已移除了该计数跟踪功能，当它在第八台服务器上复活时，就像失控的循环一样，不断发出子订单而不顾及父订单实际执行状态。

毁灭性的45分钟

设想一下，如果有一个系统自动快速下单却无法追踪订单是否已达上限，会发生什么？答案是灾难性的后果。

2012年8月1日股市开盘仅半小时，异样的交易量就引发了市场的警觉。上午9点30分开盘后，异常交易现象迅速蔓延，部分股票因超额买入而股价飙升10%，另一些则因错误卖出而大幅下跌。更令人惊讶的是，在问题暴露后的前45分钟里，骑士处理的订单量一度占到市场半壁江山，期间还无人能找出迅速止损的方法。究其原因，他们既缺乏应对这类紧急状况的标准程序，也无法实时准确诊断出问题所在。在试图回滚新代码的过程中，反而扩大了问题范围，最终在交易开始45分钟后被迫关闭了系统。

惨痛教训

这场由部署流程疏忽引发的金融风暴给所有开发和运营团队敲响了警钟。研发优质软件并进行全面测试仅仅是成功的一半，确保软件正确、安全地交付至市场同样至关重要，否则可能酿成让公司瞬间破产的大祸。此次事件中，部署工程师并非唯一的责任人，骑士的问题根源在于其部署流程未能充分考虑到面临的风险，而且整个流程天然存在易于出错的人工操作环节。

关键启示在于，部署应当实现自动化且可重复，最大程度减少人为错误。若骑士当时的部署系统实现了配置、部署及测试的自动化，或许就能避免这场悲剧的发生。对于持续交付而言，以下两点原则尤为重要：

软件发布应是一个可重复、可靠的流程；




尽可能实现自动化。





你是否也了解过类似的因研发、部署流程问题而导致的重大IT故障案例呢？欢迎在评论区分享讨论！

SMARS币