Tre Klassiska Kaskaderande Mönster

Fel sprider sig genom Beroenden

Mönster 1: Thundering herd. En delad resurs (cacheminne, lås, databas) misslyckas eller startas om. Varje klient som beroende på den gör omfattande. Varje försök överman det som kommer upp igen; återhämtningen kan aldrig slutföras.

Mönster 2: Retriesstorm. En nedströms service blir långsammare. Överordnade anropare istället för att misslycka gör omfattande. Omfattande multiplicerar den ursprungliga belastningen. Servicen blir långsammare, vilket triggar fler omfattande. Till slut överstiger belastningen även en frisk version av servicen.

Mönster 3: Dödens kö. En bearbetningskö utan baktryckning tar emot snabbare än den bearbetar. Kön växer obegränsat. Minne tär; konsument kraschar; startar om; hittar en fortfarande större kö; kraschar igen.

Gemensamt tema: en liten initial störning utlöser en positivt feedbackslinga. Systemets egen respons förstärker felet i stället för att dämpa det.

Dämpningsmekanismer

Exponentiell paus med stötestreck. Klienter som gör omfattande väntar längre varje gång, med slumpmässig avvikelse. Förhindrar synchroniserade omfattande vågor.

Kopplingsbroms. En anropare spårar nedströms fehfrekvens. Över en gräns stoppar anroparen från att anropa under en avkopplingsperiod & omedelbart misslyckas sina egna begäranden.

Bulkhead. Isolera resurser per beroende. Anslutningspool A för databas, separat anslutningspool B för cacheminne. En långsammare databas kan inte tär alla anslutningar; cacheminne kan fortsätta.

Belastningsminskning. När överbeläggning uppstår släpps begäranden på kanten i stället för att accepteras & misslyckas långsamt. En 429 på 1 ms är bättre än en 500 på 30 sekunder.

Baktryckning. När överförare sakta går när konsumenter inte kan hålla tempo. Köer blir begränsade; skickare blockeras; den ursprungliga källan för arbete känner avdraget.

Diagnostera en Kaskad

En teams API-tjänst smälter sam under en rutinmäld database-failover. Tidslinje:

- 14:00:00 — operatör uppmärksammar ståndbys-databas. Förväntad otillgänglighet: ~10 sekunder.

- 14:00:08 — primärtillgänglighet. API-tjänstens begäranden börjar misslyckas med databasanslutningsfel.

- 14:00:08 — API-tjänsten försöker igen (standardkonfiguration: 5 försök, ingen utebliven, 100 ms åt var sida).

- 14:00:11 — ståndbys, accepterar nya anslutningar.

- 14:00:11 — API-tjänsten öppnar tusentals nya databasanslutningar samtidigt (varje replika × varje parallella begäran × varje försök).

- 14:00:13 — nytt primärs anslutningspool töms; nya anslutningar avvisas.

- 14:00:13-14:05:00 — API-tjänstens repliker tömmer anslutningspooler, kastar undan exceptioner, startar om, upprepar.

- 14:05:00 — operatör stoppar manuellt API-tjänsttrafiken; databasen stabiliserar.

- 14:10:00 — successiv återställning av trafik är klar. Totalt avbrott: ~10 minuter (mot förväntade ~10 sekunder).

DNS SERVFAIL: Två Sammanförda Fel

En Riktig-Form Postmortem

Det följande är en desinficerad version av en riktig incident. Leverantörernas namn ändrats, IP:er anonymiserats; formen, tidslinjen och läxorna är ändå verkligheten.

Sammanfattning

Webbplatsen example.com returnerade SERVFAIL från alla publika DNS- Resolver för cirka 3-4 timmar. Alla andra 46 zoner på samma DNS-master var oberörd. Orsaken: två sammanförda fel.

1. Leverantör A (en sekundär DNS-leverantör) tillade en ny intern sync-IP som inte fanns i primärets allow-axfr-ips tillåtelselista.

2. Zonen example.com hade en gammal RFC-brytande CNAME-konflikt (demo.example.com hade både CNAME- & MX/TXT-anteckningar på samma etikett) som orsakade att leverantör A avvisade zonen på ny AXFR.

Tidslinje (UTC)

- ~15:00 — Leverantör A lägger till ny sync-IP 198.51.100.42 i deras infrastruktur

- 15:02 — första AXFR-out denied för 198.51.100.42 syns i primära DNS-loggar (ingen alert för detta tecken)

- ~18:00 — SOA utgångstid nås; Företag A släpper example.com zonen ur cachen

- ~18:30 — SERVFAIL upptäcks externt

- ~19:45 — orsaken identifieras

- 20:00 — 198.51.100.42 läggs till i allow-axfr-ips; primära återstartas

- 20:05 — NOTIFY skickas; AXFR inleds; zonen ÄR FORFÄLLANDE (CNAME-konflikt)

- 20:07 — check-zone avslöjar 1 fel: CNAME-konflikt på demo.example.com

- 20:09 — CNAME ersätts med A-record; zonkontroll ren (0 fel)

- 20:10 — NOTIFY skickas; AXFR slutförs; Företag A tar över zonens servande

- 20:11 — dig @8.8.8.8 example.com A returnerar korrekt IP — LÖST

Varför bara example.com?

De 47 zonerna delar samma DNS primära. AXFR-IP-blocket påverkade alla zoner. Men endast example.com hade CNAME-konflikten och endast example.com behövde en ny AXFR när förbudet genomfördes. Övriga zoner hade redan uppdaterats före förbudet eller hade ännu inte behövt uppdatera.

Latenta fel

CNAME-konflikten på demo.example.com hade funnits i flera år. Den fungerade eftersom primära serverade zonen från dess databas (lättsamt med avvikelser från RFC) och Företag A serverade från föråldrad cachematerial från före introduktionen av avvikelsen. När Företag A droppade sin cache och behövde ny data upptäcktes avvikelsen.

Uppskattning

Företag A tillskrev tyst en ny synk-IP. Primära tillåtelsen inkluderade inte den. AXFR nekades. Tre timmar senare (SOA utgångstid) droppade Företag A zonen. Latenta fel upptäcktes när systemet försökte återhämta sig.

Skriv Blameless Åtgärder

Blameless: Mål System, Inte Personer

En blameless åtgärd anger något som systemet bör göra annorlunda, inte något som en person bör göra annorlunda. 'Uppfostra operatören' är skuldbårande. 'Lägg till en automatiserad kontroll som upptäcker detta före distribuering' är skuldlös.

God blameless åtgärder klusterar i tre dimensioner:

- Förebyggande: Gör det dåliga svårare eller omöjligt

- Upphittande: Märker det tidigare om det inträffar

- Återhämtning: Begränsa skadan när det inträffar

Varje åtgärd bör ange (1) den specifika systemförändringen, (2) ansvarigt team och (3) vilken dimension den tjänar.

Kompartiment som sjunker utanför fartyget

Lånat från sjöfartsteknik

Fartyg har vattentäta bulkväggar: vertikala väggar som delar upp skrovet i kompartiment. Ett kompartiment kan översvämmas utan att fartyget sjunker; ett annat kan misslyckas utan att det påverkar övriga.

Fördelade system låter samma ord och samma idé.

Bulkväggs mönster: isolera resurser per beroende. En tjänst som anropar tre nedströms-API:er använder tre separata anslutningspools, tre separata trådpooler, tre separata återförsäljningsbudgetar. Ett nedströms-API som är långsamt eller misslyckas kan inte konsumera de resurser som är allokerade för de andra två.

Utan bulkväggar: ett långsamt beroende tär ut delade trådpoolen; anrop till andra beroenden blockeras och väntar på trådar; hela tjänsten blir otillgänglig.

Med bulkväggar: ett långsamt beroende tär ut i sitt eget pool; anrop till det misslyckas direkt; anrop till andra beroenden fortsätter normalt; explosionens spridning hålls begränsad till det misslyckade beroendet.

Kretslösare

Kretslösare mönster: ett tillståndsinriktat förskott kring ett nedströmsberoende som spårar felriktning. Tre tillstånd:

- Stängt (normalt): anrop passerar genom. Fel räknas.

- Öppet (trippat): efter en felgräns (säg, 50% fel i de senaste 30 sekunderna), öppnar kretslösaren. Anrop misslyckas omedelbart utan att försöker beroendet. Sparar kallaren från att slösa arbete; sparar beroendet från att ta emot last medan det är sjuk.

- Halvöppen (testerande): efter en avkopplingsperiod, låter kretslösaren låta en liten andel anrop genom. Om de lyckas, stänger den igen till normalt. Om de misslyckas, öppnar den igen för en annan avkopplingsperiod.

Nyckelinsikten: kretslösaren förebygger slöseri med ansträngning under känd-osund period, & ger nedströms en chans att återhämta sig utan fortsatt last.

Bulkväggar begränsar explosionens spridning. Kretslösare förebygger att explosionen fortsätter att bestå.

Begränsa explosionens spridning

Ditt API-tjänst anropar fyra nedströms-tjänster: Användartjänst, Rekommendationstjänst, Meddelandetjänst och en tredjeparts betalnings-API. Laget har hört att 'Rekommendationstjänsten har varit en aning osäker' och vill säkerställa att när den misslyckas, fortsätter resten av systemet fungera frisk.

Idag använder tjänsten en enda delad trådpool på 200 trådar och en enda delad HTTP-anslutningspool. Alla fyra nedströms tävlar om dessa resurser. Det finns inga kretsgångar.

Designa en Felmodsanalys

Sammanfattning

Du har lärt dig att upptäcka SPOFs genom inspektion, identifiera kaskadfelsmönster, skilja på utlösande fel och dold fel när du läser en postmortem, skriva skuldlösa åtgärdsobjekt över förebyggande / upptäckt / återhämtning och begränsa skaderadien med bulkheads + kretsgångar + smidig nedgång.

Använd alla fem.

Ditt lag är på väg att lansera en ny tjänst, search.example.com, som beror på tre nedströms-tjänster: en primärsökindex (index.example.com), en analytiktjänst (analytics.example.com) och en rekommendationstjänst (recs.example.com). Laget vill att du ska leda en 'felmodsanalys' före lansering.

Var detta kurs går vidare

Var detta kurs går vidare

Du kan nu upptäcka en SPOF, identifiera en kaskad, läsa en postmortem produktivt, skriva skuldlösa åtgärdsobjekt och begränsa skaderadien genom design.

Den sista lektionen i detta kurs (cs_distsys_observability_and_capacity) undervisar om vad du ska mäta så att du kan upptäcka att ett problem inträffar innan användarna gör det. Hälskontroller, versionsändpunkter, de fyra gyllene signalerna på en proxy-nivå och hur ökade kapacitetsbeslut är kopplade till observerade data.

Kompletterande lektion: geometry_of_failure_modes_and_blast_radius undersöker mellanhetens centralitet (vilken grafnod är flaskhalsen) och minskärvärde (gränsen för spridningens radiuss).

Bra jobbat. Vidare.