Notera. transl.: Den här artikeln fortsätter en stor serie artiklar från AWS-teknikevangelisten Adrian Hornsby, som försöker förklara på ett enkelt och tydligt sätt vikten av att experimentera för att mildra konsekvenserna av fel i IT-system.
"Om du misslyckas med att förbereda en plan, då planerar du att misslyckas." - Benjamin Franklin
В I den här artikelserien introducerade jag begreppet kaosteknik och förklarade hur det hjälper att hitta och rätta till brister i systemet innan de leder till produktionsfel. Den diskuterade också hur kaosteknik främjar positiv kulturell förändring inom organisationer.
I slutet av den första delen lovade jag att prata om "verktyg och metoder för att introducera fel i system." Tyvärr, mitt huvud hade sina egna planer i detta avseende, och i den här artikeln kommer jag att försöka svara på den mest populära frågan som uppstår bland människor som vill komma in i kaosteknik: Vad ska man bryta först?
Bra fråga! Han verkar dock inte vara särskilt besvärad av denna panda...
Bråka inte med kaospandan!
Kort svar: Rikta in kritiska tjänster längs förfrågningsvägen.
Längre men tydligare svar: För att förstå var du ska börja experimentera med kaos, var uppmärksam på tre områden:
- Titta på kraschhistorik och identifiera mönster;
- Besluta om kritiska beroenden;
- Använd den sk övertroende effekt.
Det är roligt, men den här delen skulle lika gärna kunna kallas "En resa till självupptäckt och upplysning". I den kommer vi att börja "spela" med några coola instrument.
1. Svaret ligger i det förflutna
Om du kommer ihåg, i den första delen introducerade jag konceptet Correction-of-Errors (COE) - en metod genom vilken vi analyserar våra misstag - misstag i teknik, process eller organisation - för att förstå deras orsak(er) och förebygga återkommande i framtiden. Generellt sett är det här du bör börja.
"För att förstå nuet måste du känna till det förflutna." — Carl Sagan
Titta på historien om misslyckanden, tagga dem i COE eller postmortems och klassificera dem. Identifiera vanliga mönster som ofta leder till problem och ställ dig själv följande fråga för varje COE:
"Kunde detta ha förutsetts och därför förhindrats genom felinjektion?"
Jag minns ett misslyckande tidigt i min karriär. Det hade lätt kunnat förhindras om vi hade utfört ett par enkla kaosexperiment:
Under normala förhållanden svarar backend-instanser på hälsokontroller från ). ELB använder dessa kontroller för att omdirigera förfrågningar till friska instanser. När det visar sig att en instans är "ohälsosam" slutar ELB att skicka förfrågningar till den. En dag, efter en framgångsrik marknadsföringskampanj, ökade trafikvolymen och backends började svara på hälsokontroller långsammare än vanligt. Det ska sägas att dessa hälsokontroller var , det vill säga tillståndet för beroenden kontrollerades.
Allt var dock bra ett tag.
Sedan, redan under ganska stressiga förhållanden, började ett av fallen utföra en icke-kritisk, vanlig ETL cron-uppgift. Kombinationen av hög trafik och cronjob pressade CPU-utnyttjandet till nästan 100 %. CPU-överbelastning bromsade ytterligare svar på hälsokontroller, så mycket att ELB beslutade att instansen upplevde prestandaproblem. Som väntat slutade balansören att distribuera trafik till den, vilket i sin tur ledde till att belastningen på de återstående instanserna i gruppen ökade.
Plötsligt började även alla andra instanser misslyckas med hälsokontrollen.
Att starta en ny instans krävde nedladdning och installation av paket och tog mycket längre tid än det tog ELB att inaktivera dem - en efter en - i den automatiska skalningsgruppen. Det är klart att snart nådde hela processen en kritisk punkt och applikationen kraschade.
Då förstod vi för alltid följande punkter:
- Att installera programvara när du skapar en ny instans tar lång tid; det är bättre att ge företräde åt det oföränderliga tillvägagångssättet och .
- I svåra situationer bör svar på hälsokontroller och ELB prioriteras - det sista du vill är att komplicera livet för de återstående fallen.
- Lokal cachning av hälsokontroller hjälper mycket (även för några sekunder).
- I en svår situation, kör inte cron-uppgifter och andra icke-kritiska processer - spara resurser för de viktigaste uppgifterna.
- Använd mindre instanser vid automatisk skalning. En grupp på 10 små exemplar är bättre än en grupp på 4 stora; om en instans misslyckas, kommer i det första fallet 10% av trafiken att fördelas på 9 poäng, i det andra - 25% av trafiken över tre poäng.
Så, kunde detta ha förutsetts och därför förhindrats genom att införa problemet?
Jaoch på flera sätt.
Först genom att simulera hög CPU-användning med hjälp av verktyg som t.ex eller :
❯ stress-ng --matrix 1 -t 60s
stress-ng
För det andra genom att överbelasta instansen med och andra liknande verktyg:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Experimenten är relativt enkla, men kan ge lite god tankeställare utan att behöva gå igenom stressen av ett riktigt misslyckande.
Men sluta inte där. Försök att återskapa kraschen i en testmiljö och kontrollera ditt svar på frågan "Kunde detta ha förutsetts och därför förhindrats genom att införa ett fel?" Detta är ett mini-kaosexperiment inom ett kaosexperiment för att testa antaganden, men börjar med ett misslyckande.
Var det en dröm eller hände det verkligen?
Så studera historien om misslyckanden, analysera EOC, tagga och klassificera dem efter "träffradie" – eller mer exakt, antalet kunder som påverkas – och leta sedan efter mönster. Fråga dig själv om detta kunde ha förutsetts och förhindrats genom att introducera problemet. Kontrollera ditt svar.
Byt sedan till de vanligaste mönstren med störst utbud.
2. Bygg en beroendekarta
Ta en stund att tänka på din ansökan. Finns det en tydlig karta över dess beroenden? Vet du vilken inverkan de kommer att få om det blir ett misslyckande?
Om du inte är så bekant med din applikations kod eller om den har blivit väldigt stor, kan det vara svårt att förstå vad koden gör och vad dess beroenden är. Att förstå dessa beroenden och deras möjliga inverkan på applikationen och användarna är avgörande för att veta var man ska börja med kaosteknik: utgångspunkten är den komponent som har störst effektradie.
Att identifiera och dokumentera beroenden kallas "bygga en beroendekarta» (beroendekartläggning). Detta görs vanligtvis för applikationer med en stor kodbas som använder kodprofileringsverktyg. (kodprofilering) och instrumentering (instrumentation). Du kan också bygga en karta genom att övervaka nätverkstrafiken.
Alla beroenden är dock inte desamma (vilket komplicerar processen ytterligare). Några kritisk, Övrig - sekundär (åtminstone i teorin, eftersom krascher ofta inträffar på grund av problem med beroenden som ansågs icke-kritiska).
Utan kritiska beroenden kan tjänsten inte fungera. Icke-kritiska beroenden"borde inte» att påverka tjänsten vid ett fall. För att förstå beroenden måste du ha en tydlig förståelse för de API:er som används av din applikation. Detta kan vara mycket svårare än det verkar - åtminstone för stora applikationer.
Börja med att gå igenom alla API:er. Markera mest betydelsefull och kritisk. Ta beroende på från kodförrådet, kolla in det anslutningsloggar, se sedan dokumentation (naturligtvis, om det finns - annars har du fortfarandeоstörre problem). Använd verktygen för att profilering och spårning, filtrera bort externa samtal.
Du kan använda program som netstat - ett kommandoradsverktyg som visar en lista över alla nätverksanslutningar (aktiva uttag) i systemet. Till exempel, för att lista alla aktuella anslutningar, skriv:
❯ netstat -a | more
I AWS kan du använda (flödesloggar) VPC är en metod som låter dig samla in information om IP-trafik som går till eller från nätverksgränssnitt i en VPC. Sådana loggar kan också hjälpa till med andra uppgifter – till exempel att hitta svar på frågan om varför viss trafik inte når instansen.
Du kan också använda . X-Ray låter dig få detaljerad, "ultimat" (början till slut) översikt över förfrågningar när de rör sig genom applikationen, och bygger även en karta över applikationens underliggande komponenter. Mycket praktiskt om du behöver identifiera beroenden.
AWS röntgenkonsol
En nätverksberoendekarta är bara en dellösning. Ja, det visar vilken applikation som kommunicerar med vilken, men det finns andra beroenden.
Många applikationer använder DNS för att ansluta till beroenden, medan andra kan använda tjänsteupptäckt eller till och med hårdkodade IP-adresser i konfigurationsfiler (t.ex. /etc/hosts).
Du kan till exempel skapa via iptables och se vad som går sönder. För att göra detta, skriv in följande kommando:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS svart hål
Om /etc/hosts eller andra konfigurationsfiler, hittar du IP-adresser som du inte vet något om (ja, tyvärr, detta händer också), du kan komma till undsättning igen iptables. Låt oss säga att du upptäckte 8.8.8.8 och vet inte att detta är Googles offentliga DNS-serveradress. Genom att använda iptables Du kan blockera inkommande och utgående trafik till den här adressen med följande kommandon:
❯ 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"
Stänger åtkomst
Den första regeln tar bort alla paket från Googles offentliga DNS: ping fungerar, men paket returneras inte. Den andra regeln släpper alla paket som kommer från ditt system till Googles offentliga DNS - som svar på ping vi får Åtgärden är inte tillåten.
Obs: i det här fallet skulle det vara bättre att använda whois 8.8.8.8, men detta är bara ett exempel.
Vi kan gå ännu djupare ner i kaninhålet, för allt som använder TCP och UDP beror faktiskt på IP också. I de flesta fall är IP kopplad till ARP. Glöm inte brandväggar...
Om du tar det röda pillret stannar du i Underlandet, och jag ska visa dig hur djupt kaninhålet går."
Ett mer radikalt förhållningssätt är att koppla ifrån bilar en efter en och se vad som är trasigt... bli en "kaosapa." Naturligtvis är många produktionssystem inte designade för en sådan brute force attack, men det kan åtminstone prövas i en testmiljö.
Att bygga en beroendekarta är ofta ett mycket långdraget arbete. Jag pratade nyligen med en kund som ägnade nästan två år åt att utveckla ett verktyg som halvautomatiskt genererar beroendekartor för hundratals mikrotjänster och kommandon.
Resultatet är dock extremt intressant och användbart. Du kommer att lära dig mycket om ditt system, dess beroenden och funktioner. Återigen, ha tålamod: det är själva resan som betyder mest.
3. Akta dig för övertro
"Den som drömmer om vad, tror på det." — Demosthenes
Har du någonsin hört talas om övertroende effekt?
Enligt Wikipedia är övertroendeeffekten "en kognitiv fördom där en persons förtroende för sina handlingar och beslut är betydligt större än den objektiva noggrannheten i dessa bedömningar, särskilt när förtroendenivån är relativt hög."
Baserat på instinkt och erfarenhet...
Enligt min erfarenhet är denna förvrängning en bra hint om var man ska börja med kaosteknik.
Akta dig för den övermodiga operatören:
Charlie: "Den här saken har inte fallit på fem år, allt är bra!"
Crash: "Vänta... jag kommer snart!"
Bias som en konsekvens av övertro är en lömsk och till och med farlig sak på grund av de olika faktorer som påverkar det. Detta gäller särskilt när teammedlemmar har gjutit sina hjärtan i en teknik eller spenderat mycket tid på att "fixa" den.
Summering
Sökandet efter en utgångspunkt för kaosteknik ger alltid fler resultat än förväntat, och team som börjar bryta saker för snabbt förlorar ur sikte den mer globala och intressanta essensen av (kaos-)teknik - kreativ användning vetenskapliga metoder и empiriska bevis för design, utveckling, drift, underhåll och förbättring av (mjukvaru)system.
Detta avslutar den andra delen. Skriv gärna recensioner, dela åsikter eller bara klappa händerna på . I nästa del I verkligen Jag kommer att överväga verktyg och metoder för att introducera fel i system. Fram tills!
PS från översättaren
Läs även på vår blogg:
- «";
- «";
- «";
- «".
Källa: will.com