Productie staat in brand bij ontwikkeling — wat het is, oorzaken en handelingsalgoritme

Wat betekent „productie staat in brand” en welke storingen zijn er

De uitdrukking „productie staat in brand” (production is on fire, everything is down) beschrijft een situatie waarin de productieomgeving niet correct werkt en dit gevolgen heeft voor gebruikers. De storing kan zich uiten als volledige onbereikbaarheid van de app (blank screen, 502-fout), gedeeltelijke onbereikbaarheid (de betalingsmodule werkt niet, maar andere functies zijn beschikbaar) of prestatievermindering (extreem lang laden). De severity van het incident wordt bepaald door het percentage getroffen gebruikers en de duur van de storing.

Volgens Atlassian Statuspage (2025) bedroeg de gemiddelde downtime voor mobiele apps in 2024 27 minuten per incident. De meest voorkomende oorzaken: coderegressie na deploy (34%), uitval van cloudprovider (22%), databaseproblemen (18%), configuratiefouten (15%) en DDoS-aanvallen (11%). Belangrijkste conclusie: de meeste storingen houden verband met wijzigingen die het team zelf heeft aangebracht, niet met externe factoren.

Het is belangrijk onderscheid te maken tussen crash (app valt aan clientzijde) en backend outage (server onbereikbaar). Crash wordt meestal verholpen met een hotfix van de clientcode, backend outage door infrastructuurwijzigingen of redeploy van de service. Te volgen metrics: voor de client — crash-free rate, voor de server — error rate 5xx en p95 latency. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — helpt snel het type storing te bepalen.

Severity-niveaus van incidenten: P0, P1, P2 en classificatiecriteria

Eenduidige severity-classificatie is de basis van snelle reactie. Zonder classificatie verspilt het team tijd aan discussie over „hoe urgent is dit” in plaats van te handelen. De klassieke schaal: P0 (critical) — app volledig onbereikbaar of gebruikersgegevens lekken, reactietijd — onmiddellijk; P1 (high) — kritieke functionaliteit werkt niet voor 50%+ gebruikers, reactietijd — 15 minuten; P2 (medium) — niet-kritieke functionaliteit onbereikbaar voor een deel van de gebruikers, reactietijd — 1 uur.

P0 vereist onmiddellijke escalatie: de dienstdoende ingenieur onderbreekt al het lopende werk en schakelt over op het incident. Als het probleem na 10 minuten niet is opgelost — wordt de tech lead ingeschakeld. Na 30 minuten — escalatie naar de engineering manager. Voor P0-incidenten is het toegestaan om alle processen te overtreden: hotfix zonder volledige code review, direct deployen naar productie, branch protection-regels negeren. Emergency override moet van tevoren op teamniveau zijn afgestemd.

Severity-tabel

Het is uiterst belangrijk om severity niet naar beneden te vergissen. P0 + P1 geclassificeerd als P2 leiden tot vertraagde reactie en langere downtime. Regel: bij twijfel — kies P0. Over-classification is beter dan under-classification: liever een extra vergadering dan een uur hersteltijd verliezen.

Eerste 10 minuten: handelingsalgoritme bij een storing

Timer starts: vanaf het moment dat er een alert of een bericht van een gebruiker binnenkomt. De eerste 10 minuten zijn het belangrijkst. Algoritme: 1) confirm the issue — zorg dat het probleem echt is (geen vals alarm); 2) stop the bleeding — verminder onmiddellijk de impact (rollback, feature toggle, endpoint blokkeren); 3) communicate — schrijf op het algemene kanaal #incident de status: wat er is gebeurd, severity, wat er wordt gedaan. De eerste 10 minuten worden niet besteed aan analyse van de hoofdoorzaak.

Parallel aan het stoppen van het bloeden begint één ingenieur met de diagnose, een tweede met de communicatie. Communicatiekanalen: Slack #incident channel (voor het team), statuspagina (voor gebruikers), e-mail/SMS-escalatie (voor management). Elke 15 minuten — statusupdate met informatie: wat bekend is, wat er wordt gedaan, geschatte hersteltijd. Status page (StatuPage, Statuspal) toont uptime en incidentgeschiedenis voor externe gebruikers.

Hoe het bloeden te stoppen: rollback, feature toggle en hotfix

De eerste en belangrijkste regel: probeer het probleem niet op productie op te lossen. Als de nieuwe release de storing heeft veroorzaakt — rollback naar de vorige stabiele versie. Als de storing wordt veroorzaakt door een specifieke functie die is uitgeschakeld via een feature toggle — schakel de toggle gewoon uit. Als noch rollback noch toggle beschikbaar is — hotfix met minimale diff. Rollback — de veiligste optie, omdat we terugkeren naar een toestand die al werkte.

Feature toggle (aka feature flag) — een krachtig hulpmiddel voor stop-the-bleeding zonder deploy. Als de betalingsmodule is gecrasht maar is uitgeschakeld via een toggle — zien gebruikers simpelweg de betaalknop niet, geen foutscherm. Toggle vereist geen build, geen review van de store, werkt binnen enkele seconden. Elke kritieke functie moet onder een feature toggle vallen met uitschakelmogelijkheid op serverniveau (remote config). Feature flag — de eerste verdedigingslinie.

Als rollback onmogelijk is (bijvoorbeeld vanwege een onomkeerbare DB-migratie) en toggle niet is voorzien — het laatste middel: hotfix met minimale correctie. Hotfix wordt gemaakt vanaf de laatste releasetag, bevat alleen de regels die nodig zijn om de storing te verhelpen en doorloopt een fast-track deploy (zie artikel „Hotfix — spoedreparaties”). Golden rule: doe na stabilisatie altijd een root cause analysis, zelfs als de oorzaak voor de hand lijkt te liggen.

Diagnose van oorzaken: logs, metrics en alarmen

Na het stoppen van het bloeden (of parallel, als het aantal ingenieurs dit toelaat) begint de diagnose. De eerste bron — logs. Gecentraliseerde logboekregistratie (ELK, Grafana Loki, Datadog Logs) maakt het mogelijk fouten te vinden op timestamp, gebruikers-ID of request-ID. Belangrijk: logs moeten gestructureerd zijn (JSON) zodat grep snel werkt. Structured logging — een verplichte vereiste voor alle services.

De tweede bron — metrics. Grafana, Datadog, New Relic tonen wanneer er een piek in fouten was, op welke endpoints, met welke statuscodes. Vergelijking van metrics voor en na deploy helpt het probleem te lokaliseren tot een specifieke service of endpoint. RED metrics (Rate, Errors, Duration) — de monitoringsstandaard voor microservices.

De derde bron — distributed tracing. Jaeger, Zipkin, Datadog APM tonen het pad van een request door microservices en identificeren waar precies de vertraging of fout optrad. Tracing is vooral nuttig bij cascade-storingen, wanneer een fout in één service fouten veroorzaakt in alle afhankelijke services. Trace ID moet worden doorgegeven van de client naar alle backend-services.

# Snel diagnosest voorbeeld met kubectl en logs
# Toon pods met fouten
kubectl get pods --field-selector=status.phase!=Running

# Controleer logs van gecrashte pod
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Zoek fouten in service van de afgelopen 30 minuten
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Belangrijk: probeer de oorzaak niet te diagnosticeren voordat het bloeden is gestopt. Als 50% van de gebruikers een crash ziet — eerst rollback, dan analyse. Uitzondering: als rollback langer zou duren dan een directe hotfix (bijvoorbeeld bij dataincompatibiliteit). In dat geval wordt hotfix onmiddellijk toegepast en wordt post-mortem na stabilisatie uitgevoerd. Diagnosis before fix — een gevaarlijk patroon dat de downtime verlengt.

Post-mortem: hoe incidenten te analyseren zonder schuldigen te zoeken

Post-mortem (ook wel incident review genoemd) — een gestructureerde analyse van het incident die 24-72 uur na de oplossing wordt uitgevoerd. Doel: begrijpen waarom de storing heeft plaatsgevonden, waarom monitoring en tests het niet vóór productie hebben opgemerkt en wat er in processen moet veranderen om herhaling te voorkomen. Blameless culture — het fundamentele principe: post-mortem bespreekt processen, tools en communicatie, niet de fouten van specifieke personen.

Structuur van het post-mortemdocument: timeline (chronologie van gebeurtenissen met timestamps), impact (getroffen gebruikers, duur, financiële verliezen), root cause (technische hoofdoorzaak), detection (hoe ontdekt, waarom niet eerder opgemerkt), response (wat is gedaan, wat had sneller gekund), action items (concrete taken met verantwoordelijken en deadlines). Action items moeten S.M.A.R.T. zijn: specific, measurable, assignable, realistic, time-bound.

Typische action items na een productiestoring: monitoring en alert toevoegen voor een metriek die stil was; testdekking uitbreiden voor de gemiste case; een pagina toevoegen aan de runbook met een stapsgewijs algoritme voor een vergelijkbare situatie; een teamtraining geven over het instrument dat verkeerd werd gebruikt. Elk action item is een concrete verandering die de kans op herhaling van het incident verkleint.