金融服务公司 Knight Capital Group 由于新软件部署失败，在 45 分钟内破产。
部署过程依赖于手动复制代码，这会导致激活旧的、未使用的代码，从而导致错误的交易。
Knight Capital Group 在 45 分钟内损失了 4.6 亿美元，不得不筹集资金来弥补损失。
这个警示故事强调了自动化和可重复部署过程对于避免灾难性错误的重要性。
本文讨论了一家公司因部署失败而破产的问题，强调了金融行业的软件腐烂和中层管理优先于软件质量的问题。它还探讨了自动化在预防此类事件中的作用以及更好的风险管理的必要性。开发人员编写了不向后兼容的代码，风险管理团队没有采取适当的行动，这两者都受到指责。本文最后强调了投资部署过程和拥有强大的部署工具的重要性。
Knight Capital Group是一家美国全球金融服务公司，从事做市、电子执行以及机构销售和交易。2012 年，Knight 是美国最大的股票交易商，在纽约证券交易所和纳斯达克市场的市场份额均约为 17%。Knight's Electronic Trading Group (ETG) 管理的日均交易量超过 33 亿笔，每日交易额超过 210 亿美元。这可不是开玩笑！
纽约证券交易所计划于 2012 年 8 月 1 日推出新的零售流动性计划。为准备此次活动，Knight 更新了其自动化、高速、算法将订单发送到市场执行的路由器，称为 SMARS。SMARS 的核心功能之一是从 Knights 交易平台的其他组件接收订单（“父”订单），然后发送一个或多个“子”订单执行。
换句话说，SMARS 将从交易平台接收大订单，并将其分解为多个较小的订单，以便找到与股票数量匹配的买家/卖家。父订单越大，生成的子订单就越多。
SMARS 的更新目的是替换旧的、未使用的代码（称为“Power Peg”），这是Knight 已经 8 年没有使用过的功能（为什么已经失效 8 年的代码仍然存在于代码库中）这是一个谜，但这不是重点）。更新的代码重新调整了用于激活 Power Peg 功能的旧标志的用途。该代码经过彻底测试并证明可以正确可靠地工作。
2012 年 7 月 27 日至 2012 年 7 月 31 日期间，Knight 每天将新软件手动部署到有限数量的服务器上，总共八 (8) 台服务器。这就是SEC 文件中关于手动部署过程的说明（顺便说一句，如果有 SEC 文件介绍您的部署，则可能出现了严重错误）。
"然而，在部署新代码的过程中，骑士公司的一名技术人员没有将新代码复制到SMARS八台计算机服务器中的一台。Knight 公司没有让第二名技术人员审查这次部署，Knight 公司没有人意识到第八台服务器上的 Power Peg 代码没有被删除，也没有添加新的 RLP 代码。Knight 公司没有要求进行这种审查的书面程序。“ - 美国证券交易委员会文件 | 第 70694 号公告 | 2013 年 10 月 16 日
东部时间 2012 年 8 月 1 日上午 9:30 市场开盘，奈特开始处理经纪商代表其客户发出的新零售流动性计划订单。部署了正确的 SMARS 的七（7）台服务器开始正确处理这些订单。发送到第八台服务器的订单触发了可能被重复使用的标志，使旧的 Power Peg 代码起死回生。
当第八服务器上的 Power Peg 标志被激活时，Power Peg 功能就开始执行子订单，但并不跟踪父订单的股票数量--有点像一个无休止的循环。
试想一下，如果您有一个能够向市场发送自动、高速订单的系统，却不跟踪是否有足够的订单被执行，会发生什么情况。是的，就是这么糟糕。
- 上午 9:30 开市时，人们很快就知道出了问题。
- 到上午 9:31 时，华尔街的许多人都明显感觉到发生了严重的事情。市场上充斥着大量订单，超出了某些股票正常交易量的正常范围。
- 到上午 9:32 时，华尔街的许多人都在想，为什么还没有停止。就高频量化交易而言，这已经是永恒的时间了。为什么没有人按下系统的终止开关呢？
事实证明，根本就没有 "死亡开关"。在头 45 分钟的交易中，Knight的执行量占交易量的 50%以上，使某些股票的价值上涨了 10%以上。结果，其他股票的价值因错误交易而下降。
更糟糕的是，Knight 的系统早在上午 8:01 就开始发送自动电子邮件（此时 SMARS 已经处理了符合盘前交易资格的订单）。电子邮件引用了 SMARS 并将错误标识为“Power Peg 已禁用”。上午 8:01 至 9:30 期间，共有 97 封此类电子邮件发送给 Knight 人员。当然，这些电子邮件并未被设计为系统警报，因此没有人立即查看它们。
Knight 经历的 45 分钟的地狱里，他们尝试了多种对策来试图阻止错误的交易。没有终止开关（也没有记录如何反应的程序），因此他们只能在每分钟交易 800 万股的实时交易环境中尝试诊断问题。
由于他们无法确定导致错误订单的原因，因此他们通过从正确部署的服务器上卸载新代码来做出反应。换句话说，他们删除了工作代码并留下了损坏的代码。这只会放大问题，导致额外的父命令在所有服务器上激活 Power Peg 代码，而不仅仅是未正确部署的服务器。最终他们在 45 分钟的交易后停止了系统。
在市场开放的前 45 分钟内，Power Peg 代码接收并处理了 212 个母订单。结果，SMARS 向市场发送了数百万个子订单，导致 154 只股票进行了 400 万笔交易，交易量超过 3.97 亿股。
45分钟内，Knight 从美国股票最大交易商、纽约证券交易所和纳斯达克主要做市商变成了破产者。他们有 48 小时的时间筹集必要的资金来弥补损失。
Knight Capital Group 最终被 Getco LLC 收购（2012 年 12 月），合并后的公司现更名为 KCG Holdings。
2012 年 8 月 1 日发生的事件应该给所有开发和运营团队上一课。仅仅开发出优秀的软件并对其进行测试是不够的，还必须确保正确地将其推向市场，这样客户才能获得所交付的价值（这样公司才不会破产）。
在这里，部署 SMARS 的工程师并不是唯一的罪魁祸首--Knight 所设置的流程并不适合他们所面临的风险。此外，他们的流程（或缺乏流程）本身就容易出错。任何时候，如果你的部署流程依赖于人类阅读和遵循指令，你就会面临风险。人类会犯错误。这些错误可能发生在指令中，可能发生在对指令的解释中，也可能发生在指令的执行中。
部署需要自动化、可重复，并尽可能避免潜在的人为错误。如果 Knight 实施了自动化部署系统（包括配置、部署和测试自动化），那么导致 Knightmare 的错误就可以避免。
持续交付的一些原则在这里也适用（即使你没有实施完整的持续交付流程）：
- 发布软件应该是一个可重复、可靠的过程。
- 尽可能实现自动化。