- एक इंजीनियर ने Snowflake की query के बाद वाली 10 मिनट idle setting घटाई, तो सालाना अनुमानित database cost करीब 10 लाख डॉलर से घटकर 5 लाख डॉलर रह गई
- कई सालों से टल रहा Advanced Analytics Platform लॉन्च के बाद भी spreadsheet, S3, Lambda, MongoDB, Snowflake और JavaScript stored procedures से उलझी जटिल ETL chain पर निर्भर था
- खर्च की बर्बादी की मुख्य वजह यह थी कि रोज 1TB से कम data process करने के बावजूद, औसतन 2 सेकंड की queries के बाद compute काफी देर तक चालू रहता था
- बदलाव पहले कुछ compute पर लागू किया गया; manager ने savings को माना, लेकिन full rollout टालना चाहा, और PowerPoint में इसे usage pattern analysis के जरिए optimization की तरह पेश किया गया
- 5 लाख डॉलर बचाने के बाद भी compensation अनिश्चित रहा, और meetings व reporting का बोझ ही बढ़ा; यह ऐसा मामला बना जहां संगठन की अक्षमता ने किसी व्यक्ति की छोटी-सी execution से ज्यादा राजनीतिक लागत पैदा की
सालों से टल रहा analytics platform
- कंपनी ने ज्यादा data-driven तरीके से काम करने के लिए analytics platform बनाने का फैसला किया और संबंधित लोगों को hire किया
- data scientist के रूप में join करने वाले engineer को असल data science काम नहीं मिला, और machine learning या data pipeline के लिए compute request पर भी जवाब मिला कि Advanced Analytics Platform, यानी AAP, के deployment तक इंतजार करें
- AAP शुरुआत में जनवरी में लॉन्च होना था, लेकिन मार्च तक खिसक गया, और फिर Covid के कारण hold पर डाल दिया गया
- उसके कंपनी छोड़ने के 3 साल बाद AAP लॉन्च के लिए तैयार हुआ, लेकिन पता चला कि जिन features की सच में जरूरत थी, वे शुरुआत की planning में थे ही नहीं
- उसी हफ्ते 4 engineers ने कंपनी छोड़ दी, और उसने अपनी शर्तें रखने के बाद AAP team join कर ली
लॉन्च के तुरंत बाद दिखा technical debt
- AAP अभी-अभी लॉन्च हुआ था, फिर भी उसमें काफी technical debt और operational risks थे
- नए hire हुए colleague ने पहले ही दिन project repository में ऐसा file पाया, जो गलत folder में जाने पर CI/CD pipeline के जरिए production delete कर सकता था
- इस file में admin account के लिए जरूरी keys और passwords भी थे
- database access permissions बदलना सिर्फ करीब 2KB CSV upload करने का काम था, फिर भी यह बेहद लंबा रास्ता लेता था
- spreadsheet को Python parse करता था
- result को S3 में डाला जाता था
- Lambda उसे फिर S3 में convert करता था
- MongoDB S3 file लेता था
- दूसरी Lambda MongoDB record को S3 में भेजती थी
- Snowpipe S3 data को Snowflake में लाता था
- JavaScript stored procedure Snowflake data को relational format में pivot करता था
- security team ने malicious content को आसानी से scan करने लायक format मांगा, इसलिए सब कुछ CSV में convert किया गया, लेकिन असल scanning tool कभी deploy नहीं हुआ
- Lambda functions पुराने implementation की निशानी
counter = 1से शुरू होते थे, और यह line लगातार copy होती रही - CI/CD tests debugging के दौरान
teecommand इस्तेमाल होने से fail code overwrite हो जाने के कारण महीनों तक failed state में रहे - API password lookup भी दो steps में उलझा हुआ था
- AWS service में
service-passwordजैसी key search करने पर value भीservice-passwordही मिलती थी - फिर उस value को दूसरी service में असली password खोजने के लिए इस्तेमाल किया जाता था
- AWS service में
- pipeline config file बनाने वाली script बाद में जरूरत पड़ सकती है, इस वजह से comment की गई 600 lines से शुरू होती थी
Snowflake setting जिसने खर्च बढ़ाया
- platform पिछले operating model से कई गुना महंगा था, और database cost budget से काफी आगे निकल गई
- ऐसा लगता था कि मूल रूप से सालाना operating cost करीब 2 लाख डॉलर रखने का इरादा था, लेकिन असल अनुमानित cost लगभग 10 लाख डॉलर तक पहुंच गई
- database Snowflake था, और Snowflake query चलाने वाले computers के size के आधार पर charge करता है
- compute चालू रहने के दौरान ही cost लगती है
- team हर हफ्ते कुछ हजार queries चलाती थी, और ज्यादातर ऐसी developer experiment queries थीं जो कम पढ़े जाने वाले PowerBI reports में छोटे-छोटे adjustments के लिए होती थीं
- average query execution time करीब 2 सेकंड था, लेकिन compute query के बाद 10 मिनट तक idle रहने के लिए configured था
- join करने के करीब एक महीने बाद उसने यह setting देखी और इसे adjust करने का सुझाव दिया, लेकिन सिर्फ procedural discussion चलता रहा कि discovery work चाहिए, execution नहीं हुआ
5 मिनट का बदलाव और validation
- कुछ महीनों बाद उसे “Discovery: Optimise Costs” card मिला, और अगले standup में बताने लायक result चाहिए था, इसलिए उसने पुरानी hypothesis को खुद verify करने का फैसला किया
- उसने दूसरे team के काबिल दिखने वाले नए engineer को admin permissions देने का request किया, लेकिन manager ने allow नहीं किया
- इसके बजाय उसने admin permissions नहीं, बल्कि lower-level database credentials share किए, और उस engineer ने cost saving की संभावना का common-sense validation किया
- हफ्ते के आखिरी दिन शाम 4 बजे, उसने बिना manager वाले engineer chatroom में check किया कि कोई issue तो नहीं है, और फिर setting बदल दी
- safety के लिए सभी compute पर नहीं, बल्कि पहले कुछ compute पर ही apply किया
savings और संगठन की प्रतिक्रिया
- अगले सोमवार, estimated bill करीब 10 लाख डॉलर से घटकर 5 लाख डॉलर हो गया
- team ने इसे बड़ी cost saving achievement की तरह पेश किया, लेकिन उसके नजरिये से यह बस पहले से बर्बाद हो रहे पैसे को रोकने जैसा था
- दूसरी teams ने मुद्दा उठाया कि नया join हुआ engineer इसी saving के समय आया था, और पूछा कि पहले इस तरह की saving के बारे में किसी को क्यों नहीं पता था
- manager खुश था, लेकिन उसका मानना था कि अगर बदलाव तुरंत सभी compute पर लागू कर दिया गया, तो department पर जरूरत से ज्यादा ध्यान जाएगा और अनचाहे सवाल उठेंगे
- इशारा था कि बदलाव को धीरे-धीरे लागू किया जाए, ताकि लगे कि यह लंबे समय में किया गया काम है
- उसे PowerPoint बनाना पड़ा, और wording कुछ इस तरह तय हुई: “usage patterns के careful statistical analysis ने resource allocation को ज्यादा प्रभावी बनाने के opportunities दिखाए”
- असल बदलाव सिर्फ एक setting adjustment था जिससे महंगा compute पूरे दिन idle न रहे
उपलब्धि के बाद बचा बोझ
- उसका मानना था कि उसने कुछ अच्छे engineers खोजकर informal तरीके से काम किया और पूरे department की तुलना में आसानी से बड़ा result दे दिया
- उसने निष्कर्ष निकाला कि capable लोग संगठन के अंदर हैं, लेकिन organizational structure के कारण असर नहीं दिखा पा रहे
- 5 लाख डॉलर बचाने के बाद उसने 30 हजार डॉलर raise मांगा, लेकिन message read होने के बाद भी जवाब नहीं मिला; उसे उम्मीद थी कि या तो कुछ नहीं मिलेगा या करीब 5 हजार डॉलर मिलेंगे
- cost saving पर बात करने के लिए meetings और बढ़ गईं, और PowerPoint बनाने का बोझ भी आ गया
- उसने अंत में कहा कि कुछ न करना उसके लिए बेहतर होता; उसने 5 मिनट की action से अपने career की सबसे बड़ी achievement हासिल की, लेकिन तुरंत ही अतिरिक्त बोझ भी उठा लिया
1 टिप्पणियां
Hacker News की रायें
यह पूरा लेख बहुत relatable लगा
US Navy में cost saving के तौर पर मेरे career record में 5 करोड़ डॉलर से ज़्यादा दर्ज था। हर बार कुछ भी करते समय PowerPoint बनाना पड़ता था और generals को present करना पड़ता था, और एक बार तो सिर्फ़ इसलिए बड़ी सज़ा मिलते-मिलते बची कि मैंने अपने boss को credit लेने नहीं दिया। जबकि असल में उस boss को यह तक नहीं पता था कि मैंने किया क्या है, इसलिए उसका credit लेने का कोई इरादा भी नहीं था
उसका एक हिस्सा वह दौर था जब मैं Lean Six-Sigma Black Belt के तौर पर enterprise-wide projects कर रहा था, और अब तो मुझे यह पूरा phrase ही नापसंद है। काम सचमुच DOD के खर्च को जितना हो सके कम करना था, और वह मेरे career का सबसे खराब समय था। लाखों डॉलर बचाने वाली problems को अपने दम पर solve करने का reward वही काम था
लेख के आख़िरी हिस्से से सहमत हूं। workplace में अच्छा काम करने को लेकर सावधान रहना चाहिए। reward लगभग कभी पैसा नहीं होता, बल्कि उसी salary पर और ज़्यादा काम बनकर लौटता है
पहले मैं कहीं बहुत बेहतर जगह पर था, और अगर मैं खुद आगे बढ़कर लाखों डॉलर बचाता था, तो सच में celebrate किया जाता था और boss credit भी देता था
toxic culture वाले workplace में कभी नहीं रुकना चाहिए। भले ही पैसा ज़्यादा हो, तब भी नहीं। अयोग्य, petty careerists और control freaks के नीचे दबकर काम करने जितना आत्मा को खोखला करने वाला कुछ नहीं
उनका सार यह था कि “अमेरिकी सरकार की अच्छी बात यह है कि वह इतनी बड़ी है कि अगर optimum solution 30% बचत देता है और second-best 29% ही बचाता है, तब भी करोड़ों से अरबों डॉलर बच जाते हैं, इसलिए कोई notice नहीं करता”
उनके बड़े projects में से एक remote military camps की energy efficiency था। Afghanistan के कुछ इलाकों तक fuel पहुंचाने पर लागत लगभग 100 डॉलर प्रति gallon आती थी, और portable generators अपनी capacity के 20–40% पर भरपूर चल रहे थे। मेरी याद में करीब 70% सबसे efficient होता है, और छोटे building बनाकर या कई tents को एक generator से जोड़कर fuel consumption काफी घटाई जा सकती थी और service quality भी सुधारी जा सकती थी
FAANG engineer के तौर पर मैंने money flow से directly जुड़े काम किए हैं, और कई क्षेत्रों का ऐसा experience भी है जो मददगार हो सकता है
फिर यह सोचकर छोड़ देता हूं कि सही लोगों और काम करने का सही क्षेत्र ढूंढना शायद काम का 95% होगा
मगर course कर लेने पर promotion में उन्हें तेज़ी से आगे बढ़ाने वाला structure था
मुझे stable salaried job चाहिए, लेकिन मुझे पता है कि अगर मैं अच्छा perform करूंगा तो managers उसे free time मानेंगे और limit तक और काम थोप देंगे। लालची लोग revenue share या profit sharing पर कभी agree नहीं करेंगे, बस कहेंगे कि सालाना 5% raise दे रहे हैं, चुप रहो और काम करो
कुछ jobs पहले company ने मुझसे उन projects के नाम लिखने को कहा जिन्हें मैं actively maintain कर रहा था, और default font size वाले Excel में list ने पूरी दो screens भर दीं। burnout इतना हुआ कि severe depression आ गया
उससे भी बुरा यह है कि job search नाम की submission ritual जैसी बकवास भी मुझे नापसंद है
Dan Luu के लेख याद आते हैं: https://danluu.com/nothing-works/
chip software tools भी कुछ ऐसे ही थे। बड़े EDA vendors को tools outsource करना standard था, लेकिन हमारे बनाए custom tools से बड़ा impact मिला और आमतौर पर उन्हें एक ही व्यक्ति बनाता या maintain करता था
मेरे वहां रहने के दौरान simulator cycles का ज़्यादातर हिस्सा एक custom simulator पर चलता था जिसे एक व्यक्ति maintain करता था, और उसकी वजह से simulator cost में हर साल लाखों डॉलर की बचत हुई। उस समय standard price एक simulator license के लिए सालाना कई हज़ार डॉलर था, और simulation machine farm में लगभग एक हज़ार machines थीं
अगर एक व्यक्ति company के लिए हर साल लाखों डॉलर की value वाला tool बना या maintain कर सकता है, तो लगता है competitors भी ज़रूर ऐसा करेंगे, लेकिन असल में ज़्यादातर ने ऐसा नहीं किया। यह वैसा ही था जैसे wafers खोलकर देखना जानने वाले लोगों को hire करने से faster और cheaper launch हो सकता था, फिर भी competitors ऐसा नहीं करते थे
Dan Luu “cocktail-party version of the efficient market hypothesis” की बात करते हैं, लेकिन “nothing works” का economics version https://en.wikipedia.org/wiki/The_Market_for_Lemons के ज़्यादा करीब है। यह market में information और information asymmetry की भूमिका पर है
efficient market hypothesis fail हो जाती है क्योंकि perfect knowledge संभव नहीं है और adverse selection सचमुच मौजूद है
कुछ companies मूल लेख में described चीज़ों के ठीक उलट भी होती हैं। ऐसी company में एक बार काम कर लेने के बाद, खराब जगह पर फिर से settle होना असंभव हो जाता है
पूरा लेख सोने जैसा है
मैनेजरों ने पूछा कि उनकी मदद के बिना इतनी बड़ी बचत कैसे हो गई, स्लाइड्स तैयार करने को कहा, कई बार पूछा कि आखिर हुआ क्या, और इसे ऐसे दिखाने के लिए धीरे-धीरे deploy करना पड़ा मानो यह किसी छोटे toggle से नहीं बल्कि समय के साथ क्रमिक रूप से हुआ हो। असर के हिसाब से raise मांगा, लेकिन बात नहीं बनी
अपने भले के लिए भी FAANG जैसी जगहों पर apply करना बेहतर होगा। कम-से-कम वहां बेहतर तरीके से ध्यान रखे जाने की संभावना ज्यादा है
और ब्लॉग में Twitter card metadata डालें तो Twitter पर यह ज्यादा अच्छा दिखेगा
“नमस्ते, मैं समझाऊंगा कि 5 लाख डॉलर की बचत कैसे संभव हुई। मूल रूप से मैंने एक दिन यह देखा कि हमारी original infrastructure कितनी बुरी तरह deploy की गई थी, और समस्या पैदा कर रहे code testing feature को हटा दिया। development, management, testing—हर पहलू से यह पूरी तरह oversight था। कुल मिलाकर यह code जितना खराब हो सकता था, लगभग उतना ही खराब था, और फिर भी इसे release कर दिया गया। और मुझसे कहा गया कि ऐसी बातें न कहूं क्योंकि इससे सब खराब दिखेंगे, और managers को ऐसा दिखाने के लिए कि उन्होंने कुछ काम किया है, इसे gradual तरीके से deploy करूं”
फिर मैं mic नीचे रखकर stage से उतर जाता
सच कहूं तो शायद परवाह करने की इच्छा बहुत ज्यादा खत्म हो गई होती। मैं लगभग 20 साल से यह काम कर रहा हूं, और bills भरने व बच्चों को खिलाने के लिए काम की परवाह करने वाले व्यक्ति के तौर पर भी ऐसा ही लगता है
मैंने cost model spreadsheet बनाई, उसे document किया और अपने boss को दे दिया, तो उन्होंने कहा “देखता हूं।” 2 हफ्ते बाद पूछा कि देखा क्या, तो बोले “सही लग रहा है। अच्छा काम।” पूछा कि trial apply करेंगे क्या, तो जवाब कमाल का था
“नहीं, हमें पैसे बचाने के लिए salary नहीं मिलती, हमें पैसे खर्च करने के लिए salary मिलती है”
तभी मुझे सरकार के Cost+Award Fee contracts सच में समझ आए
नुकसान यह है कि शायद बदलाव करने से पहले वह document लिखना पड़ेगा, पूरी team review लेनी पड़ेगी और “alignment” बनानी पड़ेगी
उसने अनजाने में 5 लाख डॉलर नहीं बचाए, बल्कि जानबूझकर 5 लाख डॉलर बचाए और अब पछता रहा है। यह वही बात नहीं है
बड़े संगठन इतने inefficient होते हैं कि हैरानी होती है वे compete कैसे कर पाते हैं, लेकिन उनके पास बहुत पैसा, economies of scale वगैरह होती हैं। इस प्रक्रिया में मूर्खतापूर्ण waste और inefficiency पर लाखों डॉलर जल जाएं तो भी किसी को खास फर्क नहीं पड़ता
फिर भी वे valuable service या product देते हैं। कितना भी inefficient हो, बिल्कुल न होने से तो efficient ही है। इसलिए competition न हो तब भी ऐसे संगठन मौजूद रहते हैं
आप पूछ सकते हैं कि छोटे संगठनों से competition का क्या। छोटे संगठनों में scale efficiency कम होती है, लेकिन अगर वे दूसरे पहलुओं में efficient हों तो कभी-कभी बड़ी कंपनियों से प्रभावी ढंग से compete कर सकते हैं। मगर बढ़कर बड़े संगठन बनते ही आखिरकार उनमें भी बड़े संगठन वाली inefficiency आ जाती है
बस चीजें ऐसे ही चलती हैं। ऐसा नहीं है कि किसी को परवाह नहीं; उल्टा company owners को बहुत परवाह होती है। समस्या यह है कि सचमुच किसी को नहीं पता इसे solve कैसे किया जाए
बड़ी कंपनियां authoritarian state-controlled enterprises जैसी failure patterns पर खत्म होती दिखती हैं। यह भी दिलचस्प है कि China ने इस मामले में control और growth के बीच संतुलन कितनी अच्छी तरह साधा है
market का गला घोंटते हुए साथ-साथ और inefficient हो जाती हैं
competition वह परीकथा है जो MBAs सुनाते हैं ताकि नए business शुरू हों और ऊपर से competition दिखे। शुरुआत से ही उनके पास मौका नहीं था
अगर सारे waste को optimization से हटाया जा सके, तो computers और business processes के लगातार efficient होते जाने के दौरान शायद उल्टा deflation होती
कभी एक बग ढूंढकर सालाना 40 लाख डॉलर के रेवेन्यू को वापस रिकवर किया था
उस गलती को दबा दिया गया ताकि उस टीम और executives को बचाया जा सके जिन्होंने उसे इतने लंबे समय तक चलने दिया था। सैलरी raise तो नहीं मिली, लेकिन कुछ allies बन गए और कुछ समय तक आराम से काम चल गया
दो servers किसी feed data से जुड़े थे, और जो feature description मैंने सुना था उसके उलट मैंने नोटिस किया कि cables अजीब तरह से connected थे
इस system के downtime की estimated cost लगभग 70 लाख डॉलर प्रति मिनट थी। मैंने कुछ जिम्मेदार कर्मचारियों और network team के सामने मुद्दा उठाया, लेकिन “हमने इसे ऐसे connect किया ही नहीं होगा” और मेरे junior होने की वजह से मुझे पूरी तरह ignore कर दिया गया
मामला important लग रहा था, इसलिए मैंने weekly group meeting में फिर से मुद्दा उठाया, और कोई खुद check करने गया तो वापस आकर बताया कि बात बिल्कुल वैसी ही थी जैसी मैंने कही थी। यह बड़ा मामला था, और network team को समस्या साफ-सुथरे ढंग से ठीक करने के लिए करीब 2 हफ्ते emergency work करना पड़ा
सब मुझसे नाराज थे। मैंने company की disaster रोक दी थी, फिर भी क्योंकि मैंने ऐसा करते हुए सबको खराब दिखा दिया था, और खासकर क्योंकि team में मेरी position low थी। यह एक important lesson था
bug fix करने के लिए बनाया गया system असल में pharmacy prescription transmission पर man-in-the-middle attack था। pharmacies price updates कभी apply नहीं करती थीं, इसलिए prescription को insurance company के system में जाने से ठीक पहले फिर से price किया जाता था। मैं एक छोटी independent pharmacy chain में काम करता था और कोई centralized dispensing system नहीं था
उस समय अपनी असीम प्रतिभा में, मैंने उस system का नाम अपने crush के नाम पर रख दिया था। headquarters को यह इतना पसंद आया कि उन्होंने मेरे system के नाम पर एक annual award बना दिया, और नतीजा यह हुआ कि वह award उसी crush के नाम पर हो गया; लेकिन असली origin बताने में मुझे बहुत शर्म आती थी
25 साल पहले की बात है, फिर भी आज तक हर साल मेरे पुराने crush के नाम वाली trophy बनाई और दी जाती है। अगर उस व्यक्ति को पता चले तो शायद वह डर से सिहर जाए
ऐसी चीजें हमेशा से होती आई हैं
बहुत पहले मैं VT100 terminals से भरे एक कमरे में गया था, semester के आखिरी weekend पर bored CS students compile खत्म होने का इंतजार कर रहे थे। system देखा तो पाया कि सबने अपने compiles batch queue में डाल रखे थे, और उस queue की default priority interactive jobs से कम थी। इसलिए कहीं से भी एक keypress higher priority ले लेता था, और लोग जितना अपने compile job की position check करते, काम उतना ही धीमा होता जा रहा था
अगले 15 मिनट तक मैंने queue के top job की priority लगातार बढ़ाई, और एक घंटे बाद सब अपना काम खत्म करके घर चले गए। कमरा मेरा हो गया। unauthorized system administrator की जीत थी ;-)
कुछ महीने पहले एक S3 bucket मिली जो लगातार बढ़ रही थी और महीने के 80,000 डॉलर खा रही थी; इससे company के सालाना 10 लाख डॉलर बच गए
जांच करने पर पता चला कि एक system, जो अब इस्तेमाल नहीं होता था, उस bucket में files copy कर रहा था। stakeholders से संपर्क किया, और उन्होंने उसे बंद करके files delete कर दीं
ऊपर के लोग खास परवाह करते नहीं दिखे। मेरे manager के manager ने कहा कि उस दूसरी team से संपर्क करो जिसे असल में यह पकड़ना चाहिए था, और बात वहीं खत्म हो गई
“उदाहरण के लिए, [table name deleted]_HOURLY पर 234,745 INSERT चलाए गए, और वे सभी 1000 rows से कम थे”
यह हमारे org के Snowflake support Slack में सचमुच पोस्ट हुआ था, और समस्या लगभग यही थी। समय के साथ फैली छोटी transactions cluster को लगातार जगाए रखती हैं। यह product small continuous loading जैसे common use case के लिए बना ही नहीं है
मैं actual experience वाला data warehouse administrator हूं, इसलिए देख रहा हूं कि लोग cost overruns एक-एक करके झेलते हुए मेरी job description को फिर से discover कर रहे हैं। वे पूरी seriousness से ऐसी बातें कहते हैं, “self-managed है, लेकिन costs monitor करनी होंगी और loads व queries को ज्यादा efficiently rewrite करना होगा।” मुझे यह पूछने से डर लगता है कि उन्हें लगता है मैं दिन भर क्या करता हूं
बहुत पुराने समय में, एक दूर की galaxy में, जिस काम के लिए N × (Oracle licenses + Sun servers) चाहिए होते थे, उसे 100 lines से कम की Perl script और एक Sun server से replace करके सालाना 30 करोड़ डॉलर से ज्यादा बचाए थे
उस process में MapReduce भी invent कर दिया था। Google से पहले
समस्या web server logs से कई statistics compute करने की थी। जैसे top 10 popular pages। original solution यह था कि logs बहुत बड़े हैं, इसलिए उन्हें कई servers पर चलने वाले Oracle database में पूरा load करो, फिर कई SQL queries चलाओ, और यह रोज repeat करो
लेखक की post पर आए impressive HN comments की gallery बढ़िया है: https://ludic.mataroa.blog/compliments/
यह भी काफी संभव है कि organization में कई लोग लेखक से बहुत आगे की सोच रहे थे। उसी group का कोई engineer या manager cost-cutting के समय इस्तेमाल करने के लिए उस inefficiency को reserve करके रखे हुए था, और ज्यादा संभावना है कि लेखक ने वह मौका खराब कर दिया। तब जब काटने को कुछ न बचे, तो भारी pain और खराब performance reviews अनिवार्य हो सकते हैं
शायद HN के discourse का स्तर गिर गया है और अब लगभग हर comment target बन सकता है, इसलिए वह dormant है
[1] https://twitter.com/shit_hn_says