प्रोडक्शन इंसिडेंट से सीखना
Production incidents से सीखना वह feedback loop है जो असली users को दिखे failure को एक स्थायी सुधार में बदल देता है। Incident production में होने वाली ऐसी अनियोजित घटना है जो users या business को नुकसान पहुँचाती है: outage, गलत data, या एक payment का दो बार कट जाना। Service बहाल होने के बाद team एक postmortem में incident को review करती है, पता लगाती है कि कौन-से tests या checks यह problem पकड़ सकते थे, और उन्हें जोड़ती है, आम तौर पर regression tests के रूप में।
उदाहरण: एक release के बाद कुछ customers से दो बार पैसे कटे। Fix दोहरे charges रोक देता है; सीख यह पूछना है कि कोई भी test धीमे payment provider के सामने क्यों नहीं चला, और फिर ऐसा test जोड़ना जो चले।
यह क्यों ज़रूरी है
Production incident किसी defect को खोजने का सबसे महँगा तरीका है: users को नुकसान होता है, support और finance का समय लगता है, और team दबाव में काम करती है। अगर नतीजा सिर्फ़ एक hotfix हो, तो वे हालात बने रहते हैं जिनकी वजह से defect बाहर निकला, और वैसा ही incident फिर होता है।
Tester के लिए हर incident test approach के बारे में ऐसा सबूत है जो कोई review नहीं दे सकता: यह ठीक-ठीक दिखाता है कि test basis, test levels, environments या oracles कहाँ हकीकत से मेल नहीं खाते थे। इस सबूत का blame के बिना इस्तेमाल regression suite को अंदाज़ों की बजाय असली risks से जोड़े रखता है।
Incident से prevention तक: feedback loop
यह lesson वहीं से शुरू होता है जहाँ detection ख़त्म होता है। क्रम मायने रखता है: पहले service बहाल करें, फिर जाँच करें, और tests व process आख़िर में बदलें, जब facts साफ़ हो जाएँ।
ISTQB की भाषा में incident के दौरान users जो अनुभव करते हैं वह एक failure है: system वह नहीं करता जो उससे अपेक्षित है। इसकी वजह code का defect हो सकती है, लेकिन configuration, data, capacity या कोई third-party service भी, इसलिए review पहले तय करता है कि क्या fail हुआ और क्यों, फिर फ़ैसला करता है कि जवाब fix और नया test है या नहीं।
- Detect और declare: कोई alert, synthetic check या customer की शिकायत एक incident record खोलती है, जिसमें समय, impact और एक owner होता है।
- Mitigate: rollback, feature flag या configuration change से नुकसान रोकें। Mitigation fix नहीं है; यह fix ढूँढने का समय देता है।
- Timeline दोबारा बनाएँ: deployments, configuration changes, alerts, logs और फ़ैसले, सब एक ही time zone में।
- Blameless postmortem करें: impact, timeline, contributing causes और action items।
- Test gap analysis करें: कौन-सा test, check या review यह problem पकड़ सकता था, किस level पर, और उसने क्यों नहीं पकड़ा।
- Prevent और verify: regression tests और बाकी actions जोड़ें, हर एक के owner और due date के साथ, और पक्का करें कि वे पूरे हुए।
- 1Detect और declareसमय, impact, ownerAlert, synthetic check या customer की शिकायत incident record खोलती है
- 2Mitigateअभी fix नहींRollback, feature flag या configuration change नुकसान रोकता हैपहले service
- 3Timeline दोबारा बनाएँDeployments, configuration changes, alerts, logs और फ़ैसले, एक time zone में
- 4Blameless postmortemimpact, timeline, causes, action itemsSystem और process में contributing causes, सज़ा के लिए कोई व्यक्ति नहीं
- 5Test gap analysisकौन-सा test या check इसे पकड़ सकता था, किस level पर, और क्यों नहीं पकड़ाtester की अगुवाई
- 6Regression tests और बाकी actionsTests, requirement, environment, monitoring: हर एक का owner और due date
- 7Verifyनया test faulty version पर fail और fix पर pass होता है; हर action बंद होता है
चरण 3–5 के दौरान Blameless: क्या और क्यों पूछें, कौन नहीं
इसके बाद:Regression suite और अगली release के risk analysis में
Blameless postmortem: बिना दोष वाला review
Quality culture वाले lesson ने postmortem को किसी incident के लिखित record के रूप में पेश किया था: उसका impact, detection, mitigation, causes और follow-up actions। यहाँ आप ख़ुद एक postmortem चलाते हैं। Google की SRE book सलाह देती है कि postmortem के triggers पहले से तय करें, जैसे users को दिखने वाला downtime या degradation जो तय सीमा से ज़्यादा हो, किसी भी तरह का data loss, rollback जैसा manual intervention, लंबा resolution time, या ऐसा failure जिसे monitoring ने detect नहीं किया।
Blameless का मतलब है कि review system और process में contributing causes ढूँढता है, सज़ा देने के लिए कोई व्यक्ति नहीं, और मानकर चलता है कि सबने अपनी जानकारी के साथ नेक नीयत से काम किया। यह शिष्टाचार नहीं, व्यावहारिक ज़रूरत है: blame से डरने वाले लोग details छोड़ देते हैं, और review असली causes तक नहीं पहुँचता। Blameless का मतलब बिना जवाबदेही नहीं है; हर action item का एक नामित owner होता है।
- Blame वाला: "Developer timeout case भूल गया।" Blameless: "Retry path का कोई test नहीं था, और code review checklist में slow responses के बारे में कुछ नहीं है।"
- Blame वाला: "QA से छूट गया।" Blameless: "Test environment का payment mock हमेशा एक second से कम में जवाब देता है, इसलिए timeout path कभी चला ही नहीं।"
- "Human error" अपने आप में कभी root cause नहीं होता: पूछें कि किस वजह से वह error करना आसान और पकड़ना मुश्किल था।
Postmortem से test gaps और regression tests तक
Postmortem में tester का मुख्य योगदान test gap analysis है। Failure को test process में पीछे की ओर trace करें: क्या इस behaviour के लिए requirement, test condition और test case थे, और क्या वह test इस build पर production जैसे environment में चला? हर "नहीं" एक gap है, और एक incident में अक्सर कई gaps होते हैं। हर तरह के gap के लिए अलग action चाहिए।
- Missing test condition या test case: न requirement ने, न risk analysis ने इस स्थिति का ज़िक्र किया, या test design वहाँ तक पहुँचा ही नहीं, जैसे edge पर कोई boundary values नहीं। Condition, acceptance criterion या test case जोड़ें।
- गलत test level: test था, लेकिन सिर्फ़ happy path पर end to end; unit या API test faulty branch तक ज़्यादा आसानी से पहुँचता है।
- अवास्तविक data या environment: test data, mocks, time zone, configuration या volumes production से अलग हैं।
- कमज़ोर oracle: test चला, लेकिन उसने वह outcome assert नहीं किया जो गलत हुआ, जैसे HTTP status जाँचा पर charges की गिनती नहीं।
- Test चला ही नहीं: skip हुआ, flaky होने की वजह से quarantine में था, या इस change के regression selection से बाहर रहा।
- Detection gap: users ने problem monitoring से पहले पकड़ी। यह action monitoring का है, test suite का नहीं।
Worked example: release के बाद दोहरा charge
एक काल्पनिक online store का incident। Release 7.3 ने payment client का timeout 30 से घटाकर 10 seconds कर दिया। Load में provider कभी-कभी 10 seconds से ज़्यादा में जवाब देता था; तब client नए payment reference के साथ retry करता था, जिसे provider नया payment मान लेता था, इसलिए कुछ customers से दो बार पैसे कटे।
नीचे postmortem के अंश में problem monitoring ने नहीं, customers ने पकड़ी, पहले दोहरे charge के 67 मिनट बाद; और ज़्यादातर action items code fix नहीं, बल्कि tests और checks हैं।
Contributing causes, किसी व्यक्ति का नाम लिए बिना: timeout के बाद retry नया payment reference भेजता है, इसलिए provider उसे वही payment नहीं पहचान पाता; payment requirement में retries का कोई ज़िक्र नहीं था; हर test environment का payment mock 1 second से कम में जवाब देता है, इसलिए timeout और retry वाला path किसी test में नहीं चला; और "एक order पर एक से ज़्यादा successful charge" के लिए कोई monitoring signal नहीं था। सारे action items release 7.4 के लिए हैं: acceptance criterion कि retry किया गया payment कभी दो बार charge न हो (PO); unit test कि retry मूल payment reference ही दोबारा इस्तेमाल करे (dev); API test जिसमें mock पहली call का जवाब 12 seconds बाद और retry का तुरंत दे, और ठीक एक charge व order status PAID की उम्मीद हो (QA); ऐसा payment mock जो धीमे जवाब simulate करे और provider की तरह दोहराए गए reference को वही payment माने (QA); और हर उस order पर alert जिसका एक से ज़्यादा successful charge हो (ops)।
- Incident declare होने के बाद mitigation में बीस मिनट लगे; prevention के लिए एक requirement, दो tests, test environment की एक नई क्षमता और एक alert चाहिए था।
- Fix से पहले API test release 7.3 पर चलाया गया और दो charges के साथ fail हुआ; fix के साथ वह pass हुआ। जो regression test defect के सामने कभी fail नहीं हुआ, वह उस defect के बारे में कुछ साबित नहीं करता।
- Tests condition को target करते हैं — धीमा provider और उसके बाद retry — incident के exact orders को नहीं, इसलिए वे उसी payment client को इस्तेमाल करने वाले हर दूसरे flow को भी बचाते हैं।
INC-0412 Customers charged twice for one order after release 7.3 (fictional)
Impact 37 orders charged twice; all refunded the same day; no data lost
Timeline all times UTC+3
09:40 Release 7.3 deployed: payment client timeout 30 s -> 10 s
09:58 First duplicate charge (found later in the payment logs)
11:05 First customer complaint to support
11:30 Incident declared; payments team and QA join
11:50 Mitigated: timeout back to 30 s by configuration; no new duplicates
15:00 All duplicate charges refunded
Detection by customers, 67 minutes after the first duplicate; no alert fired
Contributing causes (no individuals named)
- A retry after a timeout sends a new payment reference, so the provider
cannot recognise it as the same payment.
- The payment requirement said nothing about retries.
- The payment mock in every test environment answers in under 1 s,
so the timeout-and-retry path never ran in any test.
- No monitoring signal for "more than one successful charge per order".
Action items owner due
1 Acceptance criterion: a retried payment never charges twice PO 7.4
2 Unit test: a retry reuses the original payment reference dev 7.4
3 API test: the mock answers the first call after 12 s, the
retry at once; exactly one charge, order status PAID QA 7.4
4 Payment mock simulates slow answers and, like the provider,
treats a repeated payment reference as the same payment QA 7.4
5 Alert on any order with more than one successful charge ops 7.4आज़माएँ: टाइमस्टैम्प कन्वर्टर आज़माएँ: तारीख़ अंतर कैलकुलेटर
आम गलतियाँ
- Postmortem को किसी व्यक्ति के इर्द-गिर्द लिखना ("developer भूल गया"), उन हालात के बजाय जिन्होंने error संभव बनाया।
- ऐसा regression test जोड़ना जो customer का exact order दोहराए, failure के पीछे की condition नहीं।
- नया test faulty version पर कभी न चलाना, जिससे किसी को पता नहीं होता कि वह incident पकड़ता या नहीं।
- हर नए check को धीमे end-to-end UI test में डालना, जबकि unit या API test faulty branch तक ज़्यादा तेज़ी से पहुँचता है।
- "और tests जोड़ो" को ही एकमात्र action मानना, जबकि gap requirement, environment या monitoring में हो सकता है।
- Action items को बिना owner और due date के छोड़ देना, जिससे वे कभी पूरे नहीं होते।
QA का नज़रिया
Tester आम तौर पर mitigation के बाद शामिल होता है, लेकिन तैयारी तुरंत कर सकता है: release पर कौन-से tests चले, किस environment में, किस data के साथ। Postmortem में gap वाले सवाल शांति से पूछें और उनमें test process को भी शामिल करें; "हमारे tests यह देख ही नहीं सकते थे क्योंकि mock कभी timeout नहीं होता" system के बारे में एक finding है, ग़लती की स्वीकारोक्ति नहीं।
इसके बाद tracker में incident, defect, नए test cases और बदली हुई requirement को link करें, और अगली release पर जाँचें कि action items बंद हो गए हैं। Production तक पहुँचे defects (escaped defects) की list हर कुछ महीनों में review करें: एक ही तरह के बार-बार आने वाले gaps, जैसे time zones या retries, risk analysis और test strategy के लिए input हैं।
अभ्यास
Flash sale वाले time zone incident को tests में बदलें
Incident (काल्पनिक): एक flash sale की घोषणा थी कि वह रियाद समय (UTC+3) के अनुसार 30 सितंबर के दिन के अंत तक चलेगी। Server ने end time की तुलना UTC वाले मौजूदा समय से की, इसलिए sale price तीन घंटे ज़्यादा चलता रहा, रियाद में 1 अक्टूबर को 02:59:59 तक। Finance ने अगली सुबह यह देखा। सारे automated tests UTC पर set CI machines पर चलते हैं, और sale tests में end से एक दिन पहले और एक दिन बाद की तारीख़ें इस्तेमाल हुई थीं।
Postmortem draft कहता है: "Developer रियाद समय में convert करना भूल गया।" और "QA को इसे test करना चाहिए था।" दोनों वाक्यों को blameless तरीके से दोबारा लिखें, test gaps classify करें, regression tests design करें, और कम से कम एक ऐसा action बताएँ जो test नहीं है।
- Blame वाले दोनों वाक्यों को system और process के बारे में statements के रूप में दोबारा लिखें।
- इस lesson की categories से test gaps classify करें।
- कम से कम दो regression tests design करें, level, exact input times और expected results के साथ।
- जो actions test नहीं हैं उन्हें जोड़ें, और बताएँ कि आप कैसे साबित करेंगे कि नए tests defect पकड़ते हैं।
मॉडल उत्तर दिखाएँ
Blameless rewrites: "Sale-end check ने रियाद समय में सोचे गए end time की तुलना UTC वाली server clock से की, और कोई requirement या checklist नहीं बताती कि sale dates पर कौन-सा time zone लागू होता है।" और "Sale tests में end से पूरे एक दिन दूर की तारीख़ें थीं और सारे tests UTC में चलते हैं, इसलिए तीन घंटे का अंतर किसी test में दिख ही नहीं सकता था।"
Test gaps: missing test condition, क्योंकि requirement में time zone लिखा नहीं है; missing test case, क्योंकि sale ख़त्म होने के पल के आसपास कोई boundary values test नहीं हुईं; अवास्तविक environment, क्योंकि हर test UTC में चलता है; detection gap, क्योंकि problem monitoring ने नहीं, finance ने पकड़ी।
Regression tests: fixed clock के साथ एक unit test (test असली समय पढ़ने के बजाय मौजूदा समय ख़ुद set करता है), जिसमें 30 सितंबर 20:59:59 UTC (रियाद में 23:59:59) पर sale price और 21:00:00 UTC (रियाद में आधी रात) पर regular price मिले; एक API test जो test environment की clock को 30 सितंबर 21:00:00 UTC पर set करे, product का price माँगे और regular price की उम्मीद करे; और suite को एक बार फिर machine का time zone Asia/Riyadh set करके चलाना, जिसके नतीजे UTC वाले run जैसे ही होने चाहिए, ताकि साबित हो कि वे server के zone पर निर्भर नहीं करते।
दूसरे actions: sale requirement में time zone लिखें, sale के end time के बाद sale price पर हुए orders पर alert लगाएँ, और बाकी date rules, जैसे coupons और delivery cut-offs, में यही pattern खोजें। Tests को साबित करने के लिए उन्हें faulty version पर चलाएँ, जहाँ 21:00:00 UTC पर भी sale price मिलता है और test fail होता है, फिर fix पर, जहाँ वह pass होता है।
अक्सर पूछे जाने वाले सवाल
क्या हर incident के लिए पूरा postmortem ज़रूरी है?
नहीं। Criteria पहले से तय करें, जैसे तय सीमा से ज़्यादा users को दिखने वाला impact, किसी भी तरह का data loss, rollback या कोई और manual intervention, लंबा resolution time, या ऐसी problem जिसे monitoring ने detect नहीं किया। छोटे incidents के लिए छोटा लिखित review काफ़ी है, लेकिन कई मिलते-जुलते छोटे incidents मिलकर पूरे postmortem के लायक हैं।
क्या blameless का मतलब है कि कोई ज़िम्मेदार नहीं?
नहीं। उस समय की जानकारी के साथ ईमानदारी से हुई गलती के लिए किसी को सज़ा नहीं मिलती, लेकिन हर action item का नामित owner और due date होता है, और team उन्हें पूरा करने के लिए जवाबदेह है। Blame का न होना ही लोगों को अपने फ़ैसले ईमानदारी से बताने देता है, और analysis इसी पर टिका है।
क्या हर incident का अंत एक नए automated test से होना चाहिए?
Defect से हुए incident को आम तौर पर कम से कम एक regression test मिलना चाहिए, उस सबसे निचले level पर जो उसे detect कर सके। अगर cause capacity, third-party outage या configuration change है, तो बेहतर action alert, configuration check या release checklist का कोई item हो सकता है। दोनों हालात में फ़ैसला record करें।
Postmortem का root cause analysis से क्या संबंध है?
Root cause analysis, जैसे 5 whys या fishbone diagram जिनका वर्णन defect triage guide में है, एक technique है जिसे postmortem के अंदर failure से उसके causes तक पहुँचने के लिए इस्तेमाल किया जाता है। Postmortem उससे बड़ा है: वह impact, timeline, detection और mitigation भी record करता है, आम तौर पर एक अकेले cause के बजाय कई contributing causes ढूँढता है, और owner वाले actions पर ख़त्म होता है।
संदर्भ
- Postmortem Culture: Learning from Failure — Site Reliability Engineering (John Lunney and Sue Lueder)Blameless postmortems: किन घटनाओं पर postmortem ज़रूरी है, उसमें क्या दर्ज होता है — प्रभाव, root causes और follow-up कार्य — और उसमें दोष देने को क्यों बाहर रखा जाता है।
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
Mutqan tools से अभ्यास करें
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।
फ़ीचर के विवरण और फ़ील्ड सूची से संरचित टेस्ट केस (id, शीर्षक, पूर्व-शर्तें, स्टेप, अपेक्षित परिणाम, प्राथमिकता) जनरेट करें।
तारीख़ और समय को अलग-अलग timezone के बीच बदलें (रियाद, अम्मान, दिल्ली, UTC, न्यूयॉर्क, लंदन…)।
टाइमस्टैम्प (सेकंड, मिलीसेकंड, माइक्रोसेकंड) को पढ़ने योग्य तारीख़ में और वापस बदलें, किसी भी timezone में।
दो तारीख़ों के बीच सटीक अंतर वर्ष, महीने, दिन, घंटे और कुल इकाइयों में निकालें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।