16 अग॰ 2025·8 मिनट
रोलबैक ड्रिल प्लेबुक: 5 मिनट में टूटी हुई रिलीज़ कैसे बहाल करें
इस रोलबैक ड्रिल का उपयोग करके 5 मिनट में टूटी हुई रिलीज़ बहाल करने का अभ्यास करें: क्या स्नैपशॉट लें, क्या सत्यापित करें, और ड्रिल के दौरान कौन क्या क्लिक करता है।
इस रोलबैक ड्रिल का उपयोग करके 5 मिनट में टूटी हुई रिलीज़ बहाल करने का अभ्यास करें: क्या स्नैपशॉट लें, क्या सत्यापित करें, और ड्रिल के दौरान कौन क्या क्लिक करता है।
किसी रिलीज़ का टेस्टिंग में सबकुछ ठीक दिखने के बाद भी असल ट्रैफ़िक के पहले पाँच मिनट में सब कुछ टूट सकता है। डर अक्सर बग से नहीं, अनिश्चितता से आता है: क्या बदला, क्या सुरक्षित रूप से उलटा जा सकता है, और क्या रोलबैक चीज़ें और खराब कर देगा।
रिलीज़ के तुरंत बाद, फेल्योर अक्सर सादे और दर्दनाक रूप से स्पष्ट होते हैं। नया बटन मोबाइल पर पेज क्रैश कर सकता है। बैकएंड बदलाव गलत डेटा आकार लौटाए जिससे चेकआउट फेल हो। एक छोटी सी कॉन्फ़िग़ सेटिंग लॉगिन, ईमेल या पेमेंट्स तोड़ सकती है। भले ही फिक्स आसान हो, दबाव बढ़ जाता है क्योंकि यूजर देख रहे होते हैं और हर मिनट महँगा लगता है।
पैनिक तब शुरू होता है जब रोलबैक का रास्ता साफ़ नहीं होता। लोग एक ही समय पर वही सवाल पूछते हैं: क्या हमारे पास स्नैपशॉट है? कौन सा वर्ज़न आख़िरी बार अच्छा था? अगर हम ऐप रोलबैक करते हैं तो डेटाबेस का क्या? किसके पास इसे करने की पहुंच है? जब ये जवाब पहले से लिखे नहीं होते, टीम बहस में समय गंवाती है बजाय सेवा बहाल करने के।
इन्सिडेंट के दौरान अटकलबाजी का असली लागत होता है। आप समय खोते हैं, यूजर का भरोसा कम होता है, और जल्दी में किए गए बदलाव दूसरी आउटेज पैदा कर सकते हैं। इंजीनियर्स भी बहुत सारी दिशाओं में खींचे जाते हैं: डिबगिंग, संदेश भेजना, और निर्णय लेना।
एक अभ्यास रन मूड बदल देता है क्योंकि यह अनिश्चितता को मसल मेमोरी से बदल देता है। एक अच्छा रोलबैक ड्रिल सिर्फ यह नहीं कि “क्या हम कोड वापस कर सकते हैं।” यह एक दोहराने योग्य रूटीन है: आप क्या स्नैपशॉट लेते हैं, क्या रिस्टोर करते हैं, क्या सत्यापित करते हैं, और किसे कार्रवाई करने की अनुमति है। कुछ ड्रिल के बाद, रोलबैक असफलता की भावना खत्म होकर सुरक्षा उपकरण जैसा लगने लगता है।
अगर आपका डिप्लॉयमेंट सेटअप पहले से ही स्नैपशॉट और रिस्टोर सपोर्ट करता है (कुछ प्लेटफ़ॉर्म, जिनमें Koder.ai भी शामिल है, इसे रिलीज़ फ्लो में बनाते हैं), तो ड्रिल आसान हो जाते हैं क्योंकि “पहले से ज्ञात अच्छे पर वापस जाएँ” एक सामान्य क्रिया बन जाती है, न कि कस्टम इमरजेंसी प्रक्रिया। किसी भी मामले में लक्ष्य वही है: जब पल आए, किसी को भी इम्प्रोवाइज़ नहीं करना चाहिए।
“5 मिनट में बहाल” का मतलब यह नहीं कि सब कुछ परफेक्ट है। इसका मतलब है कि आप उपयोगकर्ताओं को जल्दी एक काम करने योग्य वर्ज़न पर वापस ला सकते हैं, भले ही नई रिलीज़ अभी भी खराब हो।
सेवा पहले, फिक्स बाद में। अगर आप सेवा जल्दी बहाल कर सकते हैं, तो आपको असली बग खोजने के लिए शांत समय मिल जाता है।
क्लॉक तब शुरू होती है जब आप सहमत होते हैं: “हम रोलबैक कर रहे हैं।” इसमें यह शामिल नहीं कि क्या चीजें खुद ठीक हो सकती हैं पर लंबी चर्चा हो।
अपने रोलबैक ट्रिगर पहले से तय कर लें। उदाहरण: “अगर डिप्लॉय के 3 मिनट के अंदर चेकआउट एरर X% से ऊपर रहता है, तो हम रोलबैक करते हैं।” जब ट्रिगर मिलता है, आप स्क्रिप्ट फॉलो करते हैं।
“बहाल” कुछ संकेतों का छोटा सेट होना चाहिए जो बताते हैं कि उपयोगकर्ता सुरक्षित हैं और सिस्टम स्थिर है। इसे तंग और आसानी से जांचने योग्य रखें:
जब ये संकेत अच्छे लगें, 5-मिनट टाइमर बंद कर दें। बाकी सब इंतजार कर सकता है।
ड्रिल ईमानदार रखने के लिए स्पष्ट रूप से चिह्नित करें कि आप 5-मिनट पाथ के दौरान क्या नहीं कर रहे: गहरी डिबगिंग, कोड परिवर्तन या हॉटफिक्स रिलीज़, और जो कुछ इंजीनियरिंग काम में बदल जाएगा।
रोलबैक तभी तेज़ महसूस करता है जब निर्णय ज्यादातर पहले से बना हो। एक तरीका चुनें जो ज़्यादातर इन्सिडेंट्स के लिए काम करे, फिर उसे तब तक अभ्यास करें जब तक वह उबाऊ न लगने लगे।
आपकी ड्रिल को चार सवालों के जवाब देने चाहिए:
रोलबैक सबसे अच्छा होता है जब नई रिलीज़ उपयोगकर्ताओं या डेटा को नुकसान पहुँचा रही हो और आपके पास वापस लौटने के लिए एक ज्ञात अच्छा वर्ज़न मौजूद हो। हॉटफिक्स तब बेहतर होता है जब प्रभाव छोटा हो, बदलाव सीमित हो, और आप भरोसा करते हों कि आप सुरक्षित रूप से पैच कर सकते हैं।
एक सरल डिफ़ॉल्ट अच्छा काम करता है: अगर उपयोगकर्ता मुख्य क्रिया पूरी नहीं कर पा रहे हैं (checkout, login, signup) या एरर रेट बढ़ रहा है, पहले रोलबैक करें और बाद में फिक्स करें। हॉटफिक्स उन समस्याओं के लिए रखें जो कष्टप्रद हैं पर खतरनाक नहीं।
आपका “लक्ष्य” कुछ ऐसा होना चाहिए जिसे आपकी टीम बिना बहस के जल्दी चुन सके। ज़्यादातर टीमें तीन सामान्य लक्ष्यों के साथ काम करती हैं:
अगर आपके पास विश्वसनीय डिप्लॉयमेंट स्नैपशॉट हैं, तो इसे डिफ़ॉल्ट बनाएं क्योंकि यह दबाव में सबसे अधिक दोहराने योग्य होता है। कोड तो ठीक है पर सेटिंग गलत है जैसी स्थितियों के लिए कॉन्फ़िग-ओनली रोलबैक अलग पाथ रखें।
यह भी परिभाषित करें कि “पिछला अच्छा” क्या माना जाएगा। यह सबसे हाल की रिलीज़ होनी चाहिए जिसने मॉनिटरिंग चेक पास किए हों और जिस पर कोई सक्रिय इन्सिडेंट न हो—ना कि “वह जिसको लोग याद करते हैं।”
इन्सिडेंट के दौरान मीटिंग का इंतज़ार न करें। वे ट्रिगर्स लिख दें जो रोलबैक शुरू करते हैं और उनसे चिपके रहें। सामान्य ट्रिगर्स में प्रमुख फ्लो का टूटना कुछ मिनट से अधिक समय तक, एरर रेट या लेटेंसी का सहमत सीमाएँ पार कर जाना, डेटा का जोखिम (गलत लेखन, डुप्लिकेट चार्ज), और किसी भी सुरक्षा/प्राइवेसी चिंता शामिल हो सकते हैं।
फिर तय करें कि रोलबैक किसे मंज़ूर कर सकता है। एक भूमिका चुनें (इन्सिडेंट लीड या ऑन-कॉल), और एक बैकअप। बाकी लोग सलाह दे सकते हैं, लेकिन ब्लॉक नहीं कर सकते। जब ट्रिगर लगे और अधिकारी कहे “रोलबैक करो,” तो टीम हर बार वही कदम चलाती है।
एक रोलबैक ड्रिल तभी काम करता है जब आप जल्दी से एक ज्ञात अच्छे स्थिति पर वापस आ सकें। स्नैपशॉट सिर्फ “अच्छे होते हैं” नहीं—ये रसीदें हैं जो साबित करती हैं कि क्या चल रहा था, क्या बदला, और कैसे वापस जाना है।
हर रिलीज़ से पहले सुनिश्चित करें कि आप ये आइटम बिना चैट लॉग्स ढूंढे पकड़ सकें:
डेटाबेस सुरक्षा आम जाल है। एक तेज़ ऐप रोलबैक तब मदद नहीं करता जब डेटाबेस अब नई स्कीमा की उम्मीद कर रहा हो। जोखिम भरी माइग्रेशन के लिए, दो-स्टेप रिलीज़ प्लान करें (पहले नए फील्ड जोड़ें, बाद में उनका उपयोग शुरू करें) ताकि रोलबैक संभव रहे।
हर जगह एक नामकरण नियम अपनाएँ और इसे sortable रखें:
prod-2026-01-09-1420-v1.8.3-commitA1B2C3
पर्यावरण, टाइमस्टैम्प, वर्ज़न और कमिट शामिल करें। अगर आपके टूल स्नैपशॉट्स को UI में सपोर्ट करते हैं, तो वहां भी वही नामकरण नियम उपयोग करें ताकि कोई भी सही रिस्टोर पॉइंट इन्सिडेंट के दौरान ढूंढ सके।
रोलबैक ड्रिल तब तेज़ और शांत होती है जब हर किसी को उसकी लाइन मालूम हो। लक्ष्य यह नहीं कि “सभी कूद पड़ें।” यह एक व्यक्ति निर्णय ले रहा हो, एक व्यक्ति कार्रवाई कर रहा हो, एक व्यक्ति पुष्टि कर रहा हो, और एक व्यक्ति दूसरों को सूचित कर रहा हो।
छोटी और मध्यम टीमों के लिए ये भूमिकाएँ अच्छी रहती हैं (एक व्यक्ति दो भूमिकाएँ भी निभा सकता है अगर ज़रूरी हो, पर ड्रिल के दौरान Deployer और Verifier अलग रखें):
Permissions तय करते हैं कि यह योजना वास्तविक है या सिर्फ एक अच्छा दस्तावेज़। ड्रिल से पहले तय करें कि कौन प्रोडक्शन रोलबैक कर सकता है, और इमरजेंसी कैसे काम करती है।
एक सरल सेटअप:
अगर आप किसी प्लेटफ़ॉर्म का उपयोग कर रहे हैं जो स्नैपशॉट और रोलबैक सपोर्ट करता है (जिसमें Koder.ai शामिल है), तो तय करें कि कौन स्नैपशॉट बना सकता है, कौन उन्हें रिस्टोर कर सकता है, और वह कार्रवाई कहाँ रिकॉर्ड होगी।
एक रोलबैक ड्रिल तब सबसे अच्छा काम करती है जब यह फायर ड्रिल की तरह लगे: वही कदम, वही शब्द, वही जगहें जहाँ क्लिक करना है। लक्ष्य परफेक्शन नहीं है। लक्ष्य यह है कि ऑन-कॉल कोई भी बिना विकल्पों पर बहस किए जल्दी से अंतिम ज्ञात अच्छे वर्ज़न को बहाल कर सके।
एक स्पष्ट ट्रिगर चुनें और ड्रिल शुरू होने पर उसे जोर से कहें। उदाहरण: “चेकआउट 1 मिनट से अधिक समय के लिए 500 लौटाए” या “डिप्लॉय के तुरंत बाद एरर रेट सामान्य से 5x”। इसे ज़ोर से कहने से टीम टेढ़े-मेढ़े ट्रबलशूटिंग मोड में नहीं फँसती।
रनबुक के पास एक छोटा प्रेप चेकलिस्ट रखें:
टाइमर शुरू करें। एक व्यक्ति ट्रिगर और निर्णय कहता है: “हम अब रोलबैक कर रहे हैं।”
परिवर्तनों को फ्रीज़ करें। नए डिप्लॉय्स रोकें और गैर-आवश्यक एडिट्स रोक दें जो रोलबैक के दौरान सिस्टम बदल सकते हैं।
अंतिम मौके का स्नैपशॉट लें (यदि सुरक्षित और तेज़ हो)। यह बाद में टूटा हुआ स्टेट दोबारा बनाने के लिए सुरक्षा है। इसे स्पष्ट नाम दें और आगे बढ़ें।
रनबैक कार्रवाई उसी दस्तावेज़ के अनुसार चलाएँ। इम्प्रोवाइज़ न करें। पुष्टि प्रॉम्प्ट्स को ज़ोर से पढ़ें ताकि रिकॉर्डर क्या हुआ लिख सके।
किसी एक भरोसेमंद जगह पर पुष्टि करें कि रोलबैक पूरा हुआ। हर बार एक स्क्रीन और एक संकेत उपयोग करें (deployment history view, “current version” लेबल, या स्पष्ट स्टेटस इंडिकेटर)।
कार्रवाई के तुरंत बाद, ताज़ा रहते हुए जो महत्वपूर्ण है वह कैप्चर करें:
अगर रोलबैक 5 मिनट से अधिक लेता है, उसे बहाना न बनाएं। धीमे कदम को ढूँढें, रनबुक ठीक करें, और फिर ड्रिल दोहराएँ।
रोलबैक तब ही “काम किया” माना जाता है जब उपयोगकर्ता महसूस करें कि यह काम कर गया। आपका उद्देश्य यह साबित करना नहीं कि पुराना वर्ज़न डिप्लॉय हो गया—आप यह साबित कर रहे हैं कि सेवा फिर से उपयोग करने योग्य और स्थिर है।
सत्यापन छोटा और दोहराने योग्य रखें। अगर सूची पाँच से लंबी है, लोग तनाव में होने पर इसे छोड़ देंगे।
ऐसे चेक इस्तेमाल करें जिन्हें आप तेज़ी से चला सकें, और पास/फेल स्पष्ट हो:
फंक्शनल चेक्स के बाद, अपने भरोसेमंद सबसे सरल सिस्टम हेल्थ सिग्नल पर एक नजर डालें। आप चाहते हैं कि एरर रेट कुछ मिनट के भीतर सामान्य के पास आ जाए और लेटेंसी स्पाइक बंद हो जाए।
कम दिखने वाले हिस्सों की भी पुष्टि करें: बैकग्राउंड जॉब्स प्रोसेस होना शुरू हों और क्यूज़ बढ़ नहीं रहे हों। डेटाबेस चेक्स त्वरित और उबाऊ होने चाहिए: कनेक्शन्स स्थिर, कोई स्पष्ट लॉक पाइलअप नहीं, और ऐप लिख सकता है।
अंत में, बाहरी दुनिया जहाँ मायने रखती है वहां पर भी जाँच करें। अगर सुरक्षित तरीके से कर सकते हैं तो पेमेंट टेस्ट चलाएँ, ईमेल डिलीवरी देखें, और सुनिश्चित करें कि वेबहुक एक्सेप्ट हो रहे हैं (या कम से कम फेल नहीं हो रहे)।
एक वाक्य पहले से लिखें ताकि कोई इम्प्रोवाइज़ न करे:
“Rollback complete. Core flows verified (login + checkout). Error rate and latency back to normal. Monitoring for 30 minutes. Next update at 14:30.”
मंगलवार को 10:02 है। एक नई रिलीज़ गई, और एक मिनट के भीतर कुछ यूज़र्स लॉगिन नहीं कर पा रहे। कुछ को “invalid session” मिलता है, दूसरों को कभी खत्म न होने वाला स्पिनर। साइनअप अभी भी काम करता है, इसलिए समस्या पहले छिप सकती है।
पहला संकेत आम तौर पर ड्रामाई आउटेज नहीं होता। यह एक शांत स्पाइक है: सपोर्ट टिकट, सफल लॉगिन में गिरावट, और कुछ गुस्से वाले यूज़र्स के संदेश। ऑन-कॉल को “login success rate down 18% in 5 minutes” की अलर्ट मिलती है, और सपोर्ट पोस्ट करता है: “3 users can’t log in after the update.”
क्योंकि टीम ने ड्रिल अभ्यास की है, वे ज्यादा बहस नहीं करते। वे कन्फर्म करते हैं, निर्णय लेते हैं, और कार्रवाई करते हैं।
क्या रोलबैक हुआ: वेब और API सेवाओं के लिए एप्लिकेशन कोड और कॉन्फ़िग। क्या जस का तस रहा: डेटाबेस और उपयोगकर्ता डेटा।
अगर रिलीज़ में डेटाबेस माइग्रेशन शामिल था, तो ड्रिल नियम सरल है: 5-मिनट पाथ में डेटाबेस कभी रोलबैक न करें। माइग्रेशनों को बैकवर्ड-प्रमाणन योग्य रखें, या डिप्लॉय करने से पहले दूसरे की सहमति लें।
रोलबैक के दौरान, इन्सिडेंट लीड हर कुछ मिनट में छोटे अपडेट पोस्ट करता है: उपयोगकर्ता क्या देख रहे हैं, क्या कार्रवाई हो रही है, और अगला अपडेट कब होगा। उदाहरण: “We are rolling back the last release to restore login. Next update in 2 minutes.”
रोलबैक के बाद, वे लूप बंद करते हैं: “Login is back to normal. Root cause review is in progress. We will share what happened and what we changed to prevent repeats.”
एक रोलबैक ड्रिल उबाऊ महसूस करनी चाहिए। अगर यह तनावपूर्ण लगता है, तो ड्रिल शायद असली गैप उजागर कर रही है: एक्सेस, गायब स्नैपशॉट, या ऐसे कदम जो केवल किसी के सिर में हैं।
आप असली परमिशन नहीं लेकर अभ्यास करते हैं। लोग इन्सिडेंट के बीच पता लगाते हैं कि उनके पास deploy करने का अधिकार नहीं है, या डैशबोर्ड्स तक पहुंच नहीं है। सुधार: उसी अकाउंट्स और रोल्स के साथ ड्रिल चलाएँ जो इन्सिडेंट में इस्तेमाल होंगे।
स्नैपशॉट मौजूद हैं, पर वे अधूरे या ढूँढने में कठिन हैं। टीमें ऐप का स्नैपशॉट लें पर env बदलाव, फीचर फ्लैग्स, या राउटिंग भूल जाएँ। या स्नैपशॉट का नाम बेकार हो। सुधार: स्नैपशॉट निर्माण को रिलीज़ स्टेप बनाएं और ड्रिल्स के दौरान सत्यापित करें कि स्नैपशॉट दिखाई देता है और जल्दी रिस्टोर हो सकता है।
डेटाबेस माइग्रेशन्स रोलबैक को असुरक्षित कर देते हैं। बैकवर्ड-अनकंपेटिबल स्कीमा बदलाव तेज़ रोलबैक को डेटा समस्या में बदल देते हैं। सुधार: ऐडिटिव माइग्रेशन्स को प्राथमिकता दें। अगर ब्रेकिंग बदलाव अनिवार्य हैं, तो रिलीज़ को स्पष्ट रूप से चिह्नित करें: “rollback allowed: yes/no.”
आप सफलता घोषित कर देते हैं बिना उपयोगकर्ता महसूस किए। ऐप तो डिप्लॉय हो गया, पर लॉगिन अभी भी टूटा हुआ है या जॉब्स अटके हुए हैं। सुधार: सत्यापन छोटा पर वास्तविक रखें, और टाइमबॉक्स करें।
ड्रिल दोहराने योग्य नहीं है। बहुत सारे टूल, बहुत सारे चेक, बहुत सारी आवाज़ें। सुधार: ड्रिल को एक पृष्ठ तक छोटा करें और एक मालिक रखें। अगर इसे एक रनबुक और एक कम्युनिकेशन चैनल से नहीं किया जा सकता, तो दबाव में यह नहीं होगा।
एक अच्छा रोलबैक ड्रिल आदत है, न कि नायाब प्रदर्शन। अगर आप शांति से समाप्त नहीं कर पा रहे, तो कदम घटाएँ जब तक आप कर सकें, फिर केवल वो चीज़ें जोड़ें जो वाकई जोखिम घटाती हैं।
एक रोलबैक ड्रिल तब सबसे अच्छा काम करती है जब हर कोई उसी एक-पृष्ठ चेकलिस्ट का पालन करे। उसे उस जगह पिन करें जहाँ आपकी टीम वास्तव में देखती है।
एक कॉम्पैक्ट वर्ज़न जिसे आप 10 मिनट के अंदर चला सकते हैं (सेटअप और सत्यापन सहित):
ड्रिल इतनी बार चलाएँ कि कदम सामान्य लगें। मासिक एक अच्छा डिफ़ॉल्ट है। अगर आपका प्रोडक्ट रोज़ बदलता है, तो हर दो सप्ताह चलाएँ, पर सत्यापन शीर्ष उपयोगकर्ता पाथ पर केन्द्रित रखें।
प्रत्येक ड्रिल के बाद, उसी दिन रनबुक अपडेट करें जब जानकारी ताज़ा हो। इसे रिलीज़ नोट्स के साथ स्टोर करें, और “last tested” लाइन जोड़ें ताकि कोई भी पुरानी प्रक्रिया पर भरोसा न करे।
सिर्फ़ वही मापें जो आपको सुधारने में मदद करें:
अगर आपकी टीम Koder.ai पर बनाती है, तो स्नैपशॉट और रोलबैक को आदत बनाएं: स्नैपशॉट्स का लगातार नामकरण करें, उन्हीं इंटरफेस में रिस्टोर्स का अभ्यास करें जो आप ऑन-कॉल उपयोग करेंगे, और वेरिफायर स्टेप्स में त्वरित कस्टम-डोमेन और इंटीग्रेशन चेक शामिल करें। रनबुक में इसका जिक्र रखें ताकि ड्रिल वास्तविक शिपिंग तरीकों के अनुसार रह सके।
A rollback drill is a practice run where you simulate a bad release and follow a written routine to restore the last known-good version.
The goal isn’t to “debug fast”—it’s to make restoring service repeatable and calm under pressure.
Use a pre-set trigger so you don’t debate in the moment. Common defaults:
If the trigger hits, roll back first, then investigate after users are safe.
It means you can get users back onto a working version quickly—even if the new release is still broken.
In practice, “restored” is when a small set of signals look healthy again (core user action works, error rate and latency return near normal, no crash loop).
Pick a target you can select in seconds, without discussion:
Define “previous good” as the most recent release with normal monitoring and no active incident—not the one people remember.
At minimum, capture these before every release:
Database changes are the common trap—an app rollback may not work if the schema isn’t compatible.
Name them so they sort and can be found fast, for example:
prod-YYYY-MM-DD-HHMM-vX.Y.Z-commitABC123Include environment + timestamp + version + commit. Consistency matters more than the exact format.
A simple, repeatable split for small teams:
Avoid having the Deployer also be the Verifier during drills; you want an independent “did it really work?” check.
Keep it tiny and pass/fail. Good must-pass checks include:
Then confirm error rate and latency settle back near normal, and queues/jobs aren’t backing up.
Don’t make “rollback the database” part of the 5-minute path. Instead:
This keeps the quick rollback path safe and predictable.
If your platform supports snapshots and restore as part of the release flow, drills get easier because “go back to known good” is a normal action.
On Koder.ai specifically, decide ahead of time:
The drill still needs roles, triggers, and a short verification list—tools don’t replace the routine.