Inhoud
- Voorbereiding op mislukking
- De volgende stappen
- Geen bugs, geen stress - Uw stapsgewijze handleiding voor het creëren van levensveranderende software zonder uw leven te vernietigen
- Leren en verbeteren door middel van oefeningen
Bron: pressureUA / iStockphoto
Afhaal:
Moderne systemen moeten in staat zijn om chaos aan te pakken om downtime te voorkomen. Daarom is het belangrijker dan ooit om systemen grondig te testen en hun veerkracht te waarborgen.
Ondanks onze grootste inspanningen om ze te voorkomen, zijn IT-incidenten een onvermijdelijk onderdeel van het werk - en proberen de downtime voor bedrijven te beïnvloeden wordt alleen maar lastiger. Systemen zijn tegenwoordig nauw gekoppeld en steeds complexer, en met meer bewegende delen komen er meer kansen voor dingen om fout te gaan.
Dit is een reden waarom steeds meer organisaties zich tot microservices wenden voor een grotere beschikbaarheid van services en een betere weerstand tegen falen. Maar hoewel dit geweldige uitgangspunten zijn voor het doorbreken van monolithische toepassingen, kunnen ze ook potentieel het risico van falen vergroten - tenzij uitdrukkelijk ontworpen met veerkracht in het achterhoofd.
Voorbereiding op mislukking
Gezien het inherent chaotische karakter van gedistribueerde systemen, moeten services niet alleen worden ontwikkeld om te anticiperen op falen, maar ook om automatisch te herstellen in geval van falen. Dit betekent dat er regelmatig storingen moeten worden veroorzaakt om ervoor te zorgen dat uw systemen chaos kunnen verwerken zonder de service aan eindklanten te verstoren. En om dit te bereiken, hebt u de mogelijkheid nodig om productie-achtig verkeer in testomgevingen te simuleren.
Het is natuurlijk een goed idee om de veerkracht te testen voordat wijzigingen de productie bereiken. Als u dit niet doet, kunt u niet verifiëren dat uw services zowel gemiddelde als piekbelastingen kunnen ondersteunen. In feite is de veiligste gok om ervoor te zorgen dat uw product tot tweemaal het piekbedrag aankan zonder op te schalen.
Als het gaat om het testen van de veerkracht, moeten de juiste tools zich niet al te veel zorgen maken over hoe verzoeken worden afgehandeld, alleen dat ze uiteindelijk de juiste impact hebben. Houd er rekening mee dat de invoerservice onder bepaalde omstandigheden een verzoek niet aan de rest van het systeem kan doorgeven, maar de fout niet kan melden. Riskeer geen problemen die onder de radar van monitoring vliegen door ervoor te zorgen dat end-to-end validatie in feite plaatsvindt. (Zie voor meer technische storingen: kunnen we ermee leven?)
De volgende stappen
Nadat we hebben begrepen hoe services zich onder belasting gedragen, is het tijd om de storingsgebeurtenissen te introduceren. Zoals bij alle softwaretests, is het het beste om geautomatiseerde tools te hebben waarmee u eenvoudig en snel scenario's kunt reproduceren, zodat u complexe evenementen kunt coördineren die van invloed zijn op verschillende infrastructuurtechnologieën. En naast de mogelijkheid om fixes en wijzigingen in de services te verifiëren, kunt u willekeurige foutscenario's uitvoeren in elke omgeving en volgens een schema.
Betekenisvolle faalgebeurtenissen hangen grotendeels af van de lay-out van uw services en u kunt ze formuleren door specifieke vragen te stellen die voor u relevant zijn. Wat is bijvoorbeeld de impact voor mensen die de front-end gebruiken wanneer een database voor een bepaalde periode onbereikbaar wordt? Kunnen die gebruikers nog steeds door de webinterface navigeren? Kunnen ze nog steeds updates van hun informatie verstrekken en zullen die updates correct worden verwerkt wanneer de database weer bereikbaar wordt?
Als u meerdere microservices uitvoert, kunt u vragen of er een wereldwijde uitval is als een individuele service crasht. Of als u een wachtrijmechanisme hebt om de communicatie tussen services te bufferen, wat gebeurt er wanneer de consumentenservice (of services) stopt met werken? Kunnen gebruikers nog steeds met uw applicatie werken? En bij een gemiddelde belasting, hoe lang heb je nog voordat de wachtrijen overlopen en je s begint te verliezen?
Geen bugs, geen stress - Uw stapsgewijze handleiding voor het creëren van levensveranderende software zonder uw leven te vernietigen
U kunt uw programmeervaardigheden niet verbeteren als niemand om softwarekwaliteit geeft.
Nadat u enkele belangrijke vragen over uw infrastructuur heeft gedefinieerd, kunt u beginnen met het opsommen van verschillende manieren om die storingen te simuleren. Het kan voldoende zijn om een bepaalde service of een databaseserver te stoppen. Misschien wilt u de hoofdthread van een service blokkeren om een impasse te simuleren, terwijl de container nog steeds reageert en actief is. U kunt besluiten regels in uw netwerk in te voeren om verkeer tussen specifieke services te blokkeren. In Linux-omgevingen kunt u tools zoals ‘tc’ gebruiken om netwerksituaties te emuleren, zoals hoge latentie, gevallen, beschadigde of gedupliceerde pakketten. (Het kan belangrijk zijn om gebruikers te betrekken bij het testen. Lees meer in 4 redenen waarom eindgebruikers moeten deelnemen aan het testen vóór UAT.)
Leren en verbeteren door middel van oefeningen
Een van de meest waardevolle aspecten van het creëren van faalscenario's is dat ze alle mogelijke manieren kunnen blootleggen waarop het systeem kan falen, waardoor de weg wordt gebaand naar zelfherstellende logica. Uw team doorloopt de stappen om services handmatig te herstellen - een prima oefening trouwens, om te bevestigen dat ze dit binnen SLA's kunnen doen. Aan automatisering van dit herstelproces kan worden gewerkt, maar in de tussentijd kunt u gerust zijn, wetende dat uw team het proces van het weer op de rails krijgen van services heeft doorlopen. Door foutscenario's willekeurig en regelmatig te maken en niet de volledige details van de run te onthullen, kunt u ook detectie en diagnoses aan de oefening toevoegen - wat tenslotte een cruciaal onderdeel van SLA's is.
In de kern neemt chaos engineering de complexiteit van het systeem als een gegeven, test het door nieuwe en gekke omstandigheden te simuleren en observeert hoe het systeem reageert. Dit zijn de data engineering-teams die nodig zijn om het systeem opnieuw te ontwerpen en opnieuw te configureren om meer veerkracht te bereiken. Er zijn zoveel mogelijkheden om nieuwe en nuttige dingen te leren. Het kan bijvoorbeeld voorkomen dat services geen updates ontvangen wanneer downstream-services zijn gewijzigd, of gebieden waar monitoring volledig ontbreekt. Er is geen tekort aan spannende manieren om uw product veerkrachtiger en robuuster te maken!