De Drie Foutconcepten Waarvan Je Weet
Welkom
Verspreide systemen falen in patronen. Zodra je de patronen kent, wordt elk postmortem een herkenningsoefening in plaats van een raadsel.
Drie concepten dekken het merendeel van wat telt in productiefoutanalyse:
Enige punt van fout (SPOF): een component wiens falen een groter systeem laat zakken. Vaak verborgen: de DNS-server die iedereen op aarde afhankelijk is van; het certificaat dat alles herstelt tegen; de enige database-master.
Ketsende fout: het falen van een component dat een ander trekt aan, wat een ander trekt aan, wat een ander trekt aan. Een traag database veroorzaakt time-outs in de API-taal, wat time-outs in de API-taal veroorzaakt.
Explosieve radiële: hoeveel van het systeem gaat kapot wanneer een stukje faalt. Architecturale keuzes binden of onbinden de straal. Een SPOF heeft ongebonden radiële. Een bulkgekitte service heeft gebonden radiële.
Na het voltooien van deze les zal je:
- Een SPOF in een architectuur identificeren door inspectie
- Herkennen van ketsende fout patronen: donderende kudde, herhalingsstorm, wachtrij van de dood
- Lezen van een echt tijdslijn & scheiden van de trigger van de latent defect die de trigger blootlegde
- Schrijven van schuldloze actiepunten die systemen in plaats van mensen raken, met preventie / detectie / herstel
- Redeneren over bulkheads & schakelkernen als explosieve-radiële-begrenzende instrumenten
Spot de Enige Punt van Fout
Laaggelegen Architectuur Inspectie
Overweeg een klein webarchitectuur:
- DNS: api.example.com -> enkel nameserver IP 203.0.113.10 gehost door een enkele DNS-provider
- CDN: enkele CDN-leverancier voor api.example.com
- Ingress: twee reverse proxy machines achter een load balancer
- Achtergrond: zes API-replica's in twee beschikbaarheidzones (drie per zone)
- Database: een primaire + een leesslave, in dezelfde beschikbaarheidzone
- Cache: Redis cluster, drie knopen verspreid over dezelfde twee beschikbaarheidzones
Vraag: welke componenten zijn SPOFs? Hint: SPOFs zijn niet altijd de duidelijke 'enkele machine' soort. Een cluster van drie machines allemaal in dezelfde beschikbaarheidzone is een SPOF voor dat zones falen.
Drie Klassieke Cascadepatronen
Fouten Reizen Door Afhankelijkheden
Patroon 1: Donderend hert. Een gedeelde bron (cache, sleutel, database) faalt of herstart. Elke client die daarop vertrouwde, herstart. De golf overweldigt wat weer opkomt; de herstarts stapelen zich sneller op dan de herstel kan opnemen; de herstelcompletering.
Patroon 2: Herstartstorm. Een neerstreamdienst vertraagt. Bovenaanroepers, in plaats van te falien
Patroon 3: Doodlopende wachtrij. Een verwerkingswachtrij met geen backpressure ontvangt sneller dan het verwerkt. De wachtrij groeit onbegrensd. Geheugen raakt uitgeput; de consument crasht; herstart; vindt een nog grotere wachtrij; crasht opnieuw.
Gemeenschappelijke draad: een kleine aanvankelijke verstoring activeert een positieve terugkoppelingssluis. Het systeem eigen reactie versterkt de fout in plaats van het te dempen.
Dempende Mechanismen
Exponentieel teruglopend met ruis. Clients die herstartwachten, wachten langer elke keer, met willekeurige afwijking. Voorkomt gesynchroniseerde herstartgolven.
Sluipnet. Een aanroeper houdt de neerfalingssnelheid van de downstream bij. Boven een drempel, stopt de aanroeper met het bellen gedurende een afkoelingsperiode & mislukt meteen aan eigen verzoeken in plaats daarvan. Voorkomt verspilde inspanningen, laat de downstream herstellen.
Bulkhoofd. Isoleren van resources per afhankelijkheid. Verbindingspoel A voor database, aparte verbindingspoel B voor cache. Een trage database kan niet alle connecties verhongeren; cache oproepen blijven doorgaan.
Lastvermindering. Wanneer overbelast, draaien verzoeken op de rand in plaats van ze te accepteren en langzaam te falien
Terugdrukking. Wanneer overbelaste producenten wanneer consumenten niet kunnen bijhouden. Wachtrijen worden begrensd; verzenders blokkeren; het oorspronkelijke bron van werk voelt de weerstand.
Diagnose een Cascade
Een teams API-tier smelt tijdens een routine database failover. Tijdbalk:
- 14:00:00 — operator promoot de standby database. Geplande onbeschikbaarheid: ~10 seconden.
- 14:00:08 — primaire onbeschikbaar. API-tier vragen beginnen te mislukken met databaseverbinding fouten.
- 14:00:08 — API-tier herhaalt (standaardconfiguratie: 5 herhalingspogingen, geen backoff, 100 milliseconden uit elkaar).
- 14:00:11 — standby wordt gepromoot, accepteert nieuwe verbindingen.
- 14:00:11 — API-tier opent duizenden nieuwe databaseverbindingen tegelijkertijd (elk replica × elke gelijktijdige aanvraag × elke herhaalpoging).
- 14:00:13 — nieuwes primair's verbindingspool is uitgeput; nieuwe verbindingen worden afgewezen.
- 14:00:13-14:05:00 — API-tier replicas uitputten hun verbindingspools, werpen uitzonderingen op, herstart, herhalen.
- 14:05:00 — operator stopt manueel API-tier verkeer; database stabiliseert.
- 14:10:00 — geleidelijke verkeersherstel voltooid. Totaal uitval: ~10 minuten (tegenover verwachte ~10 seconden).
DNS SERVFAIL: Twee Samensmelende Defecten
Een Echte-Vorm Postmortem
Wat volgt is een gezuiverde versie van een echt incident. Bedrijfnamen gewijzigd, IPs geanonimiseerd; de vorm, de tijdlijn & de lessen zijn echt.
Samenvatting
De site example.com gaf SERVFAIL uit vanuit alle openbare DNS-resolvers voor ongeveer 3-4 uur. Alle andere 46 zones op dezelfde DNS-master waren ongemoeid. Oorzaak: twee samensmelende defecten.
1. Vendor A (een secundaire DNS-leverancier) voegde een nieuwe interne sync-IP toe die niet in de primaire's allow-axfr-ips toegestane lijst stond.
2. De example.com zone had een jarenoude RFC-breukende CNAME-conflict (demo.example.com had zowel CNAME- als MX/TXT-records op hetzelfde label) die Vendor A deed weigeren met de zone op verse AXFR.
Tijdbalk (UTC)
- ~15:00 — Vendor A voegt nieuwe sync-IP 198.51.100.42 toe aan hun infrastructuur
- 15:02 — eerste AXFR-out geweigerd voor 198.51.100.42 verschijnt in primaire DNS-logboeken (geen waarschuwing op deze signaal)
- ~18:00 — SOA verloop bereikt; Vendor A gooit example.com zone uit cache
- ~18:30 — SERVFAIL extern gedetecteerd
- ~19:45 — oorzaak geïdentificeerd
- 20:00 — 198.51.100.42 toegevoegd aan allow-axfr-ips; primaire herstart
- 20:05 — NOTIFY verzonden; AXFR gestart; zone HEEFT nog steeds SERVFAIL (CNAME-conflict)
- 20:07 — check-zone onthult 1 fout: CNAME-conflict op demo.example.com
- 20:09 — CNAME vervangen door A-record; zonecontrole schoon (0 fouten)
- 20:10 — NOTIFY verzonden; AXFR voltooid; Vendor A begint zone te serveren
- 20:11 — dig @8.8.8.8 example.com A retourneert juiste IP — GEFIXE
Waarom alleen example.com?
Alle 47 zones delen dezelfde DNS primaire. De AXFR IP blok beïnvloedde alle zones. Maar alleen example.com had de CNAME-conflict en alleen example.com had op dat moment een nieuwe AXFR nodig toen de weigering van kracht was. Overige zones hadden al geüpdatet voordat de weigering werd toegepast of hadden nog niet nodig om te updaten.
Latente gebrek
Het CNAME-conflict op demo.example.com bestond al jaren. Het werkte omdat de primaire de zone vanuit zijn database serveerde (ontvankelijk over ten aanzien van RFC-overtraden) en Vendor A serveerde vanuit verouderde gecacheerde data van voor de introductie van de overtrading. Toen Vendor A zijn cache verloor en nieuwere data nodig had, kwam de overtrading aan het licht.
Aanwijzing
Vendor A voegde stilzwijend een nieuwe synchronisatie-IP toe. De primaire's toegestane lijst bevatte het niet. AXFR geweigerd. Drie uur later (SOA verloop) goot Vendor A de zone. Het latente gebrek kwam aan het licht toen het systeem probeerde te herstellen.
Schriftelijke actiepunten zonder schuld
Schuldloos: Doel op systemen, niet op mensen
Een schuldloos actiepunt noemt iets dat de systeem anders zou moeten doen, niet iets dat een persoon anders zou moeten doen. 'Opleiden van de operator' is schuldig. 'Voeg een geautomatiseerde controle toe die dit vangt voordat het wordt geïmplementeerd' is schuldloos.
Goede schuldloze actiepunten groeperen zich in drie dimensies:
- Voorkoming: maak het slechte iets moeilijker of onmogelijk
- Detectie: merkt het eerder op als het gebeurt
- Herstel: beperkt de schade wanneer het gebeurt
Elk item moet (1) de specifieke systeemwijziging, (2) het eigen team en (3) de dimensie noemen waar het voor dient.
Kompartimenten die Zinken Zonder het Schip
Geleend van Scheepsbouwkunde
Schepen hebben waterdichte deuren: verticale wanden die de romp in compartimenten verdelen. Één compartiment kan overstromen zonder dat het schip zinkt; een ander kan falen zonder invloed op de rest.
Gebruik van distributiesystemen leent hetzelfde woord & dezelfde idee.
Bulkhoofdpatronen: isolatie van resources per afhankelijkheid. Een service die drie downstream-API's aanroept, gebruikt drie aparte connection pools, drie aparte threadpools, drie aparte herstelpatronen. Een downstream die langzaam of faalt, kan niet de resources van de andere twee gebruiken.
Zonder bulkhoofden: één langzame afhankelijkheid verbruikt het gedeelde threadpool; aanroepen naar andere afhankelijkheden blokkeren totdat er threads beschikbaar zijn; het hele service wordt onbereikbaar.
Met bulkhoofden: één langzame afhankelijkheid verbruikt haar eigen pool; aanroepen naar haar falen snel; aanroepen naar andere afhankelijkheden verder normaal; de explosieve straal blijft beperkt tot de falende afhankelijkheid.
Stroomonderbreker
Stroomonderbrekerpatroon: een stateful wrapper rond een downstream-afhankelijkheid die het faluresignaal telt. Drie staten:
- Gesloten (normaal): aanvragen gaan door. Fouten geteld.
- Open (uitgezet): na een faluresignaal (bijvoorbeeld, 50% fouten in de laatste 30 seconden), opent de onderbreker. Aanvragen falen meteen zonder de afhankelijkheid te proberen. Bespaart de aanroeper van nutteloos werk; bespaart de afhankelijkheid van belasting terwijl het ongezond is.
- Half-open (testend): na een afkoelingsperiode laat de onderbreker een kleine fractie van aanvragen door. Als ze slagen, sluit het weer normaal. Als ze falen, opent het weer voor een andere afkoelingsperiode.
Het sleutelidee: de stroomonderbreker voorkomt nutteloze inspanningen tijdens bekende ongezonde periodes & geeft de downstream een kans om te herstellen zonder voortdurende belasting.
Bulkhoofden begrenzen de explosieve straal. Stroomonderbrekers voorkomen dat de explosie zich voortzet.
Begrensd de Explosieve Straal
Je API-service service belt 4 downstream services: User Service, Recommendation Service, Notification Service & een derde part Payment API. Het team heeft gehoord 'de Recommendation Service is een beetje onbetrouwbaar' en wil ervoor zorgen dat wanneer het faalt, het overige deel van het systeem gezond blijft.
Vandaag maakt de service een enkele gedeelde thread pool van 200 draad en een enkele gedeelde HTTP verbinding pool. Alle vier downstreams concurreren voor deze middelen. Er zijn geen circuit breakers.
Ontwerp een Foutmodus Review
Synthese
Je hebt geleerd SPOFs door inspectie te detecteren, kettingreactiespatronen te herkennen, de trigger van een latent gebrek te scheiden bij het lezen van een postmortem, schuldloze actie-items over voorkoming / detectie / herstel te schrijven, en het bereik van een ongeval te binden met bulkheads + circuit breakers + zachte landing.
Pas alle vijf toe.
Je team lanceert een nieuw service search.example.com die afhankelijk is van drie downstream services: een primaire zoekindex (index.example.com), een analytische service (analytics.example.com) en een aanbevolen service (recs.example.com). Het team wil dat je een 'foutmodus review' leidt voordat het gelanceerd wordt.
Waar deze cursus verdergaat
Waar deze cursus verdergaat
Je kunt nu een SPOF herkennen, een kettingreactie herkennen, een postmortem productief lezen, schuldloze actie-items schrijven en het bereik van een ongeval door ontwerp te binden.
Het laatste les in deze cursus (cs_distsys_observability_and_capacity) leert wat je moet meten om te ontdekken dat een probleem zich voordoet voordat gebruikers het merken. Gezondheidcontroles, versie-eindpunten, de vier gouden signalen op proxy-niveau & hoe beslissingen over piekcapaciteit terug te voeren zijn op geobserveerde gegevens.
Companion lesson: geometry_of_failure_modes_and_blast_radius onderscheidt tussenheidscentrualiteit (welke grafknoop de flesneks is) & min-cut (de bovengrond voor de explosieradius).
Goed gedaan. Voorwaarts.