慘烈：1個Bug，45分鐘損失4億多美元

【導讀】：2012年8月1日，一個 bug 一步步讓騎士資本在交易中損失了 4.65 億美金，並且直接導致破產。這個故事涉及的代碼庫，是一個大型、無人維護、腐爛的代碼庫，代碼本身將近 9 年沒用過了，真是一次集合了技術債務所有特點的慘案。

（網路圖）

2014 年我參加了一場會議並就 DevOps、代碼配置和持續交付等話題進行發言，講到 DevOps 和持續交付的時候我說了下面這個故事，來闡述自動化、可重複部署的重要性。那次會議之後，有好多人讓我在博客上分享這個故事。這是一個真實的故事，下面根據我了解的來進行分享（我並沒有親身經歷）。

下面講的是一個資產 4.6 億美元的公司在 45 分鐘內破產的故事。

背景

Knight Capital Group（騎士資本集團）是美國一家全球性的金融服務公司，主要業務有 做市、電子交易系統和機構交易。2012 年，騎士資本是美國股票市場最大的經紀商，分別佔有紐交所和納斯達克 17% 的市場份額。騎士資本的電子貿易部門管理的平均日交易量超過 33 億股，交易額高達 210 億美元。這可不是開玩笑！

到 2012 年 7 月 31 日，騎士資本擁有高達 3 億 6500 萬美元的現金及現金等價物。

2012 年 8 月 1 日，紐交所計劃啟動零售流動性項目（該項目旨在通過類似騎士資本這樣的經濟商向普通投資者提供更優惠的股票交易價格），為此，騎士資本對他們自動化且高速的演算法程序 SMARS 進行了更新，該程序向交易所發送執行命令。SMARS 程序的核心功能之一是從騎士資本交易平台的其他部分接收訂單（「父」訂單），然後發出一個或多個「子」訂單。換句話說，SMARS 程序從交易平台接收大訂單，然後根據買家或賣家的股票交易數量把大訂單拆分成合適的小訂單。父訂單越大，子訂單越多。

這次更新主要是為了把過時或沒用的功能替換掉，比如說「Power Peg」。這個功能已經 8 年沒有用到過了（ 8 年都沒用到的功能代碼仍然存在，這的確很稀奇，但這不是重點）。更新後的代碼對以前用來激活 Power Peg 功能的標識符進行了更改。這次更新經全面測試後證明安全可靠，那問題究竟出在哪？

還有哪裡可能出問題么？的確是！

從 2012 年 7 月 27 日至 31 日，騎士資本把軟體手動部署到公司為數不多的伺服器上——總共就 8 台。以下是美國證交會關於這次人工部署過程的檔案描述（順便一提，如果你的操作被記錄到證交會檔案里可就大事不妙了）。

「在部署過程中，相關技術人員忘記把新代碼拷貝到這八台伺服器其中的一台上。騎士資本也沒有安排另外的技術人員對部署過程進行複查，所以沒有人意識到第八台機器上的 Power Peg 代碼並沒有被刪除，新的 RLP 代碼也沒有被添加。對於複查，騎士資本並沒有相關的書面流程。 —— 美國證監會文件 | 發布編號 70694 | 2013-10-16」

東部時間 2012 年 8 月 1 日早上 9:30 股市開盤，騎士資本開始處理來自 RLP 新項目的交易商的訂單。其中七台正確部署的伺服器開始正確地處理訂單。但是發向第八台伺服器的訂單觸發了被更改的標識符，執行的是無效的 Power Peg 代碼。

來自「殭屍」代碼的攻擊

我們得弄清楚這段「殭屍」代碼是用來幹什麼的。這個功能以前是用來對比買/賣股票的父訂單和子訂單的數額的。父訂單數額一旦達標，Power Peg 就會向系統反饋停止訂單拆分。總的來說，Power Peg 功能可以持續追蹤子訂單，而父訂單一旦完成，該功能會立即終止子訂單活動。然而 2005 年，騎士資本把跟蹤計數這一功能轉移到稍微靠前一些的代碼里（因此 Power Peg 不再具備跟蹤計數功能了）。

當第八台機器上的 Power Peg 功能被啟動後，由於它無法跟蹤對比父訂單的股票數，所以子訂單不斷產生並執行，這就成了無法終止的死循環。

災難性的 45分鐘

你可以設想一下，當一個失去追蹤計數功能的系統無限制地、高速地向市場發出訂單時情況會有多糟糕。

早上 9:30 開盤後立即有人意識到出了問題。一分鐘後，華爾街大部分人都感覺到大事不妙了，股票市場中某些個股湧現出大量不符合常規交易量的訂單。又過了一分鐘，人們發現交易仍然沒有停止——就高速交易系統而言，交易根本停不下來。為什麼沒人嘗試停止出問題的系統呢？事後發現，這個系統根本沒有切斷開關。在 45 分鐘之內，騎士資本執行了超過日均交易額 50% 的訂單，導致部分股票市值上升超過 10%，帶來的連鎖反應是其他股票價格暴跌。

更糟的是，早在上午的 8:01（這時 SMARS 在進行開市前交易），騎士資本的系統就自動發送了有關問題的郵件。這些標記為 SMARS 的郵件提及 Power Peg 功能出現了問題。從 8:01 到 9:30，97 個個人郵箱都收到了這封郵件。估計這些郵件並沒有系統警報的作用，所以並沒有人馬上查看。天吶。

在這災難性的 45 分鐘里，騎士資本想出幾個對策來終止錯誤的交易。由於這個系統沒有切斷開關（也沒有相關情況的文檔說明），他們只能在每分鐘交易 800 萬股的線上環境中診斷問題起因。然而他們沒能發現系統問題出在哪裡，只能卸載已經部署到幾台伺服器上的新代碼。換句話說，他們把有用的代碼刪掉反而留下了問題代碼。情況惡化了，除了第八台未被正確部署的伺服器，另外七台伺服器中的父訂單也觸發了 Power Peg 功能。最後，他們終於想辦法終止了交易系統，然而已經過去了 45 分鐘。

在開市後的 45 分鐘內，騎士資本接收並處理了 212 個父訂單，SMARS 發出數百萬個子訂單，累計對 154 支股票進行了 400 萬次交易，交易量超過 3 億 9700 萬股。在內行人看來，騎士資本建立了 80 支個股 35 億美元的凈多頭倉位和 74 支個股 31 億 5000 萬美元的凈空頭倉位。對外行人來說，騎士資本在 45 分鐘內虧損了 4 億 6000 萬美元，而上文提到，騎士資本僅有 3 億 6500 萬美元。僅僅 45 分鐘，騎士資本從美國股市最大的交易商和紐交所以及納斯達克的大莊家變得一錢不值。破產後，騎士資本有 48 小時的時間籌集資金彌補損失（騎士資本還有大約六個投資者投資的 4 億美元）。騎士資本最終被 Getco LLC 收購（2012 年 12 月），合并後新公司更名為 KCG Holdings。

吸取教訓

所有運維團隊都應該從騎士資本慘案中吸取教訓。不僅要開發優秀的軟體並進行全面測試，還需要把軟體正確地交付給交易所，這樣客戶才能獲得正確的結果（才能避免公司破產）。這個事件中，我們不能把矛頭全部對準部署 SMARS 的技術人員，騎士資本的業務流程根本不足以應付他們所面對的問題。此外，這種流程（或缺陷）本來就很容易出錯。是人都會犯錯，不論何時，只要你的部署過程依賴於人工指令操作，就有可能出現問題。指令本身、對指令的解讀以及指令的執行過程都可能存在隱患。

部署應該是自動化且可重複的，這個過程應該盡量排除人為因素的干擾。假如騎士資本採用的是自動部署系統——配置、部署和測試完全自動化，這場悲劇可能就不會發生了。

持續交付的某些原則也同樣適用（即使你執行的不是一個完整的持續交付過程）：

軟體發布過程應該是可靠且可重複的。

合理的情況下，儘可能實現自動化。

（英文：Doug Seven，伯樂在線 - Ivy wang 編譯）

譯者簡介（點擊 加入專欄作者）

王悅：越長大越想成為更好的自己

打賞譯者翻出更多好文章，謝謝！

關注「伯樂在線」

看更多精選 IT 職場文章

TAG:伯樂在線 |

※慘烈！逾1600家個股下跌，25股特大單流出1億元以上
※1984年老山戰役有多慘烈：單越軍就傷亡近6000人
※人類史上最慘烈的戰役：士兵僅能存活9分鐘，200天損失200萬人
※中越兩軍19天日均損失5000人：對越反擊戰有多慘烈！
※這比賽看「死」多少人！同場43+9+9PK41+16+11，刀刀見紅太慘烈
※太慘烈：被大黃蜂50分鐘內狂叮150次，日本87歲老太不幸去世！
※上甘嶺戰役有多慘烈：雙方10萬人廝殺43天4萬人陣亡
※近代日本一次慘烈的演習，210人參加死亡199人，大多數被凍成冰棍
※中越戰爭高平戰役有多慘烈：19天傷亡10萬人，日均五千人
※618電商之戰，為何2017年會如此慘烈？
※慘烈一戰：82勇士大戰3000日本精兵，全部犧牲，斃敵170
※至少58死515傷！「今晚你們都活不成！」有人喊完這句話45分鐘後，美國最慘烈大屠殺就開始了......
※39歲的小S撞衫52歲劉嘉玲，差了13歲卻輸得如此慘烈！
※史上最慘烈的戰役，犧牲80萬，被俘66萬
※日本最慘烈軍演，210人參加死掉199人，大部分被凍成冰棍兒
※30歲趙麗穎用禮服秒贏31歲楊冪，同框41歲的她卻輸個慘烈！
※史上最慘烈的統一，22場戰役斬敵181萬！
※最新！美國最慘烈槍擊案嫌犯已身亡，64歲白人男子在酒店32層掃射，已致超50死406傷
※800毫米口徑巨炮攻打千年要塞！慘烈一役，10萬人直面死亡