Produktionen brinner vid utveckling — vad det är, orsaker och handlingsalgoritm

Vad betyder “produktionen brinner” och vilka typer av fel finns

Uttrycket “produktionen brinner” (production is on fire, everything is down) beskriver en situation där produktionsmiljön fungerar felaktigt och detta har påverkat användarna. Felet kan visa sig som fullständig otillgänglighet av appen (blank screen, 502-fel), partiell otillgänglighet (betalningsmodulen fungerar inte men andra funktioner är tillgängliga) eller prestandaförsämring (extremt långsam laddning). Incidentens severity bestäms av andelen påverkade användare och felaktighetens varaktighet.

Enligt Atlassian Statuspage (2025) var den genomsnittliga driftsstopptiden för mobilappar 2024 27 minuter per incident. De vanligaste orsakerna: kodregression efter deploy (34%), molnleverantörsavbrott (22%), databasproblem (18%), konfigurationsfel (15%) och DDoS-attacker (11%). Viktig slutsats: de flesta fel är kopplade till förändringar som teamet själv har gjort, inte till externa faktorer.

Det är viktigt att skilja mellan crash (appkrasch på klientsidan) och backend outage (serverns otillgänglighet). Crash åtgärdas vanligtvis med en hotfix av klientkoden, medan backend outage åtgärdas genom infrastrukturförändringar eller redeploy av tjänsten. Mätvärden att följa: för klienten — crash-free rate, för servern — error rate 5xx och p95 latency. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — hjälper till att snabbt fastställa felets typ.

Severity-nivåer för incidenter: P0, P1, P2 och klassificeringskriterier

Enhetlig severity-klassificering är grunden för snabb reaktion. Utan den slösar teamet tid på att diskutera “hur brådskande det är” istället för att agera. Den klassiska skalan: P0 (critical) — appen är helt otillgänglig eller användardata läcker, reaktionstid — omedelbart; P1 (high) — kritisk funktionalitet fungerar inte för 50%+ av användarna, reaktionstid — 15 minuter; P2 (medium) — icke-kritisk funktionalitet otillgänglig för en del användare, reaktionstid — 1 timme.

P0 kräver omedelbar eskalering: den jourhavande ingenjören avbryter allt pågående arbete och fokuserar på incidenten. Om problemet inte är löst efter 10 minuter — ansluter tech lead. Efter 30 minuter — eskalering till engineering manager. För P0-incidenter är det tillåtet att bryta mot alla processer: hotfix utan fullständig code review, direkt deploy till produktion, ignorera branch protection-regler. Emergency override måste vara förhandsgodkänd på teamnivå.

Severity-tabell

Det är extremt viktigt att inte göra fel i severity nedåt. P0 + P1 klassificerade som P2 leder till försenad reaktion och längre driftsstopp. Regel: om du är tveksam — sätt P0. Over-classification är bättre än under-classification: hellre kalla till ett extra möte än att förlora en timmes återhämtningstid.

Första 10 minuterna: handlingsalgoritm vid fel

Timer starts: från det ögonblick en alert eller ett meddelande från en användare kommer in. De första 10 minuterna — de viktigaste. Algoritm: 1) confirm the issue — försäkra dig om att problemet är verkligt (inte falskt larm); 2) stop the bleeding — minska omedelbart påverkan (rollback, feature toggle, blockera endpoint); 3) communicate — skriv på den allmänna kanalen #incident status: vad som hände, severity, vad som görs. De första 10 minuterna ägnas inte åt grundorsaksanalys.

Parallellt med att stoppa blödningen påbörjar en ingenjör diagnostik, den andra — kommunikation. Kommunikationskanaler: Slack #incident channel (för teamet), statussida (för användare), e-post/SMS-eskalering (för ledningen). Var 15:e minut — statusuppdatering med information: vad som är känt, vad som görs, beräknad återställningstid. Statussida (Status page) (StatuPage, Statuspal) visar drifttid och incidenthistorik för externa användare.

Hur man stoppar blödningen: rollback, feature toggle och hotfix

Den första och viktigaste regeln: försök inte åtgärda problemet i produktion. Om den nya releasen orsakade felet — rollback till föregående stabila version. Om felet orsakas av en specifik funktion som är avaktiverad via en feature toggle — stäng bara av togglen. Om varken rollback eller toggle är tillgänglig — hotfix med minimal diff. Rollback är det säkraste alternativet eftersom vi återgår till ett tillstånd som redan fungerade.

Feature toggle (även kallad feature flag) — ett kraftfullt verktyg för stop-the-bleeding utan deploy. Om betalningsmodulen har kraschat men är avaktiverad via en toggle — ser användarna helt enkelt inte betalknappen, de får ingen felbild. Toggle kräver ingen byggnad av build, ingen granskning av butik, fungerar på några sekunder. Varje kritisk funktion bör vara under en feature toggle med möjlighet att avaktivera på servernivå (remote config). Feature flag — första försvarslinjen.

Om rollback är omöjligt (till exempel på grund av en irreversibel databasmigrering) och toggle inte är tillgänglig — sista utvägen: hotfix med minimal korrigering. Hotfix skapas från den senaste release-taggen, innehåller endast de rader som behövs för att åtgärda felet och genomgår en fast-track deploy (se artikeln “Hotfix — akuta reparationer”). Golden rule: efter stabilisering, gör alltid en root cause analysis, även om orsaken verkar uppenbar.

Diagnostisering av orsaker: loggar, mätvärden och larm

Efter att ha stoppat blödningen (eller parallellt, om antalet ingenjörer tillåter) börjar diagnostiken. Den första källan — loggar. Centraliserad loggning (ELK, Grafana Loki, Datadog Logs) gör det möjligt att hitta fel baserat på tidsstämpel, användar-ID eller förfrågnings-ID. Viktigt: loggar bör vara strukturerade (JSON) så att grep fungerar snabbt. Strukturerad loggning (structured logging) är ett obligatoriskt krav för alla tjänster.

Den andra källan — mätvärden. Grafana, Datadog, New Relic visar när en topp av fel inträffade, på vilka endpoints, med vilka statuskoder. Jämförelse av mätvärden före och efter deploy hjälper till att lokalisera problemet till en specifik tjänst eller endpoint. RED-metrik (Rate, Errors, Duration) är standarden för övervakning av mikrotjänster.

Den tredje källan — distributed tracing. Jaeger, Zipkin, Datadog APM visar vägen för en förfrågan genom mikrotjänster och identifierar exakt var förseningen eller felet uppstod. Tracing är särskilt användbart vid kaskadfel, när ett fel i en tjänst orsakar fel i alla beroende tjänster. Trace ID måste vidarebefordras från klienten till alla backend-tjänster.

# Snabbt diagnosexempel med kubectl och loggar
# Lista poddar med fel
kubectl get pods --field-selector=status.phase!=Running

# Kontrollera loggar för kraschad pod
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Sök efter fel i tjänsten under de senaste 30 minuterna
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Viktigt: försök inte diagnostisera orsaken innan du stoppar blödningen. Om 50% av användarna ser en krasch — först rollback, sedan analys. Undantag: om rollback skulle ta längre tid än en direkt hotfix (till exempel vid datainkompatibilitet). I detta fall tillämpas hotfix omedelbart och post-mortem genomförs efter stabilisering. Diagnosis before fix — ett farligt mönster som ökar driftsstopptiden.

Post-mortem: hur man analyserar incidenter utan att söka syndabockar

Post-mortem (även kallad incident review) — en strukturerad analys av incidenten som genomförs 24-72 timmar efter att den lösts. Mål: förstå varför felet inträffade, varför övervakning och tester inte fångade det före produktion, och vad som ska ändras i processerna för att förhindra upprepning. Blameless culture — den grundläggande principen: post-mortem diskuterar processer, verktyg och kommunikation, inte enskilda personers misstag.

Struktur för post-mortem-dokument: timeline (tidslinje över händelser med tidsstämplar), impact (påverkade användare, varaktighet, ekonomiska förluster), root cause (teknisk grundorsak), detection (hur upptäcktes, varför fångades det inte tidigare), response (vad gjordes, vad kunde ha gjorts snabbare), action items (konkreta uppgifter med ansvariga och deadlines). Action items bör vara S.M.A.R.T.: specific, measurable, assignable, realistic, time-bound.

Typiska action items efter ett produktionsfel: lägg till övervakning och larm för ett mätvärde som var tyst; utöka testtäckningen för det missade fallet; lägg till en sida i runbooken med steg-för-steg-algoritm för en liknande situation; genomför en teamutbildning om verktyget som användes felaktigt. Varje action item är en konkret förändring som minskar sannolikheten för att incidenten upprepas.