这是一起发生在2012年的真实事件，在2014年由微软人工智能研究部门的一名主管人员(Doug Seven)公布在他的博客，但直到现在，虽然DevOps技术的兴起，这起事件的具体内容又开始被科技类媒体重新关注。
故事主角：骑士资本集团
骑士资本集团(Knight Capital Group)是一家美国的全球金融服务公司，从事做市，电子执行以及机构销售和交易。在事故发前，骑士凭借其高频交易算法，成为美国股票最大的交易商，日均交易量超过33亿股，交易额高达210亿美元，在纽交所和纳斯达克两大证券交易市场所占的份额为别为17.3％和16.9％。事件发生后，骑士破产，并于2013年被全球电子贸易公司Getco LLC收购。
事件过程
2012年7月，为了向普通投资者提供更优惠的股票交易价格，纽交所启动了一个优化股票交易计划，为此骑士资本对其交易执行算法SMARS进行了更新。
7月27日至31日，骑士资本的IT人员把新代码手动更新到8台服务器上。但由于没有安排IT人员对部署过程进行复查，没有人意识到有一台服务器上的旧代码没有被新代码替换。
8月1日早上9:30股市开盘，服务器开始处理来股票交易的订单，但那台依然使用旧代码的服务器产生了死循环，毫无限制地发出大量的交易订单。最终执行了超过日均交易额50%的订单，导致部分股票市值上升超过10%，带来的连锁反应是其他股票价格暴跌。
45分钟之内，服务器上的交易执行算法SMARS接收并处理了212个父订单，将其拆分成数百万个子订单，累计对154支股票进行了400万次交易，交易量接近4亿股。用股票语言来讲，就是骑士资本建立了80支个股35亿美元的净多头仓位和74支个股31.5亿美元的净空头仓位。意味着骑士资本在45分钟之内亏损了4.6亿美元，而骑士资本的身家是3.65亿万美元。骑士资本从美国股市最大的交易商瞬间破产，之后被Getco LLC收购。
数世评论：
只要代码的交付过程依赖于人工操作，就有可能在任何环节出现问题。操作指令本身、对指令的解读以及指令的执行过程都可能存在隐患。交付或部署过程应该是可靠且可重复的，并在合理的情况下，尽可能实现自动化，排除人为因素的干扰。假如骑士资本采用的是自动交付，配置、部署和测试完全自动化，这场悲剧可能就不会发生。
目前业界提倡的DevSecOps有两大类核心功能，一是将已知问题或潜在问题的自动检测与防护贯穿整个持续集成与持续交付(CI/CD)流程。二是在DevOPs过程中，对产生的安全相关数据进行监测和响应。
声明：本文来自数世咨询，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
