Merk. overs.: Denne artikkelen fortsetter en flott serie med artikler fra AWS-teknologievangelisten Adrian Hornsby, som på en enkel og tydelig måte vil forklare viktigheten av eksperimentering for å dempe konsekvensene av feil i IT-systemer.
"Hvis du ikke klarer å forberede en plan, så planlegger du å mislykkes." - Benjamin Franklin
В I denne artikkelserien introduserte jeg begrepet kaosteknikk og forklarte hvordan det hjelper å finne og rette opp feil i systemet før de fører til produksjonsfeil. Den diskuterte også hvordan kaosteknikk fremmer positiv kulturell endring i organisasjoner.
På slutten av den første delen lovet jeg å snakke om "verktøy og metoder for å introdusere feil i systemer." Akk, hodet mitt hadde sine egne planer i denne forbindelse, og i denne artikkelen vil jeg prøve å svare på det mest populære spørsmålet som oppstår blant folk som ønsker å komme inn i kaosteknikk: Hva skal brytes først?
Flott spørsmål! Han ser imidlertid ikke ut til å være spesielt plaget av denne pandaen...
Ikke rot med kaospandaen!
Kort svar: Målrett kritiske tjenester langs forespørselsbanen.
Lengre, men klarere svar: For å forstå hvor du skal begynne å eksperimentere med kaos, vær oppmerksom på tre områder:
- Se på krasjhistorikk og identifisere mønstre;
- Bestemme kritiske avhengigheter;
- Bruk den såkalte overmotseffekt.
Det er morsomt, men denne delen kan like gjerne hete "En reise til selvoppdagelse og opplysning". I den vil vi begynne å "spille" med noen kule instrumenter.
1. Svaret ligger i fortiden
Hvis du husker, introduserte jeg i den første delen konseptet Correction-of-Errors (COE) - en metode som vi analyserer våre feil - feil i teknologi, prosess eller organisasjon - for å forstå årsaken(e) og forhindre gjentakelse i fremtiden. Generelt er det her du bør begynne.
"For å forstå nåtiden, må du kjenne fortiden." — Carl Sagan
Se på historien om feil, merk dem i COE eller postmortems og klassifiser dem. Identifiser vanlige mønstre som ofte fører til problemer, og still deg selv følgende spørsmål for hver COE:
"Kunne dette vært forutsagt og derfor forhindret ved feilinjeksjon?"
Jeg husker en fiasko tidlig i karrieren min. Det kunne lett vært forhindret hvis vi hadde utført et par enkle kaoseksperimenter:
Under normale forhold svarer backend-forekomster på helsesjekker fra ). ELB bruker disse sjekkene til å omdirigere forespørsler til sunne tilfeller. Når det viser seg at en instans er "usunn", slutter ELB å sende forespørsler til den. En dag, etter en vellykket markedsføringskampanje, økte trafikkvolumet og backends begynte å svare på helsesjekker saktere enn vanlig. Det skal sies at disse helsesjekkene var , det vil si at tilstanden til avhengighetene ble sjekket.
Men alt var bra en stund.
Så, allerede under ganske stressende forhold, begynte en av tilfellene å utføre en ikke-kritisk, vanlig ETL cron-oppgave. Kombinasjonen av høy trafikk og cronjob presset CPU-utnyttelsen til nesten 100 %. CPU-overbelastning bremset ytterligere svar på helsesjekker, så mye at ELB bestemte at forekomsten hadde ytelsesproblemer. Som forventet sluttet balansereren å distribuere trafikk til den, noe som igjen førte til en økning i belastningen på de gjenværende instansene i gruppen.
Plutselig begynte også alle andre instanser å mislykkes i helsesjekken.
Å starte en ny forekomst krevde nedlasting og installasjon av pakker og tok mye lengre tid enn det tok ELB å deaktivere dem - en etter en - i autoskaleringsgruppen. Det er klart at snart nådde hele prosessen et kritisk punkt og applikasjonen krasjet.
Da har vi for alltid forstått følgende punkter:
- Det tar lang tid å installere programvare når du oppretter en ny forekomst; det er bedre å foretrekke den uforanderlige tilnærmingen og .
- I komplekse situasjoner bør svar på helsesjekker og ELB prioriteres - det siste du vil er å komplisere livet for de gjenværende tilfellene.
- Lokal bufring av helsesjekker hjelper mye (selv for noen få sekunder).
- I en vanskelig situasjon, ikke kjør cron-oppgaver og andre ikke-kritiske prosesser - spar ressurser til de viktigste oppgavene.
- Ved autoskalering, bruk mindre forekomster. En gruppe på 10 små prøver er bedre enn en gruppe på 4 store; hvis en instans mislykkes, vil i det første tilfellet 10 % av trafikken fordeles over 9 poeng, i det andre - 25 % av trafikken over tre poeng.
således kunne dette vært forutsett, og derfor forhindret ved å introdusere problemet?
Ja, og på flere måter.
Først ved å simulere høy CPU-bruk ved å bruke verktøy som f.eks eller :
❯ stress-ng --matrix 1 -t 60s
stress-av
For det andre ved å overbelaste instansen med og andre lignende verktøy:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Eksperimentene er relativt enkle, men kan gi litt god tankevekker uten å måtte gå gjennom stresset med en reell fiasko.
Men ikke stopp der. Prøv å reprodusere krasjen i et testmiljø og sjekk svaret ditt på spørsmålet "Kunne dette vært forutsett og derfor forhindret ved å innføre en feil?" Dette er et mini-kaoseksperiment innenfor et kaoseksperiment for å teste antagelser, men starter med en fiasko.
Var det en drøm, eller skjedde det virkelig?
Så studer historien om feil, analyser COE, merk og klassifiser dem etter «treffradius» – eller mer nøyaktig, antall kunder som er berørt – og se etter mønstre. Spør deg selv om dette kunne vært forutsagt og forhindret ved å introdusere problemet. Sjekk svaret ditt.
Bytt deretter til de vanligste mønstrene med størst utvalg.
2. Bygg et avhengighetskart
Ta deg tid til å tenke over søknaden din. Finnes det et klart kart over avhengighetene? Vet du hvilken innvirkning de vil ha hvis det oppstår en feil?
Hvis du ikke er veldig kjent med applikasjonens kode eller den har blitt veldig stor, kan det være vanskelig å forstå hva koden gjør og hva dens avhengigheter er. Å forstå disse avhengighetene og deres mulige innvirkning på applikasjonen og brukerne er avgjørende for å vite hvor man skal begynne med kaosteknikk: utgangspunktet er komponenten med størst innvirkningsradius.
Å identifisere og dokumentere avhengigheter kalles "bygge et avhengighetskart» (avhengighetskartlegging). Dette gjøres vanligvis for applikasjoner med en stor kodebase ved bruk av kodeprofileringsverktøy. (kodeprofilering) og instrumentering (instrumentering). Du kan også bygge et kart ved å overvåke nettverkstrafikken.
Imidlertid er ikke alle avhengigheter like (noe som kompliserer prosessen ytterligere). Noen kritisk, annet - sekundær (i hvert fall i teorien, siden krasj ofte oppstår på grunn av problemer med avhengigheter som ble ansett som ikke-kritiske).
Uten kritiske avhengigheter kan ikke tjenesten fungere. Ikke-kritiske avhengigheter"skal ikke» å påvirke tjenesten ved fall. For å forstå avhengigheter må du ha en klar forståelse av API-ene som brukes av applikasjonen din. Dette kan være mye vanskeligere enn det ser ut til - i hvert fall for store applikasjoner.
Start med å gå gjennom alle API-ene. Fremhev mest betydningsfull og kritisk... Ta avhengig av fra kodelageret, sjekk det ut tilkoblingslogger, deretter se dokumentasjon (selvfølgelig, hvis det finnes - ellers har du fortsattоstørre problemer). Bruk verktøyene til å profilering og sporing, filtrere ut eksterne samtaler.
Du kan bruke programmer som netstat - et kommandolinjeverktøy som viser en liste over alle nettverkstilkoblinger (aktive sockets) i systemet. For å liste opp alle gjeldende tilkoblinger, skriv for eksempel:
❯ netstat -a | more
I AWS kan du bruke (flytlogger) VPC er en metode som lar deg samle informasjon om IP-trafikk som går til eller fra nettverksgrensesnitt i en VPC. Slike logger kan også hjelpe med andre oppgaver – for eksempel å finne svar på spørsmålet om hvorfor viss trafikk ikke når instansen.
Du kan også bruke . X-Ray lar deg få detaljert, "ultimate" (ende til ende) oversikt over forespørsler når de beveger seg gjennom applikasjonen, og bygger også et kart over applikasjonens underliggende komponenter. Veldig praktisk hvis du trenger å identifisere avhengigheter.
AWS røntgenkonsoll
Et nettverksavhengighetskart er bare en delvis løsning. Ja, det viser hvilken applikasjon som kommuniserer med hvilken, men det er andre avhengigheter.
Mange applikasjoner bruker DNS for å koble til avhengigheter, mens andre kan bruke tjenesteoppdagelse eller til og med hardkodede IP-adresser i konfigurasjonsfiler (f.eks. /etc/hosts).
Du kan for eksempel lage via iptables og se hva som går i stykker. For å gjøre dette, skriv inn følgende kommando:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS svart hull
Dersom /etc/hosts eller andre konfigurasjonsfiler, finner du IP-adresser du ikke vet noe om (ja, dessverre, dette skjer også), du kan komme til unnsetning igjen iptables. La oss si at du oppdaget 8.8.8.8 og vet ikke at dette er Googles offentlige DNS-serveradresse. Ved bruk av iptables Du kan blokkere innkommende og utgående trafikk til denne adressen ved å bruke følgende kommandoer:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Stenger tilgang
Den første regelen sletter alle pakker fra Googles offentlige DNS: ping fungerer, men pakker returneres ikke. Den andre regelen slipper alle pakker som kommer fra systemet ditt til Googles offentlige DNS - som svar på ping vi får Operasjonen er ikke tillatt.
Merk: i dette spesielle tilfellet ville det være bedre å bruke whois 8.8.8.8, men dette er bare et eksempel.
Vi kan gå enda dypere ned i kaninhullet, for alt som bruker TCP og UDP avhenger faktisk også av IP. I de fleste tilfeller er IP knyttet til ARP. Ikke glem brannmurer...
Hvis du tar den røde pillen, blir du i Eventyrland, og jeg skal vise deg hvor dypt kaninhullet går."
En mer radikal tilnærming er å koble fra biler en etter en og se hva som er ødelagt... bli en "kaos-ape". Selvfølgelig er mange produksjonssystemer ikke designet for et slikt brute force-angrep, men det kan i det minste prøves i et testmiljø.
Å bygge et avhengighetskart er ofte en svært langvarig oppgave. Jeg snakket nylig med en klient som brukte nesten 2 år på å utvikle et verktøy som halvautomatisk genererer avhengighetskart for hundrevis av mikrotjenester og kommandoer.
Resultatet er imidlertid ekstremt interessant og nyttig. Du vil lære mye om systemet ditt, dets avhengigheter og operasjoner. Igjen, vær tålmodig: det er selve reisen som betyr mest.
3. Vokt dere for overmot
"Den som drømmer om hva, tror på det." — Demosthenes
Har du noen gang hørt om overmotseffekt?
I følge Wikipedia er oversikkerhetseffekten "en kognitiv skjevhet der en persons tillit til handlingene og beslutningene deres er betydelig større enn den objektive nøyaktigheten til disse dommene, spesielt når tillitsnivået er relativt høyt."
Basert på instinkt og erfaring...
Etter min erfaring er denne forvrengningen et godt hint om hvor du skal begynne med kaosteknikk.
Pass deg for den oversikre operatøren:
Charlie: "Denne tingen har ikke falt på fem år, alt er bra!"
Crash: "Vent... jeg kommer snart!"
Bias som en konsekvens av overmot er en lumsk og til og med farlig ting på grunn av de ulike faktorene som påvirker den. Dette gjelder spesielt når teammedlemmer har tømt hjertene sine i en teknologi eller brukt mye tid på å "fikse" den.
Oppsummering
Jakten på et utgangspunkt for kaosteknikk gir alltid flere resultater enn forventet, og team som begynner å bryte ting for raskt mister av syne den mer globale og interessante essensen av (kaos-)engineering - kreativ bruk vitenskapelige metoder и empirisk bevis for design, utvikling, drift, vedlikehold og forbedring av (programvare)systemer.
Dette avslutter den andre delen. Skriv anmeldelser, del meninger eller bare klapp i hendene . I neste del I virkelig Jeg vil vurdere verktøy og metoder for å introdusere feil i systemer. Før!
PS fra oversetter
Les også på bloggen vår:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com