De nya tjänster vi utvecklar i dag tar allt mer formen av distribuerade system där tjänsten är utspridd över stora geografiska områden. Typiska representanter för denna typ av tjänster är Netflix, Spotify och Uber, som många av oss använder dagligen.

Strukturen bakom dessa tjänster ser ofta likartad ut; lite förenklat består de av ett antal deltjänster som tillsammans utgör en instans av tjänsten. Var och en av dessa instanser är över tid identiska och sprids över geografiska områden och kopplas inte sällan ihop med ett Content Delivery Network (CDN). Den grundläggande motiveringen bakom denna design är att få ut innehållet så nära slutanvändaren som möjligt för att minimera fördröjningar i nätverket och maximera kvalitén för slutanvändaren.

Den absolut viktigaste mätpunkten för tjänsteleverantören är att tjänsten skall vara ständigt tillgänglig för slutanvändaren, samt att leveransen håller god kvalitet.

Utvecklarna bakom tjänsten arbetar ofta i team som fokuserar på sin del av paketet, sin deltjänst. När en ny version eller uppdatering av en deltjänst ska sjösättas trycks den nya koden ut till alla instanser som behöver den.

Det säger sig självt att stora distribuerade tjänstesystem snabbt blir mycket komplexa och svåra att felsöka. Även om varje deltjänst och instans testas noga i en testmiljö och fungerar som den ska, kan interaktionerna mellan deltjänsterna och instanserna orsaka oförutsedda händelser som i värsta fall gör att leveransen av tjänsten stoppas eller försämras. Denna typ av oförutsedda resultat orsakade av interaktioner mellan deltjänsterna gör hela systemet kaotiskt.

Chaos Engineering är en metodik och en uppsättning verktyg för att testa distribuerade system och tillhörande tjänster genom att avsiktligt införa störningar, och analysera resultaten, i produktionsmiljön. Ja, du läste rätt – i produktionsmiljön.

Techworld besökte på onsdagen seminariet European Chaos Engineering Days som gick av stapeln på KTH i Stockholm. Seminariet samlade talare från både akademin och näringslivet och behandlade både forskning och praktiska erfarenheter inom Chaos Engineering.

Bland talarna märktes Lorin Hochstein som till vardags arbetar som senior mjukvaruingenjör på Netflix. Han arbetar inom den grupp som de kallar Cloud Operations & Reliability Engineering (CORE). På Netflix, som ju verkligen är en global distribuerad tjänsteleverantör, arbetar sedan ett par år tillbaka systematiskt med att, på lagom nivå, stressa det egna produktionssystemet för att hitta fel innan felen orsakar problem. Netflix har utvecklat ett testsystemet Chaos Monkey som idag finns publicerad under en öppen källkod-licens.

Lorin Hochstein berättar att på Netflix arbetar hans team tillsammans med tjänsteägarna på frivillig basis, och att det är inte alltid tjänsteägarna är så pigga på att låta sina produktionssystem undergå Chaos Engineering.

– Det är viktigt att 'sälja in' våra tester på rätt sätt, tjänsteägarna måste känna att de får ut något mer än bara ett testresultat. De vet redan att det blir problem om man stänger ned en server, så de vill ha data som visar på potentiella problem de inte hade kunnat förutse, säger Lorin Hochstein.

På Netflix jobbar de med att ta ut en liten del av en horisontell tjänst som testobjekt och jämför resultaten med kontrollgruppen, det vill säga resten det system som upprätthåller tjänsten. De testar aldrig på vertikaler då detta skulle påverka kundernas upplevelse. Kraschar den lilla delen kommer det inte påverka tjänsten. Dessutom genomför de aldrig tester under "prime time”, vilket alltid är under kvällen i den tidszon det handlar om.

Det är viktigt att kalibrera testerna så att man stör tjänsterna lagom mycket. För klena störningar gör ingen skillnad, output blir detsamma. Och för stora störningar kan få saker att krascha vilket förstås kan påverka leveransen. Specifika störningar kan till exempel vara att stänga ned en av noderna i en distribuerad tjänst, att införa fördröjningar i nätverket eller att mata en tjänst med indata den inte räknar med att få.

Den osäkerhet som uppstår på grund av systemets icke-deterministiska karaktär kan motarbetas genom att identifiera systematiska svagheter i delsystemen innan de manifesterar sig som abnorma problem över hela systemet. Dessa systematiska svagheter kan till exempel vara otillräckliga reservsystem om en tjänst går ned, förhöjd belastning på grund av ständiga återförsök till följd av illa konfigurerade timeouter, avbrott som sker när nedströms beroenden får för mycket trafik, eller snabb fortplantning av sekundära fel till följd av ett primärt fel.

Chaos Engineering har seglat upp som en bra metod att hantera kaotiska distribuerade system främst tack vare utvecklingen av virtuella plattformar, molntjänster och inte minst devops. Chaos Engineering kan ses som ett sätt att metodiskt tillämpa experiment vars syfte är att avslöja systematiska svagheter och motarbeta osäkerheter i tjänsteleveranser. Normalt följer dessa experiment ett visst mönster:

  • Börja med att definiera ett normaltillstånd som ger ett mätbart utfall som indikerar att systemet fungerar normalt. Det kan till exempel vara att cpu-utnyttjandet på en server ligger på 80 procent.
  • Ställ upp en hypotes att detta normaltillstånd kommer fortsätta i både testgruppen och i kontrollgruppen.
  • Introducera variabler som motsvaras av verkliga händelser som kan störa systemet; detta kan vara en kraschad server, ett fel i en lagringsenhet eller otillräcklig kapacitet i nätverket.
  • Försök att motbevisa din hypotes genom att leta efter olikheter i normaltillstånden mellan testgruppen och kontrollgruppen.

Ju svårare det är att störa normaltillståndet i testgruppen, desto mer säker kan du vara på att kontrollgruppen, det vill säga produktionssystemet, är motståndskraftigt mot de störningar du introducerade i dina variabler. Om du upptäcker en svaghet har du därmed ett mål för förbättringar av ett beteende innan de orsakar verkliga problem.

För att göra testerna effektiva bör de automatiseras i så hög grad som möjligt; det är inte speciellt givande att ge sig på Chaos Engineering med manuella metoder.

Även Oracle jobbar med Chaos Engineering för att testa sina molntjänster. På liknande sätt som hos Netflix är dessa molntjänster byggda som distribuerade system av olika deltjänster på noder som ska finnas så nära slutanvändarna som möjligt.

– På Oracle hade vi till en början stora problem att få tjänsteägarna och ledningsgrupperna att acceptera Chaos Engineering. Bara ordet 'Chaos' fick dem att rygga tillbaka, säger Nazareno V. Feito Matias, principal engineer på Oracle.

Han arbetar inom en grupp i London som har till uppgift att tillämpa Chaos Engineering inom delar av Oracles tjänsteutbud. Gruppen har utvecklat ett verktyg som heter MadBull, skrivet i Python, och som till stora delar liknar Chaos Monkey, men är inte släppt under en fri licens.

Oracle går mer försiktigt fram med sina tester - det är inte tal om att ta ned servrar eller andra kritiska resurser, å andra sidan menar Nazareno att sådana tester inte är speciellt givande då alla redan vet vad som händer. Nazarenos grupp använder å andra sidan sofistikerade matematiska och statistiska modeller, och en nypa AI, för att få fram användbara data.

Netflix är som sagt lite mer våghalsiga när det gäller att stressa sina system. Enligt Lorin Hochstein är hans team idag så säkra på sina metoder att de inte ens frågar tjänsteägarna om lov innan de testar systemen.

– Vi bara kör och ser vad som händer.

Lorin Hochstein menar också att under de två till tre år som de tillämpat Chaos Engineering har Netflix tjänsteleverans blivit så stabil att de idag inriktar sina tester på andra delar av systemet.

– I dag känns det nästan meningslöst att testa tjänsteleveransen inom de ramar vi har. Visst gör vi det ibland eftersom man aldrig vet när nya problem dyker upp, eller om vi introducerar en ny tjänst, men idag ser vi aldrig de abnormaliteter vi hittade förut. Tack vare Chaos Engineering har Netflix ett mycket stabilt system i dag.

Läs också:
Alla pratar om devops – men vad är det egentligen?
Så utvecklas molntjänsterna 2019 – trenderna att hålla koll på
Office 365 gick ner igen – fick stängas av och startas om