Rollback-oefening playbook: herstel een kapotte release in 5 minuten

Waarom rollbacks eng voelen (en waarom oefening helpt)

Een release kan er in testing goed uitzien en dan binnen de eerste vijf minuten van echt verkeer kapot gaan. Het enge deel is meestal niet de bug zelf. Het is de onzekerheid: wat veranderde, wat kun je veilig terugdraaien, en of een rollback het erger maakt.

Direct na een release zijn fouten vaak simpel en pijnlijk zichtbaar. Een nieuwe knop kan de pagina op mobiel laten crashen. Een backend-wijziging kan de verkeerde datastructuur teruggeven, waardoor checkout faalt. Een kleine config-aanpassing kan login, e-mails of betalingen breken. Zelfs als de oplossing makkelijk is, loopt de druk op omdat gebruikers meekijken en elke minuut duur voelt.

Paniek begint als het rollback-pad onduidelijk is. Mensen stellen tegelijkertijd dezelfde vragen: hebben we een snapshot? Welke versie was als laatste goed? Als we de app terugrollen, wat doen we dan met de database? Wie heeft toegang om het te doen? Als die antwoorden niet opgeschreven zijn, verliest het team tijd met discussiëren in plaats van de dienst herstellen.

Gissen tijdens een incident kost echt tijd. Je verliest minuten, gebruikers verliezen vertrouwen en gehaaste wijzigingen kunnen bovenop de eerste storing een tweede storing veroorzaken. Engineers worden ook in te veel richtingen tegelijk getrokken: debuggen, berichten sturen en beslissingen nemen.

Een oefenronde verandert de sfeer omdat die onzekerheid vervangt door spierherinnering. Een goede rollback-oefening is niet alleen “kunnen we code terugzetten.” Het is een herhaalbare routine: wat je snapshot, wat je herstelt, wat je verifieert en wie mag handelen. Na een paar drills voelt rollback niet meer als falen maar als een veiligheidsinstrument.

Als je deployment-setup al snapshots en restore ondersteunt (enkele platforms, waaronder Koder.ai, bouwen dit in de releaseflow), worden drills makkelijker omdat “terug naar known good” een normale actie is, geen aparte noodprocedure. Het doel blijft hetzelfde: als het moment daar is, mag niemand improviseren.

Wat “herstel in 5 minuten” werkelijk betekent

“Herstel in 5 minuten” betekent niet dat alles meteen perfect is. Het betekent dat je gebruikers snel terug naar een werkende versie kunt krijgen, ook als de nieuwe release nog kapot is.

Service eerst, fixes later. Als je snel service herstelt, koop je rust om de echte bug te vinden.

De 5 minuten zijn voor actie, niet debat

De klok loopt vanaf het moment dat je het eens bent: “We rollen terug.” Het omvat geen lange discussie over of het misschien vanzelf herstelt.

Bepaal je rollback-trigger van tevoren. Bijvoorbeeld: “Als checkout-fouten boven X% blijven voor 3 minuten na deploy, rollen we terug.” Als de trigger afgaat, volg je het script.

Wat telt als “hersteld”?

“Hersteld” moet een kleine set signalen zijn die vertellen dat gebruikers veilig zijn en het systeem stabiel is. Houd het strak en makkelijk te controleren:

• De belangrijkste gebruikersactie werkt weer (login, checkout, zoeken of dat ene ding dat je app moet doen)
• Error rate keert terug naar bijna normaal
• Latency komt terug in een acceptabel bereik
• Geen crash loop of restart-storm

Als die signalen goed lijken, stop je de 5-minuten timer. Alles anders kan wachten.

Om de oefening eerlijk te houden, markeer expliciet wat je tijdens het 5-minuten pad niet doet: diep debuggen, codewijzigingen of hotfix-releases en alles dat verandert in regulier engineeringwerk.

Kies een rollback-benadering die je team kan herhalen

Een rollback voelt alleen snel als de beslissing grotendeels vooraf gemaakt is. Kies één aanpak die voor de meeste incidenten werkt en oefen die tot het saai is.

Je drill moet vier vragen beantwoorden:

• Rollen we terug of doen we een hotfix?
• Waar rollen we naar terug?
• Wat triggert de rollback?
• Wie heeft de autoriteit om te zeggen “doen”?

Rollback vs hotfix: kies de standaard

Rollback is het beste als de nieuwe release gebruikers of data actief schaadt en je al een bekende goede versie hebt om naartoe terug te keren. Een hotfix is beter wanneer de impact klein is, de verandering geïsoleerd en je er vertrouwen in hebt dat je veilig kunt patchen.

Een simpele standaard werkt goed: als gebruikers de belangrijkste actie niet kunnen voltooien (checkout, login, signup) of de error rates pieken, rol dan eerst terug en fix daarna. Bewaar hotfixes voor irritaties die niet gevaarlijk zijn.

Kies het rollback-doel

Je “target” moet iets zijn dat je team snel kan selecteren, zonder discussie. De meeste teams gebruiken drie veelvoorkomende targets:

• De vorige versie (laatste release die checks doorstond)
• Een deployment-snapshot die je kunt herstellen
• Een config-only rollback (feature flag of omgevingswijziging)

Als je betrouwbare deployment-snapshots hebt, maak dat de standaard omdat het het meest herhaalbaar is onder druk. Houd config-only rollback als een aparte route voor gevallen waarin de code goed is maar een instelling fout.

Definieer ook wat “vorige goed” is. Dat moet de meest recente release zijn die monitoringchecks doorstond en geen actief incident had — niet “de versie die iemand zich herinnert”.

Definieer trigger en autoriteit

Wacht niet op een vergadering tijdens een incident. Schrijf de triggers op die een rollback starten en houd je eraan. Typische triggers zijn een kapotte hoofdflow voor meer dan een paar minuten, error rate of latency voorbij afgesproken drempels, datarisico (foute writes, dubbele charges) en elke security/privacy zorg door de release.

Bepaal daarna wie de rollback kan goedkeuren. Kies één rol (incident lead of on-call), plus een backup. Iedereen mag adviseren, maar niet blokkeren. Als de trigger afgaat en de goedkeurder zegt “rollback”, draait het team elke keer dezelfde stappen.

Wat je moet snapshotten vóór elke release

Een rollback-oefening werkt alleen als je snel naar een bekende goede staat kunt terugkeren. Snapshots zijn niet alleen “nice to have.” Ze zijn het bewijs van wat draaide, wat veranderde en hoe je terugkomt.

De vijf dingen om vast te leggen

Voor elke release moet je deze items zonder zoeken kunnen pakken:

• De exacte app-build die je uitrolde: commit-hash, versienummer en het build-artifact (container tag, bundle of package).
• Databasestatus en migratieplan: welke migraties zijn toegepast en of ze omkeerbaar zijn. Voor risicovolle wijzigingen maak een backup of snapshot die je snel kunt herstellen.
• Configuratie bij deploy-tijd: feature flags, omgevingsvariabelen, third-party endpoints en wat veranderde. Secrets horen in een beveiligd systeem, maar je hebt nog steeds een versiegeschiedenis nodig.
• Infrastructuur- en routing-instellingen: domeinen, certificaten, load balancer regels en alle switches die bepalen waar verkeer naartoe gaat.
• Een korte releasenote: één zin over wat er veranderde en één zin over hoe je een succesvolle rollback verifieert.

Databaseveiligheid is de gebruikelijke valkuil. Een snelle app-rollback helpt niet als de database nu een nieuw schema verwacht. Voor risicovolle migraties plan een twee-staps release (voeg eerst velden toe, ga ze later gebruiken) zodat rollback mogelijk blijft.

Noem snapshots zodat je ze in seconden vindt

Gebruik één naamgevingsregel overal en maak hem sorteerbaar:

prod-2026-01-09-1420-v1.8.3-commitA1B2C3

Neem omgeving, timestamp, versie en commit op. Als je tools snapshots in een UI ondersteunen, gebruik daar dezelfde naamgevingsregel zodat iedereen snel het juiste restore-punt kan vinden tijdens een incident.

Rollen: wie klikt wat (en wie kijkt alleen toe)

Een rollback-oefening gaat sneller en rustiger als iedereen zijn taak kent. Het doel is niet “iedereen springt erin.” Het is één persoon die beslissingen neemt, één persoon die de actie uitvoert, één persoon die bevestigt dat het werkte en één persoon die anderen informeert.

Voor kleine en middelgrote teams werken deze rollen goed (iemand kan twee petten dragen, maar vermijd het combineren van Deployer en Verifier tijdens de drill):

• Incident lead (tijdsbewaker en besluitnemer): stelt het succesdoel en roept de rollback uit.
• Deployer (hands on keyboard): voert de rollback-stappen exact uit en vertelt hardop wat hij doet.
• Verifier (bewijs dat het werkt): draait de must-pass checks en kijkt naar de sleutel-signalen.
• Communicator (één stem extern): plaatst korte, regelmatige updates aan stakeholders en support.

Permissies bepalen of dit plan echt uitvoerbaar is of slechts een mooi document. Spreek vóór de drill af wie toestemming heeft om productie terug te rollen en hoe noodgevallen werken.

Een simpele inrichting:

• Geef de Deployer rollback-rechten tijdens on-call of geplande drill-vensters.
• Laat de Incident lead de actie goedkeuren (ook als die persoon zelf geen knop heeft).
• Zorg dat de Verifier read-only toegang heeft tot dashboards en logs.
• Stel een break-glass optie in (geaudit, tijdsbeperkte toegang).
• Test toegang tijdens drill-opzet, niet tijdens de 5-minuten timer.

Als je een platform gebruikt dat snapshots en rollback ondersteunt (inclusief Koder.ai), bepaal dan wie snapshots mag maken, wie ze mag herstellen en waar die actie wordt vastgelegd.

Stap voor stap: de rollback drill runbook

Een rollback-oefening werkt het best als het voelt als een brandalarm-oefening: dezelfde stappen, dezelfde woorden, dezelfde plekken om te klikken. Het doel is niet perfectie, maar dat iemand on-call snel de laatste bekende goede versie kan herstellen zonder opties te beargumenteren.

Voordat je begint

Kies één duidelijke trigger en spreek die uit wanneer de drill begint. Voorbeelden: “Checkout geeft 500 voor meer dan 1 minuut” of “Error rate is 5x normaal direct na deploy.” Dat hardop uitspreken voorkomt dat het team afdwaalt naar troubleshooting.

Houd een korte voorbereidingschecklist naast het runbook:

• Bevestig dat je live health-signalen ziet (uptime, error rate, kernflow)
• Bevestig de laatste bekende goede versie-identifier (tag, build, snapshotnaam)
• Bevestig waar rollbacks worden uitgevoerd (CI/CD, hosting console, platform UI)
• Bevestig hoe je nieuwe deploys pauzeert
• Bevestig wie timestamps vastlegt

Het 5-minuten runbook

1. Start de timer. Eén persoon noemt de trigger en de beslissing: “We rollen nu terug.”

2. Bevries veranderingen. Pauzeer nieuwe deploys en stop niet-essentiële aanpassingen die het systeem tijdens rollback kunnen veranderen.

3. Maak een laatste-kans snapshot (alleen als het veilig en snel kan). Dit beschermt je voor het geval je de kapotte staat later moet nabootsen. Geef het een duidelijke naam en ga door.

4. Voer de rollback-actie exact uit zoals gedocumenteerd. Improviseer niet. Lees bevestigingsprompten hardop zodat de recorder kan vastleggen wat er gebeurde.

5. Bevestig dat de rollback op één vertrouwde plek voltooid is. Gebruik elke keer één scherm en één signaal (deployment history view, “current version” label of een duidelijk statusindicator).

Vang direct na de actie vast wat telt terwijl het vers in gedachten is:

• Tijd van besluit (trigger uitgesproken)
• Starttijd rollback (eerste klik/commando)
• Voltooiingstijd rollback (vorige versie actief)
• Eerste groene verificatietijd (kerncheck slaagt)
• Eventuele verrassingen (ontbrekende permissie, onduidelijke knop, trage stap)

Als de rollback langer dan 5 minuten duurt, verontschuldig dat niet. Vind de trage stap, verbeter het runbook en voer de drill opnieuw uit.

Wat je verifieert na de rollback

Een rollback “werkt” alleen als gebruikers het als werkend ervaren. Je probeert niet alleen te bewijzen dat de oude versie is uitgerold; je bewijst dat de dienst weer bruikbaar en stabiel is.

Houd verificatie klein en herhaalbaar. Als de lijst langer is dan vijf, slaan mensen stappen over onder stress.

De 3–5 must-pass checks

Gebruik checks die je snel kunt uitvoeren met een duidelijke slag of faal:

• Gebruiker kan inloggen (of zich aanmelden) en de startpagina bereiken zonder fouten
• De kerntransactie werkt (checkout, booking, formulier verzenden)
• Eén sleutel-API endpoint geeft 200 en de response ziet er normaal uit
• Admin/support kan één kritieke actie uitvoeren (refund, annuleren, status updaten)
• Eén edge-flow die vaak faalt (wachtwoord reset, file upload, zoeken) werkt nog steeds

Na functionele checks kijk je kort naar het eenvoudigste systeemgezondheidsignaal dat je vertrouwt. Je wilt zien dat error rate daalt en latency binnen een paar minuten stopt met pieken.

Bevestig ook dat de minder zichtbare onderdelen weer draaien. Background jobs moeten verwerken en queues moeten leeglopen, niet groeien. Database-checks horen snel en saai te zijn: verbindingen stabiel, geen duidelijke lock-opbouw, en de app kan schrijven.

Test ten slotte de buitenwereld waar het telt. Als het veilig kan, voer een betaaltest uit, controleer dat e-mails niet bouncen en zorg dat webhooks geaccepteerd worden (of in ieder geval niet falen).

Bepaal de “all clear” formulering

Schrijf één zin vooraf zodat niemand improviseert:

“Rollback voltooid. Kernflows geverifieerd (login + checkout). Error rate en latency terug naar normaal. Monitoren voor 30 minuten. Volgende update om 14:30.”

Voorbeeld: een kapotte release en een nette 5-minuten restore

Het is 10:02 op dinsdag. Een nieuwe release gaat uit en binnen een minuut kunnen een deel van de gebruikers niet inloggen. Sommigen krijgen “invalid session”, anderen zien een spinner die nooit stopt. Registraties werken nog, dus het probleem is in het begin makkelijk te missen.

Het eerste signaal is zelden een dramatische outage. Het is een stille piek: supporttickets, een dip in succesvolle logins en een paar boze berichten van echte gebruikers. On-call ziet een alert: “login success rate down 18% in 5 minutes” en support meldt: “3 gebruikers kunnen na de update niet inloggen.”

De 5-minuten restore (hoe het eruit kan zien)

Omdat het team de drill heeft geoefend, debatteren ze niet lang. Ze bevestigen, beslissen en handelen.

• 10:03: On-call bevestigt en wijst een incident lead aan.
• 10:04: Besluit om terug te rollen. Regel: als login kapot is en er geen veilige fix is binnen 2 minuten, dan rollback.
• 10:05: Deployer triggert rollback naar de vorige bekende goede snapshot.
• 10:06: Verkeer gaat terug naar de vorige versie. Het team test login opnieuw op web en mobiel.
• 10:07: Incident lead meldt “Login hersteld, monitoren voor 10 minuten” en vraagt support om getroffen gebruikers te informeren.

Wat teruggerold wordt: applicatiecode en config voor web- en API-services. Wat blijft: database en gebruikersdata.

Als de release een databasemigratie bevatte, is de drill-regel simpel: rol de database nooit terug in het 5-minuten pad. Houd migraties backward compatible of stop en vraag een second opinion voor je deployt.

Wat gecommuniceerd wordt (tijdens en na)

Tijdens rollback plaatst de incident lead korte updates elke paar minuten: wat gebruikers zien, welke actie plaatsvindt en wanneer de volgende update komt. Voorbeeld: “We rollen de laatste release terug om login te herstellen. Volgende update over 2 minuten.”

Na rollback sluiten ze de lus: “Login is weer normaal. Root cause review loopt. We delen wat er gebeurde en wat we veranderen om herhaling te voorkomen.”

Veelgemaakte rollback-drill fouten (en simpele oplossingen)

Een rollback-oefening zou saai moeten voelen. Als het stressvol aanvoelt, onthult de drill waarschijnlijk echte tekortkomingen: toegang, ontbrekende snapshots of stappen die alleen in iemands hoofd bestaan.

Fouten die minuten kosten

• Je oefent met veronderstelde toegang, niet echte permissies. Mensen ontdekken midden in het incident dat ze niet kunnen deployen, config niet kunnen veranderen of dashboards niet kunnen bereiken. Oplossing: voer de drill uit met dezelfde accounts en rollen die je tijdens een incident zou gebruiken.

• Snapshots bestaan, maar zijn incompleet of moeilijk te vinden. Teams snapshotten de app maar vergeten env-wijzigingen, feature flags of routing. Of de snapshotnaam zegt niets. Oplossing: maak snapshot-creation een releasestap met een naamregel en verifieer tijdens drills dat de snapshot zichtbaar en snel restorebaar is.

• Databasemigraties maken rollback onveilig. Een backwards-incompatibele schemawijziging verandert een snelle rollback in een dataprobleem. Oplossing: geef de voorkeur aan additieve migraties. Als een breaking change onvermijdelijk is, plan een forward fix en label de release duidelijk: “rollback allowed: yes/no.”

• Je roept succes zonder te checken wat gebruikers voelen. De app staat live, maar login blijft kapot of jobs zitten vast. Oplossing: houd verificatie kort maar echt, en timebox het.

• De drill is te complex om te herhalen. Te veel tools, te veel checks, te veel stemmen. Oplossing: krimp de drill tot één pagina en één eigenaar. Als het niet kan vanuit één runbook en één communicatiekanaal, gebeurt het niet onder druk.

Een goede rollback-oefening is een gewoonte, geen heroïsche prestatie. Als je niet rustig kunt afronden, verwijder dan stappen tot het wel kan en voeg alleen toe wat echt risico verlaagt.

Korte checklist en volgende stappen

Een rollback-oefening werkt het best als iedereen dezelfde één-pagina checklist volgt. Houd het vastgezet waar je team het ook echt bekijkt.

Een compacte versie die je in minder dan 10 minuten kunt draaien (inclusief setup en verificatie):

• Voor release: bevestig rollback-punt (snapshot/version), noteer verwacht “goed” gedrag, wijs rollen toe (deployer, verifier, comms).
• Trigger: verklaar “rollback start”, start timer, bevries nieuwe deploys.
• Rollback-actie: herstel de laatst bekende goede release, leg vast wat er geklikt is en in welke volgorde.
• Verifieer: voer 2–3 kritieke checks uit (login, hoofdworkflow, één integratie of API-check), bevestig dat error rates dalen.
• Afronden: verklaar “dienst stabiel”, schrijf drie notities (wat werkte, wat vertraagde, wat te veranderen), maak deploys weer mogelijk.

Voer drills vaak genoeg uit zodat de stappen normaal voelen. Maandelijks is een goed startpunt. Als je product dagelijks verandert, doe het tweewekelijks, maar houd verificatie gefocust op het belangrijkste gebruikerspad.

Werk het runbook na elke drill dezelfde dag bij zolang het vers is. Bewaar het met releasenotes en voeg een gedateerde “last tested” regel toe zodat niemand blind vertrouwt op een verouderde procedure.

Meet alleen wat helpt verbeteren:

• Time-to-rollback (besluit tot herstel)
• Time-to-verify (hersteld tot stabiel)
• Rolhelderheid (waar aarzelden mensen of dupliceerden werk?)
• Ontbrekende info (credentials, permissies, snapshot-locatie)

Als je team Koder.ai gebruikt, behandel snapshots en rollback als onderdeel van de gewoonte: noem snapshots consistent, oefen restores in dezelfde interface die je tijdens on-call gebruikt en voeg snelle custom-domain en integratiechecks toe aan de verifier-stappen. Dat noemen in het runbook houdt de drill in lijn met hoe je werkelijk shipped.