What could possibly go wrong?

I förra artikeln beskrev jag utmaningarna med kaskadproblem och svårigheterna att förutse och felsöka rotorsak när dessa problem uppstår. Här kommer några exempel hur man kan hantera dessa sårbarheter proaktivt och/eller reaktivt.

Ett sätt kan vara att köra workshops med syftet att hitta svaren på "What could possibly go wrong?"

Sammanfattat handlar det om samla ett gäng som tillsammans spånar fram olika hypoteser som kan gå fel. Olika roller kommer att ha olika infallsvinklar, bakgrund och erfarenhet om potentiella felkällor, samt hur man kan upptäcka, mitigera och åtgärda!

Tänkbara roller som är bra att ha med

Produktägare
Mjukvaruarkitekter
Infrastrukturarkitekterer
DBA
Utvecklare
Incident manager/NOC
Säkerhetsteam
Övervakningsspecialist
Prestandatestare

Avgränsning och kravställning

Identifiera något eller några centrala kundflöden.
Vad har man för krav (SLO/SLA/OLA/osv) på flödena, finns något nedskrivet, eller finns implicita förväntningar, synka så att alla har samma uppfattning om kraven.
Analysera vilka interna och externa tjänster som är inblandade.
Vilka av dessa nedströms tjänster/system måste fungera?
Vilka system ska kunna vara nere eller fungera dåligt utan påverkan för slutanvändaren?
Rita upp en karta över anropskedjan i flödet (har man redan ett vettigt APM-verktyg kan detta ritas automatiskt), eller utgå från systemskisser. (Här kommer man troligen hitta samband och beroenden som man inte visste fanns)

Spåna, sätt scenarion, vad kan gå fel?

Projicera flödeskartan på en whiteboard.
Varje deltagare sätter upp lappar eller ritar in direkt på whiteboarden vad som skulle kunna hända med olika delsystem.
Vad förväntas hända när x inträffar, hur är systemet konfigurerat att hantera olika typer av avbrott?
Här kommer man i början att hitta en mängd scenarios som man inte har planerat för eller inte vet hur dom kommer att påverka upplevelsen. (Skriv ner och red ut med relevant team, kör inte fast och försök lösa det här och nu)
Vad kommer att hända om mer än ett av felen inträffar samtidigt, finns några samband som kan ha 'additionseffekter'?
Bestäm vilka scenarios man kan testa för att verifiera i någon miljö. (en rimlig mängd)

Arkitekturdiagram från OpenTelemetry Demo

Testa!

Genomför testerna i en dedikerad PT-miljö, om man har det, eller annan produktionslik testmiljö. Har man inte det kanske i en produktionsmiljö på nattetid om man har väldigt låg förväntad last då och låga krav på tillgänglighet nattetid, då detta kan påverka stabilitet.

Exempel på fel och beteenden som kan simuleras:

Stoppa olika mikrotjänster, databaser, distribuerade caches - relativt enkelt, stoppa enstaka tjänster.
Oväntade trafikmönster, hög last, riktade attacker mot sårbara URL'er
'Slöa ner' anrop - Kanske genom att lägga in throttling eller delays i lastbalanserare eller API-gateways.
Oväntade svar, typ att den REST-tjänst helt plötsligt ger ett HTML-svar eller oväntade HTTP-felkoder.
Introducera packet-loss någonstans till interna eller externa tjänster, databaser, cache.

Se under referenser nedan för länkar till verktyg och hur man kan simulera fel.

För er som är bekanta med Chaos Engineering finns många likheter! Att kontinuerligt köra Chaos Engineering i produktion är såklart den yttersta nivån, men det kräver en väldigt hög mognadsgrad på en mängd områden innan man ens ska fundera på det. Detta arbetssätt går att genomföra genom enklare tester och att manuellt skapa fel, och kan vara ett startskott för att jobba mot att införa automatiserade kaostester framöver.

Följ upp!

Hur gick testerna?
Stämde de hypoteser man satt för respektive scenario?
Hittade man några oväntade samband?
Triggades de larm man hade förväntat sig?
Dokumentera eller uppdatera felsökningsprocessen utifrån det man upptäckt, använd tydliga dashboards och systemsambandsdiagram. (Kan man göra självdokumenterade dashboards som visar alla relevanta samband i en bild? Se kommande post om det)
Justera larmsättning vid behov.
Hur ska problem kommuniceras ut mot kund?
- Färdiga kundmeddelanden för olika scenarion, så de som jobbar med incidenten inte behöver tänka på att skriva en pedagogisk text istället för att jobba med att koordinera jobbet.

Öva!

Detta arbetssätt kan också användas för att träna felsökning. För att de som förväntas lösa problem inte ska behöva lära sig felsökningsprocess, att hitta rätt i övervakningsverktyg och lära känna de viktigaste affärsflöden man har i verksamheten mitt i natten när något gått fel! När man visat hur man kan simulera vissa typer av problem kan detta bli ett utmärkt övningsverktyg för att bygga kompetens inom området. (Läs mer om att utbilda SRE's i boken Training Site Reliability Engineers, specifikt kapitel 4 gällande "Making Training Hands-On)

Är dokumentation, larmsättning och dashboards tillräckliga för att genomföra , eller sitter för mycket kvar i folks huvuden?

Nyckelpersoner?

Har ni några nyckelpersoner som ofta genomför felsökningar, dom du alltid ringer när problem inträffar?

Ta bort de personerna som kan systemet bäst från felsökningen, dom antas vara otillgängliga, hur går det då?

Lyckas övriga teamet ändå felsöka och hitta orsak, eller i alla fall mitigera det akuta problemet och återställa tjänsten?

Vill ni veta mer?

Kontaka oss för att sätta upp en workshop och utbilda team i det som beskrivs ovan!

Referenser

Podcastavsnitt om ämnet, dom kör en liknande "Game Day" som beskrivs ca 17 minuter in, men hela avsnittet starkt!

Achieving Reliability through Chaos Engineering with Tammy Bütow

Verktyg och länkar kring att införa fel i trafik: