तीन क्लासिक कैसकेड पैटर्न

विफलता निर्भरताओं के माध्यम से यात्रा करती है।

पैटर्न 1: ग्रेडन हड़ताल। एक साझा संसाधन (क्यू, लॉक, डेटाबेस) विफल हो जाता है या पुनरारंभ होता है। इस पर निर्भर सभी ग्राहक फिर से प्रयास करते हैं। विनाश उन्हें फिर से स्थापित करता है; पुनर्स्थापना कभी पूरा नहीं होती है।

पैटर्न 2: पुनर्प्रयास आंधी। एक नीचे से सेवा धीरे होती है। ऊपरी कॉलर, बजाय विफलता के, पुनर्प्रयास करते हैं। पुनर्प्रयास मूल लोड को गुणा करते हैं। धीरे सेवा धीरे होती है, जो और अधिक पुनर्प्रयास प्रेरित करती है। अंततः लोड स्वस्थ संस्करण को भी पार करता है।

पैटर्न 3: मौत की क्यू। एक प्रसंस्करण क्यू जिसमें पीछे की दबाव नहीं होती है, तेजी से प्रसंस्करण करती है। क्यू अनंतता में बढ़ जाता है। स्मृति समाप्त होती है; उपभोक्ता क्रैश होते हैं; पुनरारंभ करते हैं; एक और अधिक बड़े क्यू पाते हैं; फिर से क्रैश होते हैं।

सामान्य धागा: एक छोटी प्रारंभिक विचरण एक सकारात्मक प्रतिफल लूप को ट्रिगर करती है। प्रणाली की अपनी प्रतिक्रिया विफलता को बढ़ाती है बजाय इसके दबाने के।

दबाने वाले mekanizmalar

अनुपातिक विलम्बीकरण के साथ जिटर। पुनर्प्रयास करने वाले विलंबित प्रतीक्षा करते हैं, प्रत्येक बार अधिक समय के साथ, साथ में संख्या भिन्न। सिंक्रोनाइज़ पुनर्प्रयास तरंगों को रोकते हैं।

सर्किट ब्रेकर। एक कॉलर नीचे से विफलता की दर ट्रैक करता है। एक सीमा के पार, कॉलर को कुछ समय के लिए कॉल करना बंद कर देता है और तुरंत अपने स्वयं के अनुरोधों को असफल करता है। विनाश का काम रोकता है, नीचे को संभाल के लिए मिलता है।

बुल्कहेड। निर्भरता के प्रत्येक संसाधन को आइसोलेट करते हैं। कनेक्शन पूल ए डेटाबेस के लिए, सeparate connection pool B के लिए क्यू। एक धीमा डेटाबेस अन्य सभी कनेक्शन को स्टार्व नहीं कर सकता। क्यू कॉल्स जारी रहते हैं।

लोड शेडिंग। जब अधिभारित होते हैं, तो किनार से अनुरोधों को ड्रॉप करते हैं बजाय धीरे से असफल होने के। 429 मिलीसेकंड में बेहतर है बजाय 500 के 30 सेकंड में।

पीछे की दबाव। जब उपभोक्ता क्यू नहीं रख सकते, तब प्रोड्यूसर धीमे होते हैं। क्यू बाउंड होते हैं, सेंडर ब्लॉक होते हैं, मूल काम का काम गलाने लगता है।

कैसकेड का निदान करें

एक टीम का API टियर मेल्टडाउन होता है जब एक सामान्य डेटाबेस फेलовер होता है। समयरेखा:

- 14:00:00 — ऑपरेटर स्टैंडबाई डेटाबेस को प्रमोट करते हैं। अपेक्षित अनुपलब्धता: ~10 सेकंड।

- 14:00:08 — प्राथमिक अनुपलब्ध। API टियर के अनुरोध शुरू होते हैं जो डेटाबेस कनेक्शन त्रुटियों से विफल होते हैं।

- 14:00:08 — API टियर रिट्राई करता है (डिफ़ॉल्ट निर्देशिका: 5 प्रयास, कोई पीछे हटना, 100ms के साथ)।

- 14:00:11 — स्टैंडबाई प्रमोट किया गया, नई कनेक्शन स्वीकार करता है।

- 14:00:11 — API टियर थोड़ी सी नई डेटाबेस कनेक्शन एक साथ खोलता है (प्रत्येक रिप्लिका × प्रत्येक संचालित अनुरोध × प्रत्येक रिट्राई के साथ)।

- 14:00:13 — नई प्राथमिक की कनेक्शन पूल समाप्त; नई कनेक्शन अस्वीकृत।

- 14:00:13-14:05:00 — API टियर के रिप्लिका कनेक्शन पूल समाप्त होते हैं, अपवाद फेंकते हैं, क्रैश होते हैं, फिर से शुरू होते हैं, और दोहराते हैं।

- 14:05:00 — ऑपरेटर मनuale रोकता है API टियर ट्रैफिक; डेटाबेस स्थिर होता है।

- 14:10:00 — धीरे धीरे ट्रैफिक पुनर्स्थापना पूरी होती है। कुल कटौती: ~10 मिनट (वह अपेक्षित ~10 सेकंड के बजाय)।

डीएनएस SERVFAIL: दो संयुक्त मूल दोष

एक वास्तविक-शेप पोस्टमोर्टम

जो निम्नलिखित एक सैनिटाइज़ वर्जन है एक वास्तविक घटना। वेंडर नाम बदले गए, आईपी व्यक्तिगत किए गए हैं, लेकिन आकार, समयरेखा, और सबक वास्तविक हैं।

सारांश

साइट example.com ने लगभग 3-4 घंटे के लिए सभी पब्लिक डीएनएस रेज़ल्वेर्स से SERVFAIL वापस किया। अन्य 46 ज़ोनों के उसी डीएनएस मास्टर पर थे अपराध। मूल कारण: दो संयुक्त मूल दोष।

1. वेंडर A (एक द्वितीय डीएनएस प्रदाता) ने नई आंतरिक सिंक आईपी जोड़ी जो प्राथमिक की allow-axfr-ips अनुमति सूची में नहीं थी।

2. example.com ज़ोन ने वर्षों पुराने RFC-विरोधी CNAME संघर्ष (demo.example.com ने उसी लेबल पर दोनों CNAME & MX/TXT रिकॉर्ड रखे) के कारण वेंडर A को AXFR पर ज़ोन को अस्वीकार करने के लिए मजबूर किया।

समयरेखा (UTC)

- ~15:00 — वेंडर A ने अपनी संरचना में नई सिंक आईपी 198.51.100.42 जोड़ी।

- 15:02 — first AXFR-out denied for 198.51.100.42 appears in primary DNS logs (no alerting on this signal)

- ~18:00 — SOA expire window reached; Vendor A drops example.com zone from cache

- ~18:30 — SERVFAIL detected externally

- ~19:45 — root cause identified

- 20:00 — 198.51.100.42 added to allow-axfr-ips; primary restarted

- 20:05 — NOTIFY sent; AXFR initiated; zone STILL SERVFAIL (CNAME conflict)

- 20:07 — check-zone reveals 1 error: CNAME conflict on demo.example.com

- 20:09 — CNAME replaced with A record; zone check clean (0 errors)

- 20:10 — NOTIFY sent; AXFR completes; Vendor A begins serving zone

- 20:11 — dig @8.8.8.8 example.com A returns correct IP — RESOLVED

Why Only example.com?

All 47 zones share the same DNS primary. The AXFR IP block affected all zones. But only example.com had the CNAME conflict, & only example.com needed a fresh AXFR at the moment the deny was enforced. Other zones had already refreshed before the deny or did not yet need to.

Latent defect

The CNAME conflict at demo.example.com had existed for years. It worked because the primary served the zone from its database (lenient about RFC violations) & Vendor A was serving from stale cached data from before the violation was introduced. When Vendor A dropped its cache & needed fresh data, the violation surfaced.

Trigger

Vendor A silently added a new sync IP. The primary's allowlist did not include it. AXFR denied. Three hours later (SOA expire), Vendor A dropped the zone. The latent defect surfaced when the system tried to recover.

Write Blameless Action Items

Blameless: Target Systems, Not People

A blameless action item names something the system should do differently, not something a person should do differently. 'Train the operator' is blameful. 'Add an automated check that catches this before deploy' is blameless.

Good blameless action items cluster into three dimensions:

- Prevention: make the bad thing harder or impossible

- Detection: notice it sooner if it happens

- Recovery: limit the damage when it happens

Each item should name (1) the specific system change, (2) an owner team, & (3) the dimension it serves.

शिप के बिना डूबने वाले कमरों को सीमित करें

नौ इंजीनियरिंग से उधार लिया गया

नावें वॉटरटाइट बुल्कहेड्स ले जाती हैं: ऊर्ध्वगामी दीवारें जो हुल को कमरों में विभाजित करती हैं। एक कमरा भीग सकता है बिना नाव डूबे, दूसरा बाकी को प्रभावित किए बिना विफल हो सकता है।

वितरित प्रणालियां उसी शब्द को और उसी विचार को उधार लेती हैं।

बुल्कहेड पैटर्न: निर्भरता के आधार पर संसाधनों को आइसोलेट करें। एक सेवा जो तीन नीचे के एपीआई को कॉल करती है, तीन अलग-अलग कनेक्शन पूल, तीन अलग-अलग थ्रेड पूल, तीन अलग-अलग रिट्री बजेट का उपयोग करती है। एक धीमा या विफल नीचे का नहीं एक दूसरे के लिए संसाधनों को खपा सकता है।

बिना बुल्कहेड के: एक धीमा निर्भरता साझा थ्रेड पूल को थका देती है; अन्य निर्भरता के लिए कॉल ब्लॉक होते हैं जबकि थ्रेड्स का इंतज़ार करते हैं; पूरी सेवा संवेदनशील हो जाती है।

बुल्कहेड के साथ: एक धीमी निर्भरता अपने स्वयं के पूल को थका देती है; उस पर कॉल जल्दी से फेल होती हैं; अन्य निर्भरता के लिए कॉल सामान्य रूप से जारी रखें; विफल निर्भरता के साथ विस्फोट की रेडियस सीमित रहती है।

सर्किट ब्रेकर

सर्किट ब्रेकर पैटर्न: एक निर्भरता के चारों ओर एक राज्यभित्ति वाला आवरण जो विफलता की दर को ट्रैक करता है। तीन राज्य:

- बंद (सामान्य): कॉल पास होती हैं। विफलताओं को गिनते हैं।

- खुला (ट्रिप): पिछले 30 सेकंड में विफलता की सीमा (उदाहरण के लिए, 50% विफलताएं) के बाद ब्रेकर खुला होता है। कॉल तुरंत विफल होती हैं बिना विफल निर्भरता को। कॉलर को काम बर्बाद से बचाता है; निर्भरता को स्वस्थ नहीं होने के दौरान बोझ से बचाता है।

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

मुख्य अहसास: सर्किट ब्रेकर जानी-मानी विफल अवधि के दौरान प्रयास को रोकता है और डाउनस्ट्रीम को सुधार के लिए मौका देता है बिना लगातार बोझ के।

बुल्कहेड विस्फोट की रेडियस को बांधते हैं। सर्किट ब्रेकर विस्फोट को स्वयं को जारी रखने देते हैं।

विस्फोट की रेडियस को बांधें

आपकी API सेवा चार नीचे सेवाओं को कॉल करती है: यूजर सेवा, रिकमेंडेशन सेवा, नोटिफिकेशन सेवा और एक तृतीय-पक्ष पेमेंट API। टीम ने सुना है कि 'रिकमेंडेशन सेवा थोड़ी फ्लेकी रही है' और यह सुनिश्चित करना चाहती है कि जब यह विफल होती है, तो बाकी सिस्टम स्वस्थ रहता है।

आज सेवा का प्रयोग एक ही साझा थ्रेड पूल के 200 थ्रेड्स और एक ही साझा HTTP कनेक्शन पूल के लिए किया जाता है। इन संसाधनों के लिए सभी चार नीचे के सेवा प्रतिस्पर्धा करते हैं। कोई सर्किट ब्रेकर नहीं हैं।

फेलियर मोड रिव्यू डिज़ाइन करें

सिंथेसिस

आप SPOFs की जाँच करके ढूंढ सकते हैं, गिरावट के पैटर्न को पहचान सकते हैं, पोस्टमॉर्टम को पढ़कर ट्रिगर से लैटेंट डिफेक्ट को अलग कर सकते हैं, प्रतिक्रिया / पता लगाने / बहाली के लिए दोषरहित कार्रवाई पॉइंट लिख सकते हैं, और बुल्कहेड्स + सर्किट ब्रेकर्स + ग्रेसफुल डिग्रेडेशन से ब्लास्ट रेडियस को बांध सकते हैं।

सभी पांच का प्रयोग करें।

आपकी टीम नई सेवा search.example.com लॉन्च करने जा रही है जो तीन नीचे की सेवाओं पर निर्भर करती है: प्राथमिक खोज इंडेक्स (index.example.com), एक एनालिटिक्स सेवा (analytics.example.com) और एक रिकमेंडेशन सेवा (recs.example.com)। टीम को लॉन्च से पहले 'फेलियर मोड रिव्यू' करने के लिए आपको नेतृत्व करने के लिए कह रही है।

यह कोर्स आगे क्या करता है

यह कोर्स आगे क्या करता है

अब आप SPOF को पहचान सकते हैं, गिरावट के पैटर्न को पहचान सकते हैं, पोस्टमॉर्टम को पढ़कर ट्रिगर से लैटेंट डिफेक्ट को अलग कर सकते हैं, दोषरहित कार्रवाई पॉइंट लिख सकते हैं, और डिज़ाइन द्वारा ब्लास्ट रेडियस को बांध सकते हैं।

इस कोर्स के (cs_distsys_observability_and_capacity) अंतिम पाठ में सीखा जाता है कि क्या मापें ताकि पता चले कि समस्या उपयोगकर्ताओं को होती है इससे पहले। हैल्थ चेक्स, वर्जन एंडपॉइंट्स, प्रॉक्सी टियर में चार सोने के संकेतों के साथ, और संचारित क्षमता के निर्णयों को देखी गई डेटा पर वापस जोड़ा जाता है।

साथी पाठ: geometry_of_failure_modes_and_blast_radius केंद्रीयता के बीच (जो ग्राफ नोड बोतलनेक का बॉटलनेक है) और मिन-कट (ब्लास्ट रेडियस के बाउंड पर) निकालता है।

बहुत अच्छा किया। आगे बढ़ें।