Den dolda kostnaden av att vara oförberedd

Klockan är två på natten. Dashboarden lyser rött. En tjänst krånglar och kunderna märker det direkt. Teamet är utspritt.

De flesta utvecklare har varit med om den där känslan när produktionen går sönder och alla plötsligt ska lösa problem de inte tränat för. Skillnaden mellan att fixa felet på fem minuter eller på två timmar handlar oftast inte om teknisk kompetens. Den handlar om att ha gjort det förut.

Varför incidenthantering är viktigare än man tror

Riktiga incidenter bryr sig inte om hur duktig du är. De bryr sig om hur redo du är.

Under stress krymper perspektivet. Man missar saker man annars skulle se. Det är därför piloter övar i simulatorer och idrottare repeterar samma moment tills det sitter i ryggmärgen. Samma princip gäller för drift och utveckling.

Gör övningarna till något man faktiskt vill göra

Tänk om felsökning kunde vara både utmanande och rolig? Istället för att bara vänta på nästa incident kan man skapa kontrollerade övningar som efterliknar verkligheten.

Bra incidentövningar har några gemensamma drag:

• Verklighetsnära problem: Minnesläckor, timeout mot databasen, DNS-problem, SSL-certifikat som gått ut eller kedjereaktioner mellan microservices.
• Tidsbegränsning: Att ha en klocka som tickar skapar samma press som vid en riktig incident, fast utan konsekvenserna.
• Tävlingselement: En enkel leaderboard gör att folk engagerar sig mer. De vill både lösa problemet och se hur de ligger till jämfört med kollegorna.
• Regelbundenhet: Till skillnad från riktiga incidenter kan övningarna köras varannan vecka.

Vad teamet faktiskt får ut av det

När man kör regelbundna incidentövningar händer flera saker samtidigt:

• Snabbare återhämtning vid riktiga incidenter
• Bättre samarbete istället för att en person ska rädda allt
• Juniora utvecklare lär sig direkt från de mer erfarna
• Verktygen för loggning och monitorering blir naturliga att använda
• Alla får en grundtrygghet i att de har sett liknande problem förut

Så kommer du igång

Du behöver inte en dyr plattform. Börja enkelt.

1. Samla de problem ni haft tidigare. Vad har faktiskt stört er drift?
2. Skapa scenarier som speglar de incidenterna i en staging-miljö.
3. Bestäm vad varje övning ska lära ut.
4. Sätt en tydlig tidsram.
5. Avsluta alltid med en genomgång av vad som hände och varför.

Kopplingen till hur ni bygger system

Team som övar regelbundet tenderar också att fatta bättre beslut redan vid utveckling. De frågar sig oftare hur man ska upptäcka problem tidigt, vad som behöver monitoreras och hur snabbt man kan rulla tillbaka en ändring.

Det är inte en slump. När felsökning blir en naturlig del av vardagen påverkar det hur man designar system från början.

Kontinuitet är nyckeln

Det räcker inte att göra en övning då och då. Ju oftare ni övar, desto säkrare blir hanteringen när det verkligen gäller.

På NameOcean ser vi det här hos kunder som kör domäner, DNS och SSL i produktion. De som har byggt upp en vana av att öva hanterar riktiga incidenter med betydligt större lugn.

Kom igång idag

Välj ett scenario. Bjud in teamet. Starta timern. Se vad som händer.

Nästa gång produktionen faktiskt krånglar kommer ni inte stå och gissa. Ni kommer att veta vad ni ska göra.