- यह AWS US-EAST-1 क्षेत्रीय आउटेज सिर्फ एक तकनीकी खामी नहीं, बल्कि मुख्य प्रतिभा के बाहर जाने से हुई संगठनात्मक कमजोरी का संकेत माना जा रहा है
- आउटेज का कारण अब भी एक क्लासिक DNS समस्या निकला, और DynamoDB API endpoint त्रुटि की वजह से दूसरी सेवाएँ भी क्रमिक रूप से बंद होती गईं
- पहले सिस्टम की विफलता के पैटर्न याद रखने वाले अनुभवी इंजीनियरों के इस्तीफा देने से समस्या पहचानने और रिकवरी की रफ्तार साफ तौर पर धीमी पड़ गई
- Amazon के भीतर बड़े पैमाने पर छंटनी और ऊँची ‘regretted attrition’ (69~81%) ने मिलकर AWS की परिचालन स्थिरता को हिला दिया है
- यह तकनीक के पुराने हो जाने की नहीं, बल्कि लोगों की कमी से पैदा हुआ संकट है, और इसे AWS की “एक बार की दुर्घटना” नहीं बल्कि लगातार भरोसा टूटने की शुरुआत के रूप में देखा जा रहा है
DNS आउटेज और सेवा बाधित होना
- सिस्टम एडमिन्स के बीच लंबे समय से चलने वाले "It's always DNS" वाले मजाक की तरह, कई सेवा आउटेज के केंद्र में अक्सर DNS issue ही होता है
- 20 अक्टूबर 2025, 12:11AM(PDT) पर US-EAST-1 क्षेत्र में AWS सेवाओं की error rate में तेज उछाल की रिपोर्ट आई
- 1:26AM पर, DynamoDB endpoint पर request failure गंभीर रूप से बढ़ने लगे
- 2:01AM पर, DynamoDB API endpoint की DNS resolution त्रुटि को कारण के रूप में पहचाना गया, जिसके बाद कई dependent services cascading outage में चली गईं
- DynamoDB AWS infrastructure की बुनियादी सेवा है, इसलिए उस क्षेत्र की सेवा गिरने पर पूरे इंटरनेट पर असर पड़ा
- बैंकिंग, गेम, SNS, सरकारी सेवाएँ, Amazon.com शॉपिंग आदि में बड़े पैमाने पर ठप स्थिति बनी
- समस्या समझ में आने से लेकर मूल कारण पहचानने तक 75 मिनट लगे, जो AWS की “उदाहरणीय रिकवरी स्पीड” की परंपरा के हिसाब से असामान्य रूप से धीमी प्रतिक्रिया थी
- आउटेज पहचानने और कारण पता करने में इतना समय लगना, विश्लेषण के मुताबिक पारदर्शिता की कमी से ज्यादा अनुभव की कमी की वजह से था
- इस दौरान status page पर केवल “सामान्य संचालन जारी” संदेश दिखता रहा, जिस पर कम्युनिटी की आलोचना हुई
‘भविष्यवाणी’ का सच होना: इस्तीफा दे चुके लोगों की चेतावनी
- पारंपरिक रूप से AWS अपनी उच्च स्तरीय infrastructure operations क्षमता के लिए जाना जाता था, जहाँ सिर्फ एक region में outage भी बड़ा मुद्दा बन जाता था, लेकिन जितनी अधिक जटिलता और अतीत जैसे दोहराए जाने वाले issue होते हैं, उतना ही फील्ड अनुभव महत्वपूर्ण हो जाता है
- AWS के पूर्व इंजीनियर Justin Garrison ने 2023 में इस्तीफा देते समय चेतावनी दी थी कि “बड़े पैमाने की घटनाएँ (LSE) बढ़ रही हैं”
- उन्होंने अनुमान लगाया था कि “2024 में एक बड़ा आउटेज होगा”, और यह घटना मानो उसी की पुष्टि बन गई
- AWS के भीतर वरिष्ठ तकनीकी लोगों के लगातार इस्तीफे जारी रहे,
और उनके साथ दशकों में जमा हुआ tribal knowledge (आंतरिक अनुभव पर आधारित ज्ञान) भी खो गया
- DNS आउटेज जैसी स्थिति में सिर्फ तकनीकी कारण जानने वाले व्यक्ति से अधिक,
ऐसे लोगों की ज़रूरत होती है जिन्हें याद हो कि “क्या इस सिस्टम ने पहले भी ऐसा ही मसला पैदा किया था?”
- लेकिन वह याद रखने वाले लोग RTO (वापसी-से-ऑफिस नीति) के विरोध और छंटनी के कारण कंपनी छोड़ गए
प्रतिभा पलायन के सबूत
- 2022~2025 के बीच Amazon के 27,000 से अधिक कर्मचारियों की छंटनी हुई,
और विभागवार अनुपात सार्वजनिक नहीं है, लेकिन माना जाता है कि AWS भी सीधे प्रभावित हुआ
- आंतरिक दस्तावेजों के अनुसार “regretted attrition” 69~81% तक पहुँचा,
जिसका मतलब है कि “वे लोग गए जिन्हें कंपनी रोकना चाहती थी”
- Return to Office आदेश से असंतोष फूट पड़ा,
और कई रिपोर्टों में बताया गया कि अनुभवी veteran engineers ने बड़ी संख्या में नौकरी छोड़ी
- नतीजतन AWS को कम अनुभव वाली, कम लागत वाली टीमों में दोबारा संगठित किया गया,
जिससे जटिल infrastructure चलाने की उसकी क्षमता धीरे-धीरे कमजोर हुई
संरचनात्मक समस्या: ‘Frugality’ का बदल जाना
- पहले Amazon का मुख्य मूल्य Frugality था,
जिसका दर्शन था “कम संसाधनों से अधिकतम दक्षता”
- लेकिन हाल के वर्षों में इसका मतलब बदलकर “लगभग बिना संसाधनों के हर काम कर लेना” हो गया
- स्टाफ कटौती के कारण स्थिति यहाँ तक आ गई कि बुनियादी maintenance भी कठिन हो गया
- इसका मतलब यह है कि समस्या “तकनीक पुरानी होने” से नहीं, बल्कि “उसे संभालने वाले लोग नए होने” से पैदा हुई है
आगे की तस्वीर
- बाजार इस आउटेज को एक बार की घटना की तरह ले सकता है, लेकिन समस्या की संरचना बनी हुई है
- अनुभवी लोग जा रहे हैं, सिस्टम की जटिलता बढ़ रही है,
और “अगली दुर्घटना” की संभावना बढ़ाने वाला चक्र बनता जा रहा है
- AWS संभवतः इस घटना को “isolated single outage” के रूप में पेश करेगा,
लेकिन अगर अंदरूनी खालीपन बढ़ता गया तो ऐसे ही बड़े आउटेज दोहराने का जोखिम ऊँचा रहेगा
- “chickens are coming home to roost” वाली अभिव्यक्ति की तरह,
तकनीक से अधिक मानव पूंजी का नुकसान AWS का सबसे बड़ा जोखिम बनकर उभर रहा है
8 टिप्पणियां
लोग जहाँ भी हों, सब एक जैसे ही होते हैं..
यह हर बाज़ार में लागू होने वाली कहानी है।
लगता है कि IT तकनीक की know-how के साथ उसी तरह व्यवहार किया जाना चाहिए जैसे कुशल welders की know-how के साथ किया जाता है।
कुछ समय पहले पढ़ी एक पोस्ट में यह बात याद आ रही है कि
Amazon में senior engineer level 2 के बाद अगले स्तर पर जाना वाकई बहुत मुश्किल होता है। किसी वजह से ऐसा लगता है कि
ऐसी खेदजनक रिटायरमेंट जैसी घटनाएँ खासकर उसी स्तर पर ज़्यादा होती होंगी।
दूसरी तरफ, ऊपर की बात देखकर कोई यह भी सोच सकता है, 'इतने लोगों को निकाला गया था, फिर भी बात इस हद तक संभल गई...'
कोरिया में इंजीनियर एक स्तर के बाद सब मैनेजर बन जाते हैं, इसलिए वहाँ निरंतरता टूट जाती है...
अमेरिका में efficiency के नाम पर सभी senior लोगों को निकाल दिया जाता है, इसलिए वहाँ समस्या है...
वाकई, यह आसान नहीं है...
multi-az तक तो कर रखा है.. क्या अब region-स्तर की outage की तैयारी भी करनी पड़ेगी..
मुझे लगता है कि यह भी सोचना चाहिए कि क्या वह लागत वास्तव में नुकसान की लागत से अधिक है।
Hacker News राय
इंजीनियर कर्मचारियों और वेयरहाउस मज़दूरों के बीच अब ऐसा लगने लगा है कि अगर कर्मचारियों को इसी तरह निकालते रहे, तो वह दिन भी दूर नहीं जब वे लोग भी पूरी तरह चले जाएँगे जिन्होंने पहले कभी इस कंपनी में काम किया था
चाहे लाखों H1-B इंजीनियर उम्मीदवार हों और करोड़ों अवैध आप्रवासी वेयरहाउस मज़दूर, इतनी बड़ी कंपनी अगर तेज़ी से बड़े पैमाने पर छंटनी करती है, तो आखिरकार मानव संसाधन खत्म होने ही लगते हैं
यह स्थिति Robot Chicken के Star Wars पैरोडी एपिसोड की याद दिलाती है। उसमें Imperial officers, Darth Vader के force choke करने का नाटक होते ही मरने का बहाना करके lightsaber से कटने से बचने के लिए भाग जाते हैं, और बाद में किसी और नाम से वापस आते हैं, लेकिन Amazon उससे भी बदतर है। कोई भी वापस आना नहीं चाहता
https://www.youtube.com/watch?v=fFihTRIxCkg
सच कहूँ तो, कम से कम किसी भी काबिल इंजीनियर को मैंने Amazon में दोबारा काम करना चाहते नहीं देखा
क्या वेयरहाउस में सचमुच इतने अवैध आप्रवासी होते हैं? मेरी समझ से Amazon पहचान मिलान और दस्तावेज़ की जाँच काफ़ी सख़्ती से करता है। कभी-कभी पहचान की चोरी करने वाले लोग हो सकते हैं, लेकिन ऐसा बहुत ज़्यादा होगा, ऐसा नहीं लगता
सिर्फ़ छंटनी ही समस्या नहीं है, मुझे याद है कि Amazon ने जैसे ही पूरी तरह RTO लागू किया, रिक्रूटर ईमेल की बाढ़ आ गई थी
लगता है कि सिर्फ़ H-1B होने के आधार पर इंजीनियरिंग क्षमता को लेकर एक तरह का पूर्वाग्रह है
मैंने भी पहले H-1B पर काम किया था, और अब भारत लौटकर अपना बिज़नेस बना रहा हूँ। Amazon से था। जगह कठिन थी, लेकिन 90 के दशक के मध्य में stock option था, इसलिए काम करने लायक था
मुझे भरोसा है कि यहाँ मौजूद कई लोगों से मैं बेहतर coding कर सकता हूँ। और मेरे आसपास H-1B पृष्ठभूमि वाले कई लोग सचमुच बेहद सक्षम थे
पूर्वाग्रह रखने के बजाय क्षमता का सीधे मूल्यांकन करना चाहिए। प्रतिस्पर्धी को कम आँकने का नुकसान आख़िरकार खुद को ही होता है
अभी सही रास्ता यह है कि कर्मचारियों को बनाए रखा जाए और उन्हें अच्छा काम करने के लिए बेहतरीन tools दिए जाएँ
डेवलपमेंट tools हर दिन बेहतर हो रहे हैं, और फ़िलहाल headcount कम भी किया जाए तो उसका असर तुरंत नहीं दिखेगा
यह भविष्य की growth और संगठन की sustainability को दाँव पर लगाकर वर्तमान को बचाने जैसा है। गलतफ़हमी पाल लेने से downsizing बेहतर नहीं हो जाती
वास्तव में रणनीति चलती हुई दिख रही है। junior principal engineers का एक-चौथाई निकाल दिया गया, लेकिन stock बढ़ गया, और उसके बाद बड़ा outage हुआ तब भी stock फिर बढ़ गया। अभी के लिए उनकी रणनीति काम करती हुई लगती है
अब पहले की “उभरती” big tech कंपनियाँ भी IBM जैसे पुराने दिग्गज कॉर्पोरेट दौर में प्रवेश कर रही हैं
ऐसा नहीं है कि उन्हें attrition खराब होने का पता नहीं, बल्कि लगता है कि वे शुरू से ही पूरे workforce को औसत स्तर पर समतल कर, सबको एक-दूसरे से बदला जा सकने वाला human resource बनाना चाहते हैं
अब तो सिर्फ़ बहुत सक्षम होना भी “cowboy culture” कहकर खारिज किया जा रहा है
यह काफ़ी संदिग्ध लगा कि असली outage response उसी समय शुरू हुआ जब US West Coast का कार्यदिवस शुरू हुआ
उससे पहले updates में सिर्फ़ “monitoring” और “mitigation in progress” जैसा लिखा था, कोई ठोस जानकारी नहीं थी
मेरी जानकारी में recovery Seattle समय के हिसाब से लगभग सुबह 4 बजे हुई थी। काम आम तौर पर 9 बजे शुरू होता है, हालाँकि संभव है कि New York के हिसाब से यह लगभग सुबह 6 बजे शुरू हुआ हो
आज सुबह Reddit पर जो पोस्ट पढ़ी थी, अब वह और ज़्यादा मायने रखने लगी है
AWS अब भी मेरी सबसे पसंदीदा cloud है, और मैं इसे काफ़ी दक्षता से इस्तेमाल करता हूँ
मैंने भी कभी AWS में काम करने के बारे में सोचा था, लेकिन कुछ चिंताएँ सचमुच दूर हुई हैं या नहीं, यह स्पष्ट न हो तो संदेह रहता है
अगर संभावित manager इस प्रक्रिया में भी candidate की रक्षा नहीं कर सकता, तो डर लगता है कि वह अधिक गंभीर corporate culture समस्याओं में भी रक्षा नहीं कर पाएगा
आजकल पूरे FAANG पर लागू होने वाला एक विचार है: यह धारणा लगातार ताज़ा करनी होगी कि यह अब भी वह जगह है जहाँ सचमुच सक्षम लोग जाना चाहते हैं
Meta ने ज़्यादातर ज़्यादा pay और open source·open hardware releases जैसी चीज़ों से अपनी branding की, और Google ने तकनीकी बढ़त और गर्मजोशी भरी corporate culture पर ज़ोर दिया (A.K.A. नए लोगों को तराशने वाली संस्कृति, भले अब वह अधिक औपचारिक हो गई हो)
AWS के पास पहले से ही गर्व करने लायक तकनीकी प्रतिभा है, और मेरा मानना है कि इन्हें आकर्षित करने और बनाए रखने में निवेश करते हुए उद्योग में इस छवि को सक्रिय रूप से फैलाने की ज़रूरत है
startup में भी मैंने बिल्कुल यही चीज़ देखी है
acquisition के बाद अक्सर core talent या तो stock vest होने पर निकल जाता है, या बड़ी कंपनी उनकी जगह किसी और को बैठाने के लिए उन्हें बाहर कर देती है
जो लोग तकनीक को सचमुच समझते हैं वे सब चले जाते हैं, और अंत में एक ऐसा बिगड़ा हुआ codebase बचता है जिसे maintain करना संभव नहीं होता और जिसे ठीक करना किसी को नहीं आता
मुझे बहुत पसंद है कि El Reg ने मामले के मूल बिंदु पर बिल्कुल सही चोट की
अब जाकर ध्यान गया कि लेख Corey Quinn ने लिखा है, जो AWS पर बहुत लिखते रहे हैं
मुझे यह भी पसंद है कि इनके लेखक wit और personality के साथ लिखते हैं
ये लोग किसी भी मामले में असली मुद्दे पर सही निशाना लगाते हैं
“समस्या आने के 75 मिनट के भीतर कारण को एक विशेष service endpoint तक सीमित कर लिया गया”
क्या यह सचमुच इतना लंबा समय है? मैं web development में नहीं हूँ, लेकिन 75 मिनट में समस्या कहाँ है यह पता लगा लेना मुझे काफ़ी तेज़ लगता है
जब मैं firmware engineer था, तब कभी-कभी यह पता लगाने में हफ्तों लग जाते थे कि चीज़ टूटी कहाँ है
अगर समस्या की आवृत्ति सच में 0.01% हो, उसका कोई स्पष्ट संबंध न हो, और retry करने पर वह गायब हो जाए, तो सचमुच हफ्ते लग सकते हैं
लेकिन ऐसी चीज़ें आम तौर पर high-priority incidents नहीं होतीं, और असली urgent हादसे repeatable होते हैं, या फिर कुछ ऐसा होता है जो एक घंटे पहले तक ठीक था और अचानक टूट गया
आम तौर पर अगर कोई business-critical system ठीक से designed है, तो diagnosis में 75 मिनट से ज़्यादा नहीं लगना चाहिए। हाँ, उसे ठीक करने में ज़्यादा समय लग सकता है
हालाँकि वास्तविक दुनिया में ऐसे आदर्श systems बहुत आम हैं, ऐसा भी नहीं कह सकते
किसी सामान्य कंपनी के लिए 75 मिनट लंबा समय नहीं माना जाएगा। लेकिन अगर दुनिया के सबसे बड़े cloud में internet का बड़ा हिस्सा ठप हो जाए, तो बात अलग है
हो सकता है कि आधिकारिक notice में “अब भी जाँच जारी है” लिखा गया हो, लेकिन अंदरूनी तौर पर उन्होंने उससे पहले ही कारण का काफ़ी अच्छा अंदाज़ा लगा लिया हो
updates को जल्दबाज़ी में जारी करने से users बेवजह गुमराह हो सकते हैं, इसलिए सावधानी ठीक है
मेरे हिसाब से 75 मिनट किसी भी गंभीर समस्या के diagnosis के लिए लगभग top-tier speed है
Amazon को उद्योग-स्तरीय बेहतरीन infrastructure वाली कंपनी माना जाता है
दूसरी कंपनियाँ भी Amazon infrastructure पर चलती हैं, इसलिए उम्मीद रहती है कि SRE-स्तर के लोग ऐसे incidents को बहुत तेज़ी से पकड़ लें
संगठन के भीतर धीरे-धीरे गायब होता अनुभव और know-how ही वह सचमुच अहम मूल्य है जिसे सिर्फ़ Excel शीट में दर्ज करना भी मुश्किल होता है
जब संगठन असली काबिल लोगों और लंबे समय तक टिके रहने वाले विशेषज्ञों से अधिक उन लोगों को प्राथमिकता देने लगता है जो अपना निजी brand बनाते हैं या दिखावटी hiring को आगे बढ़ाते हैं, तब सिस्टम को सचमुच समझने वाला तकनीकी core धीरे-धीरे बाहर होने लगता है
जब यह असंतुलन AWS जैसे स्तर पर पहुँचता है, तो LinkedIn celebrity और checklist-आधारित DEI भर्ती असली builders पर हावी हो जाते हैं, और execution quality, accountability, तथा technical rigor धीरे-धीरे कमजोर होने लगते हैं
अब धीरे-धीरे साफ़ हो रहा है कि Andy Jassy की leadership असरदार नहीं है, और संभव है कि जल्द ही Wall Street आधिकारिक तौर पर बदलाव की माँग करे
जब लोग कहते हैं कि The Register एक सम्मानित media outlet है, तो सच कहूँ तो लगता है कि शायद वे खुद ऐसा कहलाना भी नहीं चाहेंगे…