इस आपदा में हास्य ढूँढना समझ में आता है, लेकिन सोचता हूँ कि जवाबदेही का क्या होगा
HN पर कई बार देखा है कि इस घटना से अरबों डॉलर का नुकसान हुआ, लेकिन मुकदमों की चर्चा अभी ज़्यादा नहीं दिखी
क्या लाइसेंस इतना अभेद्य है कि ग्राहकों के पास राहत पाने का कोई रास्ता ही नहीं? अगर किसी उपभोक्ता का निजी PC कुछ घंटों/दिनों के लिए बंद हो जाए तो समझ सकता हूँ, लेकिन उद्योग जगत का इस स्तर का जोखिम स्वीकार करना मुझे बेतुका लगता है
सिविल इंजीनियरिंग को गंभीर क्षेत्र माना जाने का एक बड़ा कारण भी यही है। पुल गिर जाए तो सिर्फ आर्थिक देनदारी नहीं, आपराधिक जिम्मेदारी की संभावना भी होती है, और सिविल इंजीनियरिंग के छात्रों को बार-बार सिखाया जाता है कि अनैतिक व्यवहार करने या इंजीनियर के तौर पर अस्वीकार्य जोखिम लेने पर वे जेल जा सकते हैं
क्या software engineers के लिए भी इस स्तर की जवाबदेही और पेशेवर आचार-व्यवहार तक पहुँचने का कोई रास्ता है?
सिविल इंजीनियरिंग अलग है क्योंकि वह भौतिक उत्पादों को डिजाइन करती है। कुछ भी बिल्कुल सीमा पर डिजाइन नहीं किया जाता, हर चीज़ में पर्याप्त safety margin रखा जाता है
जैसे किसी पुल की गणना इस तरह करना कि hurricane के दौरान भूकंप भी आ जाए और पुल पर ट्रक ठसाठस गुजर रहे हों, फिर उस पर 20% और जोड़ देना। अगर भरोसा न हो कि beam टिकेगी या नहीं, तो उसे बड़ा बना दो; गणना 0.5% गलत भी हो तो बड़ी समस्या नहीं होती
डिजाइन दस्तावेज़ में typo हो और कोई 15.0 feet के gap में 150 feet की beam लगाने की कोशिश करे, तो contractor पुष्टि माँगेगा। इसलिए पुल का गिरना लगभग निश्चित रूप से गंभीर लापरवाही का परिणाम होता है
इसके उलट programming में सिर्फ एक < का <= की जगह होना भी सब ठीक रहने और अरबों डॉलर के नुकसान के बीच फर्क पैदा कर सकता है। धरती पर कोई भी programmer मामूली से अधिक complexity वाली application को 100% दोषरहित नहीं लिख सकता
formal correctness proof का दावा करने वाले seL4 microkernel में भी bugs हैं। compiler और proof checker तकनीकी रूप से संभव हैं, लेकिन आप उनसे साफ तौर पर गलत काम करवाएँ तब भी वे शिकायत नहीं करते
सबसे छोटी गलती पर भी व्यावहारिक रूप से असीमित liability लेने को कोई सामान्य व्यक्ति स्वीकार नहीं कर सकता
अगर software engineers को जिम्मेदार ठहराना है, तो पहले रोज़मर्रा की सद्भावनापूर्ण गलती और गंभीर लापरवाही में फर्क करने का तरीका खोजना होगा, और इसे formalize करना बहुत कठिन होगा
Delta ने 500 million dollar के नुकसान पर मुकदमे की चेतावनी दी, तो CrowdStrike ने सार्वजनिक रूप से जवाब दिया कि contract के तहत CrowdStrike की liability limit single-digit million dollars है
इसके बाद उसने यह सूची भेजी कि मुकदमा शुरू हुआ तो discovery में backup plans, failover plans, testing schedules और results, आखिरी backup recovery drill कब हुई आदि माँगे जाएँगे
मतलब असल में यह था: “अगर मुकदमा किया तो हम आपकी IT practices को इतना गहराई से खंगालेंगे कि वे हमारी तुलना में आपको ज़्यादा शर्मिंदा करेंगी, और दिखाएँगे कि गलती आपकी थी”
राहत के उपाय हैं, लेकिन जैसा कहा गया, वे आम लोगों के लिए नहीं हैं। कंपनियाँ CrowdStrike के खिलाफ मुकदमे दायर कर रही हैं और आगे भी करेंगी, और CrowdStrike द्वारा जारी दस्तावेज़ों को देखकर लगता है कि प्रभावित कंपनियों के जीतने की संभावना बहुत अधिक है
लगता है कि वे judge, jury या arbitrator को यह समझाने में सक्षम होंगी कि CrowdStrike ने गंभीर लापरवाही की और कंपनियों को सीधे नुकसान के साथ-साथ परोक्ष reputational damage भी स्पष्ट रूप से पहुँचाया
सच कहूँ तो पता नहीं CrowdStrike आखिर तक लड़ाई लड़ेगा भी या नहीं। ज़्यादातर मामले court के बाहर settle हो जाएँगे, और अगले कुछ वर्षों में CrowdStrike को ढहते हुए भी देखा जा सकता है
कई कंपनियों के पास ऐसे events के लिए insurance होता है जिनमें revenue stream रुक जाती है। जैसे किसानों का crop insurance या बड़े retailers का disaster damage insurance होता है, वैसे ही infrastructure collapse से कुछ समय के लिए revenue 0 हो जाने की स्थिति के लिए भी कुछ न कुछ होगा
प्रभावित सभी लोग अगर ClownStrike से 100% नुकसान वसूलने की माँग करें, तब भी ClownStrike का revenue वह नुकसान नहीं झेल सकता। आप कंपनी को बंद करवाना चाहें, तब भी वास्तविक नुकसान के करीब की रकम वसूल नहीं कर पाएँगे
इसलिए जिज्ञासा है कि असल में प्रस्ताव क्या है। bug-free code लगभग असंभव है, और कुछ जोखिम users स्वीकार करते हैं
क्या आप सच में मानते हैं कि software इस्तेमाल होने से पहले 100% bug-free होना ही चाहिए? इसे साबित कैसे करेंगे? और फिर अगला सवाल यह है कि आपका अपना code कितना साफ है कि आपको लगता है यह संभव है
संभव तो है, लेकिन जवाब है समय। सिविल इंजीनियरिंग का इतिहास हजारों साल पुराना है, software engineering कहीं अधिक युवा है और इस क्षेत्र की बुनियादें भी अभी बदल रही हैं
कम से कम मेरे देश में 1970s के आखिर से systems analysts, electronic computer programmers, data processing machine operators, typists(!) के लिए licensing कानूनों के प्रस्ताव थे
अगर ये कानून पारित हो गए होते, तो हमारे देश में software development की प्रगति दशकों पीछे रह जाती। उदाहरण के लिए, एक bill “terminal (digital या visual device) सहित electronic processing device या machine का संचालन और उपयोग” सिर्फ “data processing machine operator” license रखने वालों को ही अनुमति देना चाहता था
यह समस्या CrowdStrike से आगे जाती है; यह security के उस पूरे approach को दिखाती है जिसमें regulators और insurers को संतुष्ट करने के लिए off-the-shelf security products खरीदे जाते हैं, जबकि वे असल में क्या करते हैं और कैसे काम करते हैं, इस पर ध्यान नहीं दिया जाता
इसका मतलब यह नहीं कि technology को regulate नहीं करना चाहिए, लेकिन मौजूदा “इसे खरीदो और जिम्मेदारी उतार दो” model काम नहीं करता
इससे भी बुरा यह है कि जिन लोगों ने इसकी आशंका जताई होगी—यानी IT departments—वे शायद कुछ कर ही नहीं सकते थे। संभव है company leadership ने “cyber insurance” requirements या अन्य regulations के कारण इसे अनिवार्य किया हो। पागलपन है
मैंने कई अच्छे IT लोगों को ऐसा महसूस करते देखा है, लेकिन मेरे अनुभव में अधिकांश IT departments को contract में जरूरी items पूरे हो जाने पर इस बात में कम दिलचस्पी थी कि असल समस्या हल हो रही है या नहीं
पुराने workplace में CrowdStrike जैसे software को weekend के दौरान मेरे workstation पर install कर दिया गया, और लौटकर देखा तो compile time 20% धीमा हो गया था
उस समय मैं इसे measure कर रहा था, इसलिए मेरे पास दर्जनों measurements थे, और ETL tracing से दिखाया कि वही software वजह था, लेकिन IT ने स्वीकार नहीं किया। क्योंकि vendor contract में लिखा था कि हमारे workload पर performance impact नहीं होना चाहिए
अधिकांश IT departments ने शायद इसका अनुमान नहीं लगाया होगा, और पूरी security strategy को उस संभावना के हिसाब से न बनाना भी स्वाभाविक है। यह narrative कहाँ से आ रहा है, समझ नहीं आता
Falcon ने customers को वास्तविक और सचमुच के security benefits दिए हैं और अब भी देता है। इसका मतलब यह नहीं कि वह सभी risks खत्म कर देता है, या अपने risks पैदा नहीं करता
हर engineering समस्या की तरह यह सचमुच trade-offs का खेल है। यहाँ मौजूद लोगों के लिए यह अनजाना नहीं होना चाहिए
अचानक HN hindsight और latest-event bias से भरे security experts से भर गया है, जो बता रहे हैं कि कंपनियाँ यह गोली कैसे टाल सकती थीं, लेकिन उन वास्तविक गोलियों को नहीं देखते जिन्हें वे शुरुआत में Falcon इस्तेमाल करके टाल रही थीं
यह ऐसा मामला है जो अदालत में सबूत के वीडियो या मुकदमे में इस्तेमाल हो सकता है, और यह हंसने वाली बात नहीं है
असल में यह शायद security geeks के बीच की एक बंद बातचीत का पल रहा होगा, लेकिन अब यह बड़े नुकसान झेल चुके आम लोगों के लिए खुलकर मज़ाक उड़ाने लायक सार्वजनिक हो गया
मुझे बिल्कुल नहीं लगा कि CrowdStrike के executive ने स्थिति को हल्के में लिया। उल्टा, वह भाषण स्थिति को गंभीरता से लेने, यह मानने कि यह एक बहुत बड़ी गलती थी, और उस trophy को शर्म के प्रतीक और भविष्य के CrowdStrike कर्मचारियों के लिए चेतावनी-भरी कहानी के रूप में स्वीकार करने जैसा लगा
मेरे हिसाब से उस executive का यह award स्वीकार करना वाकई गरिमापूर्ण कदम था। बेशक, ऐसा कहने का मतलब यह बिल्कुल नहीं कि CrowdStrike इस घटना की जिम्मेदारी या मुआवज़े की liability से मुक्त हो जाता है
T-shirt बनाई जाए तो मज़ेदार हो सकती है
When I use
REGEXP
I use it in my
KERNEL CODE
त्रासदी और कॉमेडी एक ही सिक्के के दो पहलू हैं
कंप्यूटर security की समस्या Vietnam War के समय ही सामने आ चुकी थी, और अमेरिका ने सचमुच प्रभावी computer security model खोजने का काम किया था। लेकिन हम ऐसे समाज में रह रहे हैं जिसने उसे लगभग याददाश्त से मिटा दिया है
कंप्यूटर जो कुछ भी चलाने वाला है, उसके ऊपर scanner को 24/7 क्यों चलना चाहिए?
operating system को परिधीय permissions पर निर्भर क्यों होना चाहिए?
CrowdStrike को दोष देना सिर्फ Linux, MacOS, Windows जैसे operating systems में मौजूद उन बुनियादी design failures से ध्यान हटाता है जिन्हें हम रोज़ अनदेखा करते हैं
अब भी Microsoft को दोष दे रहा हूं, क्योंकि updated code को kernel के बाहर चलाना और kernel mode code को केवल observation और action के लिए इस्तेमाल करना, logic के लिए नहीं, असंभव नहीं है
मैं IT में काम करता हूं, और वह बदकिस्मत व्यक्ति था जो Clown Strike द्वारा infrastructure के ज्यादातर हिस्से को उड़ाने के समय on-call था
निजी तौर पर, cloud-based बकवास इस्तेमाल न करने पर अड़े रहने की वजह से शायद हम दिनों के बजाय कुछ घंटों में recover कर पाए
इस बात से काफी चिंता है कि IT director जैसे लोग इसे समस्या नहीं मानते, और ऐसी बकवास रोकने के लिए कोई कदम नहीं उठाते, इसलिए बहुत जल्द हमें एक और cloud-based बड़ा outage झेलना पड़ सकता है
मैं बार-बार दोहरा रहा हूं कि “दूसरों के कंप्यूटरों पर निर्भर सिर्फ मूर्ख लोग होते हैं”, और मैं इससे 100% सहमत हूं
यह अजीब है कि कुछ managers या executives समझते हैं कि internal infrastructure में single point of failure खराब है, लेकिन किसी external vendor का product/service single point of failure बन जाए तो उन्हें ठीक लगता है
शायद वे मानते हैं कि contract करके पैसे देने पर वह ऐसी superhumans की टीम बनाती और maintain करती है जो internal engineers के उलट गलती नहीं करती। यह गलत भरोसा समझ में नहीं आता
100% सहमत। ऊपर से Azure VD जैसी cloud services पर बेहिसाब खर्च होते देखना हैरान करता है
सालाना cloud budget के सिर्फ एक हिस्से से भी कंपनी खुद बहुत stable और offline में भी सक्षम infrastructure बना सकती है
आपका लहजा बहुत aggressive लगता है। बात सही हो तब भी शायद मैं आपके साथ काम नहीं करना चाहूंगा
अगर आप इतने aggressive ढंग से न बोलें तो शायद अपनी बात और बेहतर तरीके से पहुंचा सकें
जब बेवकूफ CTO लोग CTO summit, अपने incentives में गड़बड़ वाले consultants, और तरह-तरह की random conferences से सलाह मानते हैं, तो करने को ज्यादा कुछ नहीं बचता
पिछले “सबसे महाविफल” winners में स्वाभाविक रूप से Microsoft का दबदबा रहा
शर्मिंदगी बांटते रह सकते हैं, लेकिन अगर आपको लगता है कि ऐसा production outage खराब processes की वजह से होता है, तो Microsoft ने भी इसमें निश्चित रूप से बड़ी भूमिका निभाई
इस हंगामे के बाद भी CEO और CTO अपनी कुर्सियों पर कैसे बने हुए हैं, यह सचमुच हैरानी की बात है
कई शहरों में 911 काम नहीं कर रहा था और hospital workflows रुकने जितने धीमे हो गए थे, लेकिन Defcon जाकर मज़ाक करने का समय है?
क्या अब भी कोई hospital है जिसके कंप्यूटर ठीक नहीं हुए? बेशक CS ने गड़बड़ की, लेकिन damages चुकाने और processes बदलने के अलावा अभी और क्या किया जा सकता है, समझ नहीं आता
लोगों को वही गलती दोहराने से रोकने के लिए चेतावनी देना समय की बुरी बर्बादी नहीं लगता
यहां CS को दोष मिलना चाहिए, यह सही है, लेकिन 911 जैसे critical systems में CS डालना अपने आप में बड़ी गलती लगता है
हालांकि जिसने ऐसा किया, उसे शायद पता था कि वह accountability से बच सकता है, इसलिए परवाह करने की वजह भी नहीं रही होगी
1 टिप्पणियां
Hacker News की राय
इस आपदा में हास्य ढूँढना समझ में आता है, लेकिन सोचता हूँ कि जवाबदेही का क्या होगा
HN पर कई बार देखा है कि इस घटना से अरबों डॉलर का नुकसान हुआ, लेकिन मुकदमों की चर्चा अभी ज़्यादा नहीं दिखी
क्या लाइसेंस इतना अभेद्य है कि ग्राहकों के पास राहत पाने का कोई रास्ता ही नहीं? अगर किसी उपभोक्ता का निजी PC कुछ घंटों/दिनों के लिए बंद हो जाए तो समझ सकता हूँ, लेकिन उद्योग जगत का इस स्तर का जोखिम स्वीकार करना मुझे बेतुका लगता है
सिविल इंजीनियरिंग को गंभीर क्षेत्र माना जाने का एक बड़ा कारण भी यही है। पुल गिर जाए तो सिर्फ आर्थिक देनदारी नहीं, आपराधिक जिम्मेदारी की संभावना भी होती है, और सिविल इंजीनियरिंग के छात्रों को बार-बार सिखाया जाता है कि अनैतिक व्यवहार करने या इंजीनियर के तौर पर अस्वीकार्य जोखिम लेने पर वे जेल जा सकते हैं
क्या software engineers के लिए भी इस स्तर की जवाबदेही और पेशेवर आचार-व्यवहार तक पहुँचने का कोई रास्ता है?
जैसे किसी पुल की गणना इस तरह करना कि hurricane के दौरान भूकंप भी आ जाए और पुल पर ट्रक ठसाठस गुजर रहे हों, फिर उस पर 20% और जोड़ देना। अगर भरोसा न हो कि beam टिकेगी या नहीं, तो उसे बड़ा बना दो; गणना 0.5% गलत भी हो तो बड़ी समस्या नहीं होती
डिजाइन दस्तावेज़ में typo हो और कोई 15.0 feet के gap में 150 feet की beam लगाने की कोशिश करे, तो contractor पुष्टि माँगेगा। इसलिए पुल का गिरना लगभग निश्चित रूप से गंभीर लापरवाही का परिणाम होता है
इसके उलट programming में सिर्फ एक
<का<=की जगह होना भी सब ठीक रहने और अरबों डॉलर के नुकसान के बीच फर्क पैदा कर सकता है। धरती पर कोई भी programmer मामूली से अधिक complexity वाली application को 100% दोषरहित नहीं लिख सकताformal correctness proof का दावा करने वाले seL4 microkernel में भी bugs हैं। compiler और proof checker तकनीकी रूप से संभव हैं, लेकिन आप उनसे साफ तौर पर गलत काम करवाएँ तब भी वे शिकायत नहीं करते
सबसे छोटी गलती पर भी व्यावहारिक रूप से असीमित liability लेने को कोई सामान्य व्यक्ति स्वीकार नहीं कर सकता
अगर software engineers को जिम्मेदार ठहराना है, तो पहले रोज़मर्रा की सद्भावनापूर्ण गलती और गंभीर लापरवाही में फर्क करने का तरीका खोजना होगा, और इसे formalize करना बहुत कठिन होगा
इसके बाद उसने यह सूची भेजी कि मुकदमा शुरू हुआ तो discovery में backup plans, failover plans, testing schedules और results, आखिरी backup recovery drill कब हुई आदि माँगे जाएँगे
मतलब असल में यह था: “अगर मुकदमा किया तो हम आपकी IT practices को इतना गहराई से खंगालेंगे कि वे हमारी तुलना में आपको ज़्यादा शर्मिंदा करेंगी, और दिखाएँगे कि गलती आपकी थी”
लगता है कि वे judge, jury या arbitrator को यह समझाने में सक्षम होंगी कि CrowdStrike ने गंभीर लापरवाही की और कंपनियों को सीधे नुकसान के साथ-साथ परोक्ष reputational damage भी स्पष्ट रूप से पहुँचाया
सच कहूँ तो पता नहीं CrowdStrike आखिर तक लड़ाई लड़ेगा भी या नहीं। ज़्यादातर मामले court के बाहर settle हो जाएँगे, और अगले कुछ वर्षों में CrowdStrike को ढहते हुए भी देखा जा सकता है
प्रभावित सभी लोग अगर ClownStrike से 100% नुकसान वसूलने की माँग करें, तब भी ClownStrike का revenue वह नुकसान नहीं झेल सकता। आप कंपनी को बंद करवाना चाहें, तब भी वास्तविक नुकसान के करीब की रकम वसूल नहीं कर पाएँगे
इसलिए जिज्ञासा है कि असल में प्रस्ताव क्या है। bug-free code लगभग असंभव है, और कुछ जोखिम users स्वीकार करते हैं
क्या आप सच में मानते हैं कि software इस्तेमाल होने से पहले 100% bug-free होना ही चाहिए? इसे साबित कैसे करेंगे? और फिर अगला सवाल यह है कि आपका अपना code कितना साफ है कि आपको लगता है यह संभव है
कम से कम मेरे देश में 1970s के आखिर से systems analysts, electronic computer programmers, data processing machine operators, typists(!) के लिए licensing कानूनों के प्रस्ताव थे
अगर ये कानून पारित हो गए होते, तो हमारे देश में software development की प्रगति दशकों पीछे रह जाती। उदाहरण के लिए, एक bill “terminal (digital या visual device) सहित electronic processing device या machine का संचालन और उपयोग” सिर्फ “data processing machine operator” license रखने वालों को ही अनुमति देना चाहता था
यह समस्या CrowdStrike से आगे जाती है; यह security के उस पूरे approach को दिखाती है जिसमें regulators और insurers को संतुष्ट करने के लिए off-the-shelf security products खरीदे जाते हैं, जबकि वे असल में क्या करते हैं और कैसे काम करते हैं, इस पर ध्यान नहीं दिया जाता
इसका मतलब यह नहीं कि technology को regulate नहीं करना चाहिए, लेकिन मौजूदा “इसे खरीदो और जिम्मेदारी उतार दो” model काम नहीं करता
इससे भी बुरा यह है कि जिन लोगों ने इसकी आशंका जताई होगी—यानी IT departments—वे शायद कुछ कर ही नहीं सकते थे। संभव है company leadership ने “cyber insurance” requirements या अन्य regulations के कारण इसे अनिवार्य किया हो। पागलपन है
पुराने workplace में CrowdStrike जैसे software को weekend के दौरान मेरे workstation पर install कर दिया गया, और लौटकर देखा तो compile time 20% धीमा हो गया था
उस समय मैं इसे measure कर रहा था, इसलिए मेरे पास दर्जनों measurements थे, और ETL tracing से दिखाया कि वही software वजह था, लेकिन IT ने स्वीकार नहीं किया। क्योंकि vendor contract में लिखा था कि हमारे workload पर performance impact नहीं होना चाहिए
Falcon ने customers को वास्तविक और सचमुच के security benefits दिए हैं और अब भी देता है। इसका मतलब यह नहीं कि वह सभी risks खत्म कर देता है, या अपने risks पैदा नहीं करता
हर engineering समस्या की तरह यह सचमुच trade-offs का खेल है। यहाँ मौजूद लोगों के लिए यह अनजाना नहीं होना चाहिए
अचानक HN hindsight और latest-event bias से भरे security experts से भर गया है, जो बता रहे हैं कि कंपनियाँ यह गोली कैसे टाल सकती थीं, लेकिन उन वास्तविक गोलियों को नहीं देखते जिन्हें वे शुरुआत में Falcon इस्तेमाल करके टाल रही थीं
यह ऐसा मामला है जो अदालत में सबूत के वीडियो या मुकदमे में इस्तेमाल हो सकता है, और यह हंसने वाली बात नहीं है
असल में यह शायद security geeks के बीच की एक बंद बातचीत का पल रहा होगा, लेकिन अब यह बड़े नुकसान झेल चुके आम लोगों के लिए खुलकर मज़ाक उड़ाने लायक सार्वजनिक हो गया
मेरे हिसाब से उस executive का यह award स्वीकार करना वाकई गरिमापूर्ण कदम था। बेशक, ऐसा कहने का मतलब यह बिल्कुल नहीं कि CrowdStrike इस घटना की जिम्मेदारी या मुआवज़े की liability से मुक्त हो जाता है
When I use
REGEXP
I use it in my
KERNEL CODE
त्रासदी और कॉमेडी एक ही सिक्के के दो पहलू हैं
xcancel के जरिए: https://xcancel.com/singe/status/1822324795645575263
कंप्यूटर security की समस्या Vietnam War के समय ही सामने आ चुकी थी, और अमेरिका ने सचमुच प्रभावी computer security model खोजने का काम किया था। लेकिन हम ऐसे समाज में रह रहे हैं जिसने उसे लगभग याददाश्त से मिटा दिया है
कंप्यूटर जो कुछ भी चलाने वाला है, उसके ऊपर scanner को 24/7 क्यों चलना चाहिए?
operating system को परिधीय permissions पर निर्भर क्यों होना चाहिए?
CrowdStrike को दोष देना सिर्फ Linux, MacOS, Windows जैसे operating systems में मौजूद उन बुनियादी design failures से ध्यान हटाता है जिन्हें हम रोज़ अनदेखा करते हैं
अब भी Microsoft को दोष दे रहा हूं, क्योंकि updated code को kernel के बाहर चलाना और kernel mode code को केवल observation और action के लिए इस्तेमाल करना, logic के लिए नहीं, असंभव नहीं है
मैं IT में काम करता हूं, और वह बदकिस्मत व्यक्ति था जो Clown Strike द्वारा infrastructure के ज्यादातर हिस्से को उड़ाने के समय on-call था
निजी तौर पर, cloud-based बकवास इस्तेमाल न करने पर अड़े रहने की वजह से शायद हम दिनों के बजाय कुछ घंटों में recover कर पाए
इस बात से काफी चिंता है कि IT director जैसे लोग इसे समस्या नहीं मानते, और ऐसी बकवास रोकने के लिए कोई कदम नहीं उठाते, इसलिए बहुत जल्द हमें एक और cloud-based बड़ा outage झेलना पड़ सकता है
मैं बार-बार दोहरा रहा हूं कि “दूसरों के कंप्यूटरों पर निर्भर सिर्फ मूर्ख लोग होते हैं”, और मैं इससे 100% सहमत हूं
शायद वे मानते हैं कि contract करके पैसे देने पर वह ऐसी superhumans की टीम बनाती और maintain करती है जो internal engineers के उलट गलती नहीं करती। यह गलत भरोसा समझ में नहीं आता
सालाना cloud budget के सिर्फ एक हिस्से से भी कंपनी खुद बहुत stable और offline में भी सक्षम infrastructure बना सकती है
अगर आप इतने aggressive ढंग से न बोलें तो शायद अपनी बात और बेहतर तरीके से पहुंचा सकें
तुलना के लिए पिछले Pwnie Award winners की सूची: https://en.wikipedia.org/wiki/Pwnie_Awards
शर्मिंदगी बांटते रह सकते हैं, लेकिन अगर आपको लगता है कि ऐसा production outage खराब processes की वजह से होता है, तो Microsoft ने भी इसमें निश्चित रूप से बड़ी भूमिका निभाई
इस हंगामे के बाद भी CEO और CTO अपनी कुर्सियों पर कैसे बने हुए हैं, यह सचमुच हैरानी की बात है
कई शहरों में 911 काम नहीं कर रहा था और hospital workflows रुकने जितने धीमे हो गए थे, लेकिन Defcon जाकर मज़ाक करने का समय है?
लोगों को वही गलती दोहराने से रोकने के लिए चेतावनी देना समय की बुरी बर्बादी नहीं लगता
हालांकि जिसने ऐसा किया, उसे शायद पता था कि वह accountability से बच सकता है, इसलिए परवाह करने की वजह भी नहीं रही होगी