Bemærk. overs.: Denne artikel fortsætter en stor serie af artikler fra AWS teknologievangelist Adrian Hornsby, som sætter sig for at forklare på en enkel og overskuelig måde vigtigheden af eksperimentering for at afbøde konsekvenserne af fejl i it-systemer.
"Hvis du undlader at forberede en plan, så planlægger du at fejle." - Benjamin Franklin
В I denne serie af artikler introducerede jeg begrebet kaosteknik og forklarede, hvordan det hjælper at finde og rette fejl i systemet, før de fører til produktionsfejl. Det diskuterede også, hvordan kaosteknik fremmer positive kulturelle forandringer i organisationer.
I slutningen af den første del lovede jeg at tale om "værktøjer og metoder til at introducere fejl i systemer." Ak, mit hoved havde sine egne planer i denne henseende, og i denne artikel vil jeg forsøge at besvare det mest populære spørgsmål, der opstår blandt folk, der ønsker at komme ind i kaosteknik: Hvad skal man bryde først?
Godt spørgsmål! Han ser dog ikke ud til at være særlig generet af denne panda...
Lad være med at rode med kaos-pandaen!
Kort svar: Målret kritiske tjenester langs anmodningsstien.
Længere, men klarere svar: For at forstå, hvor du skal begynde at eksperimentere med kaos, skal du være opmærksom på tre områder:
- Kig på nedbrudshistorik og identificere mønstre;
- Beslut dig for kritiske afhængigheder;
- Brug den såkaldte overmodseffekt.
Det er sjovt, men denne del kunne lige så godt hedde "En rejse til selvopdagelse og oplysning". I den vil vi begynde at "lege" med nogle fede instrumenter.
1. Svaret ligger i fortiden
Hvis du husker, introducerede jeg i første del konceptet Correction-of-Errors (COE) - en metode, hvormed vi analyserer vores fejl - fejl i teknologi, proces eller organisation - for at forstå deres årsag(er) og forebygge gentagelse i fremtiden. Generelt er det her du skal starte.
"For at forstå nutiden skal du kende fortiden." — Carl Sagan
Se på historien om fiaskoer, tag dem i COE eller postmortems og klassificer dem. Identificer almindelige mønstre, der ofte fører til problemer, og stil dig selv følgende spørgsmål for hver COE:
"Kunne dette have været forudsagt og derfor forhindret ved fejlindsprøjtning?"
Jeg husker en fiasko tidligt i min karriere. Det kunne nemt have været forhindret, hvis vi havde udført et par simple kaoseksperimenter:
Under normale forhold reagerer backend-instanser på sundhedstjek fra ). ELB bruger disse kontroller til at omdirigere anmodninger til sunde tilfælde. Når det viser sig, at en instans er "usund", holder ELB op med at sende anmodninger til den. En dag, efter en vellykket markedsføringskampagne, steg mængden af trafik, og backends begyndte at reagere på sundhedstjek langsommere end normalt. Det skal siges, at disse sundhedstjek var , det vil sige, at afhængighedernes tilstand blev kontrolleret.
Alt var dog fint i et stykke tid.
Så, allerede under temmelig stressende forhold, begyndte et af tilfældene at udføre en ikke-kritisk, regulær ETL cron-opgave. Kombinationen af høj trafik og cronjob skubbede CPU-udnyttelsen til næsten 100 %. CPU-overbelastning bremsede yderligere svar på sundhedstjek, så meget, at ELB besluttede, at instansen oplevede ydeevneproblemer. Som forventet holdt balanceren op med at distribuere trafik til den, hvilket igen førte til en stigning i belastningen på de resterende instanser i gruppen.
Pludselig begyndte alle andre tilfælde også at fejle sundhedstjekket.
At starte en ny instans krævede download og installation af pakker og tog meget længere tid, end det tog ELB at deaktivere dem - en efter en - i autoskaleringsgruppen. Det er klart, at hele processen snart nåede et kritisk punkt, og applikationen styrtede ned.
Så har vi for altid forstået følgende punkter:
- Installation af software, når du opretter en ny instans, tager lang tid; det er bedre at foretrække den uforanderlige tilgang og .
- I komplekse situationer bør svar på sundhedstjek og ELB prioriteres - det sidste du ønsker er at komplicere livet for de resterende tilfælde.
- Lokal caching af sundhedstjek hjælper meget (selv i nogle få sekunder).
- I en vanskelig situation, lad være med at køre cron-opgaver og andre ikke-kritiske processer – spar ressourcer til de vigtigste opgaver.
- Ved autoskalering skal du bruge mindre forekomster. En gruppe på 10 små eksemplarer er bedre end en gruppe på 4 store; hvis et tilfælde mislykkes, vil 10% af trafikken i det første tilfælde blive fordelt på 9 point, i det andet - 25% af trafikken over tre point.
således kunne dette have været forudset og derfor forhindret ved at indføre problemet?
Jaog på flere måder.
For det første ved at simulere højt CPU-forbrug ved hjælp af værktøjer som f.eks eller :
❯ stress-ng --matrix 1 -t 60s
stress-af
For det andet ved at overbelaste instansen med og andre lignende hjælpeprogrammer:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Eksperimenterne er relativt enkle, men kan give noget godt stof til eftertanke uden at skulle igennem stresset af en reel fiasko.
Men stop ikke der. Prøv at gengive nedbruddet i et testmiljø og tjek dit svar på spørgsmålet "Kunne dette have været forudset og derfor forhindret ved at indføre en fejl?" Dette er et mini-kaos-eksperiment inden for et kaos-eksperiment for at teste antagelser, men starter med en fiasko.
Var det en drøm, eller skete det virkelig?
Så studer historien om fiaskoer, analyser EOC, tag og klassificer dem efter "hitradius" - eller mere præcist, antallet af kunder, der er berørt - og kig derefter efter mønstre. Spørg dig selv, om dette kunne have været forudsagt og forhindret ved at introducere problemet. Tjek dit svar.
Skift derefter til de mest almindelige mønstre med det største udvalg.
2. Byg et afhængighedskort
Brug et øjeblik på at tænke over din ansøgning. Er der et klart kort over dets afhængigheder? Ved du, hvilken indflydelse de vil have, hvis der er en fiasko?
Hvis du ikke er særlig fortrolig med din applikations kode, eller den er blevet meget stor, kan det være svært at forstå, hvad koden gør, og hvad dens afhængigheder er. At forstå disse afhængigheder og deres mulige indvirkning på applikationen og brugerne er afgørende for at vide, hvor man skal starte med kaosteknik: udgangspunktet er komponenten med den største påvirkningsradius.
At identificere og dokumentere afhængigheder kaldes "opbygning af et afhængighedskort» (afhængighedskortlægning). Dette gøres typisk for applikationer med en stor kodebase ved hjælp af kodeprofileringsværktøjer. (kode profilering) og instrumentering (instrumentering). Du kan også bygge et kort ved at overvåge netværkstrafikken.
Imidlertid er ikke alle afhængigheder ens (hvilket komplicerer processen yderligere). Nogle kritisk, Andet - sekundær (i hvert fald i teorien, da nedbrud ofte opstår på grund af problemer med afhængigheder, der blev betragtet som ikke-kritiske).
Uden kritiske afhængigheder kan tjenesten ikke fungere. Ikke-kritiske afhængigheder"burde ikke» at påvirke servicen i tilfælde af et fald. For at forstå afhængigheder skal du have en klar forståelse af de API'er, der bruges af din applikation. Dette kan være meget sværere, end det ser ud til - i hvert fald for store applikationer.
Start med at gennemgå alle API'er. Fremhæv mest væsentlig og kritisk. Tage зависимости fra kodelageret, tjek det ud forbindelseslogfiler, se derefter dokumentation (selvfølgelig, hvis den findes - ellers har du stadigоstørre problemer). Brug værktøjerne til profilering og sporing, filtrere eksterne opkald fra.
Du kan bruge programmer som f.eks netstat - et kommandolinjeværktøj, der viser en liste over alle netværksforbindelser (aktive sockets) i systemet. Skriv f.eks. for at få vist alle aktuelle forbindelser:
❯ netstat -a | more
I AWS kan du bruge (flowlogs) VPC er en metode, der giver dig mulighed for at indsamle information om IP-trafik, der går til eller fra netværksgrænseflader i en VPC. Sådanne logfiler kan også hjælpe med andre opgaver - for eksempel at finde et svar på spørgsmålet om, hvorfor bestemt trafik ikke når frem til instansen.
Du kan også bruge . X-Ray giver dig mulighed for at få detaljeret, "ultimativ" (ende til ende) oversigt over anmodninger, når de bevæger sig gennem applikationen, og opbygger også et kort over applikationens underliggende komponenter. Meget praktisk, hvis du skal identificere afhængigheder.
AWS X-Ray konsol
Et netværksafhængighedskort er kun en delvis løsning. Ja, det viser hvilken applikation der kommunikerer med hvilken, men der er andre afhængigheder.
Mange applikationer bruger DNS til at oprette forbindelse til afhængigheder, mens andre kan bruge serviceopdagelse eller endda hårdkodede IP-adresser i konfigurationsfiler (f.eks. /etc/hosts).
Du kan f.eks. oprette via iptables og se hvad der går i stykker. For at gøre dette skal du indtaste følgende kommando:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS sort hul
Hvis /etc/hosts eller andre konfigurationsfiler, finder du IP-adresser, som du ikke ved noget om (ja, det sker desværre også), du kan komme til undsætning igen iptables. Lad os sige, at du opdagede 8.8.8.8 og ved ikke, at dette er Googles offentlige DNS-serveradresse. Ved hjælp af iptables Du kan blokere indgående og udgående trafik til denne adresse ved at bruge 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"
Lukke adgang
Den første regel sletter alle pakker fra Googles offentlige DNS: ping virker, men pakker returneres ikke. Den anden regel dropper alle pakker, der stammer fra dit system, mod Googles offentlige DNS - som svar på ping vi får Operation ikke tilladt.
Bemærk: i dette særlige tilfælde ville det være bedre at bruge whois 8.8.8.8, men dette er blot et eksempel.
Vi kan gå endnu dybere ned i kaninhullet, for alt, hvad der bruger TCP og UDP, afhænger faktisk også af IP. I de fleste tilfælde er IP bundet til ARP. Glem ikke firewalls...
Hvis du tager den røde pille, bliver du i Eventyrland, og jeg skal vise dig, hvor dybt kaninhullet går."
En mere radikal tilgang er at koble fra biler en efter en og se hvad der er gået i stykker... bliv en "kaosabe." Selvfølgelig er mange produktionssystemer ikke designet til sådan et brute force angreb, men det kan i det mindste prøves i et testmiljø.
At bygge et afhængighedskort er ofte en meget langvarig opgave. Jeg talte for nylig med en klient, der brugte næsten 2 år på at udvikle et værktøj, der semi-automatisk genererer afhængighedskort til hundredvis af mikrotjenester og kommandoer.
Resultatet er dog yderst interessant og brugbart. Du vil lære meget om dit system, dets afhængigheder og operationer. Igen, vær tålmodig: det er selve rejsen, der betyder mest.
3. Pas på overmod
"Den, der drømmer om hvad, tror på det." — Demosthenes
Har du nogensinde hørt om overmodseffekt?
Ifølge Wikipedia er overkonfidenseffekten "en kognitiv skævhed, hvor en persons tillid til deres handlinger og beslutninger er væsentligt større end den objektive nøjagtighed af disse domme, især når tillidsniveauet er relativt højt."
Baseret på instinkt og erfaring...
Efter min erfaring er denne forvrængning et godt hint om, hvor man skal starte med kaosteknik.
Pas på den oversikre operatør:
Charlie: "Denne ting er ikke faldet i fem år, alt er fint!"
Crash: "Vent... jeg er der snart!"
Bias som følge af overmod er en snigende og endda farlig ting på grund af de forskellige faktorer, der påvirker det. Dette gælder især, når teammedlemmer har hældt deres hjerter i en teknologi eller brugt meget tid på at "fikse" den.
Opsummering
Søgningen efter et udgangspunkt for kaosteknik giver altid flere resultater end forventet, og teams, der begynder at bryde ting for hurtigt, mister af syne den mere globale og interessante essens af (kaos-)ingeniørarbejde - kreativ brug videnskabelige metoder и empirisk bevis til design, udvikling, drift, vedligeholdelse og forbedring af (software)systemer.
Dette afslutter anden del. Skriv venligst anmeldelser, del meninger eller bare klap i hænderne . I næste del I virkelig Jeg vil overveje værktøjer og metoder til at introducere fejl i systemer. Indtil!
PS fra oversætteren
Læs også på vores blog:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com