- अमेरिकी stock trading का एक बड़ा स्तंभ Knight Capital Group, 1 अगस्त 2012 को SMARS deployment failure के कारण 45 मिनट में 460 मिलियन डॉलर गंवा बैठा और दिवालिया होने की कगार पर पहुंच गया
- NYSE Retail Liquidity Program के लिए तैयारी करते समय, 8 साल से उपयोग में न आए Power Peg code के flag को नई feature के लिए reuse करना हादसे की शुरुआत बना
- नया code 8 servers में से केवल 7 पर deploy हुआ था, और बचे हुए एक server ने जब नया RLP order लिया, तो निष्क्रिय पड़ी Power Peg feature फिर से चल पड़ी
- Power Peg parent order के execution volume को track किए बिना child orders लगातार route करता रहा, और Knight को kill switch व documented response procedure के बिना production environment में ही कारण ढूंढना पड़ा
- Deployment, code लिखने और testing जितना ही महत्वपूर्ण है; manual procedures पर निर्भर deployment automation, repeatability और validation के बिना घातक operational risk बन जाता है
45 मिनट में ढह गई high-speed trading company
- Knight Capital Group एक अमेरिकी financial services company थी जो market making, electronic execution, institutional sales और trading करती थी
- 2012 में Knight, अमेरिकी equities में NYSE और NASDAQ दोनों पर लगभग 17% market share वाला सबसे बड़ा trader था
- Knight का Electronic Trading Group (ETG) रोज़ औसतन 3.3 billion से अधिक trades का volume manage करता था, और प्रति दिन 21 billion डॉलर से अधिक का trade करता था
- 31 जुलाई 2012 को Knight के पास लगभग 365 million डॉलर की cash और cash equivalents assets थीं
RLP के लिए SMARS update
- NYSE 1 अगस्त 2012 को Retail Liquidity Program शुरू करने वाला था
- Knight ने इसके अनुरूप orders को market में भेजने वाले automated high-speed algorithmic router SMARS को update किया
- SMARS trading platform के “parent orders” लेकर उन्हें एक या अधिक “child orders” में बांटकर execute करने वाला system था
- parent order जितना बड़ा होता, उतने अधिक child orders बनते
- यह update 8 साल से इस्तेमाल न हो रहे Power Peg code को replace करने का काम था
- नए code ने Power Peg को activate करने वाले पुराने flag को नई feature के लिए reuse किया
- code खुद पर्याप्त रूप से test किया गया था और उसके सही चलने की पुष्टि हुई थी
Manual deployment में छूट गया एक server
- Knight ने 27 जुलाई 2012 से 31 जुलाई तक नया software रोज़ सीमित संख्या में servers पर manual deployment के रूप में deploy किया; कुल target 8 servers थे
- SEC documents के अनुसार, एक technician ने 8 SMARS servers में से एक पर नया code copy नहीं किया
- इस deployment को किसी दूसरे technician द्वारा review करने की कोई process नहीं थी, और ऐसा review मांगने वाली कोई documented procedure भी नहीं थी
- नतीजतन 8वें server से Power Peg code हटाया नहीं गया, और नया RLP code भी जोड़ा नहीं गया
Dead code फिर से कैसे जिंदा हुआ
- 1 अगस्त 2012 को सुबह 9:30 बजे (US Eastern Time) market खुलते ही Knight ने broker-dealer customer orders को Retail Liquidity Program के लिए process करना शुरू किया
- सही तरीके से deploy किए गए 7 servers ने orders normal रूप से process किए
- 8वें server पर गए order ने reuse किए गए flag के जरिए पुराने Power Peg code को फिर से चला दिया
- Power Peg मूल रूप से child order execute होने पर parent order के मुकाबले खरीदे-बेचे गए shares की संख्या गिनता था, और parent order पूरा होने पर child order routing रोक देता था
- Knight ने 2005 में cumulative tracking feature को code execution के और पहले stage में shift कर दिया था, और Power Peg के भीतर aggregate tracking हटाई जा चुकी थी
- जब 8वें server पर Power Peg flag activate हुआ, तो Power Peg ने child orders को execution market में route किया, लेकिन parent order के मुकाबले shares की संख्या track नहीं की, इसलिए वह व्यावहारिक रूप से endless loop जैसा व्यवहार करने लगा
Market open से पहले के signals और 9:30 के बाद की बेकाबू रफ्तार
- उस दिन सुबह 8:01 से Knight system ने automated emails भेजना शुरू कर दिया
- यह तब हुआ जब SMARS ने pre-market trading के लिए eligible orders process किए
- email में SMARS का उल्लेख था और error को “Power Peg disabled” के रूप में identify किया गया था
- 8:01 से 9:30 तक Knight employees को ऐसे 97 emails भेजे गए
- ये emails system alert के तौर पर design नहीं किए गए थे, इसलिए तुरंत check नहीं किए गए
- 9:30 पर market खुलते ही Wall Street के कई लोगों ने abnormal situation notice की
- 9:31 तक यह स्पष्ट हो गया कि कुछ गंभीर हो रहा है, और 9:32 तक यह सवाल बढ़ गया कि यह रुक क्यों नहीं रहा
- पहले 45 मिनटों में Knight के executions ने कुछ stocks में trading volume का 50% से अधिक हिस्सा बना लिया, और कुछ specific stock prices को 10% से ज्यादा ऊपर धकेल दिया
- गलत trades की प्रतिक्रिया में कुछ दूसरे stocks की value गिर गई
Kill switch की कमी और गलत response
- Knight के पास problematic system को तुरंत रोकने वाला kill switch नहीं था
- कोई documented response procedure भी नहीं था, इसलिए हर मिनट 8 million shares trade हो रहे production environment में ही root cause diagnose करना पड़ा
- कारण न मिल पाने पर Knight ने correctly deployed servers से नया code हटा दिया
- इस action का नतीजा यह हुआ कि working code हट गया, और problematic code बचा रहा
- इसके बाद additional parent orders ने सिर्फ एक server नहीं, बल्कि सभी servers पर Power Peg code activate कर दिया, जिससे समस्या और बढ़ गई
- Knight 45 मिनट बाद ही system को रोक सका
नुकसान का आकार और company का अंजाम
- Market खुलने के बाद पहले 45 मिनटों में Power Peg code ने 212 parent orders लिए और process किए
- SMARS ने millions of child orders market में भेजे, जिसके परिणामस्वरूप 154 stocks में 4 million trades और 397 million से अधिक shares का trading हुआ
- Knight पर 80 stocks में लगभग 3.5 billion डॉलर net long position और 74 stocks में लगभग 3.15 billion डॉलर net short position आ गई
- Knight Capital Group ने 45 मिनट में 460 million डॉलर loss realize किया
- उस समय उसके पास cash और cash equivalents assets 365 million डॉलर थे, इसलिए Knight अमेरिकी equities का सबसे बड़ा trader और प्रमुख market maker होने से दिवालिया स्थिति में पहुंच गया
- नुकसान भरने के लिए 48 घंटों के भीतर capital raise करना जरूरी था, और Knight ने लगभग 6 investors से 400 million डॉलर investment हासिल किया
- बाद में Knight Capital Group को दिसंबर 2012 में Getco LLC ने acquire किया, और merged company KCG Holdings बनी
DevOps और Continuous Delivery से सीख
- अच्छा software बनाना और test करना ही पर्याप्त नहीं है
- ग्राहकों तक value पहुंचाने के लिए software का market में सही deployment होना जरूरी है
- हादसे की वजह केवल SMARS deploy करने वाले एक engineer में नहीं थी, बल्कि Knight की process उस exposed risk को संभालने में असमर्थ थी
- ऐसी deployment जो इंसानों द्वारा instructions पढ़कर पालन करने के तरीके पर निर्भर हो, उसमें error की संभावना रहती है
- गलती instruction itself, instruction की interpretation, या instruction execute करने की process में हो सकती है
- Deployment को जितना हो सके automated और repeatable होना चाहिए, ताकि human error की संभावना कम हो
- अगर automated deployment system में configuration, deployment और test automation शामिल होते, तो Knightmare पैदा करने वाली error से बचा जा सकता था
- Continuous Delivery principles में से इस case पर लागू होने वाले दो principles हैं
- software release एक repeatable और reliable process होना चाहिए
- reasonable scope में जितना हो सके उतना automate करना चाहिए
1 टिप्पणियां
Hacker News की रायें
मुझे ठीक से समझ नहीं आता कि automatic deployment ने इस समस्या को कैसे हल किया होता। उल्टा, इससे समस्या का प्रभाव और बाद की तबाही और बढ़ सकती थी
“डेवलपर एक सर्वर पर code डालना भूल गया” को “deployment agent सर्वर पर नया binary/code डाउनलोड करते समय error में चला गया, और agent bug के कारण वह error सामने नहीं आया” से बदल दें, तो failure mode वही रहता। प्रभाव और तेज़ी से फैलता
यहाँ जिम्मेदारी डेवलपर की है, क्योंकि code backward compatibility तोड़ने वाले तरीके से लिखा गया था
market और Knight, दोनों को पता था कि गंभीर समस्या है, फिर भी trading रोकने तक 45 मिनट तक कई hotfix आज़माए गए। हो सकता है kill switch था ही नहीं, या यह डर था कि गलत समय पर दबाने से करीब 5 लाख डॉलर की opportunity cost होगी, इसलिए उसे दबाने का अधिकार किसी के पास नहीं था
उस समय मैं Knight के एक competitor में काम करता था। हम भी production में अक्सर भयानक bugs deploy करते थे, लेकिन postmortem के समय यह कल्पना करना मुश्किल था कि हमारे साथ भी वही हो सकता है। अलग-अलग trades रोकने वाले कई automated systems थे, और senior trader या operations वाला व्यक्ति सिर्फ 60 सेकंड की बातचीत से kill switch खिंचवा सकता था, और उसके fallout से डरने की जरूरत नहीं थी
असल में हम Knight के 400 मिलियन डॉलर के नुकसान से और ज्यादा कमा सकते थे, लेकिन हमारे risk system ने इसे “इतना अच्छा कि यकीन करना मुश्किल है” मानकर strategies बार-बार बंद कर दीं, जिससे profit घट गया
“Knight के एक technician ने 8 SMARS servers में से एक पर नया code copy नहीं किया” वाला हिस्सा फिर से देखना चाहिए। बेशक CI/CD pipeline भी बीच में fail होकर सिर्फ कुछ servers पर deploy कर सकती है, लेकिन मेरी नजर में इसकी संभावना कम है
मान भी लें कि ऐसा हुआ, तो Ansible Playbook उस transfer failure के पल ही रुक जाता और पूरा Playbook fail हो जाता; वह अंतिम चरण, यानी service restart, तक पहुँचता ही नहीं
यह मानवीय गलती थी, और ठीक इसी वजह से automation मौजूद है
साथ ही “दूसरे technician ने deployment review नहीं किया, और किसी को पता नहीं चला कि 8वें server से Power Peg code हटाया नहीं गया था और नया RLP code भी जोड़ा नहीं गया था” वाला हिस्सा भी CI/CD रोक सकता था। Ansible code repository के लिए “Pull Request” पहले technician को बिना review के master/main में merge करने से रोकता, क्योंकि master/main protected होना चाहिए
मुझे पूरा यकीन है कि CI/CD पर आधारित DevOps ने यह समस्या 100% हल कर दी होती
Charity Majors ने Euruko में इससे जुड़ी काफी बातें की थीं। deployment tool कोई bash script को coat पहना देने भर जैसा नहीं होना चाहिए; उसमें पर्याप्त लोग और testing होनी चाहिए, और जहाँ तक संभव हो end-to-end automated होना चाहिए
immutable architecture के करीब deployment process, failed/stopped/incomplete rollout को monitor करने वाले tools, और पिछली healthy state में जल्दी rollback करने की क्षमता हो, तो defense layers बनती हैं और चीजें बिगड़ने पर action path आसान हो जाता है। इससे यह समस्या असंभव तो नहीं होती, लेकिन इसका होना ज्यादा मुश्किल जरूर हो जाता
manual runbook में server work करते समय हर बार यह अनुमान लगाने का खेल बन जाता है कि “12वां step किया था, 13वां भी शायद किया था, तो अब 14वां है।” इंसानी दिमाग, जब कोई काम जो लाखों बार किया गया हो बीच में टूट जाए, तो इस execution और पिछली बार की याद से बनी false memory में अक्सर भरोसेमंद तरीके से फर्क नहीं कर पाता
अगर steps skip न हो सकें, इसके लिए interlock नहीं है, तो हर बार जुआ है। और interlock बनाने की मेहनत automation की लागत का काफी हिस्सा पहले ही ले लेती है
“8 साल तक dead पड़ा कोड codebase में क्यों बचा हुआ था, यह रहस्य है, लेकिन मुद्दा वह नहीं है” कहा गया था, पर मुझे तो यही असली मुद्दा लगता है
लगता है 8 साल तक इस्तेमाल न होने वाले कोड को वैसे ही छोड़ दिया गया, और जब flag को reuse करने की कोशिश की गई तभी उसे हटाने की सोची गई। अगर 8 साल पहले सही तरीके से न इस्तेमाल होने वाला कोड हटा दिया गया होता, तो कहानी बिल्कुल अलग होती। न पुराना routine फिर से जिंदा होता, न मनमाने server होते
हो सकता है Knight Capital version control इस्तेमाल नहीं करता था और “कहीं जरूरत पड़ जाए” सोचकर कोड पकड़े बैठा था। लेकिन पूरी तरह version-controlled repository में भी मैंने ऐसे developers देखे हैं जो कोड delete करने से कतराते हैं, और यह सचमुच हैरान करने वाला है। फिर जरूरत पड़े तो version control से वापस ला सकते हैं। अगर फिर जरूरत पड़ने पर आपको याद ही नहीं रहा कि वह वहाँ है, तो dead code path भी वैसे ही नहीं मिल पाता। उसे source tree में छोड़ना शुद्ध debt है
Kevlin Henney ने GOTO में software reliability पर एक शानदार talk दी थी, और Knight Capital को उदाहरण बनाकर इसी बिंदु पर बात की थी। वास्तव में इस blog post को भी quote किया है https://youtu.be/IiGXq3yY70o?si=hZ9HB2dlfj0vHvNK&t=463
“वास्तव में dead code जैसी कोई चीज नहीं होती। बस एक छोटी assumption, उस assumption में एक छोटा बदलाव, और अचानक वह dead code नहीं बल्कि zombie code बन जाता है। फिर से जिंदा हुई zombie apocalypse महंगी पड़ती है”
git logसे history देखना, और शायदgit blameइस्तेमाल कर लेनाअक्सर उन्हें git history filter करना नहीं आता।
git pickaxeया exclude patterns भी नहीं जानते, और यह सोचते तक नहीं किgit log -G'int.*foo\(' -- ':(exclude)directory'की तरह किसी खास directory को exclude करके git log मेंfooखोजा जा सकता हैइसके बजाय उन्हें current code tree में
grepकरना आता है। इसलिए वे सोचते हैं कि अगर delete नहीं किया तो सहीgrepसे फिर मिल जाएगा। delete हो गया तो हो सकता है git history में ढूंढना न आता होकुछ हद तक यह समझ में आता है। git log के अंदर का code बहुत से tools में दिखाई नहीं देता। जैसे editor autocomplete में suggest नहीं करता, और library docs में भी नहीं दिखता
अगर सच में विश्वास है कि वह code फिर इस्तेमाल होगा, तो refactoring के साथ चलता रहे और जरूरत पड़ने पर मिल जाए, इसके लिए उसे tree में छोड़े रखना कुछ हद तक defend किया जा सकता है। लेकिन Knight Capital जैसे मामले में, जहाँ साफ है कि दोबारा इस्तेमाल होना नहीं था, इसे defend करना मुश्किल है
सिर्फ “पुराना code हटाने” जैसा update भी, किसी भी change को टूटने का risk मानने वाले लोगों को मुश्किल लग सकता है। निष्पक्ष तौर पर कहें तो हर change में risk है, लेकिन पुराना code छोड़ना भी risk है
कम से कम अब इस case को साफ risk के example के रूप में दिखाया जा सकता है
इस कहानी को हर बार देखकर जो बात सच में समझ नहीं आती, वह यह है कि नया flag बनाने के बजाय मौजूदा flag को reuse किया गया। ऐसा क्यों किया गया होगा
git rebaseसे हमेशा के लिए गायब हो सकती हैउम्मीद है कि ज्यादातर organizations में main branch के आसपास ऐसा न होने देने के लिए process होते हैं। लेकिन मैंने भी एक छोटी organization में गलती से production database table बिगाड़ दी थी, इसलिए accidental
git rebaseको भी असंभव नहीं कहूंगाएक और समस्या थी कि database में सिर्फ 256 columns थे। जब नया column चाहिए होता, तो “उस समय इस्तेमाल में नहीं” रहे पुराने column को बस reuse कर लेते थे
याद सही हो तो internally भी इसे आम तौर पर “bad idea” माना जाता था, लेकिन पुराने code को साफ करना या बेहतर best practices बनाना किसी ने priority नहीं बनाया
मैंने जितने भी continuous deployment systems देखे हैं, उनमें से कोई भी इस खास bug को नहीं रोक पाता
rollout gradual था, लेकिन code में ऐसा logic bug था कि उस gradual rollout step में एक installation fail होते ही company bankrupt हो सकती थी
इसे रोकने के लिए runtime पर software version, जैसे git SHA, match कर रहा है या नहीं, यह check करना पड़ता, और software rollout infrastructure को call करने वाली tests में fault injection भी जोड़ना पड़ता
यह पूरी तरह Wild West जैसा दौर था। यह भी अहम है कि उसके बाद से trading systems बहुत बदल चुके हैं
जब मैंने 2009 में इस field में काम शुरू किया, banks, brokers और exchanges सभी की system reliability काफी खराब थी। अक्सर phone पर confirm करना पड़ता था कि executed quantity कितनी थी
मुझे याद है जब Italian exchange system rollout कर रहा था। एक समय पर production environment और UAT के मिले-जुले setup में “test” किए गए थे, और याद सही हो तो market close के बाद next release test करने के लिए सिर्फ order transmission connection IP बदला जा रहा था। UAT environment में इतने bugs थे और वह ज्यादातर आधा मरा हुआ था कि वहाँ test नहीं कर सकते थे
उन Excel spreadsheets की बात ही न करें जिनमें ChatGPT भी गाली दे दे ऐसा VBA code था, और जो कई zeros वाले trading volumes वाले products की pricing करती थीं
आजकल स्थिति बहुत अलग है। कुछ हद तक ऐसे incidents की वजह से भी। ज्यादातर चीजें automated हैं, और cowboy-style attitude भी काफी कम हुआ है
mandatory kill switches, risk/trading activity monitoring की कई layers, exchange-side monitoring हैं, और मुश्किल से सीखे गए बहुत सारे lessons सच में systems में शामिल किए गए हैं। इसी वजह से लोग good trading system बनाने की कठिनाई को naïvely देखते हैं। strategy smart हुई है, यह भी सच है, लेकिन मुख्य बात आम तौर पर यह है कि normal conditions से बाहर की किसी चीज से मरने से कैसे बचना है
quant finance में मौजूद हर व्यक्ति सचमुच Knight Capital को जानता है। “pulling a knight capital” जैसा expression भी है। यानी mission-critical system में, जो company को पलक झपकते bankrupt कर सकता है, shortcut लेने और फिर उसकी कीमत चुकाने का मतलब
हमारी टीम का सिस्टम हर दिन करोड़ों डॉलर के revenue में अहम भूमिका निभाता है। अगर सिस्टम काफी देर तक down रहे, तो वह revenue गायब हो जाता है। यहां “काफी देर” का मतलब कम-से-कम कुछ घंटे है, और उस समय के भीतर आम तौर पर बाहरी असर बहुत बड़ा होने से पहले सिस्टम को सामान्य स्थिति में वापस लाया जा सकता है
हमारे पास भी manual processes हैं, लेकिन किसी भी manual process को शुरू करने से पहले हम rollback procedure document करते हैं और deployment को monitor करते हैं। हम code deployment और feature deployment को भी अलग रखते हैं, और feature deployment को feature flags के पीछे धीरे-धीरे करते हैं
नए features या code changes के लिए नया feature flag अनिवार्य होता है। यह तकलीफ़देह और धीमा है, लेकिन इसने हमें खतरनाक स्थितियों और panic से बचाया है, और operations व on-call का बोझ भी बहुत घटाया है
सचमुच बड़ी गड़बड़ी होने के लिए कई “defect filters” से गुजरना पड़ता है। जैसे code review में बिना feature flag के behavior change छूट जाए, manual/dev environment testing में भी छूट जाए, deployment fail हो जाए, rollback fail हो या गलत हो जाए, यह बताने वाली monitoring न हो कि समस्या अभी ठीक नहीं हुई है, समय पर higher level पर escalation न हो पाए, और इतना समय निकल जाए कि SLA पूरा करने की क्षमता खो जाए
ज्यादा जोखिम वाले manual changes में दो लोगों को साथ मिलकर change करवाया जा सकता है। एक व्यक्ति video call पर बताता रहे कि क्या बदला जा रहा है, और दूसरा उसे verify करे
अगर आप ऐसे system से निपट रहे हैं जहां SLA मिनटों में मापा जाता है और change वापस नहीं किया जा सकता, तो आपको कुछ ही मिनटों में monitor और rollback करने का व्यावहारिक तरीका पता होना चाहिए। अगर काम नया और manual है, तो चार बार check करें और किसी दूसरे व्यक्ति को साथ में निगरानी करने दें। वरना कई समस्याओं के लगातार एक-दूसरे पर चढ़ते जाने से ऐसा पल आना सिर्फ समय की बात है जहां सुधार असंभव हो जाए। कोई कितना भी प्रतिभाशाली और होशियार हो, अगर इंसान को manual तौर पर change करना या change शुरू करना है, तो गलतियां हमेशा होंगी, और उस गलती की संभावना को change management process में built-in मानकर चलना चाहिए
सामान्य commerce या B2B में कई मामलों में customer वही purchase थोड़ी देर बाद फिर से try कर सकता है। यह “अभी नहीं तो कभी नहीं” वाली बात नहीं होती
मैंने भी ऐसा किया है कि seller down था, किसी नए announcement और भारी demand के कारण server crash हो गए थे, या bank maintenance की समस्या थी, तो जो चीज़ खरीदनी थी उसे बाद में फिर से try किया
संबंधित लेख:
Knightmare: A DevOps Cautionary Tale (2014) - https://news.ycombinator.com/item?id=22250847 - फरवरी 2020, 33 comments
Knightmare: A DevOps Cautionary Tale (2014) - https://news.ycombinator.com/item?id=8994701 - फरवरी 2015, 85 comments
Knightmare: A DevOps Cautionary Tale - https://news.ycombinator.com/item?id=7652036 - अप्रैल 2014, 60 comments
इसके अलावा:
The $440M software error at Knight Capital (2019) - https://news.ycombinator.com/item?id=31239033 - मई 2022, 172 comments
Bugs in trading software cost Knight Capital $440M - https://news.ycombinator.com/item?id=4329495 - अगस्त 2012, 1 comment
Knight Capital Says Trading Glitch Cost It $440 Million - https://news.ycombinator.com/item?id=4329101 - अगस्त 2012, 90 comments
और भी कुछ है क्या?
Nanex ~ 03-Aug-2012 ~ The Knightmare Explaned - https://news.ycombinator.com/item?id=4337359 - कोई comment नहीं
असली समस्या, अगर “No true Scotsman” जैसे expression को सह लें, यह थी कि उन्होंने untested configuration और binary release का combination इस्तेमाल किया
configuration और binaries को साथ-साथ match करके rollout किया जा सकता है, और ऐसा करने से इस तरह की समस्या रोकी जा सकती है। बेशक दूसरी गलतियां भी थीं, लेकिन अगर यह condition न होती तो यह समस्या हो ही नहीं सकती थी
“यह रहस्य है कि 8 साल से dead code codebase में क्यों पड़ा था, लेकिन वह मुख्य बात नहीं है” वाला हिस्सा कहानी की सबसे खराब गलती तो नहीं है, मगर यह भी नहीं कहा जा सकता कि वह मुख्य बात नहीं है
अगर dead feature को पहले से हटाया गया होता, तो software ज्यादा simple और बेहतर समझ में आने वाला होता, और उसके runaway होने की संभावना भी घटती। ऐसी maintenance के बिना लगातार आगे ही बढ़ते रहना, चाहे calculated हो या नहीं, risk है
सच में अच्छा हुआ कि मैं ऐसा code नहीं लिखता जो इंसानी intervention के बिना अपने-आप लाखों डॉलर route करता हो
यह jumbo jet उड़ाने वाला code लिखने जैसा लगता है। ऐसी जिम्मेदारी कौन लेना चाहेगा
मुझे लगता है यह काम उन खास तरह के लोगों के लिए है जिन्हें processes, tests, simulators और redundancy से प्यार होता है। जहां विमान उड़ाने वाला code खुद engineering का सिर्फ 1% है
जो चिंताएं स्वाभाविक रूप से दिमाग में आती हैं, उन्हें एक-एक करके address करना होता है, और आप जितना rationally चिंतित होंगे, business के लिए उतना बेहतर होगा। finance sector के अनुभव से मुझे लगता है कि Knight की समस्या 10% technical issue थी और 90% यह कि CTO-जैसे किसी व्यक्ति ने खुद को bold समझ लिया था। सिर्फ उस दिन या उस हफ्ते नहीं, बल्कि कुल मिलाकर
शायद इस incident का भी इसमें कुछ योगदान रहा होगा