骑士资本（Knight Capital）是一家证券交易所的金融服务公司，也是美国市场上最大的交易商之一。其在纽约证券交易所的市场份额为 17.3%，在纳斯达克的市场份额为 16.9%。
该公司有一项零售流动性计划，打算用新的 RLP 代码替换旧的 SMARS 代码。他们的策略是重新利用一个用于开启和关闭代码运行的标记。旧代码是一个留在服务器上的 "动力管道挂钩"（power pipe peg）。他们计划先升级代码，切换标记，然后开始运行新代码。那么，这过程中会出什么岔子呢？
2012 年 8 月 1 日，他们手动升级了八台服务器中的七台。一名系统管理员完成了其中七台的升级，却忘了升级第八台服务器。他们进入测试模式，在切换开关时还以为自己是在测试服务器。然而，第八台服务器却在真实网络上进行了真实交易，导致 6.4 亿美元的损失。
这一事件严重扰乱了纽约证券交易所上市的 148 家公司的股价。收到的主订单被处理，有缺陷的 "动力管道挂钩" 发出了数百万条子订单，在大约 45 分钟内促成了 154 只股票、超过 3.97 亿股的 400 万笔交易。第二天，骑士资本就破产倒闭了，原因就是有人没升级那第八台服务器。旧代码运行起来，进行了本不该有的交易。
他们原本可以采取什么不同做法来避免这类错误呢？
这个案例很好地说明了，采用持续交付（Continuous Delivery）实现部署自动化，原本可以避免出现某一台服务器配置与其他服务器不同的情况。没有自动化，每次部署都可能出现人为失误，还可能导致应用程序出现故障。针对测试环境、预发布环境和生产模拟环境进行自动化部署和测试，原本可以确保此次代码变更不会引发这场灾难。