उत्पादन में कुछ खराबी आ गई. ग्राहक-सामना करने वाली सुविधा बंद हो गई, डेटा दूषित हो गया, या कोई तैनाती रात 2 बजे किनारे हो गई। एड्रेनालाईन फीका पड़ गया है. समाधान हो गया है। अब क्या?
यही वह क्षण है जिसे अधिकांश टीमें बर्बाद कर देती हैं। वे या तो ⟦रेट्रो⟧ को पूरी तरह से छोड़ देते हैं ("हमने इसे पहले ही ठीक कर लिया है, चलो आगे बढ़ते हैं") या वे ऐसा अभियान चलाते हैं जो ऐसा न करने का दिखावा करते हुए चुपचाप दोष दे देता है। न ही अगली घटना को रोकता है.
वास्तव में दोषरहित पोस्टमॉर्टम एक उत्पाद टीम द्वारा चलाई जाने वाली उच्चतम-उत्तोलन गतिविधियों में से एक है। अच्छी तरह से किया गया, यह एक दर्दनाक घटना को प्रणालीगत सुधार में बदल देता है। खराब तरीके से किया गया, यह आपकी टीम को समस्याओं को छिपाना सिखाता है।
यहां बताया गया है कि घटना रेट्रोस्पेक्टिव को कैसे चलाया जाए जो वास्तव में काम करती है।
क्यों "निर्दोष" सिर्फ एक अच्छा शब्द नहीं है?
आइए स्पष्ट करें कि दोषरहित का मतलब क्या है, क्योंकि टीमें लगातार गलतियाँ करती हैं।
बेदाग का मतलब यह नहीं है कि "कोई शामिल नहीं था" या "किसी ने गलती नहीं की।" इसका मतलब है कि आप स्वीकार करते हैं कि इसमें शामिल लोगों ने उस समय जो कुछ वे जानते थे, जिस दबाव में थे और उनके पास जो उपकरण थे, उन्हें देखते हुए उचित निर्णय लिए। प्रश्न "किसने गड़बड़ की?" से बदल जाता है। "हमारे सिस्टम के कारण यह विफलता क्यों संभव हुई?"
यह एक व्यावहारिक कारण से मायने रखता है: यदि लोग सज़ा से डरते हैं, तो वे समस्याओं को छिपाते हैं। छिपी हुई समस्याएँ मिश्रित होती हैं। आप ऐसी घटनाओं के साथ समाप्त होते हैं जिन्हें पहले ही पकड़ लिया जा सकता था लेकिन वे तब तक पनपती रहीं जब तक कि वे आपात्कालीन स्थिति नहीं बन गईं।
लक्ष्य यह है कि समस्याओं का समाधान करना आपकी टीम का सबसे सुरक्षित कार्य हो जो कोई भी व्यक्ति कर सकता है।
किसी घटना को कब चलाना है रेट्रोस्पेक्टिव
प्रत्येक बग को औपचारिक पोस्टमॉर्टम की आवश्यकता नहीं होती है। उन घटनाओं के लिए पूरी प्रक्रिया सहेजें जो इनमें से कम से कम एक मानदंड को पूरा करती हों:
- ग्राहक प्रभाव-- उपयोगकर्ताओं को ख़राब सेवा, डेटा हानि या डाउनटाइम का अनुभव हुआ
- ज़रा सी चूक- कुछ भी नहीं टूटा, लेकिन केवल इसलिए कि किसी ने इसे समय पर पकड़ लिया
- पैटर्न दोहराएँ--समस्या की यही श्रेणी पहले भी सामने आ चुकी है
- क्रॉस-टीम भागीदारी-- घटना के लिए कई टीमों में समन्वय की आवश्यकता थी
- उपन्यास विफलताएँ-- कुछ ऐसा हुआ जिसकी आपकी निगरानी या प्रक्रियाओं ने अनुमान नहीं लगाया था
विवरण ताज़ा होने तक 48 घंटों के भीतर रेट्रोस्पेक्टिव चलाएँ। एक सप्ताह का इंतजार इस बात की गारंटी देता है कि हर किसी की याददाश्त बाद में संशोधित हो गई है।
समयरेखा: आपकी सबसे महत्वपूर्ण कलाकृति
इससे पहले कि आप किसी भी चीज़ का विश्लेषण करें, वास्तव में जो हुआ उसका पुनर्निर्माण करें। यह सुनने में जितना कठिन लगता है उससे कहीं अधिक कठिन है क्योंकि घटनाओं के बारे में लोगों की यादें बेहद अविश्वसनीय होती हैं - तनाव समय को संकुचित और विकृत करता है।
वस्तुनिष्ठ स्रोतों का उपयोग करके एक साझा समयरेखा बनाएं:
- अलर्ट और डैशबोर्ड की निगरानी करना-- मेट्रिक्स वास्तव में कब बदले?
- लॉग तैनात करें-- क्या निकला, और कब?
- चैट लॉग-- Slack या आपके घटना चैनल में लोगों ने क्या कहा?
- ग्राहक रिपोर्ट-- पहली शिकायत कब आई?
- ऑन-कॉल रिकॉर्ड-- किसे पृष्ठांकित किया गया, और उन्होंने कब प्रतिक्रिया दी?
इन्हें कालानुक्रमिक रूप से व्यवस्थित करें। सम्पादकीय मत करो. समयरेखा को एक तथ्यात्मक विवरण की तरह पढ़ा जाना चाहिए, न कि नायकों और खलनायकों की कहानी की तरह।
यह समयरेखा ही अक्सर वास्तविक समस्या का खुलासा करती है। आपको पता चल सकता है कि तैनाती 14:03 पर हुई थी लेकिन अलर्ट 14:47 तक सक्रिय नहीं हुआ, जिसका अर्थ है कि आपकी निगरानी में 44 मिनट का ब्लाइंड स्पॉट था। वह अंतर उस कोड परिवर्तन से कहीं अधिक महत्वपूर्ण है जिसके कारण समस्या उत्पन्न हुई।
मूल कारण विश्लेषण: स्पष्ट से परे जाना
घटना रेट्रोस्पेक्टिव में सबसे आम विफलता आपके द्वारा खोजे गए पहले कारण पर रुकना है। एक सर्वर की मेमोरी ख़त्म हो गई. एक शून्य जाँच गायब थी. एक कॉन्फ़िगरेशन मान गलत था. ये सभी सत्य हैं, और ये सभी अपर्याप्त हैं।
5 क्यों विधिकाम करता है क्योंकि यह आपको स्पष्ट से परे जाने पर मजबूर करता है।
घटना से शुरू करें और पूछें "क्यों?" बार-बार:
- एपीआई ने 20 मिनट के लिए 500 त्रुटियां लौटाईं।क्यों?
- डेटाबेस कनेक्शन पूल समाप्त हो गया था।क्यों?
- एक क्वेरी बिना टाइमआउट और कनेक्शन होल्ड किए चल रही थी।क्यों?
- क्वेरी को प्रदर्शन समीक्षा के बिना हालिया पीआर में जोड़ा गया था।क्यों?
- डेटाबेस-स्पर्शी परिवर्तनों के लिए कोई आवश्यक प्रदर्शन समीक्षा चरण नहीं है।क्यों?
अब आपके पास सिस्टम स्तर पर कार्रवाई योग्य कुछ है: प्रश्नों के लिए एक समीक्षा गेट जोड़ें, न कि केवल उस व्यक्तिगत डेवलपर के लिए एक अनुस्मारक जिसने इसे लिखा है।
5 क्यों के बारे में एक चेतावनी:एकल कारण श्रृंखला होने पर यह विधि अच्छी तरह से काम करती है। कई घटनाओं में कई योगदान कारक होते हैं जो एक साथ आते हैं। उन मामलों में, एक फिशबोन आरेख या एक सरल "योगदान कारक" सूची सब कुछ को एक श्रृंखला में मजबूर करने से अधिक ईमानदार है।
रेट्रोस्पेक्टिव सत्र की संरचना करना
यहां एक प्रारूप है जो 60 मिनट की घटना ⟦रेट्रो⟧ के लिए अच्छा काम करता है। गंभीरता के आधार पर समय समायोजित करें।
1. टाइमलाइन वॉकथ्रू (15 मिनट)
पुनर्निर्मित समयरेखा प्रस्तुत करें. प्रतिभागियों से इसे सही करने या इसमें जोड़ने के लिए कहें। अभी कारणों पर बहस न करें - केवल तथ्य स्थापित करें।
2. प्रभाव मूल्यांकन (10 मिनट)
जो हुआ उसे परिमाणित करें. कितने उपयोगकर्ता प्रभावित हुए? व्यवसाय लागत क्या थी? क्या कोई डेटा खो गया था? यह बातचीत को वास्तविकता पर आधारित करता है और प्रतिक्रिया को प्राथमिकता देने में मदद करता है।
3. योगदान कारक (20 मिनट)
यह मूल विश्लेषण है. घटना के प्रत्येक चरण के लिए - कारण, पता लगाना, प्रतिक्रिया, समाधान - पूछें: किस कारण से यह आवश्यकता से अधिक बदतर हो गया? किस बात ने इसे बेहतर बनाया?
उपयोगी संकेत:
- निर्णय लेते समय लोगों के पास किस जानकारी की कमी थी?
- हमारी टूलींग या निगरानी में कहां कमी रह गई?
- प्रतिक्रिया के दौरान कौन सी प्रक्रियाओं ने अच्छा काम किया?
- किस चीज़ से पता लगाना तेज़ हो गया होगा?
- हैंडऑफ़ कहाँ टूट गए?
4. एक्शन आइटम (15 मिनट)
विशिष्ट, स्वामित्व वाले, समयबद्ध सुधार उत्पन्न करें। उन्हें वर्गीकृत करें:
- तत्काल सुधार- जो विशिष्ट चीज़ टूटी है उसे पैच करें (ये पहले से ही किया जाना चाहिए)
- पता लगाने में सुधार- समस्या के इस वर्ग को पकड़ने के लिए बेहतर अलर्ट, डैशबोर्ड या परीक्षण
- प्रक्रिया परिवर्तन-- समीक्षा गेट्स, रनबुक अपडेट, या एस्केलेशन पथ सुधार
- प्रणालीगत निवेश-- बड़ा वास्तुशिल्प या टूलींग कार्य जो इस जोखिम श्रेणी को कम करता है
अपने आप को 3-5 कार्य आइटम तक सीमित रखें। एक पोस्टमॉर्टम जो 15 कार्य आइटम उत्पन्न करता है, उनमें से शून्य को पूरा करेगा। बेरहमी से प्राथमिकता दें.
दोषहीनता की भाषा
भाषा नीतियों से अधिक संस्कृति को आकार देती है। यहाँ ठोस बदलाव हैं:
| के बजाय | कोशिश |
|---|---|
| "जॉन ने ख़राब तैनाती को बढ़ावा दिया" | "14:03 पर तैनाती ने प्रतिगमन की शुरुआत की" |
| "टीम को इसे पकड़ना चाहिए था" | "हमारी समीक्षा प्रक्रिया ने परिवर्तन के इस वर्ग को चिह्नित नहीं किया" |
| "कोई कॉन्फ़िगरेशन अपडेट करना भूल गया" | "कॉन्फ़िगरेशन को परिनियोजन प्रक्रिया के भाग के रूप में अद्यतन नहीं किया गया था" |
| "किसी ने ध्यान क्यों नहीं दिया?" | "यह इतनी जल्दी क्यों दिखाई देगा?" |
पैटर्न: घटनाओं और प्रणालियों का वर्णन करें, लोगों और उनकी विफलताओं का नहीं। यह अस्पष्ट होने के बारे में नहीं है. आप किसी व्यक्तिगत गलती को शामिल किए बिना इस बारे में बेहद विशिष्ट हो सकते हैं कि क्या गलत हुआ।
आम नुकसान जो रेट्रो घटना को कमजोर करते हैं
निकटतम कारण पर रुकना।सुधार हो गया, बग को ठीक कर दिया गया, हो गया। अगर आप यहीं रुकेंगे तो आपके सामने अलग-अलग खासियतों वाली ऐसी ही घटनाएं आती रहेंगी।
एक्शन आइटम बनाना कोई ट्रैक नहीं करता।बिना मालिक और समय सीमा के एक कार्य वस्तु एक इच्छा है। प्रत्येक नए पोस्टमॉर्टम की शुरुआत में पिछली घटनाओं से कार्रवाई मद की पूर्ति की समीक्षा करें।
नेतृत्व के लिए ⟦रेट्रो⟧ को सेनिटाइज़ करना।यदि लिखित रिकॉर्ड को निदेशकों या उपाध्यक्षों तक पहुंचने से पहले बेहतर दिखने के लिए संपादित किया जाता है, तो आपके पास विश्वास की समस्या है। पूरा मुद्दा पारदर्शिता का है।
उन्हें केवल आउटेज के लिए चला रहे हैं।निकट की चूकों का विश्लेषण करना अक्सर अधिक मूल्यवान होता है क्योंकि जोखिम कम महसूस होता है और लोग अधिक स्वतंत्र रूप से बोलते हैं। यदि किसी तैनाती के कारण लगभग व्यवधान उत्पन्न हो गया है, लेकिन कैनरी के दौरान किसी ने इसे पकड़ लिया, तो यह भी समझने लायक है।
इसे स्टेटस मीटिंग में बदलना।⟦रेट्रो⟧ विश्लेषण और सीखने के लिए है। घटना के दौरान किसने क्या किया, इसे एक सूची न बनने दें। समयरेखा पहले से ही इसे कवर करती है।
एक घटना ज्ञानकोष का निर्माण
व्यक्तिगत पोस्टमॉर्टम उपयोगी होते हैं. पोस्टमॉर्टम की खोज योग्य लाइब्रेरी परिवर्तनकारी है।
जब आपके पास छह महीने की घटनाओं का दस्तावेजीकरण हो, तो आप इस तरह के प्रश्न पूछना शुरू कर सकते हैं: हमारी कितनी प्रतिशत घटनाएं तैनाती से संबंधित हैं? पता लगाने का हमारा औसत समय क्या है? क्या हमारे कार्य आइटम वास्तव में पूरे हो रहे हैं?
एक सुसंगत प्रारूप रखें ताकि घटनाएं तुलनीय हों। उन्हें श्रेणी (तैनाती, बुनियादी ढाँचा, डेटा, तृतीय-पक्ष निर्भरता) के आधार पर टैग करें। उन्हें संगठन में सभी के लिए सुलभ बनाएं, न कि किसी टीम विकी में बंद कर दें।
समय के साथ, यह लाइब्रेरी आपकी सबसे मूल्यवान इंजीनियरिंग परिसंपत्तियों में से एक बन जाती है। नई टीम के सदस्य आपके सिस्टम को किसी भी आर्किटेक्चर दस्तावेज़ से बेहतर ढंग से समझने के लिए पिछली घटनाओं को पढ़ सकते हैं।
इसे चिपकाना
घटनाओं से सीखने वाली टीमों और उन्हें दोहराने वाली टीमों के बीच का अंतर अनुसरण करने में आता है।
प्रत्येक घटना पर पिछली कार्रवाई की समीक्षा करें ⟦रेट्रो⟧। यदि एक ही योगदान कारक दो बार प्रकट होता है, तो इसे बढ़ाएं - यह एक संकेत है कि आपकी सुधार प्रक्रिया में ही सुधार की आवश्यकता है।
उन लोगों को पहचानें जो समस्याएं जल्दी सामने लाते हैं। यदि कोई ऐसी चिंता व्यक्त करता है जिससे किसी घटना को रोका जा सके, तो यह सार्वजनिक रूप से जश्न मनाने लायक है। आप अपने इच्छित व्यवहार को सुदृढ़ कर रहे हैं।
और स्वीकार करें कि घटनाएँ घटेंगी। लक्ष्य शून्य घटनाएँ नहीं है. लक्ष्य यह है कि प्रत्येक घटना नई हो - आप नए और दिलचस्प तरीकों से असफल हो रहे हैं, एक ही असफलता को बार-बार नहीं दोहरा रहे हैं।
NextRetro निःशुल्क आज़माएँ-- अंतर्निहित टेम्प्लेट और अनाम कार्ड संग्रह का उपयोग करके अपनी टीम के साथ संरचित, दोषरहित घटना रेट्रोस्पेक्टिव चलाएँ।
आखरी अपडेट:फरवरी 2026
पढ़ने का समय:7 मिनट
