CrowdStrike के पूर्व कर्मचारी: “Quality control प्रक्रिया का हिस्सा नहीं था”

 (semafor.com)
1 पॉइंट द्वारा GN⁺ 2024-09-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • पूर्व कर्मचारियों का कहना है कि जुलाई 2024 की बड़ी outage से पहले ही वे तंग deadlines, अत्यधिक workload और बढ़ती technical समस्याओं के बारे में management को बताते रहे थे
  • इंटरव्यू देने वाले 24 पूर्व कर्मचारियों में से कई का मानना था कि executives ने quality से ज्यादा speed को प्राथमिकता दी, और कुछ कर्मचारियों को पर्याप्त training के बिना coding और operations का काम दिया गया
  • CrowdStrike ने पूर्व कर्मचारियों के बयानों के बड़े हिस्से को खारिज करते हुए पलटकर कहा कि जानकारी के स्रोत “कंपनी policy का स्पष्ट उल्लंघन करने के कारण निकाले गए कुछ असंतुष्ट पूर्व कर्मचारी” हैं
  • जुलाई में Falcon Sensor update की खामी ने 85 लाख computers को रोक दिया, Fortune 500 कंपनियों को अधिकतम 5.4 अरब डॉलर का नुकसान हुआ, और CrowdStrike उस quarter में लगभग 6 करोड़ डॉलर के expected contracts से चूक गया
  • लंबे समय से चल रही quality और operations समस्याओं और जुलाई outage के बीच सीधा संबंध पुष्टि नहीं हुआ है, लेकिन इसके बाद CrowdStrike को revenue और profit outlook घटाने, Congress में testimony और lawsuits के दबाव का सामना करना पड़ा

outage से पहले से जमा होती quality चिंताएं

  • CrowdStrike के पूर्व software engineers का कहना है कि जुलाई की बड़ी outage से एक साल से भी ज्यादा पहले से वे तंग deadlines, अत्यधिक workload और बढ़ती technical समस्याओं के बारे में वरिष्ठों को बता रहे थे
  • पूर्व कर्मचारियों के अनुसार, ये मुद्दे meetings, emails और exit interviews में बार-बार उठाए गए
  • पूर्व senior user experience designer Jeff Gardner ने कहा कि “speed सबसे अहम थी” और quality control प्रक्रिया या बातचीत का हिस्सा नहीं था
  • एक पूर्व senior manager ने बताया कि कई meetings में कर्मचारियों ने चेतावनी दी थी कि अगर वे ऐसा “product जिसे support नहीं किया जा सकता” जारी करते हैं, तो ग्राहकों को “failure” की स्थिति में डाल सकते हैं

पूर्व कर्मचारियों की अलग-अलग गवाही और कंपनी का खंडन

  • Semafor से interview करने वाले पूर्व कर्मचारी कुल 24 थे
    • 10 ने कहा कि उन्हें fired या layoff किया गया था
    • 14 ने कहा कि उन्होंने voluntary resignation दिया था
    • एक व्यक्ति 2024 की गर्मियों तक कंपनी में था
  • 3 पूर्व कर्मचारी अन्य कर्मचारियों के बयानों से सहमत नहीं थे
    • 2023 में कंपनी छोड़ने वाले Joey Victorino ने कहा कि CrowdStrike “जो भी करता था, उसमें बहुत meticulous था”
  • कंपनी ने report की बातों के बड़े हिस्से को खारिज किया
    • उसने कहा कि जानकारी “कंपनी policy का स्पष्ट उल्लंघन करने के कारण निकाले गए कुछ असंतुष्ट पूर्व कर्मचारियों” से आई है
    • कंपनी ने कहा कि वह product resilience सुनिश्चित करने के लिए कड़ी testing और quality control करती है, और इसके उलट दिए गए विवरणों को पूरी तरह खारिज करती है

तेज growth के बाद जुलाई की outage

  • CrowdStrike की स्थापना 2011 में हुई थी, और 2013 में Falcon antivirus package launch करने के बाद वह cybersecurity industry की प्रमुख कंपनियों में बढ़ी
  • 2019 में public listing के बाद कंपनी ने कर्मचारियों की संख्या में हजारों की बढ़ोतरी की, और fiscal year 2024 के अंत तक revenue 1,000% से ज्यादा बढ़ गया
  • जुलाई 2024 में गलत software update ने इतिहास की सबसे बड़ी IT outage हो सकने वाली घटना को जन्म दिया
    • 85 लाख computers रुक गए
    • Fortune 500 कंपनियों का नुकसान अधिकतम 5.4 अरब डॉलर तक पहुंच सकता है
    • हवाई यात्री airports पर फंस गए, online banking access रुक गया, और emergency call centers offline हो गए
  • CFO Burt Podbere ने 28 अगस्त की earnings call में कहा कि 31 जुलाई को समाप्त quarter में जिन contracts के close होने की उम्मीद थी, उनमें से लगभग 6 करोड़ डॉलर के contracts छूट गए
  • CEO George Kurtz ने 19 जुलाई को कहा कि वे घटना के scale को नहीं भूलेंगे और सुनिश्चित करेंगे कि ऐसा फिर कभी न हो

testing, customer data और LogScale के मामले

  • कुछ पूर्व कर्मचारियों ने कहा कि product release की speed से तालमेल बिठाने की प्रक्रिया में software quality checks कभी-कभी जल्दबाजी में किए जाते थे
  • 2019 से 2023 तक काम करने वाले Preston Sego ने कहा कि लोगों को पर्याप्त testing करने के लिए मनाना कभी-कभी मुश्किल होता था
    • उनका काम यह review करना था कि customer तक code changes deploy होने से पहले user experience developers की testing bugs को ठीक से report कर रही है या नहीं
    • Sego ने कहा कि internal Slack पर return-to-office policy की आलोचना करने के बाद फरवरी 2023 में उन्हें “insider threat” बताकर fired किया गया
    • CrowdStrike ने कहा कि वह individual personnel matters पर चर्चा नहीं करती
  • professional services department में एक customer की confidential information गलती से दूसरे customer folder में तीन बार upload होने ही वाली थी
    • CrowdStrike ने इस incident की पुष्टि की और कारण manual data entry error बताया
    • कंपनी ने समझाया कि data host names, IP addresses और domain names जैसी basic information थी
    • उसने कहा कि अब customer confidential data गलत तरीके से transfer न हो, इसके लिए checks चलाए जाते हैं
  • कई पूर्व कर्मचारियों ने कहा कि Falcon LogScale में भी समस्याएं थीं
    • एक ने याद किया कि गलत update के कारण potential malicious activity बताने वाले real-time alerts कम से कम दो बार थोड़े समय के लिए बंद हो गए थे
    • कुछ engineers ने कहा कि internal meetings में इसे तंग schedule का नतीजा माना गया
    • CrowdStrike ने यह कहते हुए इस मामले को खारिज किया कि उसे ऐसे किसी “bad update” की जानकारी नहीं है, जिसमें customers को alerts नहीं मिले
    • कंपनी ने कहा कि LogScale ऐसी service के रूप में design नहीं की गई है जो customers को potential data breach की जानकारी “real-time” में दे

Falcon OverWatch Cloud Threat Hunting launch विवाद

  • एक पूर्व कर्मचारी ने कहा कि 2022 में launch किया गया Falcon OverWatch Cloud Threat Hunting जल्दबाजी में launch किया गया था
  • यह service ऐसी है जिसमें CrowdStrike security experts customers के cloud environments, जैसे Amazon Web Services, में ऐसे suspicious behavior खोजते हैं जो breach का संकेत दे सकते हैं
  • project में शामिल एक पूर्व senior manager ने कहा कि आम तौर पर 1 साल लगने वाला काम engineers और threat hunters को 2 महीने में करने को दिया गया
  • उन्होंने कहा कि launch के समय threat hunters के पास customers के cloud systems को पूरी तरह monitor करने के लिए जरूरी internal tools की कमी थी, और launch के लगभग 1 साल बाद, यानी पिछली गर्मियों तक, वे मौजूदा security system alerts पर response कर रहे थे
  • उसी पूर्व senior manager ने कहा कि laptop और desktop जैसे customer computer systems की निगरानी के लिए trained employees को cloud threat detection में लगाया गया, लेकिन नई training mandatory नहीं की गई
  • CrowdStrike ने पुष्टि की कि नए “cloud threat hunters” team को hire करने के बजाय उसने मौजूदा engineers का इस्तेमाल किया
    • उसने कहा कि क्योंकि यह नई service थी, इसलिए experienced “cloud threat hunters” उपलब्ध नहीं थे, और CrowdStrike द्वारा विकसित किए जाने से पहले मौजूद ही नहीं रहे क्षेत्र में specific training पाए लोगों को hire करना संभव नहीं था
    • कंपनी ने कहा कि नई training mandatory नहीं थी, लेकिन इच्छुक employees को दी गई
    • उसने जोड़ा कि employees को उनकी role के अनुरूप नियमित training मिलती है
  • SANS Institute, CrowdStrike service launch से 2 साल पहले यानी 2020 से cloud security training courses और lectures देता आ रहा था
  • CrowdStrike ने कहा कि OverWatch service हमेशा intended तरीके से काम करती रही, और project में जल्दबाजी की गई थी या threat hunters के पास जरूरी tools नहीं थे—इन विवरणों को उसने खारिज किया

पुराना code और बढ़ा workload

  • Sego ने कहा कि project आगे बढ़ाने के लिए temporary तौर पर लिखा गया code बाद में अक्सर improve नहीं किया जाता था
  • एक पूर्व senior engineer ने बताया कि पुराने code को ठीक करने के लिए समय मांगने की उनकी 20 से ज्यादा requests स्वीकार नहीं की गईं
  • CrowdStrike ने जवाब दिया कि coding एक iterative process है, और real product experience के आधार पर code deploy करना और लगातार improve करना software industry में सामान्य है
  • पूर्व कर्मचारियों ने पुराने code को improve न कर पाने की वजहों में से एक बढ़े workload को बताया
    • कुछ ने कहा कि workforce reduction और reorganization के बाद उन्हें ज्यादा काम संभालना पड़ा
    • CrowdStrike ने layoffs पर comment करने से इनकार किया और कहा कि employees की संख्या हर साल लगातार बढ़ी है
    • कंपनी ने समझाया कि R&D खर्च fiscal year 2022 के 37.13 करोड़ डॉलर से बढ़कर fiscal year 2024 में 76.85 करोड़ डॉलर हो गया, और इसका ज्यादातर कारण employees की संख्या में वृद्धि थी
  • कंपनी ने कहा कि वह teams से अलग-अलग feedback लेती है, उसका evaluation और incorporation करती है, और high-performance culture बनाए रखने पर ध्यान देती है
  • उसने यह भी जोड़ा कि पिछले 4 वर्षों में वह Fortune 100 Best Companies to Work For में चुनी गई है

outage के बाद costs और follow-up प्रक्रियाएं

  • CrowdStrike ने जुलाई outage का कारण Falcon Sensor update की खामी को बताया
  • इस घटना से कंपनी की stock market value 21 अरब डॉलर से ज्यादा घट गई
  • इसके बाद कई lawsuits आए, और Delta Airlines ने हजारों flights cancel होने के बाद अपने नुकसान का अनुमान 55 करोड़ डॉलर लगाया और lawsuit की संभावना जताई
  • Senior Vice President Adam Meyers सितंबर 2024 में Congress में testify करने वाले हैं
  • CrowdStrike President Michael Sentonas ने अगस्त में hackers convention में “Most Epic Fail” award accept करते हुए कहा कि जब आपने बहुत बड़ी गलती की हो, तो उसे स्वीकार करना बहुत महत्वपूर्ण है
  • पूर्व कर्मचारियों द्वारा बताए गए लंबे समय से चले आ रहे मुद्दों और जुलाई outage के बीच संबंध अभी पुष्टि नहीं हुआ है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-09-14
Hacker News की राय

  • “गति सबसे ज़्यादा अहम थी, और quality control हमारी process या बातचीत का हिस्सा नहीं था” जैसी बातों के लिए नाराज़ पूर्व कर्मचारियों पर टिके लेख की कीमत GrubHub के apology gift card जितनी ही लगती है
    मैं CrowdStrike को अच्छी नज़र से नहीं देखता, लेकिन अगर किसी के मन में रंजिश हो और ध्यान पाने का मौका मिले, तो कोई भी कुछ भी कह सकता है। ऊपर से यह व्यक्ति designer था और शायद quality control में सीधे शामिल भी नहीं रहा होगा
    लेख में भी लिखा है कि 24 पूर्व कर्मचारियों में से 10 को निकाला गया या layoff हुआ, 14 ने खुद इस्तीफा दिया, और 3 लोग बाकी बयानों से सहमत नहीं थे। Joey Victorino ने कहा कि CrowdStrike “हर काम में बेहद बारीक था”, तो आखिर में पक्का कुछ भी बहुत कम है

    • “पक्का कुछ नहीं” कहना मुश्किल है, क्योंकि इतिहास का सबसे बड़ा IT outage हुआ था, और postmortem analysis में भी validation checks की कमी सामने आई थी
      staged rollout के बिना इसे सीधे दुनिया भर के production environment में push कर दिया गया, और कोई lab भी नहीं थी जहां नया code सचमुच install और run होता। धुआं दिख रहा है, और आग लगी थी—ऐसी कई गवाहियां भी हैं, इसलिए इसे इसी context में देखा जा सकता है
    • CrowdStrike जैसी कंपनी ने इतना भारी-भरकम बड़ा हादसा करने के बाद पूर्व कर्मचारियों को “नाराज़ लोग” का label लगाने का खास हक नहीं दिखता
      उल्टा ऐसे कर्मचारी अंदरूनी हालात ज़्यादा ईमानदारी से बता सकते हैं, और भले वे quality assurance/quality control department में न रहे हों, माहौल तो समझ सकते हैं। कंपनी की हां में हां मिलाने वालों से ऐसी जानकारी ज़्यादा भरोसेमंद लगती है
    • हमारे पास रिपोर्ट यह है कि Semafor ने जिन लोगों का interview किया, उन्हें भरोसेमंद माना, उनमें दिलचस्प बिंदु थे, और वे एक-दूसरे या दूसरे सबूतों से आम तौर पर मेल खाते थे
      आप कह सकते हैं कि Semafor अपना काम ठीक नहीं करता या दुर्भावनापूर्ण है, लेकिन जिस paragraph को quote किया गया है उसी में विरोधी evidence भी साथ दिया गया है, इसलिए यह आसान दावा नहीं है
      कंपनी के एक पूर्व कर्मचारी से सुनें तो वह निजी मामला हो सकता है, लेकिन कई लोग वही शिकायत करें तो उसे कहीं ज़्यादा गंभीरता से देखना चाहिए
    • यह online reviews जैसा है। अगर आप सिर्फ positive/negative reviews चुनकर बाकी छिपा दें तो बेकार है, लेकिन मिले हुए सभी reviews report करें तो वह अभी भी उपयोगी है
      असंतुष्ट व्यक्ति के review छोड़ने की संभावना ज़्यादा होती है, और CrowdStrike छोड़ने वालों के भी असंतुष्ट होने की संभावना ज़्यादा है। यह biased data है, फिर भी काम का data है
    • अगर design quality control में शामिल नहीं है, तो quality control ठीक से नहीं हो रहा। अगर design development process से जुड़कर quality control को समझ नहीं पाता, तो design भी सही से नहीं हो रहा

  • मुझे हैरानी है कि यहां comments इसे इतनी आसानी से खारिज कर रहे हैं। engineers समेत पूर्व कर्मचारी कह रहे हैं कि पिछली कंपनी की खतरनाक development culture ने दुनिया भर के बड़े outage और पुराने outages में योगदान दिया
    ऐसी गवाही को भरोसेमंद, या कम से कम उपयोगी जानकारी मानना चाहिए, लेकिन कई लोग सिर्फ उस UX designer पर हमला करते दिख रहे हैं जिसने कहा कि “quality control हमारी process का हिस्सा नहीं था”
    शायद “shipping speed ही सब कुछ है” वाली line, यानी “move fast and break things”, में बहुत लोग खुद को देख रहे हैं। क्योंकि code deploy करने का रोमांच, fire-fighting, impact बनाना, और cleanup अगले engineer और manager पर डाल देने की culture परिचित लगती है
    zero-interest-rate era के नज़रिए से ऐसी process failure bug नहीं, feature जैसी लग सकती थी। “quality” पर जोर भी customer के पैसे से मज़े करते हुए काम करने में बाधा डालने वाली झंझट भरी रुकावट जैसा लगता होगा

    • यह कोई game नहीं है। आम तौर पर मैं सहमत होता, लेकिन अगर बात low-level kernel driver की हो तो मामला अलग है, और security company होने से यह और गंभीर हो जाता है
      पहले एक customer ने kernel driver पर आधारित custom high-security solution order किया था; वे offline computer पर critical database चला रहे थे और सभी system calls को track कर data में बदलाव हो तो exact बदलावों की alerting और logging चाहिए थी। backups भी कभी बाहर नहीं जाने चाहिए थे, और site installation से पहले Windows में ntdll hooking की जांच जैसी safety procedures भी required थीं। exceptions, hangs, deadlocks मंज़ूर नहीं थे, और एक भी system call छूटना disaster था
      इसलिए driver code बदलने पर हर बार अलग-अलग hardware वाले 7 office computers पर तय procedure से फिर test करते थे, और release से पहले final test और भी व्यापक होता था
      इस standard से देखें तो CrowdStrike लगभग पूरी तरह amateur लगता है। security community में इसका कोई योगदान नहीं, और research level भी junior security researcher जैसा दिखता है। खुलेआम बढ़ा-चढ़ाकर कहना या जल्दबाज़ी में conclusions निकालना भी community में अच्छा नहीं माना जाता
      Kaspersky और Checkpoint जैसी असली expert companies को देखना चाहिए। उन्होंने सिर्फ verified top-tier security solutions ही नहीं बनाए, बल्कि zero-days खोजकर exploit होने से पहले report करने जैसी valuable research भी community को मुफ्त में दी है। CrowdStrike आलोचना के लायक है
    • क्या कोई सचमुच metaphorical fire-fighting का आनंद लेता है? ऐसा rework काफी frustrate करने वाला लगता है
    • पूर्व quality assurance engineer के तौर पर, मैं confirm कर सकता हूं कि quality को अक्सर self-interest के पीछे भागने वालों के सामने पड़ी झंझट भरी रुकावट माना जाता है। बाहर से इसे इस तरह भी पेश किया जाता है कि customer के पैसे पर मज़े करने में बाधा है
      कई सालों में बार-बार देखी गई org-restructuring strategies में सबसे यादगार थी: “सभी engineering staff को हर domain में instantly replaceable resource की तरह train करेंगे।” यह पूरी तरह जगह पर खड़े रहने जैसा है

  • critical software infrastructure को critical physical infrastructure की तरह regulate करना चाहिए। जैसे buildings और bridges बनाने वालों पर “वे खुद सही कर लेंगे” भरोसा नहीं किया जाता, बल्कि regulation और inspection अनिवार्य किए जाते हैं, वैसा ही होना चाहिए
    अगर software रुकने पर दुनिया भर में लाखों लोग फंस जाते हैं, तो वह critical infrastructure है। इस बार यह एक साधारण “accident” था, लेकिन आगे युद्ध जैसी स्थिति में threat actors systems गिराने की कोशिश करें तो यह और गंभीर हो सकता है

    • सोच रहा हूं कि क्या आपने देखा कि problem वाला software ज़्यादातर उन्हीं companies में install था जहां regulation और inspection, system administrators की common sense से ऊपर रखे जाते हैं। क्या आप यकीन से कह सकते हैं कि समाधान सिर्फ उसी तरह के और regulation हैं?
    • वे companies CrowdStrike चला ही इसलिए रही थीं क्योंकि regulation था
    • “industry regulate की तो अमेरिका चीन से हार जाएगा” या “regulation अमेरिका की competitive edge मार देगा” जैसी reactions मैंने कई बार सुनी हैं, और यह सच में निराशाजनक है
      अगर कोई domain safety-critical है, तो उसे बाकी चीजों से ज़्यादा सख्ती से देखना चाहिए, और for-profit company के self-regulated quality assurance process पर नहीं छोड़ना चाहिए। बड़े button को दबाने से पहले और review चाहिए
      जोड़ दूं कि quotes में लिखा वाक्य मेरा नहीं है, बल्कि regulation की बात छेड़ने पर दूसरों से सुना गया counterargument है
    • हर चीज़ की तरह सस्ता, तेज़, अच्छा में से सिर्फ दो चुनने का नियम लागू होता है
      software लगभग हमेशा सस्ता और तेज़ बनाया जाता है। NASA तक software mistake की वजह से rocket को उड़ान के दौरान explode होते देख चुका है

  • कल सुबह मुझे खबर मिली कि एक परिचित व्यक्ति का अभी-अभी निधन हो गया है और अंतिम संस्कार अगले हफ्ते तय है
    वह एक महीने से अधिक समय तक अस्पताल में था, फिर घर लौटने के कुछ ही दिनों बाद उसे स्ट्रोक आया
    लेकिन मुझे याद आया कि उसकी एक महत्वपूर्ण सर्जरी मूल रूप से तय थी, पर CrowdStrike outage के कारण टल गई थी। दोबारा शेड्यूल मिलाकर सर्जरी होने में कई हफ्ते लग गए
    उस दिन उसकी सर्जरी हुई, और मैं लगातार सोचता रहता हूं कि अगर वह अपनी स्थिति और भविष्य के तनाव में अस्पताल में कुछ और हफ्ते न रहा होता, तो क्या नतीजा अलग होता

    • यह लिखने के लिए धन्यवाद, और अच्छा हुआ कि आपने इसे शेयर किया। यह distributed harm का एक उदाहरण है
      इस घटना से पैदा हुए लाखों नुकसानों में से एक, लेकिन इसे पैसे में नहीं बदला जा सकता, इसलिए असल में इसकी “गिनती” नहीं होती
      उदाहरण के लिए, अगर आप 3 साल के बच्चे के घुटने पर लात मारकर उसे जिंदगी भर के लिए विकलांग बना दें, तो जाहिर है आपको राक्षस कहा जाएगा। लेकिन अगर आप ऐसे शिक्षा सुधार का समर्थन करें जो स्कूलों से American Sign Language को बाहर कर दे और बधिर बच्चों को विकास के दौर में भाषा के बिना बड़ा होने पर मजबूर करे, तो ऐसे काम के कुल पैमाने और नुकसान को बयान करने के लिए हमारे पास ठीक से शब्द भी नहीं हैं
      हम distributed harm से ठीक से निपट नहीं पाते। इसकी बड़ी वजह यह है कि उससे पैदा होने वाले सभी ठोस नुकसान हमें दिखते नहीं, और दिख भी नहीं सकते
    • CrowdStrike का बचाव करने की कोशिश नहीं है, लेकिन सिर्फ कमियां देखना थोड़ा unfair है। अगर उस अस्पताल ने vaccine software न खरीदा होता और वह ransomware का शिकार हो जाता, तो क्या होता?

  • जिसे engineering process expert के तौर पर quote किया गया है, वह senior UX designer है—यह बात सवाल पैदा करती है। लगता नहीं कि वह kernel patch deployment process के बहुत करीब रहा होगा

    • सीधे करीब रहने की संभावना कम है, लेकिन फिर भी यह कंपनी की समग्र culture दिखाता है और हमारे जानने वाली kernel engineering culture से भी मेल खाता है। सीमित testing, review की कमी, सामान्य safety guardrails का इस्तेमाल न होना जैसी चीजें

  • CrowdStrike के quality control को जायज ठहराने की कोशिश नहीं है, लेकिन जिन कई software development जगहों पर मैंने काम किया है, वहां भी quality control गायब होने के मामले काफी आम थे
    लेख पढ़कर ऐसा लग सकता है कि हर software project की अच्छी तरह testing होती है, लेकिन मेरे अनुभव में ज्यादातर चीजें जल्दबाजी में release होती हैं

    • मैंने कई trillion-dollar software companies में काम किया है, लेकिन जानबूझकर dedicated quality assurance organization नहीं रखे गए थे। सारा ध्यान तेजी से आगे बढ़ने पर था
      entertainment software या कम अहमियत वाले business software के लिए यह ठीक हो सकता है, लेकिन critical software के लिए यह बहुत खराब विचार है। अफसोस की बात है कि “तेजी से आगे बढ़ो” वाला रवैया उन जगहों तक फैल गया जहां उसे होना ही नहीं चाहिए था
    • इस विषय पर हुई बहुत-सी चर्चाएं ideal testing और deployment practices को आधार मानकर की गई हैं। Silicon Valley या investment banks अलग हो सकते हैं, लेकिन मेरे काम करने वाली telecom जैसी कंपनियां उस ideal से काफी दूर हैं
      industry ऐसी जगह लगती है जहां कुछ सक्षम लोग किसी तरह systems को चलाए रखते हैं, जबकि बाकी हिस्सों में चौंकाने वाली technical incompetence दिखती है। management हर मौके पर quality के बजाय short-term cost cutting को प्राथमिकता देता है, और नतीजे में भयानक technical debt और उत्साह खो चुकी, overworked workforce जमा होती जाती है। quality issues उठाने पर नुकसान झेलना पड़ता है, इसलिए आखिरकार लोग quality की परवाह करना छोड़ देते हैं

  • कुछ former employees नाराज होकर CrowdStrike को खराब दिखाने वाली बातें कह सकते हैं। हर कंपनी में ऐसा होता है
    लेकिन CrowdStrike की अब credibility 0 है। वे जो भी कहते हैं, उसका एक शब्द भी मैं नहीं मानता

    • Boeing जैसी companies में तो संतुष्ट कर्मचारियों की list शायद और छोटी हो

  • CrowdStrike के बारे में ज्ञात हर बात Knight Capital की याद दिलाती है। छोटे cultural issues कैसे पूरी functional failure में बदलते हैं, और आखिरकार ऐसा bug बन जाते हैं जो कंपनी को खत्म कर दे

    • Knight Capital को प्रति मिनट 10 million dollars का नुकसान हो रहा था
      बुधवार सुबह stock market में अफरातफरी पैदा करने वाली trading problem से पहले ही इतना खर्च हो रहा था, और Knight Capital Group ने घोषणा की कि computer flaw के कारण गलती से खरीदे गए सारे shares बेचते हुए उसे 440 million dollars का नुकसान हुआ
      “flaw” कह रहे हैं…
      https://en.wikipedia.org/wiki/Therac-25

  • पिछली कंपनी में कुछ customers और liability insurers ने compliance वजहों से CrowdStrike अपनाने पर जोर दिया था। खासकर BCG ने CrowdStrike इस्तेमाल करने की मांग की थी
    CrowdStrike न इस्तेमाल करने के लिए मनाना वाकई कठिन लड़ाई थी। आखिरकार सफलता मिली, लेकिन कई stakeholders को मनाने में बहुत meetings और समय लगा। लगता है बहुत-से लोग बस हार मानकर इसे deploy कर चुके होंगे

    • उत्सुक हूं कि आखिरकार आपने कोई दूसरा EDR solution इस्तेमाल किया, या फिर deploy न करने के लिए ही मना लिया

  • मैंने एक बार ऐसी team में काम किया था जो organization में CrowdStrike agent deploy करती थी, और सबसे बड़ी समस्याओं में से एक यह थी कि daemon भारी मात्रा में logs लिखता था, फिर भी इसे रोकने या कम करने के लिए कोई setting नहीं थी