Hva er kaosteknikk & hvorfor er det viktig?

Hvorfor er kaosteknikk viktig? La oss se på hvorfor kvalitetssikring (QA) finnes i utgangspunktet. 

Ganske enkelt finnes QA fordi den virkelige verden ikke ser ut til å tillate at vi, uansett hvor hardt vi prøver, kan lage perfekt programvare som alltid gjør det den er utformet og ment å gjøre. 

Feil sniker seg inn. Maskiner tolker koden vår annerledes enn vi hadde tenkt. Ting skjer. Kvalitetsteknikk finnes for å forsøke å finne disse utilsiktede problemene før kundene våre gjør det. 

Hva er kaosteknikk?

Kaosteknikk er en disiplinert tilnærming til å identifisere potensielle feil før de blir til driftsavbrudd. Med kaosteknikk utformer du eksperimenter med feilinjisering og sammenligner det du tror vil skje, med det som faktisk skjer i systemene dine. Du «ødelegger ting med hensikt» for å lære hvordan du bygger mer motstandsdyktige systemer.

Hvorfor er kaosteknikk viktig?

Fordi systemer er i endring. Tradisjonelt kjører QA en rekke ulike tester og testtyper for proaktivt å lete etter disse problemene, lenge før koden havner i produksjon. Disse testene kjøres på slutten av et bygg og før koden distribueres offentlig, vanligvis i et trinn- eller testmiljø i stedet for testing i produksjon. 

Så langt, så bra, hvis vi arbeider etter en tradisjonell modell for programvareutvikling og distribusjon. Monolittiske utforminger og distribusjon til maskiner som eies av virksomheten, gir stor grad av kontroll. Denne kontrollen innebærer stabilitet. Det gjør disse trinn- og testmiljøene lik produksjonsmiljøene og gjør det mulig å gjennomføre vellykket testing i dem.

Distribuerte systemer er annerledes. Skyen er annerledes. Vi kontrollerer ikke infrastrukturen. Den er i konstant endring. Infrastrukturen endres i tråd med utformingen vår, med individuelle tjenester og mikrotjenester, mens lastbalansering starter opp flere beregningsnoder eller fjerner dem etter behov. Systemer for automatisk overtakelse justerer seg selv for å sikre at risiko håndteres. Den konstante endringen forårsaker uventet, fremvoksende atferd. Dette er atferd vi ikke alltid kan forutsi, men som vi kan gjenskape og fremprovosere ved hjelp av en testform som kalles kaosteknikk.

Testingen må tilpasses etter hvert som systemene endres

Vi kan ikke teste alt produksjonskoden vår og miljøet vil møte, på en effektiv måte, ved å teste i et annet miljø. Vi kan teste mange ting, og tradisjonell QA gjør dette ganske godt og bør fortsette med det, selv om noe av det kanskje nå kan gjøres ved hjelp av automatisering i byggkjøringen. Men måten vi har utført QA på, kan ikke teste hvordan det distribuerte systemet vårt vil reagere når nettverket mellom et datalager og flere beregningsnoder blir overbelastet og forsinkelsen øker, for eksempel.

De automatiserte og menneskestyrte testene våre tar ikke høyde for dette raskt skiftende produksjonsmiljøet, der tjenester starter og avsluttes etter behov. Den eneste måten å teste om et distribuert system vil forbli pålitelig når det utsettes for fremvoksende atferd forårsaket av endrede produksjonsforhold, er å gjøre det alle testparadigmer gjør: prøve og finne ut.

Slik fungerer kaosteknikk: Test og lær gjennom feil

Vi har alle mål for oppetid. Vi ønsker alle å forbedre ytelsen vår. For å gjøre dette må vi bruke alle tilgjengelige ressurser til å lære så mye som mulig om hvordan systemene våre håndterer feil, enten det er en bruker som ikke klarer å legge inn egnede data i et skjemafelt, eller en systemkomponent i skyen som ikke fungerer som forventet.

 «Hva skjer når?» er et spørsmål vi alle liker å stille. Deretter prøver vi og finner ut.

Fordi systemene og systemutformingene våre har utviklet seg på en så enestående måte, må vi også videreutvikle testmetodene våre for å få en bedre forståelse av hvordan de distribuerte systemene våre vil håndtere feil, og hvordan feil i komponenter og avhengigheter påvirker hele systemet. Helhetlig testing av denne typen er det kaosteknikk er utviklet for å utføre, fordi den kan teste hele systemet slik det eksisterer i produksjon.

Et program for kaosteknikk starter i det små, med testing av ting vi allerede vet eller tror vi vet:

• Vil overvåkingssystemet vårt aktivt fange opp nettverksforsinkelse over en bestemt terskel? 
• Vil det utløse en varsling til ingeniøren som har vakt, eller kanskje automatisk risikoredusering? 
• Har konfigurasjonen vår endret seg over tid, eller starter vi fortsatt opp beregningsnoder i henhold til spesifikasjonene?

Hvordan klarer hver tjenesteinstans seg ved lett testing? Middels? Omfattende? De bør alle være like, og vår lastbalansering bør fordele belastningen mellom dem på riktig måte. Hva skjer hvis én instans begynner å motta en betydelig høyere belastning enn de andre fordi lastbalanseringstjenesten vår har problemer?

Systematisk testing av kaotiske systemer gir viktige fordeler

Vi tester ved hjelp av den vitenskapelige metoden, begynner i det små og er bevisste på hva vi gjør. Vi utformer tidlige eksperimenter for å minimere konsekvensområdet, altså settet av tjenester og komponenter som vi mener kan bli påvirket, og for å minimere omfanget av eksperimentparameterne. 

Når vi lykkes her, kan vi bestemme oss for å bygge videre trinn for trinn, enten ved å styrke tilliten til systemet vårt eller ved å utvide den prioriterte listen over forbedringer vi skal gjøre. Når vi gjennomfører disse forbedringene og tester på nytt ved hjelp av det samme kaoseksperimentet og de samme parameterne, vil systemet bestå, og vi vil vite at det er mer pålitelig enn det var tidligere.

Dette er den eneste måten vi kan lære hvordan systemene våre faktisk håndterer feil i produksjon, der kundene våre til syvende og sist vil oppleve resultatene. Hvis vi finner de små problemene nå, før de får mulighet til å utvikle seg til store problemer, kan vi sørge for at stadig færre systemiske feil oppstår.

Dette gjør kaosteknikk til et fantastisk verktøy for pålitelighet. Det er en disiplin som hjelper oss med å gjøre det i skyen og i stor skala som vi tidligere kunne oppnå i mindre, kontrollerte miljøer ved hjelp av tradisjonell kvalitetssikring.

Dette betyr til syvende og sist færre omfattende produksjonsfeil og driftsavbrudd. Når kaosteknikk faktisk implementeres og brukes konsekvent, vil tjeneste- og komponentfeil som forventes å oppstå i skyens kaos, ikke ha noen innvirkning på kundene våre. De vil faktisk aldri vite at det oppsto en feil, og det er det egentlige målet.

Hva skjer nå?

Jeg snakket om kaosteknikk mer detaljert i en episode av podkasten The QA Lead med Jonathon Wright.

Redaktørens merknad:

Du kan holde deg oppdatert med andre podkaster og artikler fra The QA Lead ved å melde deg på nyhetsbrevet.

Du kan også bli medlem for å få tilgang til forumet til The QA Lead-fellesskapet, der du kan dele beste praksis med andre QA-er og kvalitetsingeniører. Håper vi sees der!

Relatert lesning: DE 10 BESTE PROGRAMVAREVERKTØYENE FOR KVALITETSINGENIØRING: EN KOMPLETT VEILEDNING