Azure के भरोसे को तोड़ने वाले फ़ैसले – एक पूर्व Azure Core इंजीनियर का रिकॉर्ड

 (isolveproblems.substack.com)
3 पॉइंट द्वारा GN⁺ 29 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Microsoft Azure Core के भीतर अवास्तविक निर्णय-प्रक्रियाओं के जमा होने से तकनीकी अव्यवस्था और भरोसे के टूटने तक पहुँचने की प्रक्रिया को एक पूर्व इंजीनियर ने विस्तार से बताया है
  • हार्डवेयर सीमाओं को नज़रअंदाज़ करने वाली Windows फीचर पोर्टिंग योजना और 173 मैनेजमेंट एजेंट्स की अव्यवस्थित भरमार को प्रमुख समस्याओं के रूप में चिन्हित किया गया है
  • यह जटिल संरचना OpenAI, Anthropic, सरकारी cloud जैसे महत्वपूर्ण workloads को संभाल रही है, इसलिए एक अकेली त्रुटि के वैश्विक outage में फैलने का जोखिम मौजूद है
  • प्रबंधन की चुप्पी के बीच OpenAI के साथ संबंधों का बिगड़ना, अमेरिकी सरकार का भरोसा खोना, फीचर रिलीज़ में देरी जैसी बाद की घटनाएँ सामने आईं
  • नतीजतन यह 1 ट्रिलियन डॉलर के market value के मिटने तक पहुँचा, और cloud infrastructure संचालन में तकनीकी वास्तविकता की समझ और सादगी बनाए रखने के महत्व को रेखांकित किया गया

Azure के भरोसे के पतन का अंदरूनी रिकॉर्ड

  • Microsoft Azure Core टीम के भीतर अवास्तविक निर्णय-प्रक्रियाओं और उनसे पैदा हुई तकनीकी व संगठनात्मक अव्यवस्था पर एक पूर्व इंजीनियर का संस्मरण
  • Overlake R&D टीम में शामिल होने के पहले ही दिन, हार्डवेयर सीमाओं की अनदेखी करने वाली Windows फीचर पोर्टिंग योजना पर चर्चा होते देखी
  • 173 मैनेजमेंट एजेंट्स मौजूद थे, लेकिन स्थिति इतनी जटिल और अपारदर्शी थी कि उनके काम और आवश्यकता को कोई स्पष्ट रूप से नहीं जानता था
  • यही संरचना OpenAI, Anthropic, सरकारी cloud जैसे महत्वपूर्ण workloads को संभाल रही है, इसलिए एक अकेली गलती से वैश्विक outage होने का जोखिम है
  • लेखक के अनुसार इसका परिणाम OpenAI का भरोसा खोना, अमेरिकी रक्षा विभाग का सार्वजनिक अविश्वास, और 1 ट्रिलियन डॉलर की market value का मिटना रहा

Azure Core में शामिल होना और शुरुआती स्थिति

  • 1 मई 2023 को Azure Boost offloading card और network accelerators को संभालने वाली Overlake R&D टीम में senior engineer के रूप में शामिल हुए
  • इससे पहले Windows टीम और Core OS टीम में kernel सुधार और container platform development पर काम किया, और Docker, AKS, App Services, Windows Sandbox जैसी प्रमुख तकनीकों में योगदान दिया
  • Overlake card के शुरुआती डिज़ाइन (2020~2021) में भी शामिल रहे और host OS तथा accelerator card के बीच communication protocol का प्रस्ताव दिया था
  • Azure platform को 10 साल से अधिक समय तक सीधे संचालित और विकसित कर चुके विशेषज्ञ के रूप में वापसी की

पहली मीटिंग में दिखी अवास्तविक योजना

  • जॉइनिंग के पहले ही दिन टीम की मासिक planning meeting में Windows components को Overlake card पर port करने की योजना देखी
  • जबकि Overlake card की RAM capacity और power budget बेहद सीमित थे, टीम Windows फीचर्स को वहाँ ले जाने की कोशिश पर चर्चा कर रही थी
  • हार्डवेयर विनिर्देशों के हिसाब से यह असंभव योजना थी, फिर भी “इसे कुछ junior developers को दे देते हैं” जैसी बात कही गई
  • संगठन Windows को Linux पर port करके VM management agent को बनाए रखने की दिशा पर गंभीरता से विचार कर रहा था
  • लेखक ने इसे “वास्तविकता से कटी हुई योजना” माना और निष्कर्ष निकाला कि पूरा संगठन असंभव लक्ष्य की ओर मार्च कर रहा था

तकनीकी सीमाएँ और संरचनात्मक समस्याएँ

  • उस समय stack 400W Xeon CPU पर केवल कुछ दर्जन VM संभाल सकता था, जो hypervisor की 1,024 VM सीमा से बहुत दूर था
  • अत्यधिक resource उपयोग के कारण customer VM में jitter जैसी performance समस्याएँ मौजूद थीं
  • ऐसी अक्षम stack को छोटे ARM SoC पर port करके scale करने की योजना तकनीकी रूप से असंभव थी
  • लेखक ने कहा कि “नई तकनीक सीखने से ज़्यादा ज़रूरी काम पूरे संगठन को फिर से वास्तविकता में लौटाना था”

Azure Linux और Overlake से जुड़ी अंदरूनी बातचीत

  • Linux System Group के प्रमुख के साथ 90 मिनट की बातचीत में पता चला कि Overlake card के लिए 173 agents को porting candidates के रूप में चुना गया था
  • जाँच में सामने आया कि Microsoft के भीतर कोई भी इन 173 agents की भूमिका, परस्पर क्रिया, या अस्तित्व का कारण स्पष्ट रूप से नहीं समझा सकता था
  • Azure का मूल VM, networking और storage है, और बाकी सेवाएँ इन्हीं के ऊपर बनी हैं, फिर भी अनावश्यक जटिलता लगातार जमा होती गई
  • ऐसे अनियंत्रित components का समूह OpenAI, Anthropic और सरकारी cloud जैसे प्रमुख workloads को मैनेज कर रहा था

भरोसे का टूटना और बाद की घटनाएँ

  • यह जटिल संरचना राष्ट्रीय सुरक्षा और business continuity के लिए गंभीर जोखिम पैदा कर सकती थी
  • बाद में CEO, board, और Cloud+AI डिविज़न के EVP को भेजे गए पत्रों का कोई जवाब नहीं मिला
  • इसके परिणामस्वरूप OpenAI के साथ संबंध बिगड़ना, अमेरिकी सरकार का भरोसा टूटना (रक्षा मंत्री के सार्वजनिक बयान), engineering waste और Rust migration का निर्देश, तथा feature releases में देरी जैसी घटनाएँ हुईं
  • लेखक ने इसे “1 ट्रिलियन डॉलर की market value के मिटने की घटना” कहा और Azure इस्तेमाल करने वाली कंपनियों को production environment पर निर्भरता के जोखिम के बारे में चेताया

निष्कर्ष

  • Azure के भीतर तकनीकी जटिलता, कमजोर प्रबंधन, और अवास्तविक निर्णय-प्रक्रियाओं के जमा होने से भरोसा कैसे टूटा, यह सामने आता है
  • यह उस संगठन का उदाहरण है जो महत्वपूर्ण infrastructure संभालते हुए भी वास्तविकता-बोध खोकर संरचनात्मक विफलता की ओर मार्च करता रहा
  • cloud infrastructure की स्थिरता और सादगी, और संगठन के भीतर तकनीकी निर्णय-क्षमता बनाए रखने के महत्व पर ज़ोर दिया गया है

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

1 टिप्पणियां

 
GN⁺ 29 일 전
Hacker News की राय

  • जो व्यक्ति हर दिन Azure इस्तेमाल करता है, उसके नज़रिए से अगर यह खुलासा सच है, तो लगता है कि बहुत सी बातें समझ में आ जाती हैं
    UI बेतरतीब है और डॉक्यूमेंटेशन ऐसा लगता है जैसे AI ने लिखा हो और वह गलत हो, और सेवाओं के इतने प्रकार हैं कि यह तक समझ नहीं आता कि किसे इस्तेमाल करें
    कंसल्टेंट की मदद के बिना इसे कॉन्फ़िगर करना मुश्किल है, और कॉन्फ़िगरेशन के बाद भी यह भरोसा नहीं होता कि यह सही से काम कर रहा है
    ईमानदारी से कहें तो यह अभी तक चल रहा है, यही हैरानी की बात है

    • पहले Azure की डॉक्यूमेंटेशन देखकर प्रभावित हुआ था, लेकिन एक हफ़्ते की इम्प्लीमेंटेशन के बाद टेस्ट एनवायरनमेंट में GraphAPI डॉक्यूमेंटेशन के मुताबिक काम नहीं कर रहा था, इसलिए सब पूरी तरह विफल हो गया
      उसके बाद से मैं डॉक्यूमेंटेशन पर भरोसा नहीं करता
    • मैंने Azure कंसल्टेंट्स के साथ काम किया है, और वे भी Azure से नफ़रत करते हैं
    • मैनेजमेंट ने कहा कि क्रेडिट बहुत हैं, इसलिए AKS पर माइग्रेट किया, लेकिन pod रैंडम तरीके से क्रैश होने लगे और DB नोड्स की डिस्क लेटेंसी अचानक बढ़ गई
      जो सेवा GCP पर स्थिर चल रही थी, वह अप्रत्याशित हो गई

  • मैंने Azure OpenAI को लोड के समय दूसरे ग्राहकों के prompt response लीक करते देखा है
    संबंधित ट्वीट भी है
    लेकिन माहौल ऐसा है जैसे किसी को परवाह ही नहीं

    • यह जानने की जिज्ञासा है कि “Azure OpenAI” से ठीक-ठीक क्या मतलब है — GitHub Copilot, Microsoft Copilot, OpenAI API, या Azure पर होस्ट किए गए किसी LLM में से एक?
      स्थिति पूरी तरह wild west जैसी लगती है

  • इस लेख के दावे इतने विशिष्ट हैं कि हैरानी होती है
    सोचने वाली बात है कि लेखक whistleblower है या सिर्फ़ कोई असंतुष्ट पूर्व कर्मचारी
    CEO और बोर्ड को सीधे रिपोर्ट भेजने वाला हिस्सा खास तौर पर प्रभावशाली लगा
    अमेरिकी कॉर्पोरेट संस्कृति में ऐसी प्रक्रिया का ‘रूढ़िगत’ होना अजीब लगता है
    Azure सच में इतना अस्थिर है या नहीं, यह जानने के लिए वास्तविक यूज़र अनुभव दिलचस्प होंगे

    • मैं वास्तव में SRE के रूप में AWS, Azure और GCP तीनों चलाता हूँ, और 80~90% आउटेज Azure में होते हैं
      Azure को समस्या का पता नहीं चलता, कारण भी नहीं पता होता, और यहाँ तक कि उसे परवाह भी नहीं लगती
      पूरी टीम Azure से नफ़रत करती है
    • Azure में consistency issues और race conditions बहुत ज़्यादा हैं
      यह अच्छा लगा कि AWS Bedrock में OpenAI models इस्तेमाल किए जा सकते हैं, जिससे Azure से बचा जा सकता है
      reliability अब भी गंभीर समस्या है
    • बड़ी कंपनियाँ अक्सर अल्पकालिक metrics के लिए quality की कुर्बानी दे देती हैं
      “जल्दी ship करो और बाद में ठीक कर लेंगे” वाली रणनीति आखिरकार ऐसे नतीजे लाती है
    • मैंने पहले एक security report देखी थी जिसमें Azure container से escape करके management controller की vulnerability खोजी गई थी
      तब से मैं उस पर भरोसा नहीं करता
    • चाहे मुफ्त credits भी मिलें, फिर भी AWS या GCP को पैसे देकर इस्तेमाल करना बेहतर लगता है

  • लेख कुछ हद तक भावनात्मक रूप से बढ़ा-चढ़ाकर लिखा गया लगता है, जिससे मूल मकसद धुंधला हो गया है
    Azure की आंतरिक grade structure या Sev2 स्तर के issues कोई बहुत असाधारण चीज़ नहीं हैं
    Azure में समस्याएँ हैं, लेकिन उसका scale इतना बड़ा है कि कुछ खुरदुरापन स्वाभाविक है
    असली परिपक्वता सिस्टम के भीतर रहकर सुधार करने की कोशिश में है, ऐसा लगता है

    • बोर्ड को सीधे चिट्ठी भेजना संगठन के भीतर शायद ही कभी अच्छा परिणाम देने वाला कदम होता है
      Azure अव्यवस्थित हो सकता है, लेकिन यह भी संभव है कि लेखक का तरीका भी समस्या का हिस्सा रहा हो
    • AWS और GCP का UX/DX काफ़ी बेहतर है, जबकि Azure तो यह भी नहीं बताता कि क्या काम क्यों नहीं कर रहा
      Azure के बारे में धारणा पूरी तरह नकारात्मक है
    • Microsoft सरकारी संस्थानों का डिफ़ॉल्ट समाधान हो सकता है, लेकिन पूरे सिस्टम को फिर से लिखने का प्रस्ताव व्यावहारिक नहीं है
      लेखक का दृष्टिकोण उल्टा भरोसा कम करता है
    • यह चौंकाने वाली बात है कि लेखक के अनुसार कम seniority वाले लोगों को core systems सौंपे गए थे
    • “सब कुछ टूट चुका है” चिल्लाने वाले लोग बहुत होते हैं, लेकिन यह संगठन की जड़ता से जुड़ी समस्या भी हो सकती है
      नए कर्मचारियों के “wtf/day” कहने की आवृत्ति किसी संगठन के स्वास्थ्य का संकेतक जैसी लगती है
      बाहर से देखने पर भी Azure की quality बेहद खराब दिखती है
      AWS का पीछा करने की जल्दी में features फेंकते-फेंकते वह भारी technical debt के दलदल में फँस गया
      IPv6, azcopy, VM upgrades जैसे बुनियादी फ़ीचर भी अब तक अस्थिर हैं

  • एक पुराने सहकर्मी Azure हर दिन इस्तेमाल करते हैं, और उनकी शिकायतों का विस्फोट सुनकर इस लेख की बातों को समझना आसान हो जाता है
    12 साल पहले जब cloud specialization चुन रहा था, तब Azure को थोड़ी देर इस्तेमाल करके ही वह धीमा और टूटा हुआ प्लेटफ़ॉर्म लगा था, और यह लेख उस आकलन की पुष्टि करता है

  • लेख के अंतिम हिस्से में Microsoft द्वारा 2025 में 15,000 कर्मचारियों की छंटनी का ज़िक्र ध्यान खींचता है
    यह AI boom के बाद की हक़ीक़त दिखाने वाला उदाहरण लगता है

    • लेकिन मुझे लगता है कि वह हिस्सा लेख का अपेक्षाकृत कमज़ोर तर्क है
      OpenAI contract GPU capacity की समस्या थी, और layoffs अलग मुद्दा हैं
      असली समस्या engineer rotation और accountability की कमी है
      हर प्रोजेक्ट में नए लोग लगाए जाते हैं, और ownership की भावना गायब हो जाती है

  • यह हिस्सा कि host के compromise होते ही सभी VM memory तक पहुँचा जा सकता है, बेहद ख़तरनाक लगता है

    • यह कल्पना करना भी मुश्किल है कि ऐसी architecture को अच्छा विचार मानने वाला माहौल कैसा रहा होगा
    • समझ नहीं आता कि लेखक को इससे क्या उम्मीद थी

  • Satya Nadella के वेतन के 9.65 करोड़ डॉलर तक, यानी 22% बढ़ने वाले CNBC उद्धरण को,
    और Artemis II के astronaut के इस कथन को कि “Outlook के दोनों इंस्टेंस काम नहीं कर रहे,” साथ देखकर विडंबना महसूस हुई

    • “Outlook के दो इंस्टेंस” — एक ही पहले से बहुत ज़्यादा है

  • लेख की बातें कुछ बढ़ा-चढ़ाकर कही गई लगती हैं, लेकिन मैंने भी इसी तरह के सिस्टम चलाए हैं, इसलिए stability बनाए रखने के लिए लगातार लड़ते रहने की यादें ताज़ा हो गईं
    दूसरी कंपनियों में भी ऐसे मुद्दे देखे हैं, लेकिन Azure के scale की गंभीरता नहीं थी
    ऐसी संरचना आखिरकार self-destructive loop में बदलती दिखती है

  • मैंने 2018 में Azure इस्तेमाल किया था, और वह धीमा, महँगा और बेहद खराब quality वाला लगा
    GitHub फ़ोरम पर दूसरे यूज़र्स के साथ मिलकर बुनियादी फ़ीचर्स तक न चलने वाली समस्याओं को हल करने की कोशिश की थी
    इस लेख ने उस समय के कई सवालों का जवाब दे दिया
    निजी तौर पर मुझे Google Cloud सबसे अच्छी तरह डिज़ाइन किया गया प्लेटफ़ॉर्म लगा, लेकिन AWS की तुलना में मानवीय सहायता कम होना खलता है

    • GCP का support सच में बहुत खराब है
      अकाउंट मैनेजर तीन महीने में तीन बार बदल गया, और quota requests या system limits से जुड़े सवाल कभी-कभी अनदेखे कर दिए जाते हैं