DevOps Foundations · Module 8: Security and safe-change basics · Lab
Run Go/No-go and Roll Back a Bad New Version
50 min hands-on · Advanced
A small versioned service with two releases (one good, one bad) plus its indicators on a dashboard; all fixtures under /tmp/dlab-m08-03.
Two ways to do this lab: in your browser on Killercoda (free, no install), or on your own machine as a local guide. Killercoda runs one free scenario at a time: if you see a waiting queue, close other Killercoda tabs and wait a minute.
Objectives
- Run the go/no-go checklist with owners before the rollout
- Detect the bad release on indicators and call rollback by rule
- Verify traffic recovery and record the drill timings
Step 1
Decide with the checklist
Write the go/no-go (indicators, budget, rehearsed rollback, staffing, comms draft) with a name per line, run it for the new version, and record the go with any accepted risks named.
Step 2
Roll out, detect, roll back
Ship the bad version to the fixture, watch the indicators cross the rollback rule (error rate plus timebox), and roll back to the previous digest. Time every step from detection to recovery.
Step 3
Verify and record
Verify traffic recovery on the graph, confirm the old version serving, and write the drill report: detection time, rollback time, recovery proof, and what the next fix release must change.
How to confirm it worked
- Go/no-go run with owners and accepted risks recorded
- Rollback triggered by the written rule, not gut feel
- Detection-to-recovery timed with traffic recovery verified on the graph
- Drill report filed with timings and the required fix direction