Knightmare: DevOps警告の物語 (2014)

• 2012年の世界的な大手金融サービス企業であるKnight Capital Groupの警鐘的な事例を扱った記事で、失敗したソフトウェアデプロイにより45分で破綻寸前に追い込まれたケース。
• 2012年当時、Knight Capital Groupは米国株の最大のトレーダーで、1日の平均取引件数は33億件超、毎日210億ドル超を取引していた。
• 同社はNYSEの新しいRetail Liquidity Programの開始に備え、自動化された高速アルゴリズムルーターであるSMARSを更新した。
• この更新は、Knightが8年間使っていなかった古い未使用コード「Power Peg」を置き換えるためのものだった。
• 新しいコードは8台のサーバーに手動で配布されたが、技術者のミスで1台のサーバーには新コードがコピーされず、古いPower Pegコードが有効化された。
• Power Peg機能が親注文に対する株式数を追跡しないまま子注文を実行するためのルーティングを開始し、注文の無限ループが発生した。
• 市場が開くと、Knightのシステムは注文で市場をあふれさせ、一部の株は価値が10%以上上昇し、他の株は誤った取引に反応して下落した。
• KnightのシステムはSMARSを参照し、エラーを「Power Peg無効化」と特定する97通の自動メールを送信したが、これはシステムアラートとして設計されておらず、すぐには確認されなかった。
• 取引開始後45分の間に、Power Pegコードは212件の親注文を処理し、154銘柄について400万件の取引を実行して、3億9700万株超を処理した。
• Knight Capital Groupは45分で4億6000万ドルの損失を出し、その結果として破綻した。彼らは6社の投資家からの4億ドルの出資を通じて、損失を補うために必要な資本を調達した。
• 記事は、このような大規模な失敗を避けるために、デプロイを完全に自動化し、再現可能にすることの重要性を強調しており、これはDevOps/Continuous Delivery計画の一部である。
• 著者は、ソフトウェアのリリースは再現可能で信頼できるプロセスであるべきであり、人為的ミスのリスクを減らすため、可能な限り自動化されるべきだと提案している。

[GN⁺]

Hacker Newsの意見

• 自動化されたデプロイは問題を防げなかった可能性があり、互換性のないコードのせいで問題を拡大させた可能性もある。
• 自動取引システムには組み込みのキルスイッチが必要であり、それは機能を保証するために定期的にテストされるべきだ。
• 継続的デプロイシステムは、致命的な障害につながったこのバグのような論理エラーを防げなかった可能性がある。
• 「Knight Capitalをやらかす」という表現は、重要なシステムで手を抜いてその結果に直面することを指す言葉として、クオンツ金融で知られている。
• 高頻度取引は、物事がいかに素早く悪化しうるかを示す極端な例だ。
• 大規模な売買量を処理するシステムでは、リスクを軽減するために手動プロセス、ロールバック手順、そして機能フラグを備えることが重要だ。
• Knight Capitalの事故は、すべての取引を停止するか手動介入を警告する自動SCRAMシステムを無視した結果だった。
• 8年間にわたってコードベースにデッドコードが存在していたことはリスクを示しており、積極的な保守作業の不足を表している。
• 設定とバイナリが同時にロールアウトされていれば、この種の問題は防げたはずだ。
• 古いフラグを再利用したことは重大なミスであり、デプロイにおける適切なプラクティスの重要性を強調している。