डेवलपमेंट में प्रोडक्शन में आग लगी — यह क्या है, कारण और कार्य योजना

“प्रोडक्शन में आग लगी” का क्या मतलब और खराबी के प्रकार

“प्रोडक्शन में आग लगी” (सब कुछ डाउन है) अभिव्यक्ति एक ऐसी स्थिति का वर्णन करती है जहां प्रोडक्शन वातावरण ठीक से काम नहीं कर रहा है और उपयोगकर्ता प्रभावित हुए हैं। खराबी पूर्ण एप्लिकेशन अनुपलब्धता (खाली स्क्रीन, 502 त्रुटि), आंशिक अनुपलब्धता (भुगतान मॉड्यूल काम नहीं करता लेकिन अन्य कार्य उपलब्ध हैं), या प्रदर्शन में गिरावट (अत्यधिक धीमी लोडिंग) के रूप में प्रकट हो सकती है। घटना की गंभीरता प्रभावित उपयोगकर्ताओं के प्रतिशत और खराबी की अवधि से निर्धारित होती है।

Atlassian Statuspage (2025) के अनुसार, 2024 में मोबाइल एप्लिकेशन के लिए औसत डाउनटाइम 27 मिनट प्रति घटना था। सबसे सामान्य कारण: डिप्लॉयमेंट के बाद कोड रिग्रेशन (34%), क्लाउड प्रदाता आउटेज (22%), डेटाबेस समस्याएं (18%), कॉन्फ़िगरेशन त्रुटियां (15%) और DDoS हमले (11%). मुख्य निष्कर्ष: अधिकांश खराबी उन बदलावों के कारण होती हैं जो टीम ने स्वयं किए, न कि बाहरी कारकों के कारण।

क्रैश (क्लाइंट पर एप्लिकेशन का गिरना) और बैकएंड आउटेज (सर्वर की अनुपलब्धता) के बीच अंतर करना महत्वपूर्ण है। क्रैश आमतौर पर क्लाइंट कोड के हॉटफिक्स से ठीक किया जाता है, जबकि बैकएंड आउटेज के लिए बुनियादी ढांचे में बदलाव या सेवा की पुनर्नियोजन की आवश्यकता होती है। निगरानी मीट्रिक्स: क्लाइंट के लिए — क्रैश-फ्री दर, सर्वर के लिए — 5xx त्रुटि दर और p95 विलंबता। APM (एप्लिकेशन प्रदर्शन निगरानी) — Sentry, New Relic, Datadog — खराबी के प्रकार को जल्दी से निर्धारित करने में मदद करता है।

घटना की गंभीरता: P0, P1, P2 और वर्गीकरण मानदंड

एकीकृत गंभीरता वर्गीकरण त्वरित प्रतिक्रिया का आधार है। इसके बिना टीम कार्रवाई करने के बजाय “yह कितना जरूरी है” पर चर्चा करने में समय बर्बाद करती है। क्लासिक पैमाना: P0 (गंभीर) — एप्लिकेशन पूरी तरह से अनुपलब्ध है या उपयोगकर्ता डेटा लीक हो रहा है, प्रतिक्रिया समय — तत्काल; P1 (उच्च) — 50%+ उपयोगकर्ताओं के लिए महत्वपूर्ण कार्यक्षमता टूटी हुई है, प्रतिक्रिया समय — 15 मिनट; P2 (मध्यम) — कुछ उपयोगकर्ताओं के लिए गैर-महत्वपूर्ण कार्यक्षमता अनुपलब्ध है, प्रतिक्रिया समय — 1 घंटा।

P0 तत्काल एस्केलेशन की आवश्यकता है: ऑन-कॉल इंजीनियर किसी भी चालू कार्य को रोकता है और घटना पर स्विच करता है। यदि 10 मिनट में समस्या हल नहीं होती है — तकनीकी लीड शामिल होता है। यदि 30 मिनट के बाद — इंजीनियरिंग मैनेजर को एस्केलेशन। P0 घटनाओं के लिए किसी भी प्रक्रिया को तोड़ना स्वीकार्य है: पूर्ण कोड समीक्षा के बिना हॉटफिक्स करना, सीधे प्रोडक्शन में डिप्लॉय करना, ब्रांच प्रोटेक्शन नियमों को अनदेखा करना। आपातकालीन ओवरराइड टीम स्तर पर पहले से सहमत होना चाहिए।

गंभीरता तालिका

गंभीरता को कम आंकने की गलती न करना बेहद महत्वपूर्ण है। P2 के रूप में वर्गीकृत P0 और P1 घटनाएं विलंबित प्रतिक्रिया और बढ़े हुए डाउनटाइम की ओर ले जाती हैं। नियम: यदि संदेह है — P0 सेट करें। अधिक वर्गीकरण कम वर्गीकरण से बेहतर है: एक अतिरिक्त बैठक आयोजित करना रिकवरी का एक घंटा खोने से बेहतर है।

पहले 10 मिनट: खराबी के दौरान कार्य योजना

टाइमर शुरू होता है: जब कोई अलर्ट या उपयोगकर्ता से संदेश आता है। पहले 10 मिनट सबसे महत्वपूर्ण हैं। योजना: 1) समस्या की पुष्टि करें — सुनिश्चित करें कि समस्या वास्तविक है (झूठा अलार्म नहीं); 2) ब्लीडिंग रोकें — तुरंत प्रभाव कम करें (रोलबैक, फीचर टॉगल, एंडपॉइंट ब्लॉकिंग); 3) संचार — सामान्य #incident चैनल में लिखें: क्या हुआ, गंभीरता, क्या किया जा रहा है। पहले 10 मिनट मूल कारण विश्लेषण पर खर्च नहीं किए जाते।

ब्लीडिंग रोकने के समानांतर, एक इंजीनियर निदान शुरू करता है जबकि दूसरा संचार संभालता है। संचार चैनल: Slack #incident चैनल (टीम के लिए), स्थिति पृष्ठ (उपयोगकर्ताओं के लिए), ईमेल/SMS एस्केलेशन (प्रबंधन के लिए)। हर 15 मिनट — जानकारी के साथ स्थिति अपडेट: क्या पता है, क्या किया जा रहा है, अनुमानित रिकवरी समय। स्थिति पृष्ठ (StatusPage, Statuspal) बाहरी उपयोगकर्ताओं के लिए अपटाइम और घटना इतिहास प्रदर्शित करता है।

ब्लीडिंग कैसे रोकें: रोलबैक, फीचर टॉगल और हॉटफिक्स

पहला और सबसे महत्वपूर्ण नियम: प्रोडक्शन पर समस्या को ठीक करने का प्रयास न करें। यदि नए रिलीज़ ने खराबी पैदा की — पिछले स्थिर संस्करण पर वापस जाएं। यदि खराबी किसी विशिष्ट फीचर के कारण हुई है जो फीचर टॉगल के पीछे है — बस टॉगल बंद करें। यदि न तो रोलबैक और न ही टॉगल उपलब्ध है — न्यूनतम diff के साथ हॉटफिक्स लागू करें। रोलबैक सबसे सुरक्षित विकल्प है क्योंकि यह उस स्थिति में लौटता है जो पहले से काम कर रही थी।

फीचर टॉगल (उर्फ फीचर फ्लैग) डिप्लॉयमेंट के बिना ब्लीडिंग रोकने का एक शक्तिशाली उपकरण है। यदि भुगतान मॉड्यूल टॉगल के माध्यम से बंद है — उपयोगकर्ता एरर स्क्रीन पाने के बजाय बस भुगतान बटन नहीं देखते हैं। टॉगल को बिल्ड की आवश्यकता नहीं है, स्टोर समीक्षा की आवश्यकता नहीं है, और सेकंडों में प्रभावी होता है। प्रत्येक महत्वपूर्ण फीचर सर्वर-स्तर (रिमोट कॉन्फ़िग) पर बंद करने की क्षमता वाले फीचर टॉगल के पीछे होना चाहिए। फीचर फ्लैग — रक्षा की पहली पंक्ति।

यदि रोलबैक असंभव है (जैसे, अपरिवर्तनीय डेटाबेस माइग्रेशन के कारण) और कोई टॉगल नहीं है — अंतिम उपाय: न्यूनतम सुधार के साथ हॉटफिक्स। हॉटफिक्स नवीनतम रिलीज़ टैग से बनाया जाता है, इसमें केवल खराबी को ठीक करने के लिए आवश्यक पंक्तियाँ होती हैं, और फास्ट-ट्रैक डिप्लॉयमेंट से गुजरता है (लेख देखें “हॉटफिक्स — तत्काल सुधार”)। सुनहरा नियम: स्थिरीकरण के बाद, हमेशा मूल कारण विश्लेषण करें, भले ही कारण स्पष्ट लगे।

कारणों का निदान: लॉग, मीट्रिक्स और अलर्ट

ब्लीडिंग रोकने के बाद (या समानांतर में, यदि इंजीनियरों की संख्या अनुमति देती है) निदान शुरू होता है। पहला स्रोत — लॉग। केंद्रीकृत लॉगिंग (ELK, Grafana Loki, Datadog Logs) टाइमस्टैम्प, उपयोगकर्ता ID या अनुरोध ID द्वारा त्रुटियां खोजने की अनुमति देती है। महत्वपूर्ण: लॉग संरचित (JSON) होने चाहिए ताकि grep तेजी से काम करे। संरचित लॉगिंग सभी सेवाओं के लिए अनिवार्य आवश्यकता है।

दूसरा स्रोत — मीट्रिक्स। Grafana, Datadog, New Relic दिखाते हैं कि त्रुटि स्पाइक कब हुआ, किन एंडपॉइंट्स पर और किन स्टेटस कोड के साथ। डिप्लॉयमेंट से पहले और बाद के मीट्रिक्स की तुलना किसी विशिष्ट सेवा या एंडपॉइंट पर समस्या को स्थानीयकृत करने में मदद करती है। RED मीट्रिक्स (Rate, Errors, Duration) — माइक्रोसर्विसेज निगरानी का मानक।

तीसरा स्रोत — वितरित ट्रेसिंग (distributed tracing)। Jaeger, Zipkin, Datadog APM माइक्रोसर्विसेज के माध्यम से अनुरोध पथ दिखाते हैं और पहचानते हैं कि वास्तव में देरी या त्रुटि कहाँ हुई। ट्रेसिंग विशेष रूप से कैस्केडिंग विफलताओं में उपयोगी है, जब एक सेवा में खराबी सभी आश्रित सेवाओं में त्रुटियां पैदा करती है। ट्रेस ID क्लाइंट से सभी बैकएंड सेवाओं तक प्रेषित होनी चाहिए।

# kubectl और लॉग का उपयोग करके त्वरित निदान उदाहरण
# त्रुटियों वाले पॉड्स सूचीबद्ध करें
kubectl get pods --field-selector=status.phase!=Running

# क्रैश हुए पॉड के लॉग जांचें
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# पिछले 30 मिनट के लिए सेवा में त्रुटियां खोजें
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

महत्वपूर्ण: ब्लीडिंग रोकने से पहले कारण का निदान करने का प्रयास न करें। यदि 50% उपयोगकर्ता क्रैश देख रहे हैं — पहले रोलबैक करें, फिर जांच करें। अपवाद: यदि रोलबैक में सीधे हॉटफिक्स से अधिक समय लगेगा (जैसे, डेटा असंगतता के कारण)। इस मामले में, तुरंत हॉटफिक्स लागू करें और स्थिरीकरण के बाद पोस्ट-मॉर्टम करें। ठीक करने से पहले निदान एक खतरनाक पैटर्न है जो डाउनटाइम बढ़ाता है।

पोस्ट-मॉर्टम: दोष ढूंढ़े बिना घटनाओं की समीक्षा कैसे करें

पोस्ट-मॉर्टम (जिसे घटना समीक्षा भी कहा जाता है) एक संरचित घटना विश्लेषण है जो समाधान के 24–72 घंटे बाद आयोजित किया जाता है। इसका उद्देश्य: यह समझना कि खराबी क्यों हुई, निगरानी और परीक्षण इसे प्रोडक्शन से पहले क्यों नहीं पकड़ पाए, और पुनरावृत्ति को रोकने के लिए प्रक्रियाओं में क्या बदलाव करना है। दोषरहित संस्कृति एक मूलभूत सिद्धांत है: पोस्ट-मॉर्टम प्रक्रियाओं, उपकरणों और संचार पर चर्चा करता है, न कि विशिष्ट व्यक्तियों की गलतियों पर।

पोस्ट-मॉर्टम दस्तावेज़ की संरचना: समयरेखा (टाइमस्टैम्प के साथ घटनाओं का कालक्रम), प्रभाव (प्रभावित उपयोगकर्ता, अवधि, वित्तीय नुकसान), मूल कारण (तकनीकी मूल कारण), पहचान (यह कैसे खोजा गया, पहले क्यों नहीं पकड़ा गया), प्रतिक्रिया (क्या किया गया, क्या तेजी से किया जा सकता था), कार्य (जिम्मेदार व्यक्तियों और समय सीमा के साथ विशिष्ट कार्य)। कार्य S.M.A.R.T. होने चाहिए: विशिष्ट, मापने योग्य, असाइन करने योग्य, यथार्थवादी, समय-बद्ध।

प्रोडक्शन खराबी के बाद विशिष्ट कार्य: उस मीट्रिक के लिए निगरानी और अलर्ट जोड़ना जो चुप थी; छूटे हुए मामले के लिए परीक्षण कवरेज का विस्तार करना; समान स्थिति के लिए चरण-दर-चरण एल्गोरिदम के साथ रनबुक में एक पृष्ठ जोड़ना; उस उपकरण पर टीम प्रशिक्षण आयोजित करना जिसका गलत उपयोग किया गया था। प्रत्येक कार्य एक ठोस बदलाव है जो घटना की पुनरावृत्ति की संभावना को कम करता है।