Knightmare: DevOps की चेतावनी भरी कहानी (2014)

• 2012 में वैश्विक प्रमुख वित्तीय सेवा कंपनी Knight Capital Group की एक चेतावनी भरी कहानी पर यह लेख है, जिसमें एक असफल software deployment के कारण कंपनी 45 मिनट में दिवालिया होने की कगार पर पहुंच गई।
• 2012 में Knight Capital Group अमेरिकी शेयरों का सबसे बड़ा trader था, जिसकी औसत दैनिक trading volume 3.3 billion से अधिक थी और जो हर दिन 21 billion डॉलर से अधिक का व्यापार करता था।
• कंपनी NYSE के नए Retail Liquidity Program के लॉन्च की तैयारी करते हुए अपने automated high-speed algorithmic router SMARS को update कर रही थी।
• यह update "Power Peg" नाम के पुराने, अनुपयोगी code को replace करने के लिए था, जिसका Knight ने 8 वर्षों से उपयोग नहीं किया था।
• नया code 8 servers पर manually deploy किया गया, लेकिन technician की गलती से एक server पर नया code copy नहीं हुआ और पुराना Power Peg code सक्रिय हो गया।
• Power Peg feature ने parent orders के लिए share count track किए बिना child orders execute करने के लिए routing शुरू कर दी, जिससे orders का एक infinite loop बन गया।
• बाजार खुलते ही Knight का system orders से market को भरने लगा, जिससे कुछ shares का मूल्य 10% से अधिक बढ़ गया, जबकि अन्य shares गलत trades की प्रतिक्रिया में गिर गए।
• Knight के system ने SMARS का संदर्भ देते हुए और error को "Power Peg disabled" के रूप में पहचानते हुए 97 automated email messages भेजे, लेकिन उन्हें system alerts के रूप में design नहीं किया गया था और वे तुरंत देखे नहीं गए।
• trading शुरू होने के 45 मिनट के दौरान, Power Peg code ने 212 parent orders process किए और 154 stocks में 4 million trades को संभालते हुए 397 million से अधिक shares process किए।
• Knight Capital Group को 45 मिनट में 460 million डॉलर का नुकसान हुआ, जिसके कारण वह दिवालिया हो गई। उसने लगभग आधा दर्जन investors से 400 million डॉलर के निवेश के जरिए नुकसान की भरपाई के लिए आवश्यक पूंजी जुटाई।
• लेख इस बात पर जोर देता है कि ऐसे बड़े failures से बचने के लिए deployment को पूरी तरह automated और repeatable बनाना कितना महत्वपूर्ण है, जो DevOps/Continuous Delivery योजना का हिस्सा है।
• लेखक का सुझाव है कि software release एक repeatable और reliable process होना चाहिए, और human error के जोखिम को कम करने के लिए इसे यथासंभव automated होना चाहिए।

[GN⁺]

Hacker News राय

• ऑटोमेटेड डिप्लॉयमेंट शायद समस्या को रोक नहीं पाता, और incompatible code की वजह से समस्या को बढ़ा भी सकता था.
• ऑटोमेटेड ट्रेडिंग सिस्टम में built-in kill switch होना चाहिए, और इसकी कार्यक्षमता सुनिश्चित करने के लिए इसे नियमित रूप से टेस्ट किया जाना चाहिए.
• continuous deployment system शायद इस bug को नहीं रोक पाता, क्योंकि यह एक logic error था जो विनाशकारी विफलता तक ले गया.
• "Knight Capital ko khinch kar neeche lana" जैसा शब्द quantitative finance में जाना जाता है, जहाँ critical systems में shortcuts लेने और उसके नतीजे भुगतने की बात होती है.
• high-frequency trading इस बात का चरम उदाहरण है कि चीजें कितनी तेजी से गलत हो सकती हैं.
• बड़े पैमाने के sales volume संभालने वाले सिस्टम के लिए risk को कम करने हेतु manual process, rollback steps, और feature flags होना महत्वपूर्ण है.
• Knight Capital की घटना ऑटोमेटेड SCRAM system को अनदेखा करने का नतीजा थी, जो या तो सभी ट्रेड रोक देता या manual intervention के लिए अलर्ट करता.
• 8 साल तक codebase में dead code का मौजूद रहना risk को दर्शाता है, और यह proactive maintenance की कमी दिखाता है.
• अगर configuration और binary को एक साथ rollout किया गया होता, तो इस तरह की समस्या रोकी जा सकती थी.
• पुराने flags को फिर से इस्तेमाल करना एक गंभीर गलती थी, जो deployment में उचित practices के महत्व को रेखांकित करता है.