這是一起發生在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過程中，對產生的安全相關數據進行監測和響應。
關鍵詞：DevSecOps；DevOps；代碼安全；
閱讀更多 數世諮詢 的文章
