Oefen deze rollback-oefening om een kapotte release binnen 5 minuten te herstellen: wat je snapshot, wat je controleert en wie welke knop indrukt tijdens de oefening.
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.
“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 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.
“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:
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.
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:
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.
Je “target” moet iets zijn dat je team snel kan selecteren, zonder discussie. De meeste teams gebruiken drie veelvoorkomende targets:
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”.
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.
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.
Voor elke release moet je deze items zonder zoeken kunnen pakken:
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.
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.
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):
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:
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.
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.
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:
Start de timer. Eén persoon noemt de trigger en de beslissing: “We rollen nu terug.”
Bevries veranderingen. Pauzeer nieuwe deploys en stop niet-essentiële aanpassingen die het systeem tijdens rollback kunnen veranderen.
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.
Voer de rollback-actie exact uit zoals gedocumenteerd. Improviseer niet. Lees bevestigingsprompten hardop zodat de recorder kan vastleggen wat er gebeurde.
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:
Als de rollback langer dan 5 minuten duurt, verontschuldig dat niet. Vind de trage stap, verbeter het runbook en voer de drill opnieuw uit.
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.
Gebruik checks die je snel kunt uitvoeren met een duidelijke slag of faal:
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).
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.”
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.”
Omdat het team de drill heeft geoefend, debatteren ze niet lang. Ze bevestigen, beslissen en handelen.
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.
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.”
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.
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.
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):
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:
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.
Een rollback drill is een oefening waarin je een slechte release simuleert en een vaststaande routine volgt om de laatst bekende goede versie te herstellen.
Het doel is niet om snel te debuggen, maar om het herstellen van de dienst herhaalbaar en kalm te maken onder druk.
Gebruik een vooraf ingestelde trigger zodat je niet ter plekke hoeft te debatteren. Gangbare regels:
Als de trigger afgaat, rol dan eerst terug en onderzoek later als gebruikers veilig zijn.
Het betekent dat je gebruikers snel terug op een werkende versie kunt krijgen — ook als de nieuwe release nog steeds kapot is.
In de praktijk is “hersteld” wanneer een klein aantal signalen weer gezond oogt (kernactie werkt, error rate en latency zijn bijna normaal, geen crash loop).
Kies een doel dat je binnen seconden kunt selecteren, zonder discussie:
Definieer “vorige goede” als de meest recente release met normale monitoring en zonder actief incident — niet degene die iemand zich herinnert.
Vang minimaal het volgende voor elke release:
Database-wijzigingen zijn de gebruikelijke valkuil — een app-rollback helpt niet als het schema incompatibel is.
Noem ze zo dat ze sorteren en snel te vinden zijn, bijvoorbeeld:
prod-YYYY-MM-DD-HHMM-vX.Y.Z-commitABC123Zorg dat je omgeving + timestamp + versie + commit opneemt. Consistentie is belangrijker dan het exacte formaat.
Een eenvoudige, herhaalbare rolverdeling voor kleine teams:
Vermijd dat de Deployer ook de Verifier is tijdens drills; je wilt een onafhankelijke “werkt het echt?” check.
Hou het klein en duidelijk. Goede must-pass checks zijn onder andere:
Controleer daarna dat error rate en latency binnen een paar minuten weer normaal zijn en dat queues/jobs niet vollopen.
Maak database rollback geen onderdeel van het 5-minuten pad. Doe dit in plaats daarvan:
Zo blijft het snelle rollback-pad veilig en voorspelbaar.
Als je platform snapshots en restore in de releaseflow ondersteunt, wordt een drill makkelijker omdat “terug naar known good” gewoon een normale actie is.
Op Koder.ai specifiek, beslis van tevoren:
De drill heeft nog steeds rollen, triggers en een korte verificatielijst nodig — tools vervangen de routine niet.