一家拥有 4 亿美元资产、日均交易额超过 210 亿美元的公司，因为一次失败的部署，居然在 45 分钟内破产了。你也许听说过这个故事，却未必知道完整细节。

在之前的一个技术大会上，我发表了一个与 DevOps、配置即代码和持续交付相关的演讲。我用本文的故事说明了完全自动化和可重复的部署对于 DevOps 和持续交付来说是多么的重要。自从那次大会之后，有一些人希望我能够通过博客来分享接下来这个故事。需要说明的是：这个故事是真实的，它真的发生过。

新津资本集团(Knight Capital Group)是美国一家全球性金融服务公司，从事市场营销、电子执行、机构销售和电子交易等方面的业务。2012 年的时候，新津还是美国最大的股票交易商，在纽交所和纳斯达克的市场份额分别为 17% 左右。新津电子交易部门 (ETG)的日均交易量超过 33 亿笔，日均交易额超过 210 亿美元。

截止 2012 年 7 月 31 日，新津集团还拥有约 3.65 亿美元的现金和现金等价物。

纽约证券交易所计划在 2012 年 8 月 1 日推出一个新的零售流动性计划(该计划旨在通过像新津这样的零售经纪人为散户投资者提供更好的定价服务)。为了准备这次活动，新津升级了他们的自动化高速算法路由器，这个路由器将订单发送到交易市场去执行，也就是所谓的 SMARS。SMARS 的一个核心功能是接收来自新津交易平台其他组件的订单 (“父”订单)，然后将一个或多个“子”订单发送到交易中心。换句话说，SMARS 会从交易平台收到大订单，并将其分成多个较小的订单，以便找到与股票交易量匹配的买家 / 卖家。父订单越大，生成的子订单就越多。

对 SMARS 的更新是为了替换被称作“Power Peg”的老旧代码，后者在新津集团已经 8 年没有使用过了。(为什么已经废弃 8 年的代码仍然被保留在代码库中?这是一个谜，但这不是重点)。更新后的代码使用了一个旧标志，可用来激活 Power Peg 功能。代码经过了全面的测试，证明可以可靠地运行。

一切好像都没什么问题，黑天鹅事件却在不经意间来临了，并最终在 45 分钟内击垮了这家公司。

在 2012 年 7 月 27 日至 2012 年 7 月 31 日期间，新津每天会手动将新版本部署到八台服务器上。这就是美国证券交易委员会文件中所说的手动部署过程(顺便说一句，如果美国证券交易委员会文件提到了部署相关东西，可能意味着出现了严重的错误)。

在事发后的 2013 年 10 月 16 日美国证券交易委员会第 70694 号文件中，我们才了解到当时发生了什么：

“然而，在部署新代码期间，新津的一名技术人员没有将新代码复制到所有的 SMARS 计算机服务器上，而是漏掉了其中的一台。没有其他技术人员负责评审这个部署过程，也没有人知道 Power Peg 代码并没有从第八台服务器上删除，第八台服务器也没有部署新代码。新津没有正式的书面程序要求进行这样的评审。”

2012 年 8 月 1 日美国东部时间上午 9 点 30 分，股市开盘，新津开始代表客户处理新零售流动性计划订单。部署了新代码的七台 SMARS 服务器开始处理这些订单，但发送到第八台服务器的命令触发了使用旧代码的标志，激活了 Power Peg 功能。

我们有必要了解一下 Power Peg 代码是干什么用的。在执行子订单时，它会根据父订单计算购买 / 出售的股票数量。一旦父订单执行完成，Power Peg 会指示系统停止路由子订单。也就是说，Power Peg 会跟踪子订单，并在父订单完成后停止发送它们。早在 2005 年，新津就将这个累计跟踪功能移到了代码执行的较早阶段(因此从 Power Peg 中删除了计数跟踪功能)。

当第八台服务器上的 Power Peg 功能被激活后，它开始路由子订单，但却没有根据父订单的情况跟踪股票数量，这有点像一个死循环。

想象一下，如果你有一个系统，它会向市场自动快速发送订单，但不跟踪是否已经执行了足够多的订单，会发生什么?是的，后果很严重。

上午 9 点 30 分股市开盘，人们很快就知道出了问题。到上午 9 点 31 分，华尔街有很多人都清楚地看到一些严重的事情正在发生。股市上充斥着一些非正常交易量的股票订单。上午 9 点 32 分，华尔街的人开始寻思着为什么问题没有得到解决?为什么没有人使出必杀技来解决这个问题?事实是，根本就没有所谓的必杀技。在头 45 分钟里，新津的订单交易量占比超过 50%，将某些股价推高了 10%，而其他一些股价因错误交易而下跌。