Tre Klassiska Kaskaderande Mönster

Fel Sprider Sig Genom Beroenden

Mönster 1: Dånande hjord. En delad resurs (cacheminne, lås, databas) misslyckas eller startar om igen. Varje klient som beroende på den gör om försöket samtidigt. Floden översvämmar det som kommer upp igen; återförsöken störtar snabbare än återhämtningen kan absorbera dem; återhämtningen avslutas aldrig.

Mönster 2: Retriesånda. En nedströms service sakta ner. Överordnade anropare, i stället för att misslyckas, gör om försöket. De återförsök multiplicerar den ursprungliga belastningen. Den sakta servicen sakta ner ytterligare, vilket utlöser fler återförsök. Till slut överstiger belastningen ens en frisk version av tjänsten.

Mönster 3: Dödens kö. En bearbetningskö med ingen baktryckning tar emot snabbare än den bearbetar. Kön växer obegränsat. Minne uttöms; konsumenten kraschar; startar om; hittar en fortfarande större kö; kraschar igen.

Gemensamt tråd: En liten initial störning utlöser ett positivt återkopplingsloop. Systemets egen respons förstärker felet i stället för att dämpa det.

Dämpningsmekanismer

Exponentiell backoff med stövel. Klienter som gör om väntar längre varje gång, med slumpmässig avvikelse. Förhindrar samordnade återförsöksvågor.

Cirkelbrytare. En anropare spårar nedströms felriktning. Bortom ett tröskelvärde avbryter den anropet för en avkopplingsperiod & avbryter omedelbart sina egna begäranden.

Bulkhead. Isolera resurser per beroende. Anslutningspool A för databas, separat anslutningspool B för cacheminne. En långsam databas kan inte stjäla alla anslutningar; cachekall fortsätter.

Lastavledning. När överbelastad, släng begäranden på kanten i stället för att acceptera dem & misslyckas långsamt. En 429 på 1 ms är bättre än en 500 på 30 sekunder.

Baktryckning. Sakta ner producenter när konsumenter inte kan hålla. Köarna blir begränsade; skickarna blockeras; den ursprungliga källan till arbete känner av motståndet.

Diagnostera en Kaskad

En teams API-skikt smälter ner under en rutinmässig databashantering. Tidslinje:

- 14:00:00 — operatören upphöjer ståndby-databasen. Förväntad otillgänglighet: ~10 sekunder.

- 14:00:08 — primär otillgänglig. API-skiktets begäranden misslyckas med databasanslutningsfel.

- 14:00:08 — API-skiktet gör omfattande (standardkonfiguration: 5 försök, ingen backoff, 100 ms mellan varje försök).

- 14:00:11 — ståndby upphöjs, accepterar nya anslutningar.

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

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

- 14:00:13-14:05:00 — API-skiktets repliker tömmer sina anslutningspooler, kastar undantag, startar om, upprepar.

- 14:05:00 — operatören stoppar manuellt API-skiktets trafik; databasen stabiliseras.

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

DNS SERVFAIL: Två Samverkande Fel

En Riktig Form Postmortem

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

Sammanfattning

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

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

2. Zonen example.com hade en årsålders RFC-brytande CNAME-konflikt (demo.example.com hade både CNAME & MX/TXT poster på samma etikett) som orsakade Leverantör A att avvisa zonen vid ny AXFR.

Tidslinje (UTC)

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

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

- ~18:00 — SOA utgångsperiod nådd; Företag A tar bort example.com zonen från cacheminnet

- ~18:30 — SERVFAIL upptäcks externt

- ~19:45 — orsaken identifierad

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

- 20:05 — NOTIFY skickas; AXFR initieras; zonen ÄR fortfarande SERVFAIL (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 börjar serva zonen

- 20:11 — dig @8.8.8.8 example.com A returnerar rätt IP — UPPLÖST

Varför endast example.com?

Alla 47 zoner 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 fräsch AXFR när förbudet genomfördes. Övriga zoner hade redan uppdaterats före förbudet eller hade ännu inte behövt göra det.

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 om RFC-brott) och Företag A serverade från gammal cachad data från före införandet av brottet. När Företag A drog sitt cacheminne och behövde frisk data uppenbarade sig brottet.

Uppstart

Företag A tillsköt tyst ett nytt synk-IP. Primärets tillåtelselista innehöll inte det. AXFR nekas. Tre timmar senare (SOA utgångsperiod) drog Företag A ner zonen. Latenta fel uppenbarade sig när systemet försökte återhämta sig.

Skriv Blameless Action Items

Blameless: Mål för System, Inte Människor

Ett blameless action item namnger något som systemet bör göra annorlunda, inte något en person bör göra annorlunda. 'Utbildningsoperatören' är skuldbårande. 'Lägg till en automatiserad kontroll som upptäcker detta före distribution' är skuldfrämmande.

Goda blameless action items klusterar i tre dimensioner:

- Förebyggande: göra det dåliga svårare eller omöjligt

- Upptäckt: märker det tidigare om det inträffar

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

Varje objekt bör namnge (1) den specifika systemändringen, (2) ägande team och (3) dimensionen det tjänar.

Kompartiment som sjunker utan fartyget

Lånat från skeppsbyggnadsteknik

Fartyg har vattentäta bulkväggar: vertikala väggar som delar 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ådpools, tre separata återhämtningsbudgetar. Ett långsamt eller misslyckat nedströms kan inte använda de resurser som är tilldelade för de andra två.

Ingen bulkvägg: ett långsamt beroende tömmer det gemensamma trådpoolen; anrop till andra beroenden blockerar och väntar på trådar; hela tjänsten blir oförståelig.

Med bulkväggar: ett långsamt beroende tömmer sitt eget pool; anrop till det misslyckas genast; anrop till andra beroenden fortsätter normalt; sprickans spridning hålls begränsad till det misslyckade beroendet.

Kretsbräckare

Kretsbräckare mönster: ett tillståndsbaserat förskott kring ett nedströmsberoende som spårar felfrekvensen. Tre tillstånd:

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

- Öppet (släppt): efter ett feltröskelvärde (säg, 50% fel de senaste 30 sekunderna), öppnar kretsbräckaren. Anrop misslyckas genast utan att försöka beroendet. Sparar anroparen från att slösa bort arbete; sparar beroendet från att ta emot last medan det är ohälsosamt.

- Halvöppen (testerande): efter en avkopplingsperiod, låter kretsbräckaren en liten del av anropen genom. Om de lyckas, stänger den tillbaka till normalt. Om de misslyckas, öppnar den igen för en annan avkopplingsperiod.

Nyckelinsikten: kretsbräckaren förhindrar slöseri med ansträngning under känd-ohälsosamma perioder och ger nedströms en chans att återhämta sig utan fortsatt last.

Bulkväggar begränsar sprickans spridning. Kretsbräckare förhindrar att sprickan fortsätter att vara öppen.

Begränsa sprickans spridning

Ditt API-tjänst använder fyra nedströms-tjänster: User Service, Recommendation Service, Notification Service och en tredjepartsbetalnings-API. Laget har hört att 'Recommendation Service har varit lite osäker' och vill vara säkra på att systemet fungerar friskt om den fallerar.

Idag använder tjänsten en enda delad trådpool med 200 trådar och en enda delad HTTP-anslutningspool. De fyra nedströms-tjänsterna konkurrerar om dessa resurser. Det finns inga säkerhetskopior.

Designa en Felmodsanalys

Sammanfattning

Du har lärt dig att upptäcka SPOFs genom granskning, känna igen mönster för fel som sprider sig, skilja på utlösande fel och latenta fel när du läser en postmortem, skriva skuldbefriande åtgärdsförslag över förebyggande / upptäckt / återhämtning och begränsa spridning av fel med bulkheads + säkerhetskopior + försiktig nedgång.

Använd alla fem.

Ditt lag lanserar en ny tjänst search.example.com som är beroende av tre nedströms-tjänster: en primär sökalgoritm (index.example.com), en analytisk tjänst (analytics.example.com) och en rekommendations-tjänst (recs.example.com). Laget vill att du ska leda en 'felmodsanalys' innan lansering.

Vart Denna kurs Tar Sig

Vart Denna Kurs Tar Sig Nästa

Du kan nu upptäcka en SPOF, känna igen en spridning av fel, läsa en postmortem produktivt, skriva skuldbefriande åtgärdsförslag och begränsa spridning av fel genom design.

Den sista lektionen i detta kurs (cs_distsys_observability_and_capacity) lär dig vad du ska mäta så att du upptäcker att ett problem inträffar innan användare gör det. Hälsokontroller, versionsändpunkter, de fyra gyllene signalerna på en proxy-nivå och hur beslut om överskottskapacitet är kopplade till observerade data.

Kompletterande lektion: geometry_of_failure_modes_and_blast_radius utifrån mellanhetens centralitet (vilken grafnod som är flaska) & min-snitt (gränsen för spridningsradie).

Bra jobbat. Vidare.