這大概是我讀過的最慘痛的一份bug報告。它描述了一個去年下半年爆發的軟件bug是怎樣一步步使得騎士資本（Knight Capital）在交易中損失了4.65億美金，并且直接導致了公司的破產。

這個故事，有著一個大型、無維護、腐爛（代碼本身長達 8 年沒用過了）代碼庫的技術債務的所有特點，真是一個極為低劣且無職業素養的Devops故事。

重點摘要：

為了允許客戶參與紐約股票交易所的“零售流動性計劃”（RLP），騎士資本對它的指 令處理流程相關的系統和軟件代碼進行了幾次修改，其中有5個被安排在從2012年8月1號開始。這些修改包括在SMARS上開發和部署新的軟件代碼。 SMARS是一個自動化高速算法路由器，可以把指令發送到市場上執行。SMARS的一個核心功能是用于接受從騎士交易系統的其他組件發送過來的指令 （“父”指令），然后根據可用流動性的需求，向外部市場發送一個或多個代表指令（或者“子”指令）以便執行。

13. 在部署時，SMARS上的新RLP代碼本來是用于取代指令路由器上與之相關 但并未使用的代碼。那些未被使用的代碼之前被用于一個叫做“Power Peg”的功能，但是騎士多年前就已經不再使用了。雖然很久不用了，但是在部署 RLP代碼時，Power Peg功能仍然存在而且可以被調用。并且，新的RLP代碼重用了一個原本用于激活Power Peg的標記。騎士原本預計刪除 Power Peg代碼，這樣當標記設置為“是”的時候，參與工作的將會是新的RLP代碼，而不是Power Peg代碼。

14. 之前騎士使用Power Peg代碼時，當子指令被執行時，有一個累積數量 功能會計算父指令中被執行的股票數。這個功能會指明讓代碼在父指令已經全部被執行后不再發送子指令。2003年，騎士停止使用Power Peg功能。 2005年，騎士把Power Peg代碼中這段追蹤累積股票數的功能挪到了SMARS代碼順序中更前面一點的地方。挪完之后，騎士并沒有重新測試 Power Peg代碼，已確定在被調用時Power Peg是否仍然能夠正確運作。

15. 從2012年7月27號開始，騎士分批將新的RLP代碼部署到SMARS 上，連續幾天把它放置到數目有限的SMARS服務器上。然而，在部署新代碼的過程中，騎士的某個技術人員并沒有把新的代碼復制到八臺SMARS服務器的其 中一臺上。騎士沒有讓第二位技術人員復查這次部署，也沒有人意識到第八臺服務器其實并沒有刪除Power Peg代碼，也沒有安裝新的RLP代碼。騎士沒 有任何書面流程要求這樣的復查。

16. 8月1號，騎士從經紀自營商那里收到了有權參與RLP的客戶的指令。那七臺 安裝了新代碼的服務器正確處理了那些指令。但是，使用了重用標記的指令發送到第八臺服務器，觸發了那臺服務器上殘留的有缺陷的Power Peg代碼。因 此，那臺服務器開始向特定交易中心發送子指令以便執行。

19. 8月1號，騎士同樣收到了有權參與RLP并且特別指定在開市前交易的指令。 有6臺SMARS處理了那些指令，從東部時間大概早上8:01開始，騎士的一個內部系統根據SMARS自動發出郵件信息（叫做”BNET指令拒絕”），發 現了一個叫做“Power Peg已被禁止”的錯誤。騎士系統在上午9:30開市之前向騎士的某組員工發送了97封這樣的郵件。騎士沒有把這類信息設計為 系統報警，騎士員工在收到時也基本上不會檢查。

更慘的是：

27. 8月1號，騎士并沒有關于事故反應的監控流程。說得更具體一點，騎士沒有監 控流程在重大問題發生時可以指導它的相關員工。在8月1號，騎士基本上依賴于它的技術團隊在實時交易的環境下，試著發現和解決SMARS問題。當騎士的員 工在試圖查找問題源頭的同時，它的系統仍然在持續發出上百萬條子指令。在一次試圖解決問題時，騎士把新的RLP代碼從正確安裝的七臺服務器上卸載了。這加 劇了這個問題，因為它導致額外新進來的父指令激活了那些服務器上殘留的Power Peg代碼，就像第八臺服務器上已經發生的一樣。

這篇文檔的其他部分絕對值得一讀，但是重要的是推薦了新的為避免類似災難的人為過程。導致這個bug的運營錯誤沒有什么是和人為因素有關的，反而更 象是因為很爛的部署腳本和很不幸的產品監控。什么樣業余的系統才會連確保服務器集群運行統一軟件發布的監控都沒有?。扛挥谜f可以檢查返回值的部署腳 本……

我們只能希望那些未使用代碼的“書面測試過程”指的是有系統的測試， 就象參照一個十年前的wiki頁面所說的那樣。

***的部分是關于罰金：1200萬美金，雖然最終審計也披露系統有條理地發送了無擔保賣空指令。

原文鏈接：http://pythonsweetness.tumblr.com/post/64740079543/how-to-lose-172-222-a-second-for-45-minutes