更糟糕的是，新津的系统在当天早些时候就开始自动发送电子邮件了——早上 8 点 01 分。电子邮件提到了 SMARS，其中有一个错误是“Power Peg 已禁用”。在上午 8 点 01 分至 9 点 30 分之间，有 97 封邮件被发送给新津的员工。当然，这些邮件不算是系统告警，所以没有人去查看它们。

在这地狱般的 45 分钟内，新津尝试了几种应对措施，试图阻止错误的交易。但并没有什么必杀技可用(也没有关于如何应对这类情况的正式程序)，所以他们只能试着在每分钟处理 800 万股交易的实时交易环境中诊断问题。由于他们无法确定是什么原因导致了错误的发生，所以打算将服务器上新部署的代码回滚。换句话说，他们移除了可以运行的代码，留下了坏代码。这样做只会将问题放大，导致更多的父订单在所有服务器上都激活了 Power Peg 功能。最终，在经过了 45 分钟的交易后，他们停止了系统。

在开盘后的 45 分钟内，Power Peg 代码收到并处理了 212 个父订单。SMARS 向交易市场发送了数以百万计的子订单，总共有 400 万笔交易，涉及 154 支股票，总量 3.97 亿股。用外行的话说，新津在 45 分钟内就亏损了 4.6 亿美元。但新津只有 3.65 亿美元的现金和现金等价物。在 45 分钟内，新津从美国最大的股票交易商和纽约证券交易所及纳斯达克的主要做市商变成了一家破产企业。他们有 48 小时的时间来筹集弥补损失所需的资金(他们也的确成功地从大约 6 个投资者那里获得了 4 亿美元的投资)。但是，新津最终被 Getco LLC(2012 年 12 月)收购，合并后的公司叫作 KCG Holdings。

所有的开发和运营团队都应该引以为戒。开发出好的软件，经过全面测试还远远不够，还需要确保它们被正确地交付给市场，让客户获得软件交付的价值(这样就不会让你的公司破产)。在这次事件中，部署 SMARS 的工程师并不是唯一的罪魁祸首——新津的开发部署流程并没有考虑到他们所面临的风险。此外，他们的流程(甚至是没有流程)天生就容易出错。不管在任何时候，只要部署过程依赖人工阅读和遵循指令，那就是将自己暴露在风险之中。人是会犯错误的。错误可能出在指令上、指令的解释上或指令的执行上。

部署应该是自动化且可重复的，并且尽可能避免潜在的人为错误。如果新津的部署系统是自动化的——包括配置、部署和测试——那么这次事件就可以避免。

以下是适用于持续交付的两个原则：

软件发布应该是一个可重复的、可靠的过程。

尽可能实现自动化。