經典真實故事 — 45 分鐘搞垮 1 家上市公司
覺得我們的內容實用嗎？ MyApollo 電子報讀者募集中！歡迎訂閱電子報!
如果有人/老闆鐵齒認為軟體部署不需要做自動化的話，你可以給他說說這個故事。
2012 年一家名為騎士資本集團(Knight Capital Group)的美國上市公司，該公司提供包含股票等電子交易的服務，同時該公司大概擁有總值 3.65 億美元的資產，顯然做得相當不錯。
在 7 月 27 到 7 月 31 之間，騎士資本更新股票交易的功能，增加一個稱為 SMARS 的新功能，該功能可以將大筆的股票交易買賣訂單，拆成多筆小的訂單，然後到市場上搓合相對應的買單或賣單，例如有客戶想要買 1,000 shares 的 MSFT, 那它可能就會拆成 100 筆都是買 10 shares 的 MSFT 訂單，當然這只是舉例，實際運作的演算法沒有被公開。
然後 8 月 1 號， SMARS 正式開始運作並處理收到的訂單，接下來的 45 分鐘，市場上出現大量訂單，這期間騎士資本貢獻了市場上約 50% 左右的交易量(trading volume)，有些股票價值甚至因此異常上漲/下跌，而更糟的是這 45 分鐘騎士資本虧損近 4.6 億美元，遠大於其所擁有的總資產 3.65 億美元，註定了它破產的下場。
發生這件事情的根本原因在於：
- 開發人員手動部署新功能時漏了 1 台伺服器，也沒有流程可以複驗部署是否正確、完整，這導致有 1 台伺服器是以舊的程式碼在運作！
- 舊的程式碼中有一段存在 8 年但沒有作用的功能被錯誤開啟，導致該功能產生近似無窮迴圈的功能，進而對市場發出許多訂單，而且這種股票交易的功能多半屬於高頻交易，一旦有任何問題發生，它會在短時間內製造大量的錯誤，相當可怕！
這個真實事件告訴我們：
- 手動部署的流程相當不可靠，人類是容易犯錯的，如果你屈就使用人工部署，就相當於將自身暴露在風險之中。相較於過去，現在你擁有大量的解決方案可供選擇，例如 Jenkins, CircleCI, Ansibile 等等，請好好擁抱自動化。
- Dangling “unused” code 的問題應該被重視，如同此案例，存在 8 年沒有作用的程式碼，不僅開發團隊沒有作為，更忽略其所帶來的風險，最後導致 unused code 突破天際在謝幕前上演一齣驚天大戲。
- 緊急災難處置的重要性。這個問題如果能在 1 - 2 分鐘內被處置完畢的話，不管是全自動 rollback 或者是緊急停止系統，都可以大大降低損失，不過前提還是團隊必須事先針對各種可能發生的緊急災難做出設想與各種演練才行。
以上就是關於騎士資本怎麼在 45 分鐘破產的故事，有興趣的話可以到 Doug Seven 的部落格閱讀 “Knightmare: A DevOps Cautionary Tale” 1 文。
