रेज़िलिएंस टेस्टिंग

Resilience testing की परिभाषा: विफलता और recovery

Pillar गाइड resilience को उसके व्यापक अर्थ में लेती है — लोड, विफलता और हमले में व्यवहार। यह गाइड विफलता और recovery वाला हिस्सा कवर करती है: जब सामान्य ट्रैफ़िक के दौरान सिस्टम का कोई हिस्सा टूटता है, तब क्या होता है।

Resilient सिस्टम वह नहीं जो कभी फ़ेल न हो; वह है जिसकी विफलताएँ छोटी और कम समय की रहें। Resilience testing इस विचार को जाँचों में बदलती है: किसी नामित fault के दौरान सेवा एक लिखी हुई सीमा में रहे (जैसे 99% checkout अब भी सफल), ऐसा न हो सके तो एक तय degraded मोड में जाए (cache से कीमतें, क़तार में रखे ऑर्डर), और fault ख़त्म होने के बाद तय समय में सामान्य हो जाए — बिना किसी के हाथ से कुछ restart किए।

ISO/IEC 25010:2023 इन गुणों को reliability के तहत रखता है और उसे चार उप-विशेषताओं में बाँटता है: faultlessness, availability, fault tolerance और recoverability। Resilience testing आख़िरी तीन को सीधे परखती है: क्या ज़रूरत के समय सेवा उपलब्ध है? क्या हार्डवेयर या सॉफ़्टवेयर faults के बावजूद वह इच्छित ढंग से चलती है? और रुकावट के बाद क्या वह प्रभावित डेटा वापस पाकर वांछित स्थिति में लौटती है? Chaos engineering इसी काम का प्रयोगात्मक रूप है; उसके सिद्धांत सुरक्षित रूप से संभव होने पर production ट्रैफ़िक पर experiments चलाने को प्राथमिकता देते हैं।

परफ़ॉर्मेंस टेस्टिंग टीमों में resilience testing अक्सर stress test के बाद का क़दम होती है: वही एनवायरनमेंट, वही workload model और वही load generator, बस एक fault जोड़कर। QA रोडमैप का "स्ट्रेस टेस्टिंग" lesson overload के बाद की recovery कवर करता है; resilience testing सामान्य लोड पर किसी विफलता के बाद की recovery कवर करती है।

• Continuity — fault मौजूद रहते हुए यूज़र requests का कितना हिस्सा अब भी सफल है, fault से पहले की steady state की तुलना में।
• Containment — fault उसी हिस्से में रहे जहाँ लगा: धीमा payment provider प्रोडक्ट सर्च को धीमा न करे।
• Degradation — पूरी सेवा संभव न हो तो प्रोडक्ट requirements में बताए degraded मोड में जाए और यूज़र को बताए।
• Detection — monitoring fault को पहचाने और तय समय में सही लोगों को alert करे।
• Recovery — fault ख़त्म होने के बाद सेवा अपने आप, लक्ष्य के भीतर, बिना खोए या दोहराए डेटा के steady state में लौटे।

Resilience testing बनाम परफ़ॉर्मेंस टेस्टिंग

दोनों टूल और एनवायरनमेंट साझा करते हैं, इसलिए अक्सर आपस में गड़बड़ा दिए जाते हैं। अंतर इसमें है कि टेस्ट के दौरान क्या बदलता है। परफ़ॉर्मेंस टेस्ट — load, stress, spike या soak — ट्रैफ़िक की मात्रा बदलता है और हर कंपोनेंट को स्वस्थ रखता है, ताकि पता चले कि सिस्टम कितना तेज़ है और कितना लोड उठा सकता है। Resilience test ट्रैफ़िक को यथार्थ, स्थिर स्तर पर रखता है और एक कंपोनेंट की सेहत बदलता है, ताकि पता चले कि उस कंपोनेंट के बिगड़ने पर यूज़र क्या अनुभव करते हैं और सिस्टम कैसे उबरता है।

ISTQB का performance testing पाठ्यक्रम load, stress, scalability, spike, endurance, concurrency और capacity testing गिनाता है, और ISTQB की stress testing की परिभाषा तय न्यूनतम से कम उपलब्ध संसाधनों को भी शामिल करती है, जैसे ज़रूरत से कम मेमोरी — यहीं दोनों प्रैक्टिस मिलती हैं। रोज़ के काम में दोनों साथ चलती हैं: परफ़ॉर्मेंस टेस्ट baseline, capacity और समझदार timeouts तय करते हैं, और resilience टेस्ट जाँचते हैं कि चीज़ें फ़ेल होने पर सिस्टम उसी baseline पर कैसा व्यवहार करता है। कोई सिस्टम हर load test पास करके भी पहली धीमी dependency पर गिर सकता है, क्योंकि load test कभी किसी dependency को धीमा नहीं करता।

• सवाल: परफ़ॉर्मेंस — यह कितना तेज़ है और टूटने से पहले कितना लोड उठाता है? Resilience — इसका कोई हिस्सा फ़ेल हो तो यूज़र के साथ क्या होता है, और यह कितनी जल्दी उबरता है?
• क्या बदलता है: परफ़ॉर्मेंस — लोड (यूज़र, request rate, डेटा की मात्रा, अवधि)। Resilience — एक कंपोनेंट की सेहत (latency, errors, crash, नेटवर्क का टूटना, भरी डिस्क)।
• क्या स्थिर रहता है: परफ़ॉर्मेंस — हर कंपोनेंट स्वस्थ। Resilience — यथार्थ, स्थिर लोड।
• Inputs: परफ़ॉर्मेंस — workload model, load profile, टेस्ट डेटा। Resilience — steady-state baseline, hypothesis, fault, blast radius, abort conditions।
• Pass criteria: परफ़ॉर्मेंस — किसी तय लोड पर p95/p99 latency, throughput और error rate; capacity की सीमा। Resilience — fault के दौरान success rate, degraded मोड का दिखना, alert का चलना, RTO/RPO के मुक़ाबले recovery time, कोई खोया या दोहराया डेटा नहीं।
• आम टूल: परफ़ॉर्मेंस — JMeter, k6, Locust। Resilience — fault proxies (Toxiproxy), HTTP mocks, Chaos Mesh, LitmusChaos, AWS FIS, Azure Chaos Studio, साथ में एक load generator।

                    Performance testing                      Resilience testing
Question            How fast is it, and how much load can    What do users get when one part fails,
                    it carry before it breaks?               and how fast does it recover?
What changes        The load: users, request rate, data      The health of one component: latency,
                    volume, duration                         errors, crashes, network, full disk
What stays fixed    Every component is healthy               A realistic, steady load
Inputs              Workload model, load profile,            Steady-state baseline, hypothesis,
                    test data                                fault, blast radius, abort conditions
Pass criteria       p95/p99 latency, throughput and error    Success rate during the fault, degraded
                    rate at a stated load; capacity limit    mode shown, alert fired, recovery time
                                                             vs RTO/RPO, no lost or duplicated data
Typical tools       JMeter, k6, Locust                       Fault proxies (Toxiproxy), HTTP mocks,
                                                             Chaos Mesh, LitmusChaos, AWS FIS,
                                                             Azure Chaos Studio + a load generator
Output              Latency curves, capacity figure          Experiment record: expected vs observed,
                                                             findings, follow-up actions

Resilience requirements: RTO, RPO, SLO और degraded modes

Resilience test को वही चाहिए जो load test को: रन से पहले संख्या में लिखा लक्ष्य। ज़्यादातर सिस्टम के लिए पाँच तरह की requirements काफ़ी हैं।

नीचे की शीट एक काल्पनिक दुकान के checkout का उदाहरण है; इसकी हर पंक्ति एक टेस्ट है।

• Recovery time objective (RTO) — NIST SP 800-34 इसे वह कुल समय बताता है जितनी देर किसी information system के कंपोनेंट recovery चरण में रह सकते हैं, इससे पहले कि संगठन के मिशन या बिज़नेस प्रक्रियाओं पर बुरा असर पड़े। Resilience test असली recovery time — fault से सामान्य सेवा तक — मापता है और उसकी तुलना RTO से करता है।
• Recovery point objective (RPO) — उसी प्रकाशन में: वह समय-बिंदु जिस तक outage के बाद डेटा वापस लाना ज़रूरी है; यानी हाल का कितना डेटा खोना बिज़नेस सह सकता है। Failover test इसे fault से पहले लिखे आख़िरी रिकॉर्ड की तुलना recovery के बाद मौजूद डेटा से करके मापता है।
• Service level objective (SLO) और error budget — Google की SRE पुस्तक SLO को किसी indicator (SLI) से मापे जाने वाले सर्विस लेवल का लक्ष्य मान या मानों की रेंज बताती है, जैसे सफल requests का हिस्सा। Error budget वह विफलता है जिसकी SLO गुंजाइश छोड़ता है: 30 दिनों में 99.5% सफलता के SLO और 2,000,000 requests पर 10,000 फ़ेल हो सकते हैं। Resilience टेस्ट जाँचते हैं कि fault contain होने पर SLO टिका रहे, और production experiments ऐसे प्लान होते हैं कि वे budget का सिर्फ़ एक छोटा, तय हिस्सा ख़र्च करें। Degraded मोड भी मुफ़्त नहीं है: SLO से बाहर परोसे गए उसके requests भी budget ख़र्च करते हैं, और requirements में लिखा होना चाहिए कि कितना।
• Degraded modes — विफल होने की जगह प्रोडक्ट क्या करता है: read-only मोड (ग्राहक ब्राउज़ कर सकता है और अपने ऑर्डर देख सकता है, पर नया ऑर्डर नहीं दे सकता), cached डेटा (10 मिनट तक पुरानी कीमतें), queueing (ऑर्डर स्वीकार, confirmation ईमेल बाद में), या कोई ग़ैर-ज़रूरी फ़ीचर बंद (recommendations छिपे)। हर मोड के लिए एक trigger, यूज़र संदेश और exit शर्त चाहिए जिन्हें टेस्ट किया जा सके।
• Detection और recovery time — alert कितनी जल्दी चले, और fault ख़त्म होने के बाद बिना किसी manual क़दम के सेवा कितनी जल्दी steady state में लौटे।

Resilience requirements - Bustan Market checkout (fictional example)

SLO          99.5% of checkout requests succeed within 3 s, rolling 30 days
             error budget 0.5%: about 10,000 of 2,000,000 requests a month may fail
Payments     slow (answers in up to 3 s): checkout completes, p95 <= 4 s, errors <= 1%;
             checkouts over 3 s still count against the SLO: at about 2,800 an hour,
             10% over 3 s spends ~280 (about 3% of the monthly budget) per hour
             failing: "Card payment is unavailable - your basket is saved",
             no HTTP 500, no duplicate charge; breaker opens, retries stop
             recovered: normal checkout within 60 s, no restart
Price cache  lost: prices read from the database, at most 200 queries/s, p95 <= 1.5 s
Order DB     zone loss: failover to the replica, RTO 15 min, RPO 1 min
E-mail       service down: orders accepted, confirmations queued, sent within 1 h
Detection    alert "checkout errors" to on-call within 5 min of user errors above 5%

Resilience experiment डिज़ाइन करना

हर resilience test एक experiment है जिसकी लिखी हुई अपेक्षा होती है। Principles of Chaos Engineering इसका ढाँचा बताते हैं: steady state को सिस्टम के ऐसे मापने-योग्य output के रूप में परिभाषित करें जो सामान्य व्यवहार दिखाए, मान लें कि वह जारी रहेगा, असली दुनिया की घटनाओं जैसे variables डालें, और फ़र्क़ खोजकर hypothesis को ग़लत साबित करने की कोशिश करें। Steady state यूज़र को महसूस होने वाले outputs के बारे में है — throughput, error rate, latency percentiles — CPU जैसे आंतरिक metrics नहीं। SRE पुस्तक के चार golden signals में से latency, traffic और errors steady-state मानदंड बनते हैं, और चौथा, saturation, उन्हें समझाने वाला diagnostic रहता है।

Hypothesis ऐसे लिखें कि वह फ़ेल हो सके: "जब payment API 2 s धीमा जवाब दे, तब checkout कम से कम 99% requests के लिए सफल रहे और p95 4 s से कम रहे, क्योंकि client timeout 3 s है और connection pool उसी हिसाब से बना है।" जो hypothesis mechanism का नाम लेती है, वह फ़ेल होने पर बताती है कि कहाँ देखना है।

• एक बार में एक variable। एक आकार का एक fault डालें, ताकि नतीजे में बदलाव का एक ही कारण हो। Faults को तभी मिलाएँ जब हर एक अकेले पास हो चुका हो।
• Blast radius। पहले से तय करें: कौन-सा एनवायरनमेंट, instances या ट्रैफ़िक का कितना हिस्सा, कौन-से यूज़र (सिर्फ़ test accounts, या असली ट्रैफ़िक का छोटा हिस्सा) और कितनी देर। सबसे छोटे से शुरू करें और पास होने के बाद ही बढ़ाएँ।
• Abort conditions। वे सीमाएँ लिखें जो experiment तुरंत ख़त्म कर दें — जैसे दो मिनट तक 5% से ज़्यादा user-facing errors, या experiment से बाहर की किसी टीम का कोई alert — और यह भी कि stop कौन बोलेगा। Load generator इसका एक हिस्सा लागू कर सकता है: abortOnFail वाले k6 thresholds पार होते ही रन रोक देते हैं।
• आज़माया हुआ बाहर निकलने का रास्ता। Fault हटाने वाला command fault डालने से पहले काम करना चाहिए; उसे एक बार स्वस्थ सिस्टम पर चलाकर देखें।
• Injection से पहले observability। जाँचें कि dashboards steady-state metrics और ख़ुद fault (dependency की latency, circuit breaker की स्थिति) दिखाते हैं। Fault नहीं दिखता तो उसका असर भी नहीं दिखेगा; और अगर monitoring डाले गए fault को पकड़ न पाए, तो वही पहली finding है।
• पहले baseline, फिर fault, फिर recovery। Injection से पहले कम से कम 10–15 मिनट की steady state दर्ज करें, fault को इतनी देर रखें कि metrics स्थिर हो जाएँ, और हटाने के बाद तब तक मापते रहें जब तक steady state लौट न आए।

RESILIENCE EXPERIMENT RX-<nnn>          Owner: <name>          Date: <yyyy-mm-dd>

Service -> dependency   <service> -> <dependency>
Steady state            <metric = value>, measured for <n> min before injection
Hypothesis              When <fault> hits <dependency>, <service> will <behaviour>
                        because <mechanism>; <metric> stays <limit>.
Fault (one variable)    <type>, <size>, <duration>, injected with <tool>
Blast radius            <environment>; <share of instances or traffic>; <which users>
Traffic                 <synthetic rate, or share of real traffic>
Observe                 <dashboards, logs, traces, alert names>
Abort if (any one)      <user-facing errors > x% for y min> | <p95 > z s>
                        | <alert from a team outside the experiment>
Abort method            <command or button>, last tried on <date>
Pass if                 <criteria compared with the steady state>
Recovery check          steady state back within <t> after removal, no manual step,
                        data reconciled (no lost or duplicated records)
Result                  pass | fail | aborted     Findings: <ids>     Follow-ups: <tickets>

आज़माएँ: API हेल्थ चेकर आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र

Fault catalogue: क्या inject करें और क्या देखें

Faults अपने architecture और incident इतिहास से चुनें, सबसे ज़्यादा जोखिम वाले पहले; नीचे की सूची वे faults कवर करती है जिनसे ज़्यादातर सिस्टम का सामना होता है। हर बिंदु का दूसरा हिस्सा बताता है कि क्या देखना है — वह सबूत जो pass या fail तय करता है।

• Dependency latency — 500 ms जोड़ें, फिर caller के timeout से थोड़ा कम और थोड़ा ज़्यादा delay। देखें: कॉल configured timeout पर ख़त्म होती है, connection या thread pools भरते नहीं, और जो endpoints उस dependency का इस्तेमाल नहीं करते वे पहले जितने तेज़ रहते हैं।
• Error responses — dependency से 500, Retry-After हेडर के साथ 503, या 429 लौटवाएँ। देखें: retry सिर्फ़ retry-योग्य errors पर होता है, Retry-After का पालन होता है, और यूज़र को कच्चे 500 की जगह स्पष्ट संदेश दिखता है।
• Timeouts और hangs — dependency कनेक्शन स्वीकार करती है पर कभी जवाब नहीं देती। देखें: कॉल को आपका अपना timeout ख़त्म करता है (मिनटों बाद ऑपरेटिंग सिस्टम का डिफ़ॉल्ट नहीं), और कॉल के रोके संसाधन मुक्त होते हैं।
• Crashes और restarts — ट्रैफ़िक के दौरान कोई process, container या instance बंद करें। देखें: health checks उसे rotation से बाहर करते हैं, चल रहे requests सुरक्षित रूप से retry होते हैं या साफ़ फ़ेल होते हैं, queued काम खोता नहीं, और restart के बाद वह वापस जुड़ता है।
• Network partition और packet loss — 5–10% packets गिराएँ, या दो कंपोनेंट के बीच का लिंक काटें। देखें: loss retransmission की वजह से latency के रूप में दिखता है, clustered data stores partition के दोनों तरफ़ परस्पर-विरोधी writes स्वीकार नहीं करते, और लिंक जुड़ने पर connections फिर बनते हैं।
• Disk full — logs, temporary files या डेटाबेस वाला volume भर दें। देखें: भरने से पहले alert, डेटा बिगाड़ने की जगह writes का स्पष्ट error के साथ फ़ेल होना, और जगह ख़ाली होने पर सेवा का उबरना।
• Clock skew — किसी एक node की घड़ी कुछ मिनट आगे या पीछे करें। देखें: token validation (RFC 7519 exp और nbf के लिए सिर्फ़ छोटी leeway की अनुमति देता है, आमतौर पर कुछ मिनट से ज़्यादा नहीं), certificate validity जाँच, scheduled jobs, और timestamp से events को क्रम देने वाली हर चीज़।
• Expired certificates और credentials — कोई test certificate एक्सपायर होने दें, या कोई API key या secret revoke करें। देखें: कारण बताने वाला स्पष्ट error, एक्सपायरी से कई दिन पहले alert, और ऐसा rotation जो redeploy के बिना लागू हो।
• Zone या region loss — एक availability zone के सारे instances बंद करें, या डेटाबेस को उसकी replica पर failover करें। देखें: बची capacity लोड उठाती है या नहीं, RTO के मुक़ाबले failover time, RPO के मुक़ाबले खोया डेटा, और DNS या load balancer में बदलाव।
• Retry storms — कोई dependency गिराएँ, फिर तब वापस लाएँ जब बहुत से clients retry कर रहे हों। देखें: हर यूज़र request पर dependency को कितनी कॉल मिलती हैं, backoff और jitter retries को समय में फैलाते हैं या नहीं, और dependency उबरती है या फिर से गिरा दी जाती है।
• Cache failure — cache बंद करें, या flush कर दें ताकि हर request miss हो। देखें: cold start के दौरान डेटाबेस लोड, latency, क्या एप्लिकेशन एक ही entry फिर से बनाने वाले requests की संख्या सीमित करता है, और requirements अनुमति दें तो क्या वह पुराना डेटा देता है।
• Message-queue backlog — consumers को 30 मिनट के लिए रोकें, फिर चालू करें। देखें: queue depth और message age के alerts, queue भरने पर producers क्या करते हैं, drain time, और हर message का एक ही बार process होना (consumers idempotent होने चाहिए, क्योंकि redelivery होती है)।

आज़माएँ: Mock एरर रिस्पॉन्स जनरेटर आज़माएँ: SSL सर्टिफ़िकेट चेकर आज़माएँ: JWT एक्सपायरेशन चेकर

हर resilience pattern को कैसे टेस्ट करें

Michael Nygard की Release It! ऐसे stability patterns बताती है जो विफलता को स्थानीय रखते हैं — इनमें timeouts, circuit breakers, bulkheads, fail fast और shed load शामिल हैं। नीचे की सूची इनमें backoff के साथ retries, idempotency और graceful degradation जोड़ती है, जो उस catalogue से नहीं बल्कि SRE पुस्तक और RFC 9110 से आते हैं, पर उसी तरह टेस्ट होते हैं। कोड में pattern का होना और आपकी settings के साथ उसका काम करना एक बात नहीं है; हर pattern का एक टेस्ट है जो इसे साबित करता है।

• Timeouts — timeout से थोड़ा कम और थोड़ा ज़्यादा latency डालें और जाँचें कि कॉल configured मान पर ख़त्म हो। कॉल की श्रृंखला में हर layer का timeout उसके caller से छोटा होना चाहिए; SRE पुस्तक पूरे request में एक ही deadline आगे बढ़ाने (deadline propagation) की सलाह देती है, ताकि downstream सेवा उस request पर काम बंद कर दे जिसे client छोड़ चुका है।
• Exponential backoff और jitter के साथ retries — एक यूज़र request पर dependency को मिलने वाली कॉल गिनें। Retries layers के पार गुणा होते हैं: SRE पुस्तक के उदाहरण में तीन layers, हर एक तीन बार retry करती हुई, एक यूज़र action को डेटाबेस पर 64 प्रयासों में बदल देती हैं। जाँचें: प्रयासों और delay पर cap, delays का randomised होना (बहुत से clients के retries लहरों में न आएँ), सिर्फ़ retry-योग्य विफलताओं पर retry (timeout या 503, कभी 400 या 422 नहीं), और 429 व 503 पर Retry-After का पालन।
• Circuit breakers — failure rate को breaker की threshold से ऊपर ले जाएँ और जाँचें कि वह open हो (कॉल timeouts का इंतज़ार करने के बजाय milliseconds में फ़ेल हों), reset timeout के बाद एक trial कॉल जाने दे (half-open), और dependency स्वस्थ होने पर फिर close हो। State में बदलाव metrics या logs में दिखने चाहिए।
• Bulkheads — एक dependency का connection या thread pool ख़त्म कर दें और जाँचें कि दूसरी dependencies वाले endpoints अपनी सामान्य latency बनाए रखें। यह containment जाँच है: एक धीमा partner पूरी सेवा न गिराए।
• Idempotency — एक ही request दो बार भेजें, और पहले प्रयास के timeout के बाद फिर से, और जाँचें कि असर एक ही हो: एक ऑर्डर, एक charge। RFC 9110 PUT और DELETE को idempotent और POST को non-idempotent बताता है, इसलिए जो POST retry हो सकता है उसे एक idempotency key चाहिए जिसके आधार पर सर्वर duplicates हटाए।
• Graceful degradation — dependency बंद करें और जाँचें कि requirements में लिखा degraded मोड दिखे, यूज़र को बताया जाए, और recovery के बाद प्रोडक्ट अपने आप पूरे मोड में लौटे। Degraded modes सामान्य संचालन में शायद ही कभी चलते हैं, और ठीक इसी वजह से उन्हें टेस्ट चाहिए।
• Load shedding और rate limiting — ट्रैफ़िक को capacity से ऊपर ले जाएँ और जाँचें कि अतिरिक्त requests जल्दी और सस्ते में ठुकराए जाएँ (429 या 503, बेहतर हो तो Retry-After के साथ, milliseconds में), ज़रूरी ट्रैफ़िक कम ज़रूरी ट्रैफ़िक से पहले सुरक्षित रहे, और स्वीकार किए गए requests अब भी SLO पूरा करें। RFC 6585 429 Too Many Requests परिभाषित करता है।

आज़माएँ: API स्टेटस कोड सिम्युलेटर आज़माएँ: Mock एरर रिस्पॉन्स जनरेटर आज़माएँ: Concurrent रिक्वेस्ट टेस्ट जनरेटर

Resilience testing सेशन (game day) कैसे चलाएँ

Resilience testing सेशन — जिसे आमतौर पर game day कहते हैं — एक निर्धारित, समय-सीमित अभ्यास है जिसमें टीम सिस्टम में योजनाबद्ध faults डालती है और अपनी प्रतिक्रिया का अभ्यास करती है, ताकि सॉफ़्टवेयर के साथ लोग, runbooks और alerts भी टेस्ट हों। AWS Well-Architected गाइडेंस game days को production जैसे एनवायरनमेंट में घटनाओं का simulation बताती है, जो सिस्टम, प्रक्रियाओं और टीम की प्रतिक्रिया को टेस्ट करता है — उन्हीं टीमों के साथ जो असली घटना सँभालेंगी, और नियमित रूप से।

पहला सेशन छोटा रखें: एक सेवा, दो से चार scenarios, आधा दिन, production से मेल खाते staging एनवायरनमेंट में। इसका मूल्य इस तुलना में है कि टीम ने क्या उम्मीद की और असल में क्या हुआ — उसमें वह भी शामिल है जिस पर किसी का ध्यान नहीं गया।

• तैयारी (एक से दो हफ़्ते पहले): risk सूची और हाल के incidents से सेवा और scenarios चुनें; हर scenario के लिए hypothesis और abort condition लिखें; service owner की मंज़ूरी लें; on-call, customer support और निर्भर टीमों को तारीख़ और scope बताएँ; dashboards और alerts जाँचें; हर fault हटाने का अभ्यास करें।
• Roles: facilitator जो agenda चलाता है और तय करता है कि कब आगे बढ़ना है; एक operator जो faults डालता और हटाता है, ताकि कोई और सिस्टम न बदले; responders — on-call इंजीनियर — जो दिखी चीज़ को असली incident की तरह सँभालते हैं; observers जो dashboards देखते और बताते हैं; और scribe जो समय-मुहर वाली timeline रखता है।
• Runbook: हर scenario के लिए injection command, अपेक्षित observations, removal command और abort condition, उसी क्रम में जिसमें वे इस्तेमाल होंगे। Responders टीम के सामान्य incident runbooks से काम करते हैं, ताकि उनकी कमियाँ findings के रूप में सामने आएँ।
• Safety: कोई भी stop बोल सकता है; stop पर operator हर fault हटाता है और कुछ भी और करने से पहले टीम steady state की पुष्टि करती है। किसी असली incident, release या peak अवधि के दौरान शुरू न करें।
• एनवायरनमेंट: शुरुआती रन के लिए fault proxy वाला test एनवायरनमेंट; ज़्यादातर सेशनों के लिए production जैसी topology और synthetic ट्रैफ़िक वाला staging; production सिर्फ़ उन experiments के लिए जो staging में पास हो चुके हों — छोटे blast radius, बचे हुए error budget, off-peak समय और तैयार stop conditions के साथ।
• Debrief (उसी दिन): हर scenario से गुज़रें — अपेक्षित, observed, कब और किसने detect किया, कब recover हुआ, कौन-से manual क़दम लगे। इसे blameless रखें, जैसा SRE पुस्तक का postmortem अध्याय बताता है: विषय सिस्टम और प्रक्रिया है, व्यक्ति नहीं। हर finding owner और तारीख़ वाला ticket बनती है, और फ़ेल हुआ scenario fix के बाद फिर चलाया जाता है।

RESILIENCE GAME DAY - <service> - <date>, <start>-<end> <time zone>

Goal          <the question this session answers>
Environment   <test | staging | production>    Traffic: <synthetic rate | real share>
Scope         in: <services>    out: <services>
Approved by   <service owner>, <on-call lead>
Notified      on-call, customer support, <dependent teams>, <provider if needed>

Roles
  Facilitator  <name>   runs the agenda, decides when to move on
  Operator     <name>   the only person who injects and removes faults
  Responders   <names>  on-call engineers, respond as in a real incident
  Observers    <names>  watch dashboards and report what they see
  Scribe       <name>   keeps the timeline: time, event, who

Stop rule     anyone may call STOP; the operator removes all faults (<command>)
Abort if      <user-facing errors > x% for y min> | <SLO burn > z> | <real incident>

Agenda
  09:00  Briefing: goal, scenarios, roles, stop rule; baseline dashboards checked
  09:20  Scenario 1  <fault>     hypothesis: <...>     time box 30 min
  10:00  Scenario 2  <fault>     hypothesis: <...>     time box 30 min
  10:40  Scenario 3  <fault>     hypothesis: <...>     time box 30 min
  11:20  All faults removed; steady state confirmed
  11:30  Debrief (blameless): expected vs observed, surprises, runbook and alert gaps
  12:15  Close: findings recorded, follow-up tickets with owners and dates

Record per scenario
  Injected / removed      <hh:mm:ss> / <hh:mm:ss>
  Detected by / at        <alert or person> / <hh:mm:ss>
  Steady state held       yes | no  (<values>)
  Recovered at            <hh:mm:ss>    manual steps: <none | list>
  Findings                <ids>

आज़माएँ: वेबसाइट अपटाइम चेकर

Resilience testing टूल, और हर तरह का टूल कहाँ चलता है

Resilience testing टूल कुछ श्रेणियों में आते हैं, ज़्यादातर इस हिसाब से कि fault कहाँ डाला जाता है। नीचे के विवरण हर प्रोजेक्ट के अपने दस्तावेज़ से लिए गए हैं; कौन-सा फ़िट है यह आपके प्लेटफ़ॉर्म पर निर्भर है, किसी ranking पर नहीं।

सूची के बाद की स्क्रिप्ट हर merge पर चलने वाली जाँच का उदाहरण है, जो नीचे के worked example की client settings (timeout 3 s, एक retry, checkout की 5 s deadline) के लिए लिखी गई है। Toxiproxy payment कॉल को timeout से ज़्यादा धीमा करता है; स्क्रिप्ट जाँचती है कि ठीक एक retry के बाद checkout अपनी deadline के भीतर स्पष्ट 503 के साथ रुक जाए, फिर fault हटाकर जाँचती है कि अगला checkout बिना restart के सफल हो।

• Fault proxies सेवा और उसकी dependency के बीच बैठते हैं। Toxiproxy — chaos और resiliency testing में नेटवर्क और सिस्टम की स्थितियाँ simulate करने वाला एक TCP proxy — jitter के साथ latency, bandwidth की सीमा, timeouts, connection resets और टुकड़ों में बँटा डेटा जैसे "toxics" जोड़ता है, और टेस्ट कोड से HTTP API द्वारा नियंत्रित होता है। यह TCP स्तर पर काम करता है, इसलिए HTTP status नहीं लौटा सकता; 500, 503 और 429 के लिए इसे HTTP mock के साथ जोड़ें।
• HTTP mocks और stubs असली dependency की जगह चुने हुए status codes, bodies और delays लौटाते हैं — CI में error handling और retries टेस्ट करने का सबसे सस्ता तरीक़ा। इस साइट का API Status Code Simulator manual जाँचों के लिए 200 से 599 तक कोई भी status, 10 s तक के वैकल्पिक delay के साथ लौटाता है; यह rate-limited है, इसलिए ज़्यादा मात्रा वाले automated रन के लिए local mock इस्तेमाल करें।
• Kubernetes chaos प्लेटफ़ॉर्म pods, nodes और उनके आसपास के नेटवर्क में faults डालते हैं। Chaos Mesh — Kubernetes custom resources पर बना एक CNCF incubating प्रोजेक्ट — pod failures, network latency और packet loss, DNS और HTTP faults, CPU और memory stress, file I/O faults, clock jumps और JVM faults दस्तावेज़ करता है, और experiments को workflows में जोड़ता है। LitmusChaos, यह भी CNCF incubating और Kubernetes-native, experiments को custom resources के रूप में घोषित करता है और उन्हें resilience probes से परखता है — HTTP, command, Kubernetes और Prometheus जाँचें जिनकी सफलता verdict का हिस्सा है।
• Cloud fault-injection सेवाएँ प्रोवाइडर के अपने संसाधनों पर काम करती हैं। AWS Fault Injection Service actions, targets और stop conditions वाले templates से experiments चलाती है, जहाँ stop condition एक CloudWatch alarm है जो experiment रोक देता है; AWS production से पहले planning और pre-production रन की सलाह देता है। Azure Chaos Studio किसी resource की management API से service-direct faults (virtual machine बंद करना, Azure Cosmos DB account का failover) और virtual machines के अंदर agent-based faults (CPU pressure, process kill) चलाता है; इसके नए Workspaces, तैयार outage Scenarios के साथ, इस गाइड के लिखे जाने के समय public preview में थे।
• Load generator स्थिर ट्रैफ़िक और abort logic का एक हिस्सा देता है: JMeter, या error rate और p95 latency पर thresholds के साथ k6।
• कहाँ चलते हैं: fault proxies और mocks CI में हर merge पर (कुछ तेज़, deterministic जाँचें); Kubernetes और cloud टूल staging और pre-release सेशनों में; production experiments सिर्फ़ stop conditions, छोटे blast radius और error budget के तय हिस्से के साथ। AWS की chaos-engineering गाइडेंस जोड़ती है कि जिस experiment को सिस्टम पास कर चुका हो, उसे pipeline में automated regression test के रूप में रखा जाए।
• Resilience testing strategy इन परतों को क्रम से जोड़ती है: पहले लिखी requirements; हर merge पर CI में तेज़ fault tests; हर बड़ी release या इन्फ़्रास्ट्रक्चर बदलाव से पहले staging experiments और एक game day; जो पास हो चुका हो सिर्फ़ उसके लिए सुरक्षित production experiments; और पूरा सेट तय समय-सारणी पर दोहराया जाए, क्योंकि कोड न बदले तब भी dependencies बदलती हैं।

#!/usr/bin/env bash
# Resilience check on every merge (example). docker compose starts the app with
# PAYMENTS_URL=http://toxiproxy:21212, a payments stub on :8080 and Toxiproxy (API on :8474).
set -euo pipefail
TOXI=http://localhost:8474
APP=http://localhost:3000
STUB=http://localhost:8080   # the example stub counts the calls it receives at /__calls

checkout() {  # prints "<status> <seconds>"
  curl -s --max-time 10 -o /dev/null -w '%{http_code} %{time_total}' -X POST "$APP/api/checkout" -H 'Content-Type: application/json' -d @basket.json
}

curl -sf -X POST "$TOXI/proxies" -d '{"name":"payments","listen":"0.0.0.0:21212","upstream":"payments-stub:8080"}' > /dev/null

# 1. Payments slower than the 3 s client timeout. With this client (timeout 3 s, one retry
#    after up to 200 ms, 5 s checkout deadline) the first call times out, the retry is cut
#    off by the deadline, and checkout must answer with a clear 503 in about 5 s.
curl -sf -X DELETE "$STUB/__calls" > /dev/null
curl -sf -X POST "$TOXI/proxies/payments/toxics" -d '{"name":"slow","type":"latency","attributes":{"latency":4000,"jitter":0}}' > /dev/null
read -r status seconds <<< "$(checkout)"
[ "$status" = "503" ] || { echo "FAIL slow payments: got $status, expected 503"; exit 1; }
awk -v s="$seconds" 'BEGIN { exit !(s < 5.5) }' || { echo "FAIL slow payments: took ${seconds}s, deadline is 5 s"; exit 1; }
calls=$(curl -sf "$STUB/__calls")
[ "$calls" = "2" ] || { echo "FAIL slow payments: stub saw $calls calls, expected 2 (one retry)"; exit 1; }
echo "ok   slow payments -> $status in ${seconds}s after $calls calls"

# 2. Fault removed: the next checkout succeeds without a restart
curl -sf -X DELETE "$TOXI/proxies/payments/toxics/slow"
read -r status seconds <<< "$(checkout)"
[ "$status" = "201" ] || { echo "FAIL recovery: got $status, expected 201"; exit 1; }
echo "ok   recovered -> $status in ${seconds}s"

curl -sf -X POST "$TOXI/reset" > /dev/null

आज़माएँ: API स्टेटस कोड सिम्युलेटर आज़माएँ: API हेल्थ चेकर

Worked example: payment API धीमा और फ़ेल होने पर checkout

Bustan Market (काल्पनिक) जानना चाहता है कि payment provider का दिन ख़राब हो तो उसका checkout क्या करता है। Experiment production जैसे staging एनवायरनमेंट में चलता है, जहाँ k6 test accounts से प्रति सेकंड 20 checkouts का स्थिर ट्रैफ़िक भेजता है। Payments, Toxiproxy (latency के लिए) और provider के एक stub (errors के लिए) से होकर जाते हैं। संबंधित settings: payment client timeout 3 s; 200 ms तक के बाद (full jitter) एक retry, सिर्फ़ timeout और 503 पर; पूरे checkout request पर 5 s की deadline; हर charge पर Idempotency-Key हेडर; 40 connections का pool; और ऐसा circuit breaker जो पिछली 100 कॉल में 50% से ज़्यादा फ़ेल होने पर open हो।

किसी भी fault से पहले 15 मिनट मापी गई baseline: checkout p95 850 ms, सफलता 99.6%, payment कॉल का औसत 300 ms और p95 420 ms, प्रोडक्ट पेज p95 300 ms।

• Run 1 — 20 मिनट तक payment कॉल 2 s धीमी। अपेक्षा: हर कॉल औसतन लगभग 2.3 s और p95 पर 2.42 s, 3 s timeout से कम, तो checkout p95 अधिकतम 4 s, errors अधिकतम 1%, प्रोडक्ट पेज अपरिवर्तित। Observed: checkout p95 4.8 s, p99 5.0 s — यानी deadline — और 3.4% errors; प्रोडक्ट पेज 310 ms। Pool ने इसे समझाया: Little's law के अनुसार एक साथ चल रही कॉल = arrival rate × हर कॉल का औसत समय ≈ 20 × 2.3 s ≈ 46, जो 40 connections से ज़्यादा है, इसलिए checkouts connection के लिए क़तार में लगे, और सबसे लंबा इंतज़ार करने वाले 3.4% 5 s की deadline तक पहुँचकर फ़ेल हुए। Fail। Bulkhead टिका रहा: प्रोडक्ट पेज पर असर नहीं पड़ा।
• Fix और re-run — pool को एक प्रयास के उस worst case से तय करें जिसकी timeout अनुमति देता है: 20 कॉल/s × 3 s = 60, ऊपर की ओर 64 किया। जब कॉल timeout होकर retry होती हैं तो प्रयासों की दर दोगुनी तक हो सकती है, इसलिए कोई किफ़ायती pool पूरे outage को कवर नहीं करता; वह स्थिति circuit breaker पर छोड़ी गई है, जो open होकर कॉल रोक देता है। Re-run: checkout p95 2.9 s, errors 0.5%। Pass।
• Run 2 — 20 मिनट तक 30% payment कॉल 503 लौटाती हैं। अपेक्षा: एक retry के साथ checkout तभी फ़ेल होता है जब दोनों प्रयास फ़ेल हों, तो 1 − 0.3 × 0.3 = 91% सफल; बाक़ियों को "card payment उपलब्ध नहीं है, आपकी basket सुरक्षित है" संदेश, कभी 500 नहीं; payment कॉल अधिकतम 1.3 गुना (हर कॉल पर एक retry की 30% संभावना); कोई duplicate charge नहीं; breaker बंद रहे, क्योंकि 30% उसकी 50% threshold से कम है। Observed: 90.8% सफल, 9.2% को संदेश, कोई 500 नहीं, प्रति checkout 1.29 कॉल, stub के idempotency keys log से ऑर्डर मिलाने पर शून्य duplicate charges, breaker पूरे समय बंद। Pass।
• Detection — "checkout errors" alert 5 मिनट के भीतर चलना चाहिए। वह 7 मिनट 40 सेकंड बाद चला: वह 10 मिनट का औसत लेता है, इसलिए 0.4% baseline के मुक़ाबले लगभग 9% user-facing failures के साथ औसत 5% को 5 मिनट से थोड़ा ज़्यादा समय बाद ही पार कर पाया, और फिर alert ने अपने evaluation interval के अलावा 2 मिनट और इंतज़ार किया। Fail; window 5 मिनट और pending समय 1 मिनट किया गया, और re-run में alert 3 मिनट 50 सेकंड पर चला।
• Recovery — 503 रुकने के बाद सफलता 35 s में, बिना restart, baseline पर लौट आई। Pass।

Bustan Market (fictional) - checkout -> payment API in staging, k6 at 20 checkouts/s
Baseline (15 min): checkout p95 850 ms, success 99.6%, pages p95 300 ms,
                   payment call mean 300 ms, p95 420 ms
Settings: payment timeout 3 s; 1 retry after up to 200 ms (full jitter); checkout deadline 5 s;
          pool 40; breaker opens at >50% failures in the last 100 calls

Run  Fault (20 min each)       Expected                        Observed                        Result
1    payment calls +2 s        checkout p95 <= 4 s,            p95 4.8 s, errors 3.4%,         FAIL
                               errors <= 1%, pages unchanged   p99 5.0 s (the deadline),
                                                               pool 40/40 busy, pages 310 ms
1b   same, pool 40 -> 64       as run 1                        p95 2.9 s, errors 0.5%          PASS
2    30% of payment calls 503  >= 90% succeed, rest get the    90.8% succeed, 9.2% message,    PASS
                               message, 0 HTTP 500, 0 dupes,   0 HTTP 500, 0 duplicates,
                               calls <= x1.3, breaker closed   x1.29 calls, breaker closed
     - detection               alert within 5 min              alert at 7 min 40 s             FAIL
     - recovery after removal  baseline within 60 s            baseline after 35 s             PASS

Follow-ups: RX-14 pool size = peak calls/s x timeout, in the payment client (done, re-run passed);
                  timeouts with retries can double the attempt rate - left to the breaker
            RX-15 alert window 10 min -> 5 min, pending 2 min -> 1 min (re-run: alert at 3 min 50 s)

आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र आज़माएँ: API परफ़ॉर्मेंस कंपेरेटर आज़माएँ: HTTP रिक्वेस्ट बेंचमार्क

Resilience testing की आम ग़लतियाँ

• Production से शुरुआत। Production experiments आख़िर में आते हैं, जब वही fault staging में पास हो चुका हो और abort का रास्ता आज़माया जा चुका हो।
• Steady state दर्ज किए बिना fault डालना। Baseline के बिना "checkout धीमा हो गया" मापा नहीं जा सकता, और नतीजा एक राय बनकर रह जाता है।
• कई चीज़ें एक साथ बदलना। एक रन में दो faults, नया build और configuration बदलाव ऐसी विफलता छोड़ते हैं जिसके चार संभावित कारण हों।
• सिर्फ़ पूरे outages टेस्ट करना। असली dependencies पूरी तरह बंद होने के मुक़ाबले कहीं ज़्यादा बार धीमी होती हैं या कुछ requests फ़ेल करती हैं — और धीमी dependency pools और timeouts पर बंद dependency से ज़्यादा भारी पड़ती है।
• यूज़र की जगह सर्वर मापना। CPU और pod restarts diagnostics हैं; pass criteria user-facing success rate, latency और डेटा की शुद्धता हैं।
• Experiment के दौरान लोड नहीं। कई faults का असर सिर्फ़ concurrency में दिखता है — pool exhaustion, retry storms, बढ़ती queues। ख़ाली staging सिस्टम वह आसानी से झेल जाता है जो production नहीं झेलेगा।
• बाद में डेटा न जाँचना। Duplicate charges, आधे लिखे ऑर्डर और खोए messages latency ग्राफ़ पर नहीं दिखते; सिस्टम ने जो स्वीकार किया उसे उससे मिलाएँ जो उसने स्टोर किया।
• सेशन को ही deliverable मानना। Tickets, owners और re-run तारीख़ के बिना game day सिर्फ़ कमज़ोरी का दस्तावेज़ बनकर रह जाता है।
• एक बार चलाकर छोड़ देना। Dependencies, configuration और ट्रैफ़िक बदलते हैं; पास हुए experiments को regression tests के रूप में रखें और game days तय समय-सारणी पर दोहराएँ।

अक्सर पूछे जाने वाले सवाल

संदर्भ

• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023उत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information SystemsNIST · 2010Information systems के लिए contingency planning, जिसमें recovery targets तय करने और टेस्ट करने में इस्तेमाल होने वाली recovery time objective (RTO) और recovery point objective (RPO) की परिभाषाएँ शामिल हैं।
• Site Reliability Engineering: How Google Runs Production SystemsGoogle / O'Reilly Media · 2016सर्विस लेवल ऑब्जेक्टिव, एरर बजट, "चार गोल्डन सिग्नल" की निगरानी और ओवरलोड संभालना — लचीलेपन का परिचालन पक्ष।
• Monitoring Distributed Systems — Site Reliability Engineering (Rob Ewaschuk)Google / O'Reilly Media · 2016monitoring पर Google की SRE गाइडेंस: black-box बनाम white-box monitoring और चार golden signals — latency, traffic, errors और saturation।
• Addressing Cascading Failures — Site Reliability Engineering (Mike Ulrich)Google / O'Reilly Media · 2016Overload और retries एक विफलता को cascade में कैसे बदलते हैं, और टेस्ट करने लायक़ बचाव: randomised exponential backoff, retry सीमाएँ और budget, deadline propagation, load shedding और graceful degradation।
• Postmortem Culture: Learning from Failure — Site Reliability Engineering (John Lunney and Sue Lueder)Google / O'Reilly Media · 2016Blameless postmortems: किन घटनाओं पर postmortem ज़रूरी है, उसमें क्या दर्ज होता है — प्रभाव, root causes और follow-up कार्य — और उसमें दोष देने को क्यों बाहर रखा जाता है।
• Release It! Second Edition: Design and Deploy Production-Ready Software (Michael T. Nygard)The Pragmatic Bookshelf · 2018स्थिरता पैटर्न — टाइमआउट, सर्किट ब्रेकर, बल्कहेड, बैक-प्रेशर — और वे विफलता के तरीके जिन्हें लोड टेस्टिंग खोजने के लिए है।
• Circuit Breaker (Martin Fowler)martinfowler.com · 2014Circuit breaker pattern: closed, open और half-open स्थितियाँ, failure thresholds और reset — वह व्यवहार जिसे resilience test को देखना होता है।
• Principles of Chaos Engineeringprinciplesofchaos.org · 2019Chaos engineering की परिभाषा और उसकी experiment पद्धति: मापने-योग्य steady state, hypothesis, असली दुनिया जैसे fault variables और न्यूनतम blast radius।
• REL12-BP04 Test resiliency using chaos engineering — AWS Well-Architected Framework, Reliability PillarAmazon Web ServicesFault-injection experiments चलाना: steady state, hypothesis, guardrails और stop conditions, production से पहले pre-production, और पास हुए experiments को CI/CD में regression tests के रूप में रखना।
• REL12-BP05 Conduct game days regularly — AWS Well-Architected Framework, Reliability PillarAmazon Web ServicesGame days: production जैसे एनवायरनमेंट में घटनाओं का simulation, ताकि सिस्टम, प्रक्रियाएँ और टीम की प्रतिक्रिया टेस्ट हों, असली घटनाएँ सँभालने वाली टीमों के साथ, और उसके बाद review जिसकी सीखें पूरी होने तक ट्रैक हों।
• What is AWS Fault Injection Service? — AWS FIS User GuideAmazon Web ServicesAWS की managed fault-injection सेवा: actions, targets और stop conditions से बने experiment templates, जहाँ stop condition एक CloudWatch alarm है जो experiment रोक देता है।
• What is Azure Chaos Studio?MicrosoftAzure के लिए Microsoft की managed chaos-engineering सेवा: service-direct और agent-based faults, और तैयार outage Scenarios वाले Workspaces (public preview में)।
• Basic Features — Chaos Mesh documentationChaos Mesh (CNCF)Chaos Mesh Kubernetes पर जो fault types डालता है — pod, network, DNS, HTTP, stress, file I/O, time, kernel और JVM faults — और उसके chaos workflows व dashboard।
• What is Litmus — LitmusChaos documentationLitmusChaos (CNCF)LitmusChaos, एक CNCF incubating chaos engineering framework जो chaos experiments को Kubernetes custom resources के रूप में घोषित करता है।
• Certified Tester Performance Testing (CT-PT)ISTQB · 2018performance testing पर ISTQB का specialist पाठ्यक्रम: बुनियादी अवधारणाएँ, performance measurements, टेस्ट गतिविधियाँ व कार्य, और टूल।
• Grafana k6 documentationGrafana LabsGrafana k6 का आधिकारिक दस्तावेज़ — एक open-source और extensible load व performance testing टूल।
• RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
• RFC 6585: Additional HTTP Status CodesIETF · 2012428, 429 Too Many Requests, 431 और 511 को परिभाषित करता है, रेट लिमिटिंग के लिए Retry-After हेडर सहित।
• RFC 7519: JSON Web Token (JWT)IETF · 2015JWT फ़ॉर्मेट — हेडर, पेलोड, सिग्नेचर — और रजिस्टर्ड क्लेम iss, sub, aud, exp, nbf, iat और jti को परिभाषित करता है।