CTO की करियर-दांव वाली कहानी: बिट लेवल तक उतरकर DB हैक किया
(tech.devsisters.com)- Devsisters के इतिहास में CookieRun: Kingdom का सबसे लंबा 36 घंटे का आउटेज
- मुख्य distributed DB के रूप में CockroachDB का उपयोग: 4 nodes, 12TB storage, 7 replicas
- डेटाबेस scaling के दौरान आधे nodes डाउन हो गए
- इसके कारण पूरी service ठप हो गई, और CockroachDB के support engineer ने माना कि recovery संभव नहीं है
- इसलिए storage में सेव डेटा को खुद ढूंढने की कोशिशों को संकलित करने वाला लेख
24 टिप्पणियां
यह सच में काफी विवादित पोस्ट लगती है..? सर्विस के नज़रिए से यह कैसी रही होगी, पता नहीं, लेकिन इस पर काम करने वाले डेवलपर्स को ज़बरदस्त संतुष्टि मिली होगी।
पता नहीं यूज़र्स की प्रतिक्रिया कैसी रही होगी, लेकिन rollback को रोकने की कोशिश की गई — इस बात पर एक यूज़र के तौर पर मैं तारीफ़ का एक वोट देना चाहूँगा.. हालांकि 36 घंटों के दौरान हुए यूज़र churn और customer experience को सोचें तो नुकसान शायद ज़्यादा बड़ा रहा होगा, लेकिन डेवलपर के नज़रिए से देखें तो यह एक दिलचस्प चुनौती रही होगी। अगर कंपनी game नहीं बल्कि bank होती, तो क्या होता?
कहा जाता है कि Pokémon Go, GCP के Spanner का उपयोग करता है (https://cloud.google.com/blog/topics/…), लेकिन AWS में उसका कोई खास उपयुक्त विकल्प नहीं दिखता।
उस दस्तावेज़ के आधार पर डेवलपमेंट टीम की मंशा को समझें, तो उस प्रोजेक्ट में CockroachDB का इस्तेमाल नहीं करना चाहिए था।
आपको कौन-सा DB इस्तेमाल करना चाहिए था?
सेवा के हिसाब से यह काफ़ी डरावना लग सकता है.
मज़े से पढ़ा।
देखा तो पता चला कि उस ब्लॉग पर इस outage से जुड़ी सामग्री को series के रूप में पोस्ट किया गया है। लगातार पढ़ते हुए, इसे संभाल रहे लोगों ने जो जबरदस्त mental breakdown जैसा महसूस किया होगा, वह काफ़ी प्रभावशाली लगा।
मुझे पक्का नहीं है कि बिज़नेस के लिहाज़ से 36 घंटे में सभी यूज़र जानकारी को बहाल करना, कुछ यूज़र्स के अनुभव को नुकसान पहुँचाकर ज़्यादातर लोगों को बचाने वाले rollback से बेहतर फैसला था या नहीं। डेवलपर के नज़रिए से देखें तो इसमें दिलचस्प बातें हैं।
लेख में ऐसा एक अंश है।
ग्राहकों को सबसे बेहतरीन अनुभव देना हमारा मिशन था, और इसे सच्चे मन से अमल में लाने के लिए हमने पूरा प्रयास किया। किसी ने भी निराश होकर हार नहीं मानी।
यहाँ भी यह सुनने को मिल रहा है कि पैसे के लिए कुछ यूज़र्स को छोड़ देना ठीक है, और इससे कोरियाई गेम इंडस्ट्री में यूज़र्स के साथ होने वाले व्यवहार का अहसास एक बार फिर हो जाता है।
यह कुछ ज़्यादा ही पेचीदा नज़रिये से देखा गया लगता है, और नतीजे के हिसाब से देखें तो अगर समस्या हल नहीं होती, तो समय भी बेकार जाता और rollback भी rollback की तरह होता, इसलिए लोगों की नाराज़गी भी झेलनी पड़ती।
और सेवा उपलब्ध न होने के दौरान उपयोगकर्ताओं को छोड़ देने वाले नज़रिये से देखें, तो बात वही रहती है।
बहुत, बहुत गहराई से सहमत हूँ...
डेवलपर के नज़रिये से यह पढ़ना बहुत दिलचस्प था (उत्तेजक शीर्षक सहित), लेकिन मैंने भी इसे काफ़ी हद तक इसी तरह देखा। यह थोड़े पुराने लेख में आया हुआ विवरण है, इसलिए वास्तविक स्थिति से कुछ अंतर हो सकता है, लेकिन लगता है कि Cookie Run: Kingdom की बिक्री 300 अरब won से ज़्यादा थी, इसलिए 36 घंटे के downtime को अपेक्षित राजस्व में बदलकर देखने और rollback के बाद दिए जाने वाले मुआवज़े की राशि की तुलना करके ही यह फ़ैसला किया गया होगा.
समस्या-समाधान को महत्व देने वाली डेवलपर संस्कृति जिस संगठन में मज़बूत हो, उसका भी कुछ न कुछ असर रहा होगा, ऐसा मुझे लगता है.
अगर मैं होता, तो मैं कौन-सा फ़ैसला करता, यह अब भी निश्चित रूप से नहीं कह सकता।
आजकल गेम्स में (खासकर उन गेम्स में जिनमें random gacha/pull जैसी चीज़ें होती हैं) rollback... सच में सिर्फ़ सबसे खराब स्थिति में ही इस्तेमाल किया जा सकने वाला तरीका है.. L कंपनी के गेम की तरह image की परवाह न करने पर ही यह संभव है, इसलिए खास तौर पर इस घटना में rollback न करके बाद में बड़ा compensation देना बेहतर रहा, और यूज़र्स भी मज़ाक में कहते थे कि अगर resources कम पड़ें तो क्या server एक बार फिर नहीं फटेगा? मुझे लगता है यह सही फ़ैसला था.
क्योंकि यह एक गेम है, इसलिए अगर 36 घंटे पहले तक rollback किया जाता तो cache से जुड़ी वजहों से आर्थिक नुकसान काफ़ी बड़ा हो सकता था।
मुझे भी लगता है कि बिज़नेस के लिहाज़ से यह सही फैसला नहीं था।
अनजाने में हुई config mistake (यही सबसे critical और हैरान कर देने वाली human error थी। replication को काम न करने लायक बना देने वाला इतना बड़ा manipulation इस तरह कर बैठना—DB design developers सबको भी ले आएँ, तब भी इसे recover नहीं किया जा सकता)
इसलिए डेटा को पूरी तरह उड़ाया नहीं जा सकता था... तो latest data consistency छोड़कर भी, आखिर में saved binary form वाले DB data को सीधे ढूँढकर (7 TB) इसे csv में convert करने के लिए एक Go program लिखना... ?
ये conversion Go program बनाना, चाहे कितना भी अच्छा बना लें, इसका मतलब ही क्या होगा..
हाय.. सच, सिर्फ सोचकर ही घुटन होती है। आखिर ऐसा करना ही क्यों पड़ा होगा..
ऐसी human error न हो, इसके लिए process को मजबूत करना सबसे ज़्यादा ज़रूरी होगा। outage handle करते हुए binary conversion में जो मेहनत हुई, उसकी बात मत ही कीजिए।
क्या ऐसी बात नहीं करने की कोई अलग वजह भी है? पोस्टमॉर्टम को सार्वजनिक करना अपने आप में ही मायने रखता है।
मेरी राय में, अगर सच में मददगार लेख लिखना है, तो शीर्षक कुछ ऐसा होना चाहिए, है न?
"Node configuration की गलती की वजह से cluster unavailable error क्यों हुआ: कारणों का विश्लेषण और सीखे गए सबक"
ऐसी बातों पर अलग से लिखा जा सकता है, और "समस्या के कारण का विश्लेषण" तथा "समस्या समाधान की प्रक्रिया" अलग-अलग विषय हैं, और दोनों ही महत्वपूर्ण बातें हैं, लेकिन सिर्फ इसलिए कि "समस्या के कारण का विश्लेषण" नहीं था, लेख की वैल्यू को कम करके देखना समझना मुश्किल है...
अगर आप यह कहते कि कारण विश्लेषण पर भी आगे एक फॉलो-अप लेख लिख दें तो और अच्छा होगा, तो ठीक था, लेकिन उससे पहले उसे बेकार कहना अच्छी प्रवृत्ति नहीं है।
सख्ती से कहें तो यह 'incident resolution process' नहीं, बल्कि "अधूरे डेटा को मेहनत से recover करने" की प्रक्रिया है। बस नुकसान की सीमा थोड़ी कम हो गई? लगभग इतना ही।
ऊपर के लेख में डेटा रिकवरी को “अपूर्ण” बताया गया है, यह कहाँ लिखा है? कम से कम ऊपर के लेख की सामग्री के अनुसार तो पूरी रिकवरी सफल हुई थी। और जो DB उड़ गया था, उसे रिकवर करना अगर समस्या का समाधान नहीं है तो फिर क्या है? उस घटना के बाद क्या संबंधित सेवा ने वैसे ही अपना संचालन बंद कर दिया था?
लेकिन यह इस कहानी को न बताने की वजह तो नहीं है, है न?
ज़िंदगी को आप वाकई बहुत मुश्किल बनाकर जीते हैं