Opmerking. vert.: Dit artikel vervolgt een geweldige reeks artikelen van AWS-technologie-evangelist Adrian Hornsby, die op een eenvoudige en duidelijke manier het belang van experimenteren wil uitleggen om de gevolgen van storingen in IT-systemen te verzachten.
“Als je er niet in slaagt een plan op te stellen, dan ben je van plan te falen.” - Benjamin Franklin
В In deze reeks artikelen heb ik het concept van chaos-engineering geïntroduceerd en uitgelegd hoe het helpt om fouten in het systeem te vinden en te corrigeren voordat deze tot productiefouten leiden. Er werd ook besproken hoe chaos-engineering positieve culturele verandering binnen organisaties bevordert.
Aan het einde van het eerste deel beloofde ik te praten over ‘tools en methoden voor het introduceren van fouten in systemen’. Helaas had mijn hoofd in dit opzicht zijn eigen plannen, en in dit artikel zal ik proberen de meest populaire vraag te beantwoorden die opkomt bij mensen die zich willen verdiepen in chaos-engineering: Wat moet je eerst breken?
Geweldige vraag! Hij lijkt echter niet echt last te hebben van deze panda...
Knoei niet met de chaospanda!
Kort antwoord: Target kritieke services langs het aanvraagpad.
Een langer maar duidelijker antwoord: Om te begrijpen waar je moet beginnen met experimenteren met chaos, moet je op drie gebieden letten:
- Kijken naar crashgeschiedenis en patronen identificeren;
- Beslissen over kritische afhankelijkheden;
- Gebruik de zogenaamde overmoedig effect.
Het is grappig, maar dit deel zou net zo goed kunnen worden genoemd "Een reis naar zelfontdekking en verlichting". Daarin gaan we beginnen met “spelen” met een aantal coole instrumenten.
1. Het antwoord ligt in het verleden
Weet je nog, in het eerste deel introduceerde ik het concept van Correction-of-Errors (COE) - een methode waarmee we onze fouten analyseren - fouten in technologie, processen of organisaties - om de oorzaak(en) ervan te begrijpen en te voorkomen herhaling in de toekomst. Over het algemeen is dit waar u moet beginnen.
“Om het heden te begrijpen, moet je het verleden kennen.” - Carl sagan
Kijk naar de geschiedenis van mislukkingen, tag ze in COE of postmortems en classificeer ze. Identificeer gemeenschappelijke patronen die vaak tot problemen leiden, en stel uzelf voor elke COE de volgende vraag:
“Had dit kunnen worden voorspeld en dus voorkomen door foutinjectie?”
Ik herinner me een mislukking aan het begin van mijn carrière. Het had gemakkelijk voorkomen kunnen worden als we een paar eenvoudige chaos-experimenten hadden uitgevoerd:
Onder normale omstandigheden reageren backend-instanties op statuscontroles van ). ELB gebruikt deze controles om verzoeken om te leiden naar gezonde exemplaren. Wanneer blijkt dat een instance “ongezond” is, stopt ELB met het versturen van verzoeken ernaar. Op een dag, na een succesvolle marketingcampagne, nam het verkeersvolume toe en begonnen de backends langzamer dan normaal te reageren op gezondheidscontroles. Het moet gezegd worden dat deze gezondheidscontroles dat waren , dat wil zeggen dat de status van de afhankelijkheden werd gecontroleerd.
Toch ging alles een tijdje goed.
Vervolgens begon een van de instanties, al onder nogal stressvolle omstandigheden, een niet-kritieke, reguliere ETL-cron-taak uit te voeren. De combinatie van veel verkeer en cronjob zorgde ervoor dat het CPU-gebruik bijna 100% bedroeg. Overbelasting van de CPU vertraagde de reacties op statuscontroles verder, zozeer zelfs dat de ELB besloot dat de instantie prestatieproblemen ondervond. Zoals verwacht stopte de balancer met het distribueren van verkeer, wat op zijn beurt leidde tot een toename van de belasting van de resterende instanties in de groep.
Plotseling begonnen ook alle andere gevallen de gezondheidscontrole niet te doorstaan.
Het starten van een nieuw exemplaar vereiste het downloaden en installeren van pakketten en het duurde veel langer dan de ELB nodig had om ze - één voor één - uit te schakelen in de autoscaling-groep. Het is duidelijk dat het hele proces al snel een kritiek punt bereikte en dat de applicatie crashte.
Toen begrepen we voor altijd de volgende punten:
- Het installeren van software bij het maken van een nieuw exemplaar duurt lang; het is beter om de voorkeur te geven aan de onveranderlijke aanpak en .
- In complexe situaties moeten reacties op gezondheidscontroles en ELB's voorrang krijgen - het laatste wat u wilt is het leven voor de overige gevallen ingewikkelder maken.
- Lokaal cachen van gezondheidscontroles helpt veel (zelfs voor een paar seconden).
- Voer in een moeilijke situatie geen cron-taken en andere niet-kritieke processen uit - spaar middelen voor de belangrijkste taken.
- Gebruik bij automatisch schalen kleinere exemplaren. Een groep van 10 kleine exemplaren is beter dan een groep van 4 grote exemplaren; als één instantie faalt, wordt in het eerste geval 10% van het verkeer verdeeld over 9 punten, in het tweede geval 25% van het verkeer over drie punten.
aldus Had dit kunnen worden voorzien en dus voorkomen door het introduceren van het probleem?
Ja, en op verschillende manieren.
Ten eerste door een hoog CPU-gebruik te simuleren met behulp van tools zoals of :
❯ stress-ng --matrix 1 -t 60s
stress-ng
Ten tweede, door de instantie te overbelasten met en andere soortgelijke hulpprogramma's:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
De experimenten zijn relatief eenvoudig, maar kunnen stof tot nadenken bieden zonder de stress van een echte mislukking te moeten doorstaan.
Maar stop daar niet. Probeer de crash na te bootsen in een testomgeving en controleer je antwoord op de vraag "Had dit kunnen worden voorzien en dus voorkomen door het introduceren van een fout?" Dit is een mini-chaos-experiment binnen een chaos-experiment om aannames te testen, maar beginnend met een mislukking.
Was het een droom, of is het echt gebeurd?
Bestudeer dus de geschiedenis van mislukkingen, analyseer EOC, tag en classificeer ze op basis van ‘hitradius’ (of beter gezegd: het aantal getroffen klanten) en zoek vervolgens naar patronen. Vraag jezelf af of dit had kunnen worden voorspeld en voorkomen door het probleem te introduceren. Controleer je antwoord.
Ga dan over op de meest voorkomende patronen met het grootste bereik.
2. Bouw een afhankelijkheidskaart
Denk even na over uw aanvraag. Is er een duidelijke kaart van de afhankelijkheden? Weet u welke impact ze zullen hebben als er een mislukking is?
Als u niet zo bekend bent met de code van uw toepassing of als deze erg groot is geworden, kan het moeilijk zijn om te begrijpen wat de code doet en wat de afhankelijkheden ervan zijn. Het begrijpen van deze afhankelijkheden en hun mogelijke impact op de applicatie en gebruikers is van cruciaal belang om te weten waar te beginnen met chaos engineering: het startpunt is het onderdeel met de grootste impactradius.
Het identificeren en documenteren van afhankelijkheden heet "het maken van een afhankelijkheidskaart» (afhankelijkheidstoewijzing). Dit wordt doorgaans gedaan voor toepassingen met een grote codebasis met behulp van codeprofileringstools. (codeprofilering) en instrumentatie (instrumentatie). U kunt ook een kaart maken door het netwerkverkeer te monitoren.
Niet alle afhankelijkheden zijn echter hetzelfde (wat het proces nog ingewikkelder maakt). Sommige kritisch, ander - ondergeschikt (althans in theorie, aangezien crashes vaak optreden als gevolg van problemen met afhankelijkheden die als niet-kritisch werden beschouwd).
Zonder kritische afhankelijkheden kan de service niet werken. Niet-kritieke afhankelijkheden "zou niet moeten» om de service te beïnvloeden bij een val. Om afhankelijkheden te begrijpen, moet u een duidelijk inzicht hebben in de API's die door uw applicatie worden gebruikt. Dit kan een stuk moeilijker zijn dan het lijkt - tenminste voor grote toepassingen.
Begin met het doorlopen van alle API's. Markeer het meest betekenisvol en kritisch. Nemen зависимости vanuit de coderepository, bekijk het eens verbindingslogboekenen vervolgens bekijken de documentatie (natuurlijk, als het bestaat - anders bestaat het nog steedsоgrotere problemen). Gebruik de hulpmiddelen om profilering en tracering, filter externe oproepen uit.
Je kunt programma's gebruiken zoals netstat - een opdrachtregelhulpprogramma dat een lijst weergeeft met alle netwerkverbindingen (actieve sockets) in het systeem. Om bijvoorbeeld alle huidige verbindingen weer te geven, typt u:
❯ netstat -a | more
In AWS kun je gebruik maken van (stroomlogboeken) VPC is een methode waarmee u informatie kunt verzamelen over IP-verkeer dat van of naar netwerkinterfaces in een VPC gaat. Dergelijke logs kunnen ook helpen bij andere taken, bijvoorbeeld het vinden van een antwoord op de vraag waarom bepaald verkeer de instantie niet bereikt.
Je kan ook gebruiken . Met X-Ray kunt u gedetailleerd, "ultiem" worden (eind tot eind) overzicht van verzoeken terwijl ze door de applicatie gaan, en bouwt ook een kaart op van de onderliggende componenten van de applicatie. Erg handig als u afhankelijkheden wilt identificeren.
AWS röntgenconsole
Een netwerkafhankelijkheidskaart is slechts een gedeeltelijke oplossing. Ja, het laat zien welke applicatie met welke communiceert, maar er zijn andere afhankelijkheden.
Veel applicaties gebruiken DNS om verbinding te maken met afhankelijkheden, terwijl andere mogelijk gebruik maken van servicedetectie of zelfs hardgecodeerde IP-adressen in configuratiebestanden (bijv. /etc/hosts).
U kunt bijvoorbeeld creëren via iptables en kijk wat er kapot gaat. Om dit te doen, voert u de volgende opdracht in:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS-zwart gat
Als in /etc/hosts of andere configuratiebestanden, je vindt IP-adressen waar je niets vanaf weet (ja, helaas gebeurt dit ook), je kunt weer te hulp schieten iptables. Laten we zeggen dat je het hebt ontdekt 8.8.8.8 en weet niet dat dit het openbare DNS-serveradres van Google is. Door het gebruiken van iptables U kunt inkomend en uitgaand verkeer naar dit adres blokkeren met behulp van de volgende opdrachten:
❯ 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"
Toegang sluiten
De eerste regel verwijdert alle pakketten van de openbare DNS van Google: ping werkt, maar pakketten worden niet geretourneerd. De tweede regel laat alle pakketten die afkomstig zijn van uw systeem naar de openbare DNS van Google vallen - als reactie hierop ping we krijgen Operatie niet toegestaan.
Let op: in dit specifieke geval is het beter om dit te gebruiken whois 8.8.8.8, maar dit is slechts een voorbeeld.
We kunnen nog dieper in het konijnenhol gaan, omdat alles wat TCP en UDP gebruikt eigenlijk ook afhankelijk is van IP. In de meeste gevallen is IP gekoppeld aan ARP. Vergeet firewalls niet...
Als je de rode pil slikt, blijf je in Wonderland, en ik zal je laten zien hoe diep het konijnenhol gaat."
Een radicalere benadering is om verbinding verbreken auto's één voor één en kijk wat er kapot is... word een 'chaos-aap'. Natuurlijk zijn veel productiesystemen niet ontworpen voor zo’n brute force-aanval, maar het kan in ieder geval in een testomgeving worden uitgeprobeerd.
Het opstellen van een afhankelijkheidskaart is vaak een zeer langdurige onderneming. Ik sprak onlangs met een klant die bijna twee jaar heeft besteed aan het ontwikkelen van een tool die semi-automatisch afhankelijkheidskaarten genereert voor honderden microservices en opdrachten.
Het resultaat is echter buitengewoon interessant en nuttig. U leert veel over uw systeem, de afhankelijkheden en de werking ervan. Nogmaals, wees geduldig: het is de reis zelf die er het meest toe doet.
3. Pas op voor overmoed
“Wie van wat droomt, gelooft erin.” – Demosthenes
Heb je ooit gehoord van overmoedig effect?
Volgens Wikipedia is het overmoedseffect “een cognitieve vertekening waarbij het vertrouwen van een persoon in zijn daden en beslissingen aanzienlijk groter is dan de objectieve nauwkeurigheid van die oordelen, vooral wanneer het niveau van vertrouwen relatief hoog is.”
Gebaseerd op instinct en ervaring...
In mijn ervaring is deze vervorming een goede indicatie van waar te beginnen met chaos-engineering.
Pas op voor de overmoedige operator:
Charlie: "Dit ding is al vijf jaar niet gevallen, alles is in orde!"
Crash: "Wacht... ik ben er zo!"
Vooroordelen als gevolg van overmoed zijn verraderlijk en zelfs gevaarlijk vanwege de verschillende factoren die daarop van invloed zijn. Dit geldt vooral wanneer teamleden hun hart in een technologie hebben gestoken of veel tijd hebben besteed aan het ‘repareren’ ervan.
Opsommen
De zoektocht naar een startpunt voor chaos-engineering levert altijd meer resultaat op dan verwacht, en teams die te snel dingen kapot gaan maken, verliezen de meer mondiale en interessante essentie van (chaos-)engineering - creatief gebruik wetenschappelijke methodes и empirisch bewijs voor het ontwerpen, ontwikkelen, exploiteren, onderhouden en verbeteren van (software)systemen.
Hiermee wordt het tweede deel afgesloten. Schrijf recensies, deel meningen of klap gewoon in de handen . In het volgende deel I echt Ik zal instrumenten en methoden overwegen om fouten in systemen te introduceren. Tot!
PS van vertaler
Lees ook op onze blog:
- «";
- «";
- «";
- «.
Bron: www.habr.com