Kaosteknik: Ett steg mot tillförlitlighet

En resa mot mikrotjänster

IT-organisationer har genomgått en massiv omvandling när det gäller människor, processer och teknik för att tillgodose affärsbehov som att uppnå snabbare time-to-market. Människor har återkvalificerats till full stack; processer har flyttat från vattenfall till iterativ och smidig; team har blivit linjära och DevOps-metoder har tillämpats på automatisering av programvaruutveckling och distribution. Även om monolitarkitekturen tillåter logisk modularitet oavsett förbättringar eller nya funktioner, distribueras den fortfarande som en enhetlig enhet vilket gör kontinuerlig distribution tråkig och tidskrävande. För att lösa den här utmaningen har organisationer migrerat från monolitisk arkitektur till tjänstorienterad arkitektur och i de flesta fall till mikrotjänster. Övergången till mikrotjänster har hjälpt team att utveckla, testa och distribuera program mer effektivt, snabbt och ofta. Dessutom har införandet av mikrotjänster avsevärt förbättrat kpi:er (Key Performance Indicators), såsom distributionsfrekvens och ledtid till förändring, vilket hjälper till att få funktioner att komma ut på marknaden på en kortare tidslinje och hjälpa verksamheten.

Tekniska utmaningar med arkitektur för mikrotjänster

IT-företag som har anammat mikrotjänster har sett enorma fördelar. Utmaningar kvarstår dock när det gäller att hantera operativa och tekniska komplexiteter. En ökning av antalet och det ömsesidiga beroendet för mikrotjänster kan också öka felpunkterna, vilket sedan påverkar följande mått:

• Genomsnittlig tid till lösning (MTTR): den genomsnittliga tiden mellan början av en incident och dess lösning
• Genomsnittlig tid mellan fel (MTBF): den genomsnittliga tiden som förflutit mellan fel

Dessa mått mäter tillgängligheten för system och används av systemtillförlitlighetsoperationer och utvecklingsteam för att stödja kontrakt med servicenivåavtal (SLA). Högre systemåterställningstid/MTTR och frekventa fel i systemet/MTBF kan påverka systemets tillgänglighet och tillförlitlighet, vilket avsevärt påverkar SLA/SLO-åtaganden (service level agreement/service level objective) i kontrakt.

Införa kaosteknik för att förbättra tillgängligheten

Kaosteknik involverar en serie övningsexperiment som körs på systemen för att kontrollera och förbättra förtroendet för deras förmåga att motstå turbulenta förhållanden i produktionen. Enligt en rapport från 2021 av Gremlin¹ hade 23% av teamen som ofta körde kaosteknikprojekt en MTTR på under en timme; 60% hade en MTTR på under 12 timmar. Det är därför implementering av kaosexperiment tidigt och ofta i livscykeln för programvaruutveckling (SDLC) möjliggör följande:

• Förbättrad MTTR: I icke-produktionsmiljön förbereder att fixa korrigeringsfel teamen och förbättrar deras hastighet när det gäller att lösa incidenter i produktionsmiljöer.
• Förbättrad MTBF: I icke-produktionsmiljön kan fel identifieras proaktivt och lösas, vilket minskar fel i produktionen.

Idag upplever många toppföretag garanterad oöverträffad tillgänglighet och tillförlitlighet genom att implementera kaosexperiment som en del av sitt SDLC. Att förbättra MTBF och MTTR påverkar därför hög systemtillgänglighet och avviker inte från de utlovade SLA: erna / SLA: erna.

Kaostestning kan avslöja systembrister

Organisationer kan införa kaosteknik med hjälp av en sexstegsstrategi som visas i bilden nedan:

Låt oss utveckla de sex stegen som nämns ovan. Vi tar hjälp av ett exempel på ett mikrotjänstbaserat filmbokningsprogram. Den distribueras på ett Kubernetes-kluster på en offentlig molnleverantör, som visas i bild 2 nedan.

Olika tjänster, som show timing, filmklassificering, biljettköp, betalning, e-post och SMS, distribueras i enskilda behållare, var och en insvept i en separat pod. Frontend-användargränssnittet och databasen körs också på poddarna. 

Steg 1: Upptäckt

Under den här fasen måste teamen samarbeta för att få den information som krävs om ett program och dess miljö genom att:

• Analysera alla tjänster/komponenter, funktioner, beröringspunkter och beroenden mellan tjänster, inklusive uppströms-nedströms, oberoende tjänster, konfigurationer och datalager 
• Utforska infrastruktur och distributionsmetod
• Identifiera felpunkter för varje komponent/tjänst
• Fastställa påverkan på verksamheten för varje felpunkt 

Steg 2: Definiera steady state

Under detta skede bör teamen:

• Definiera programmets normala tillståndsbeteende mätbart 
• Mäta affärs- och driftsmått (t.ex. svarstid, dataflöde, felfrekvens osv.)
• För de identifierade måtten markeras det acceptabla värdeintervallet 

I exempelprogrammet för filmbokning (figur 2) är tjänsten – filmbokning – en affärskritisk komponent, eftersom den är kopplad till intäktsgenerering. Vanligtvis, under de första dagarna av en filmrelease, får denna komponent massiva samtidiga träffar. Därför blir dataflödet (möjligheten att hantera dessa begäranden utan försämring) det översta måttet i tratten, och produkthanteringsteamet definierar det acceptabla dataflödet som inom intervallet 50–65 begäranden per sekund för filmbokningstjänsten.

Steg 3: Bygg en hypotes

När det stabila tillståndet har definierats för tjänsterna identifierar du experimenten som ska injiceras och antar vad som kommer att gå fel (t.ex. vad kan påverka tjänsten, systemet och kunderna?). Prioritera dessutom experimenten baserat på kundpåverkan och den höga frekvensen av händelser.

Nu ska vi avsluta podden som kör filmbokningsstjänsten i exempelprogrammet. Vi antar att Kubernetes automatiskt identifierar avslutningen och etablerar en ny podd.

Steg 4: Kör experimentet och mät och analysera resultaten 

Börja köra experiment i en icke-produktionsmiljö. Det är dock viktigt att förstå hur systemet beter sig innan du kör experimentet. Mät de nödvändiga mätvärdena under normala förhållanden och mät sedan samma mätvärden efter att ha injicerat experiment. Om det finns en allvarlig inverkan efter att experimentet har körts avbryter du experimentet och kör återställningsplanen för att återgå till ett stabilt tillstånd.

Steg nedan för att utföra ett filmboknings POD-dödsexperiment:

• Vi har skapat Grafana – ett analys-, visualiserings- och övervakningsverktyg med öppen källkod för flera plattformar. Övervaka dataflöde, felfrekvens och svarstid innan du utför experimentet, enligt bild 5 och 6.

• Utnyttja prestandaverktyget med öppen källkod, Apache JMeter, för att simulera samtidig belastning under en viss varaktighet på filmbokningstjänstbegäranden.
• Kör kaosexperimentet - avslutningen av filmbokningspodden - genom att utnyttja vilket kaosverktyg som helst.
• Observera dataflöde, felfrekvens och svarstid efter experimentet, enligt bild 7 och 8 (i Grafana).

• Analysera felfrekvens, tröskelvärde och genomströmning (inspelat från för- och efterexperiment) för att verifiera avvikelser 

Data visar att när filmbokningspodden avslutas ligger felfrekvensen och latensen över det normala intervallet. Dataflödet sjunker tills Kubernetes identifierar avslutningen och automatiskt tar upp en podd som innehåller filmbokningsstjänsten; detta fel måste åtgärdas.

Steg 5: Fixa och testa igen

I det här fallet är en av de potentiella korrigeringarna att skala antalet repliker; Detta säkerställer att ett angivet antal poddar körs kontinuerligt. Även om en podd misslyckas hanterar de andra poddarna begäran. Observera att efter fixen, i bilden nedan, finns det noll fel. Dataflöde och svarstid är som förväntat och väl inom intervallet. 

Med implementeringen av mikrotjänsttåliga designmönster kan fel i programmet också lösas. Utvecklare kan skapa felresistenta mikrotjänstprogram med hjälp av återhämtningsmönster, till exempel en kretsbrytare, återförsök och tidsgräns.

Steg 6: Öka sprängradien iterativt

När experimentet börjar köras är rekommendationen att gradvis öka experimentets radie. I exempelexperimentet ovan avslutar vi till exempel en tjänst och avslutar sedan en annan successivt. Därför måste man börja experimentera i mellanlagringsmiljöer och sedan flytta till produktion.

Kaosteknikens bästa praxis 

• Målexperiment i en förproduktionsmiljö: Starta experiment i utvecklings- eller mellanlagringsmiljön. Efter att ha fått förtroende för den lägre miljön och förstått effekterna av experimenten, kör experiment i produktionsmiljöer.
  
• Utnyttja automatisering: Börja med ett manuellt test med hjälp av verktyg, men dra nytta av automatisering för att få snabbare feedback.
• Kör experiment kontinuerligt: När du får förtroende för experimenten bör du se till att chaos-experiment körs kontinuerligt i CI/CD-pipelinen.
• Öka sprängradien iterativt: Fokusera på kända experiment och starta små experiment (t.ex. börja med en container, mäta nätverksfördröjning mellan två tjänster osv.)
• Återhämtningsplan: Säkerställ en återställningsplan för varje experiment.

Avslutande tankar

För att säkerställa användarnöjdhet och kvarhållning i den digitala världen måste företag överväga vissa faktorer (tid till marknad, användarupplevelse, pålitligt system och förmågan att återhämta sig snabbt) för att driva verksamheten och ge värde till slutanvändarna. Att införliva kaosteknik i SDLC möjliggör både operativa och tekniska fördelar, såsom förebyggande av intäktsförluster, minskade underhållskostnader, förbättrad incidenthantering, en minskning av negatoriska incidenter, en lättare börda för jourpersonal och en bättre förståelse för systemfellägen och förbättrad systemdesign.

På grund av dess många fördelar bör organisationer gå mot kaosteknik för att underlätta skapandet av pålitliga mjukvarusystem.

Referenser:

1. Horgan, Aileen. "Tillståndet för kaosteknik 2021." Publicerad 26 januari 2021. Tillståndet för kaosteknik 2021 (gremlin.com)